☰

Удаление шифров CBC, специфичных для SSLv3

tag-icon • tag-icon ssl openssl
Удаление шифров CBC, специфичных для SSLv3

Мне нужно отключить специфичные для SSLv3 шифры CBC в качестве временного решения уязвимости POODLE, поскольку существуют устаревшие приложения, которым необходимо использовать SSLv3. После ознакомления с документацией OPENSSL выяснилось, что существуют общие шифры между SSLv3 и TLSV1, такие как:

  • SSL_DHE_RSA_WITH_DES_CBC_SHA
  • DHE-RSA-DES-CBC-SHA
  • TLS_DHE_RSA_WITH_DES_CBC_SHA
  • DHE-RSA-DES-CBC-SHA

Мой вопрос в том, есть ли способ отключить, например,DHE-RSA-DES-CBC-SHAспециально для SSLv3 и повлияет ли это действие на TLSv1?

Я использую nginx, Varnish и Apache с OPENSSL.

решение1

Эта конфигурация должна быть сделана на вашем веб-сервере. OpenSSL позволяет вам указывать шифры только программно, как сказано в этомответ SE.

Поскольку вы сказали, что используете Apache и nginx (веб-кэш Varnish не поддерживает SSL), я нашел эти страницы, посвященные той же теме, хотя они и адресованы BEAST:

  1. Настройка Apache-Nginx и OpenSSL
  2. Усиление защиты наборов шифров OpenSSL вашего веб-сервера

Это о том,SSL-терминациякоторый позволяет Varnish кэшировать ваш контент:


Очень важно P.S.:

PS1 - Не забудьте использоватьHSTS
PS2 - Всегда устанавливайте флаг "Безопасный" для файлов cookie, созданных внутри зашифрованных соединений. Забыв об этом, вы очень легко можете слить информацию злоумышленникам.

решение2

Канонический ответ:https://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerabilityи предпочитает исключитьпротоколSSLv3, а не шифры.

Предварительно, два отдельных набора шифров, которые вы называете, используют оригинальный DES, переименованныйодинарный DES, и являютсянебезопасно во ВСЕХ версиях протокола. Оригинальный DES был заменен и отозван десять лет назад. (Точнее, FIPS46-3 был заменен FIPS197 AES в 2001 году, затем отозван в 2005 году, и только тройной DEA, НЕ одинарный DEA, был переиздан как SP800-67 в 2004 году как одобренный, но не стандартный.) Они классифицируются как LOW в конфигурации шифра openssl, и вместе с EXPORT (еще менее безопасный) и eNULL (совершенно небезопасный) должныникогдабыть настроены, если только вам не приходится иметь дело с серьезно устаревшей системой, которую нельзя модернизировать, заменить или модернизировать, как, например, один из старых марсианских посадочных модулей.

Что касается вашего вопроса, то на самом деле не существует шифров CBC, специфичных для SSLv3, хотя они есть.не- SSLv3. В openssl конфигурация разрешенных наборов шифров и протоколов является отдельной и почти независимой; AFAICS единственным ограничением является то, что шифры, использующие новые функции TLSv1.2 (аутентифицированное шифрование GCM или хэши SHA-2), не могут быть выбраны ни в одном старом протоколе, а несколько шифров, используемых в SSLv2, но не назначенных кодов SSLv3+, поскольку они уже были небезопасны в 1996 году, не могут быть использованы в SSL3+. ДажеСогласно стандартам, единственные различия для шифровмежду SSL3 и TLS1 или 1.1:

  • 40-битные шифры EXPORT были официально удалены в 1.1 -- но openssl все равно поддерживает их в 1.1 и 1.2 как расширение. Но они были и остаются небезопасными, и вам не следует их использовать, если вы не путешествуете во времени назад в 1990-е и не попадаете под правовые ограничения внекоторыйместа тогда.

  • Обмен ключами Fortezza, добавленный для умиротворения правительства США в период «криптовалюта — это оружие», и никогда не использовавшийся никем, кроме, может быть, АНБ, был удален TLS1. Он не реализован openssl влюбойпротокол.

  • первая партия шифров ECC вhttps://www.rfc-editor.org/rfc/rfc4492официально применяются только к TLS1+, поскольку они полагаются на расширения в ClientHello иhttps://www.rfc-editor.org/rfc/rfc3546для расширений не удалось изменить SSL3, но openssl >=1.0.0 (или какой-нибудь 0.9.8, если его подправить) реализует их в SSL3, рассматривая расширения как по умолчанию "без ограничений" -- но только если одноранговый узел согласен, чего другие одноранговые узлы, кроме намеренно позаимствованных последних openssl, вероятно, не сделают. Этоединственное возможное полезное различие в шифрах.Если предположить, что у вас есть сертификат и закрытый ключ RSA, вы можете использовать ECDHE-RSA и надеяться, что он будет работать только на TLS1+.

Вот почему openssl ciphers -v [$cipherstring]утилита командной строки показывает SSLv3 как «версию» для большинства шифров; это означает SSLv3 И ВЫШЕ.

Вкратце:ЕСЛИ ваши клиенты, использующие только SSL3, не согласовывают шифры ECC (а большинство очень старых клиентов, вероятно, не согласовывают, хотя более новые могут) И ВСЕ ваши клиенты TLS1+ДЕЛАТЬ(что гораздо менее определенно) и предполагая распространенный случай RSA cert&privatekey, вы можете включить ECDHE-RSA-(3DES или AES)-CBC, но отключить DHE-RSA-anything-CBC и RSA-anything-CBC. Это также дает вам Perfect Forward Secrecy.

При желании можно также включить RC4 для всех SSL3+, с PFS или без, но и здесь есть свои нюансы:

Ваши "устаревшие приложения" веб или что-то еще? Если веб, вы не можете получить более-менее приличный браузер? Если пользовательское приложение нельзя заставить повторно отправлять одни и те же конфиденциальные данные ПОСЛЕ данных злоумышленника, оно изначально не "кусаемое".

Связанный контент