Весь зверинец

SPL
Итого 19 устойчивых шифронаборов, однако не все из них подходят для использования в реальной жизни на публичном веб-сервере: алгоритм шифрования CAMELLIA, как и AES в режиме CCM, поддерживается чуть более, чем никем, с CHACHA20 и его верным спутником POLY1305 знакомы лишь относительно современные браузеры, а для использования шифронаборов на основе ECDSA, как уже было сказано, требуется соответствующий TLS-сертификат. Таким образом у нас остается лишь 4 «дополнительных» шифронабора:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384.
Соблазнительно предположить, что если браузер поддерживает комбинацию ECDHE+ECDSA, то уж с ECDHE+RSA он точно справится, но это не всегда так – многие умеют только в DHE+RSA, и чтобы удовлетворить запросы всех старых браузеров, на сайте с RSA сертификатом необходимо поддерживать два шифронабора:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.
Это даст нам совместимость как минимум со следующими операционными системами и браузерами:
Android 4.4.2 + Android Browser (Chrome);
Windows XP + Chrome 49/Firefox 49/ Opera 12.18;
Windows 7 + Internet Explorer 11/Chrome 31/Firefox 31;
OS X + Firefox 29/Chrome 37;
iOS 9 + Safari 9;
Java 8b.
Про *nix системы не скажу – зависит от сборки, но очевидно, что проблемы как таковой не существует. Единственная проблема возникнет с Windows Phone 8.1 + IE 10, которые поддерживают только одну устойчивую комбинацию – ECDHE+ECDSA.
А что же делать пользователям Windows XP + IE 6 или какого-нибудь Android 2.3? – спросит заботливый админ. Продолжать сидеть без доступа к современному Интернету, – отвечу я, – поскольку даже поддержка веб-сервером протокола SSL 2.0 им ничем не поможет. Дело в том, что даже если накатить на Windows XP все выпущенные для него обновления (по май 2019 года) и обновить штатный браузер до версии 8, это принесет лишь поддержку TLS 1.2, но не устойчивых шифронаборов. Кроме того, Windows XP как не знал, так и не узнает, что такое Server Name Indication (SNI), HTML 5 Live HTML и CSS 3.
Готовы ради упертых «полутора землекопов» держать для сайта выделенный IP и не обновлять верстку? Тогда добавьте поддержку, например, TLS_RSA_WITH_AES_256_CBC_SHA256, но скорее следует предположить, что современный пользователь Windows XP уже давно пользуется альтернативным браузером, который поддерживает даже TLS 1.3. То же верно и для Android 2.3, установив на который Firefox 27, мы получим полноценную поддержку TLS 1.2 и AEAD шифронаборов, а не установив – просто не сможем пользоваться значительной частью современных сайтов даже по HTTP.
Все вышесказанное, разумеется, не является призывом к отказу от поддержки более стойких шифронаборов, которые будут востребованы современными браузерами, и которые следует предлагать для согласования в первую очередь.
Чтоб два раза не вставать, рассмотрим кратко и ситуацию с эллиптическими кривыми. NSA Suite B Cryptography признает только две из них – NIST P-384 и NIST P-256, поддержка которых на веб-сервере обеспечит доступ к сайту как современных, так и «устаревших» браузеров. Собственно, достаточно поддерживать только NIST P-384 для «старичков» и Curve25519 для современных браузеров; ну разве что еще NIST P-521 добавить, для некоторых «передовых старичков».
Подытожим: если мы хотим, чтобы сайт оставался доступен для «устаревших» браузеров, но при этом поддерживал только устойчивые версии протокола защиты транспортного уровня и шифронаборов, поступим следующим образом.
Для сайта с TLS-сертификатом, подписанным по алгоритму ECDSA, включим поддержку шифронабора TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
Для сайта с TLS-сертификатом, подписанным по алгоритму RSA, включим поддержку шифронаборов TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 и TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.
Для обоих сайтов включим поддержку эллиптической кривой NIST P-384 или NIST P-256 и зададим порядок предпочтения шифронаборов и эллиптических кривых, согласно которым вышеуказанные наборы и кривые предлагаются браузерам для согласования после более устойчивых, например после TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 и Curve25519 соответственно.
===========
Источник:
habr.com
===========
Похожие новости:

• [Информационная безопасность] Проблемы безопасности онлайн банков
  
• [Информационная безопасность, Законодательство в IT] Информационная безопасность и коммерческая тайна
  
• [Информационная безопасность, Мессенджеры] WhatsApp не откажется от обновления политики конфиденциальности
  
• [Информационная безопасность] О безопасности Сбербанка Онлайн
  
• [Информационная безопасность] ТОП-3 ИБ-событий недели по версии Jet CSIRT
  
• [Информационная безопасность, JavaScript, Google Chrome, Браузеры] Новая утечка истории браузера через favicon
  
• [Информационная безопасность, Исследования и прогнозы в IT, Законодательство в IT] Почему Microsoft перестала бороться с пиратством своего ПО (перевод)
  
• [Информационная безопасность, Microsoft Azure, Облачные сервисы] Microsoft подтвердила утечку исходного кода Azure, Exchange и Intune при атаке на SolarWinds
  
• [Информационная безопасность, Законодательство в IT] Коммерческая тайна. Частые вопросы и ответы
  
• [Информационная безопасность, Облачные сервисы] Используем чек-лист ENISA для проверки безопасности облачного провайдера и чтения SLA

Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_https, #_tls_1.2, #_informatsionnaja_bezopasnost (
Информационная безопасность
)