В мире DevOps и SRE, где каждый сбой — это потенциальная катастрофа, мы привыкли следовать правилу «исправлять всё, что сломано». Мы настраиваем алерты, используем системы мониторинга (например, Pingera), и стремимся к идеальной оценке в любом отчете безопасности. Но что, если идеальный результат в отчете не всегда совпадает с идеальным пользовательским опытом?
Сегодня мы поговорим об интересном парадоксе: почему некоторые компании, включая технологических гигантов вроде Google, сознательно оставляют свои SSL-конфигурации с «низким» рейтингом, и почему иногда это решение — наиболее взвешенное и верное.
Когда мониторинг SSL-сертификатов показывает «плохой» результат
Представим, что вы запустили сканирование SSL-сертификата своего сайта с помощью нашего инструмента (или его аналогов, вроде Qualys SSL Labs). Вы видите результат, который далёк от заветной A+: например, оценка B или даже C. Отчёт указывает на использование «слабых шифров» (weak ciphers) или устаревших протоколов, таких как TLS 1.0/1.1. Ваша первая реакция — паника. Как это исправить?
Но давайте посмотрим на проблему под другим углом. Почему эти «устаревшие» протоколы и шифры вообще существуют?
Загадка Google: почему у них не A+?
Если вы просканируете, например, google.com, вы с удивлением обнаружите, что его рейтинг не всегда идеален. Часто он понижен именно из-за поддержки старых, но не сломанных, шифров. Зачем Google это делает?
Ответ прост — доступность.
Google стремится к тому, чтобы их сервисы были доступны для максимально широкой аудитории. Это включает пользователей, которые до сих пор используют:
Старые версии операционных систем (например, Windows 7, XP, которые не обновлялись годами).
Устаревшие браузеры, которые не поддерживают современные стандарты TLS 1.3 и современные шифры.
Редкие устройства или IoT-девайсы, чьё ПО давно не обновлялось.
Отключение старых шифров позволило бы Google получить заветный A+ в отчёте, но при этом отрезало бы доступ к их сервисам для миллионов пользователей по всему миру.
Ярким примером такого компромисса является шифровый набор TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA. Этот, казалось бы, устаревший набор все еще может быть включен на сервере для совместимости, например, с Internet Explorer 7 на Windows XP. Давайте разберем его по частям, чтобы понять, в чем проблема:
ECDHE: Современный и безопасный алгоритм обмена ключами (Elliptic Curve Diffie-Hellman Ephemeral), который обеспечивает Perfect Forward Secrecy. Это отличный компонент.
AES_128: Современный и надежный алгоритм симметричного шифрования.
CBC (Cipher Block Chaining): Режим работы шифра. Вот здесь и кроется одна из уязвимостей. CBC уязвим к так называемым "padding oracle" атакам (например, POODLE), которые позволяют злоумышленнику восстанавливать зашифрованный текст, анализируя ошибки при расшифровке.
SHA (specifically SHA-1): Хеш-функция, используемая для проверки целостности данных. SHA-1 считается криптографически небезопасной и устаревшей.
Таким образом, несмотря на наличие сильных компонентов (ECDHE и AES), использование устаревших и уязвимых CBC и SHA-1 делает этот шифровый набор небезопасным по современным стандартам. Однако, для поддержки устаревших клиентов, которые не могут использовать более новые наборы (например, с GCM или SHA-256), такой компромисс является вынужденным.
Сколько таких пользователей? Немного. Но это важно
Вполне логично задаться вопросом: а сколько вообще пользователей до сих пор используют такие браузеры, как Internet Explorer 7? По актуальной статистике, их доля на мировом рынке браузеров для десктопов составляет менее 1%. Это мизерный показатель, и в большинстве случаев вам не нужно беспокоиться о таких клиентах.
Однако, для кого-то эти 0.1% пользователей могут быть критически важными. Если вы работаете в B2B-сегменте, где ваши клиенты — это крупные корпорации или государственные учреждения, которые используют устаревшее ПО, отключение поддержки старых шифров может обернуться для вас потерей прибыли. Для этих компаний доступность — ключевой фактор, а риски, связанные с уязвимостями, могут быть приемлемы, если речь идет о некритичных данных.
Баланс между безопасностью и доступностью
Итак, перед нами дилемма: безопасность или доступность?
Безопасность требует, чтобы мы использовали только самые современные и сильные шифры и протоколы, чтобы минимизировать риск перехвата данных. Если ваши клиенты используют только современные браузеры, то можно отключить старые шифры и протоколы.
Доступность же, наоборот, заставляет нас поддерживать совместимость со старым ПО, даже если оно менее защищено.
В большинстве случаев правильный выбор — это золотая середина. Для большинства критически важных бизнес-приложений, где обрабатываются персональные данные, платежи и другая конфиденциальная информация, приоритет — безопасность. Для контентных сайтов, блогов или информационных ресурсов доступность может быть важнее.
Вам, как инженеру, нужно оценить риски и принять взвешенное решение. Наша задача — не просто выставить оценку, а дать вам полную информацию, чтобы вы могли принимать такие решения осознанно.
Например, наш инструмент для сканирования SSL-сертификатов не просто выставляет оценку, но и предоставляет детальный список уязвимостей, таких как слабые шифры, устаревшие протоколы или некорректно настроенные сертификаты. Это позволяет вам точно видеть, что именно влияет на рейтинг, и решать, стоит ли это исправлять.