Тему подсказало обсуждение предыдущего поста, в котором прозвучал голос заботливого администратора веб-сервера: TLS 1.2 и AEAD – выбор здорового человека, но кто пожалеет пользователей «устаревших» браузеров? Давайте это обсудим – мнимую несовместимость «современного» TLS и «устаревших» браузеров.
Гипотеза звучит следующим образом: если на веб-сервере оставить поддержку только устойчивых версий протокола защиты транспортного уровня TLS (1.2 и 1.3) и шифронаборов (AEAD), пользователи «устаревших» браузеров зайти на сайт не смогут.
Совершим необязательный экскурс в историю… В 2005 году (т.е. 16 лет тому назад), американское Агентство национальной безопасности анонсировало корпус стандартов, руководств, рекомендаций и прочих поддерживающих документов по использованию криптографических алгоритмов – NSA Suite B Cryptography.
В 2009 году IETF опубликовал RFC5430 Suite B Profile for Transport Layer Security, где установил, какие протоколы и шифронаборы должны использоваться для HTTPS-соединения, чтобы соответствовать требованиям АНБ. Уже тогда для соответствия этим требованиям веб-сервер и веб-браузер должны были поддерживать TLS версии 1.2 и шифронаборы TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 и TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
То есть, как минимум последние 11 лет разработчики знали, каким требованиям должна соответствовать их продукция, чтобы иметь возможность претендовать на американский госзаказ. Поэтому следующий факт вы, вероятно, воспримете без удивления: все реально используемые сегодня браузеры поддерживают упомянутый шифронабор в варианте с 128-битным шифроключом, а многие (но не все) – и с 256-битным.
На этом можно было бы закончить статью, порекомендовав всем администраторам веб-серверов оставить поддержку только TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 и не забивать себе голову мифами о несовместимости TLS 1.2 с «устаревшими» браузерами, если бы не нюанс: в TLS версии младше 1.3 алгоритм цифровой подписи в шифронаборе должен совпадать с алгоритмом в TLS-сертификате, а веб-серверов с сертификатом, подписанным по алгоритму ECDSA, в доменной зоне .RU менее 6%, оставшиеся используют для подписи RSA.
Кто виноват – вопрос отдельного исследования, нас же интересует что делать? Давайте для начала вспомним, что к устойчивым шифронаборам сегодня относятся не только рекомендуемая АНБ комбинация ECDHE+ECDSA+AES, но и другие:
Весь зверинец
TLS_DHE_RSA_WITH_AES_128_CCM;
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_DHE_RSA_WITH_AES_256_CCM;
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;
TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256;
TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384;
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256;
TLS_ECDHE_ECDSA_WITH_AES_128_CCM;
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;
TLS_ECDHE_ECDSA_WITH_AES_256_CCM;
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256;
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384;
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256;
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256;
TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384;
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_DHE_RSA_WITH_AES_256_CCM;
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;
TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256;
TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384;
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256;
TLS_ECDHE_ECDSA_WITH_AES_128_CCM;
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;
TLS_ECDHE_ECDSA_WITH_AES_256_CCM;
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256;
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384;
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256;
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256;
TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384;
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.
Итого 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),
Готовы ради упертых «полутора землекопов» держать для сайта выделенный 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 соответственно.