Комментарии 18
А чем не подходит:
https://www.immuniweb.com/ssl/?id=mr7ExbBc
Меня устраивает мой результат вполне :)
DNSSEC и TLSA этим тестом не проверяется, но у меня это тоже есть.
А в вашем тесте мой сайт сколько набирает если не секрет ?
По п. 5.8 — имхо если уж проверять то HSTS а не upgrade-insecure-requests так как:
"The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header, which should still be set with an appropriate max-age to ensure that users are not subject to SSL stripping attacks."
2. 5.х — это бонусные критерии, которые добавляют баллы, но не влияют на попадание в ту или иную группу. Т.е. подход такой: есть — хорошо, нет — не смертельно. Конкретно по 5.8: upgrade-insecure-requests — пока не стандартизированная директива и требовать ее наличия нельзя. Напротив, обе проверяемые директивы HSTS (4.7) стандартизированы и не вчера. Вот preload — это уже vendor-specific и может негативно повлиять на доступность сайта вообще, если админу зачем-то потребуется отключить HSTS, поэтому ее в критерии не включили до стандартизации. При этом 4.7 и 5.8 не взаимозаменяемы, как, скажем, варианты 4.3: можно поддерживать только CRL или только OCSP и не вылетить из группы.
Кстати, а из каких соображений CBC поддерживаете?
Исключительно из-за того чтобы не потерять часть посетителей с apple устройств старых и IE 11 под WIN7/8 (писать мне стали что не открывается сайт) — через годик отключу.
2.
Ну как-то зря HSTS без preload — имхо надуманная ситуация про админа решившего отключить.
3.
За TLS 1.3 0-RTT (Early_Data) снижать баллы будете? (Я считаю что не надо снижать — ну не влияет повторное согласование на безопасность).
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Forward Secrecy 256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Forward Secrecy 128
2. Основная «претензия» к preload, что она vendor-specific и ЕМНИП не стандартизирована.
3. Нет, поддержка TLS 1.3 вообще рассматривается как бонус, а не must have.
1.
По сообщениям не попавшим на сайт пользователей (возможно без обновлений ОС и браузера). Да и не так это принципиально — через год CBC отключу !
Кстати, рекомендуется еще добавить что-нибудь на основе TLS_CHACHA20_POLY1305_* в TLS 1.2 — пользователи устройств без аппаратного AES скажут спасибо.
Да, так и есть — спасибо!
Я уже думаю через год не только CBC отключить а вообще tls 1.2 :)
Ну у меня выделенный сервер и LA = 0 даже в пиковой (для моего сайта) нагрузке :)
А может Минкомсвязи не сможет esni отдельно побороть и запретит весь tls 1.3 тогда мой план рухнет :)
Сегодня вышел nginx 1.19.4 в котором стало возможно управлять Cipher в TLS 1.3 — обновил конфиг — стало так:
https://www.ssllabs.com/ssltest/analyze.html?d=www.babai.ru&s=2a07:ac80:0:4b:0:0:0:2
Теперь до "А" в вашем тесте добрался :) ?
1. Как ни странно, TLS_ECDHE_ECDSA — более универсальный комплект, чем TLS_ECDHE_RSA. С ним будет работать все, что в принципе может работать в современных условиях: TLS-сертификаты с SHA-2, SNI и это все. На Огнелисе даже будет доступен TLS 1.3 под WinXP.
2. Кривые я бы поставил в таком порядке: x25519, secp521r1, secp384r1. А secp256r1 и x448 можно выкинуть: клиенты, которые могут работать в современном мире, поддерживают минимум secp384r1, а x448 прекрасна, но фактически ее пока очень мало кто поддерживает на стороне клиента. Если уж весь набор, то тогда так: x25519, x448, secp521r1, secp384r1, secp256r1 – в порядке убывания стойкости (хотя кто крепче из первых двух – еще вопрос). Быстрее согласовываться будет без лишних кривых и в таком порядке.
3. SCSV можно дропнуть: он бессмысленен, если ничего ниже TLS 1.2 не поддерживается.
Приглашение к обсуждению методики составления индекса HTTPS-защищенности сайтов