Firefox не поддерживает аутентифицированное шифрование совместно с традиционным DHE, только Chrome и IE, а у них в плане HTTPS есть проблемы серьёзнее, так что от отказа от ECC особого эффекта не вижу, мне эта идея кажется сомнительной.
Сервер не поддерживает возобновление подключения TLS (стандарт RFC 5746) и нетолерантен к TLS 1.2, то есть обрывает соединение в случае его анонсирования в ClientHello. Сервер отправляет TCP Reset, и браузеру приходится отправлять новый ClientHello с анонсированием TLS 1.1 максимум (причём самым первым набором шифра будет TLS_FALLBACK_SCSV 0x5600, предупреждение о возможной атаке на понижение протокола), и только после этого сервер отправляет ServerHello и объявляет об использовании TLS 1.0, а у этого протокола уже есть известные уязвимости.
Но этого ещё не всё. Сервер поддерживает только шифр RC4, использование которого запрещено стандартом RFC 7465. Firefox уже сейчас не объявляет поддержку RC4 в первом сообщении ClientHello, только при следующих попытках.
Скоро выйдет Firefox 37, где такое поведение будет разрешено только при посещении сайтов из специального белого списка, иначе никакого подключения.
Пытался как-то вечером открыть картой дверь в Сбер, а оказалось, что она и так открыта, просто нужно было сильнее дёрнуть, заедает. Комментарий ранее пытавшегося: «А, это как у меня в подъезде».
www.ssllabs.com/ssltest/analyze.html?d=online.openbank.ru
«Открытие» до сих пор поддерживает SSL 3, использует слабые параметры Диффи-Хеллмана, имеет сертификат уровня Domain Validation (в субъекте даже организация не указана), а на главной странице онлайн-банкинга подгружает шрифт по HTTP. О, даже nginx старой версии палится.
Пока у банков такой HTTPS, к чему этот театр безопасности? Quis custodiet ipsos custodes? Я бы на месте ЦБ без рейтинга A+ на SSL Labs вообще лицензии лишал, а они всякой хренью занимаются.
Есть ещё такой момент: возможность посещения сайта такими клиентами зависит от сертификата и конфигурации дефолтного HTTPS-хоста. Даже если SNI-хост поддерживает только самые современные протоколы и шифры, старые клиенты без поддержки SNI могут посещать ваш сайт в случае наличия общих алгоритмов с дефолтным хостом. В таком случае сначала клиенты получают ошибку несовпадения адреса сервера (чужой сертификат), в случае игнорирования сайт открывается, но сединение аутентифицировано и зашифровано сертификатом и настройками дефолтного хоста, а не вашего. Видите проблему безопасности?
Такая проблема возможна и с современными браузерами, особенно Internet Explorer, где поддерживаемые протоколы SSL/TLS переключаются проще всего. Речь идёт о поддержке браузером SSL 2. Это вынуждает браузер отправлять сообщение ClientHello в соответствующем формате, который не поддерживает расширения, включая SNI. Таким образом, в случае включённого SSL 2 посетитель так же получит ошибку несовпадения адреса и шифрование соединения чужим ключом. Так может продолжаться до бесконечности. Вместо чужого сертификата сервер должен сразу обрывать соединение в случае получения ClientHello в формате SSL 2, что вынудит пользователя поправить настройки браузера.
Подведём итог:
— Сервер не должен обслуживать клиентов без поддержки SNI, то есть у таких старых клиентов не должно быть общих алгоритмов с дефолтным хостом. Самый эффективный метод — дефолтный сертификат ECDSA вместо RSA. Если клиент не поддерживает SNI, он также не поддерживает ECDSA, и в результате получит ошибку рукопожатия вместо чужого сертификата. С марта 2015 это утверждение справедливо для всех симулируемых в SSL Labs клиентов.
— Сервер не должен быть совместим с рукопожатиями SSL 2. Посмотреть можно в самом конце отчёта SSL Labs: SSL 2 handshake compatibility. Методы решения этой проблемы ещё до конца не вывел, но вопрос прорабатывается :).
P.S. Уж столько комментариев оставил, что можно было и свою статью запилить.
Только наоборот :). Если точнее, то:
«With modern browsers» дают в случае согласовывания какого-либо Диффи-Хеллмана как минимум со всеми браузерами, помеченными зелёной буквой R справа от их названия.
Если хотя бы один браузер с зелёным R согласовывает RSA, будет жёлтое «With some browsers». Кстати, это типичный случай для серверов, которые не умеют ECDHE, но умеют DHE. С Internet Explorer ситуация наоборот, Microsoft имеет тенденцию не поддерживать DHE, но поддерживать ECDHE. Исключение — современные версии, поддерживающие DHE совместно с аутентифицированным шифрованием.
Пример наглядно: www.ssllabs.com/ssltest/analyze.html?d=mozilla.org Для таких случаев я предлагал показывать конкретное предупреждение, что сервер не обеспечивает PFS именно с Internet Explorer, но особо не заинтересовались.
«With most browsers ROBUST» дают в случае использования DHE и/или ECDHE для всех успешных рукопожатий, кроме IE на XP.
Ну да, ROBUST — это когда сайт поддерживает не только Диффи-Хеллман на эллиптических кривых, но и традиционный, а если у традиционного слабые параметры, должно быть только «с современными браузерами», как у google.com, который традиционный DHE не умеет.
Это с какой стороны посмотреть. Со слабыми параметрами обеспечивать PFS, именно P, сомнительно. Кстати, в баге о присваивании A+ таким сайтам предложил вообще не считать DHE 1024 как обеспечивающий FS: github.com/ssllabs/ssllabs-scan/issues/80
Если для посещения сайта используется устаревший браузер, до сих пор уязвимый к BEAST, серверу лучше отвергать запросы на безопасные соединения и посылать TCP Reset.
Можно лишиться части аудитории, использующей Apple, так как они закрыли дыру самыми последними, но я считаю это даже благом, так как продукты Apple в плане HTTPS действительно решето, такое нельзя допускать.
На всякий случай, чтобы у вас было понимание происходящего: SSL Labs не умеет (на данный момент) проверять доверие к сайту для каждого симулированного клиента, проверяется физическая возможность подключения без учёта доверия. Java 6 не проходит тест из-за невозможности обработки параметров Диффи-Хеллмана больше 1024 бит.
Java 6 прошла бы тест Handshake simulation при отсутствии ssl_dhparam в конфиге (даже несмотря на недоверие к StartCom), но все наборы шифров с использование традиционного Диффи-Хеллмана были бы помечены слабыми. A+ на данный момент такие сайты всё ещё получают, но это баг в рейтинге, который уже исправляется.
1024-битные параметры Диффи-Хеллмана уже считаются слабыми, скоро с ними получить A+ будет нельзя, минимум 2048.
4096 или 2048 — это уже в зависимости от ключа.
На заметку: SPDY для A+ не требуется, но станет на одно замечание меньше у сервиса проверки GlobalSign (что-то вроде русской версии SSL Labs, но не обновлялась с апреля 2014).
preload — это ваше разрешение на добавление вашего сайта в предзагруженный HSTS-список Google Chrome. Если у вас это прописано, любой может зайти на hstspreload.appspot.com и запросить у Google добавление вашего сайта в браузер, чтобы даже самое первое посещение было сразу по HTTPS. Да, и это всем будет видно из исходников.
Например, в FF не помогает удаление сертификатов центра WoSign CA Limited :(
Поздновато, но всё же отвечу. Вы цепочку доверия смотрели? Сайты отправляют промежуточный сертификат WoSign, выданный от корневого сертификата StartCom или Comodo. Пока вы доверяете StartCom и Comodo (самый популярный CA, не так давно даже обогнал Symantec), вы будете доверять WoSign.
Проверка владения доменом
А бесплатные сервисы делают хорошее дело, позволяя защититься даже некоммерческим проектам.
А когда коммерческие проекты экономят на сертификатах — это нормально? Позор Хабрахабру, Госуслугам, банку Открытие и всем остальным организациям, использующим сертификаты проверки домена! Даже у меня на сайте с простенькой JS-игрой про Путина сертификат выдан после проверки документов организации. Вот DigiCert и Entrust молодцы, вообще не позволяют себе выдавать сертификаты Domain Validation.
Оно мне надо? Вы пробовали побороться с динозавром? Например, с диплодоком? Или вглядываться в бездну в поисках «искры разума»?
Когда МТС подменял сертификат сайта интим-досуга, я пожаловался в Роскомнадзор, а они перенаправили жалобу Якунину (не который президент РЖД, а который начальник ГУ МВД). Недавно пришло письмо из управления уголовного розыска, что вопрос передан в ведомство по моему административному округу. Это несмотря на то, что сайт в списке запрещённых давно и надолго.
С 1 января сайт доступен в Tor, а трасерт до обычной версии теперь через Telia Sonera. Но появилась проблема с сетью доставки контента форчана, не могу смотреть порнушные гифки без изменения HTTPS на HTTP. Предыдущий вопрос ещё не решён, а так ещё раз бы пожаловался. Да, этот тоже в реестре.
У вас же блокируют удалённый из реестра сайт, и ничего не предпринимаете. Возможно, вам оно и не надо.
Ещё Яндекс не умеет нормально определять моё местоположение по IP-адресу, постоянно каждые несколько недель изменяет своё мнение на этот счёт.
— Вы в Щербинке? А, нет, вы в Коммунарке? Так, в Румянцево?
— Яндекс, ты пьян! Я в старой Москве живу.
Ирония в том, что Google, американская корпорация, по этому же IP правильно определяет район Москвы, и сразу же показывает его карту по запросу «где я».
Но этого ещё не всё. Сервер поддерживает только шифр RC4, использование которого запрещено стандартом RFC 7465. Firefox уже сейчас не объявляет поддержку RC4 в первом сообщении ClientHello, только при следующих попытках.
Скоро выйдет Firefox 37, где такое поведение будет разрешено только при посещении сайтов из специального белого списка, иначе никакого подключения.
«Открытие» до сих пор поддерживает SSL 3, использует слабые параметры Диффи-Хеллмана, имеет сертификат уровня Domain Validation (в субъекте даже организация не указана), а на главной странице онлайн-банкинга подгружает шрифт по HTTP. О, даже nginx старой версии палится.
www.ssllabs.com/ssltest/analyze.html?d=click.alfabank.ru
«Альфа» забанил тестирование онлайн-банкинга. Видно, есть, что скрывать, стыдно.
www.ssllabs.com/ssltest/analyze.html?d=bco.vtb24.ru
www.ssllabs.com/ssltest/analyze.html?d=telebank.ru
Без комментариев.
Пока у банков такой HTTPS, к чему этот театр безопасности? Quis custodiet ipsos custodes? Я бы на месте ЦБ без рейтинга A+ на SSL Labs вообще лицензии лишал, а они всякой хренью занимаются.
Такая проблема возможна и с современными браузерами, особенно Internet Explorer, где поддерживаемые протоколы SSL/TLS переключаются проще всего. Речь идёт о поддержке браузером SSL 2. Это вынуждает браузер отправлять сообщение ClientHello в соответствующем формате, который не поддерживает расширения, включая SNI. Таким образом, в случае включённого SSL 2 посетитель так же получит ошибку несовпадения адреса и шифрование соединения чужим ключом. Так может продолжаться до бесконечности. Вместо чужого сертификата сервер должен сразу обрывать соединение в случае получения ClientHello в формате SSL 2, что вынудит пользователя поправить настройки браузера.
Подведём итог:
— Сервер не должен обслуживать клиентов без поддержки SNI, то есть у таких старых клиентов не должно быть общих алгоритмов с дефолтным хостом. Самый эффективный метод — дефолтный сертификат ECDSA вместо RSA. Если клиент не поддерживает SNI, он также не поддерживает ECDSA, и в результате получит ошибку рукопожатия вместо чужого сертификата. С марта 2015 это утверждение справедливо для всех симулируемых в SSL Labs клиентов.
— Сервер не должен быть совместим с рукопожатиями SSL 2. Посмотреть можно в самом конце отчёта SSL Labs: SSL 2 handshake compatibility. Методы решения этой проблемы ещё до конца не вывел, но вопрос прорабатывается :).
P.S. Уж столько комментариев оставил, что можно было и свою статью запилить.
«With modern browsers» дают в случае согласовывания какого-либо Диффи-Хеллмана как минимум со всеми браузерами, помеченными зелёной буквой R справа от их названия.
Если хотя бы один браузер с зелёным R согласовывает RSA, будет жёлтое «With some browsers». Кстати, это типичный случай для серверов, которые не умеют ECDHE, но умеют DHE. С Internet Explorer ситуация наоборот, Microsoft имеет тенденцию не поддерживать DHE, но поддерживать ECDHE. Исключение — современные версии, поддерживающие DHE совместно с аутентифицированным шифрованием.
Пример наглядно: www.ssllabs.com/ssltest/analyze.html?d=mozilla.org Для таких случаев я предлагал показывать конкретное предупреждение, что сервер не обеспечивает PFS именно с Internet Explorer, но особо не заинтересовались.
«With most browsers ROBUST» дают в случае использования DHE и/или ECDHE для всех успешных рукопожатий, кроме IE на XP.
www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.96
Вот сервер, не умеющий обычный DHE, только ECDHE. Старые клиенты (Android 2, Java 6 и OpenSSL 0.9.8) согласовывают RSA, потому что не умеют ECDHE, от этого и результат «With modern browsers».
www.ssllabs.com/ssltest/analyze.html?d=crypto.cat
Этот умеет DHE 4096 и получает «With most browsers ROBUST».
www.ssllabs.com/ssltest/analyze.html?d=www.fastmail.com&s=66.111.4.148
У этого DHE 1024 с рейтингом A+ и ROBUST, что свидетельствует о поддержке DHE, но с слабыми параметрами такого сообщения быть не должно.
Можно лишиться части аудитории, использующей Apple, так как они закрыли дыру самыми последними, но я считаю это даже благом, так как продукты Apple в плане HTTPS действительно решето, такое нельзя допускать.
Java 6 прошла бы тест Handshake simulation при отсутствии ssl_dhparam в конфиге (даже несмотря на недоверие к StartCom), но все наборы шифров с использование традиционного Диффи-Хеллмана были бы помечены слабыми. A+ на данный момент такие сайты всё ещё получают, но это баг в рейтинге, который уже исправляется.
4096 или 2048 — это уже в зависимости от ключа.
Я сам крайне недоволен, но это факт.
С 1 января сайт доступен в Tor, а трасерт до обычной версии теперь через Telia Sonera. Но появилась проблема с сетью доставки контента форчана, не могу смотреть порнушные гифки без изменения HTTPS на HTTP. Предыдущий вопрос ещё не решён, а так ещё раз бы пожаловался. Да, этот тоже в реестре.
У вас же блокируют удалённый из реестра сайт, и ничего не предпринимаете. Возможно, вам оно и не надо.
— Вы в Щербинке? А, нет, вы в Коммунарке? Так, в Румянцево?
— Яндекс, ты пьян! Я в старой Москве живу.
Ирония в том, что Google, американская корпорация, по этому же IP правильно определяет район Москвы, и сразу же показывает его карту по запросу «где я».