Pull to refresh

Comments 36

Полез искать, что это за CCM такой. Оказалось, переименованный CBC. Интересно, AES-CTR куда переименовали, или что с ним сделали?

Ну если так смотреть на вещи, то CTR переименовали в GCM ;)
Если я правильно понимаю, это список с примененным апдейтом, без него этих двух CipherSuite не будет
Можно обойтись *CBC* вариантом.
У меня как раз недавно не завелся IE7 для сервера с конфигом Mozilla intermediate. Добавление ECDHE-RSA-AES128-SHA256 решило проблему, рейтинг A+ от ssllabs по-прежнему.
Не всегда, была тут прекрасная неделя когда один вендор без объявления войны сказал — а мы тут ТЛС1.2 подкрутили и CBC не будет работать больше через 2 дня. 12(даже не Р2 сервер), только этот апдейт и спас, поскольку организовать новый сервер и перетащить клиента на него за это время у нас невозможно
В критичных случая лучше прикрутить на сайт еще и ECDSA сертификат: как ни странно покажется, но ECDHE+ECDSA поддерживается большим количеством «устаревших» клиентов, чем устойчивые вариации с использованием RSA для подписи.
Можно, но не нужно — Windows 7 SP1 + IE 11 поддеживают:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

SSL Labs и прочие «валидаторы SSL» свой рейтинг строят на требованиях NIST SP 800-52, хорошо еще если второй редакции (2019 г. издания). Которая а) еще неизвестно как долго разрабатывалась, б) ориентируются на зоопарк американского госсектора, в) предназначена не только для публичных сайтов, а вообще для всего, что коммуницирует по TLS.
Конкретно SSL Labs не учитывает, например, поддержку EMS, которая требуется согласно NIST SP.800-52 и ставит А+ о-о-очень сомнительным на мой вкус серверам.
А вот у меня не поддержал. И патч указанный не ставится.
1. ECDHE_ECDSA наборы тоже не поддерживает?
2. SP1 стоит? Думаю, это pre-requirement для KB3042058, судя по дате выпуска.
1. Возможно, заблокированы в GP.
2. Смотрите тогда лог установки, что установщику не понравилось.
SSL Labs и прочие «валидаторы SSL» свой рейтинг строят на требованиях NIST SP 800-52, хорошо еще если второй редакции (2019 г. издания). Которая а) еще неизвестно как долго разрабатывалась, б) ориентируются на зоопарк американского госсектора, в) предназначена не только для публичных сайтов, а вообще для всего, что коммуницирует по TLS.
Конкретно SSL Labs не учитывает, например, поддержку EMS, которая требуется согласно NIST SP.800-52 и ставит А+ о-о-очень сомнительным на мой вкус серверам.

Подскажите, пожалуйста, какой валидатор тогда адекватен современным реалиям?
SSL Labs — я так понял, речь про Qualys?

Понимаете, «современные реалии» — это же вкусовщина в любом случае, и для каждого они будут свои. У кого-то непубличный сервер и все клиенты под контролем, он может только TLS 1.3 оставить и ввести двустороннюю аутенификацию по сертификатам, а у кого-то на публичный сервер ходит клиент, который ничего выше SSL не понимает, а дропнуть его нельзя (хоть это и ужасно, но это жизнь).
Каждому стоит определиться именно со своими потребностями и возможностями и плясать от них, протестировав свой сервер в разных валидаторах. И не заморачиваться рейтингом — A+ может быть недостаточно для реально серьезной защиты банковского сайта, а для кого-то и B нормальный рейтинг с учетом его реальных потребностей и реальной защищенности от предполагаемого уровня угроз. Кроме того, валидаторы иногда расходятся в показаниях, и надо смотреть конфиги своего сервера: действительно ли это трудно обнаруживаемая при тестах дыра, или у кого-то глюки?
Да, SSL Labs — это Qualys, неплохой валидатор, но не единственный.

Создатели этого теста супер-параноики (моему сайту снижена оценка до 97% только за использование early_data (0-RTT) ).


Они считают что https://IP уже должен HSTS отдавать — а у Вас не отдаёт.


:)

Думаете, в этом дело? Т.е. они так неявно требуют нестандартной директивы preload в заголовке?
Добавлю, что для голой Win7 sp1 перед установкой KB3042058 необходимо установить в начале KB4474419-v3, затем KB4490628 и только после этого поставится KB3042058.
По поводу браузера для Windows XP — есть Otter Browser.
Есть много чего, что использует не schannel, а свои, более продвинутые криптобиблиотеки.
Даже если браузер не поддерживает протокол, не проблема сделать прокси, который будет подключаться к серверу с любым современным протоколом, а браузеру отдавать хоть голый http.
Только не для рядового пользователя, которому проще «помочь» на стороне сервера.
А вот какой на данный момент локальный рабочий прокси под Windows есть?
Это на самом деле актуально для устройств на андроид относительно старых.
Сходу конкретных программ не назову, но вообще локальных проксей полно, для разных задач. Скажем, Squid часто используется. Да и nginx можно как проксю использовать. Всякие рекламорезки нередко как прокси реализованы. Я себе для одного сайта вообще набросал на Перле скриптик, который получает https и по http передаёт эти данные через Proxomitron в браузер (некоторую рекламу так проще оказалось резать). Сам Proxomitron, кстати, это тоже прокси, но с https он не дружит.

Ну вот старенький киндл, ещё с кнопочками и whispernet на борту. Раньше можно было ходить в википедию. Теперь ходить он по-прежнему может, но вот открывать — уже нет. А с левым прокси проблема прямо противоположная — может и сможет открыть, но сходить не сможет.
Пат!

Тут всё зависит от функций и возможностей Киндла. В большинстве случаев можно всё-таки как-то извернуться (другой вопрос, будет ли потраченное время стоить результата). Скажем, если используется подключение через домашний роутер, или если на самом Киндле можно настроить произвольный DNS-сервер, то можно будет подменять DNS-ответ, чтобы запросы на Википедию перенаправлялись на другую машину, где поднят веб-сервер, перебрасывающий запросы на реальный сайт. А если речь о браузере, в котором можно ввести произвольный адрес, то можно поднять сервис, который будет не обычной проксёй, а «обёрткой» (не знаю, как правильно называется такой тип). Скажем, сервис живёт на 192.168.1.15, мы вводим урл 192.168.1.15/en.wikipedia.org/wiki/Proxy, сервис вычленяет из урла адрес en.wikipedia.org/wiki/Proxy, скачивает страницу по этому адресу и отдаёт её браузеру. В общем, примерно как веб-архив, только он-то из своего хранилища берёт, а тут к исходному сайту подключение выполняется. Но этот подход не со всеми сайтами будет работать. Ведь там придётся парсить страницу и подменять все абсолютные ссылки, иначе они будут указывать не туда. А на некоторых сайтах эти ссылки генерируются скриптами, и до них так просто не доберёшься…

Через домашний роутер я и сам могу ).
Речь про whispernet, который даёт всемирный бесплатный доступ через 3G, но только к киндл-стору и википедии. И имеет на борту "экспериментальный браузер" на webkit. Сейчас по факту доступ есть, но открыть он ничего не может. А к любым сайтам-"помогайкам" наоборот, доступа нет.

Спасибо, очень актуальная статья ) не хватает только конкретных конфигов для nginx.

Так и быть, делюсь своим набором, и актуально и A+ будет


ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;


add_header Strict-Transport-Security max-age=15768000;

А есть ли смысл использовать AES-256? 128 уже не считается устойчивым?

В основном, из соображений перфекционизма. И обеспечения очень долгосрочной PFS.
Sign up to leave a comment.

Articles