Канонический ответ - https://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability и предпочитает исключать протокол SSLv3, а не шифры.
Предварительно, два разных набора шифров, которые вы называете, используют оригинальный DES, с ретронимом Single-DES и небезопасны во ВСЕХ версиях протокола. Оригинальный DES был заменен и снят десять лет назад. (Точнее, FIPS46-3 был заменен FIPS197 AES в 2001 году, затем отменен в 2005 году, и только с тройным DEA, а не с одним DEA, был переиздан как SP800-67 в 2004 году как одобренный, но не стандартный.) Они классифицируются как LOW в конфигурации шифра openssl, и вместе с EXPORT (даже менее безопасным) и eNULL (совершенно небезопасным) никогда не должны настраиваться, если вам не приходится иметь дело с серьезно устаревшей системой, которую нельзя модернизировать, заменить или перенести. - закончил, как, может быть, один из старых марсианских кораблей.
На ваш вопрос, на самом деле не существует специфичных для SSLv3 CBC-шифров, хотя они не -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 в http://tools.ietf.org/html/rfc4492 официально применяется только к TLS1+, потому что они полагаются на расширения в ClientHello и http://tools.ietf.org/html/rfc3546, поскольку расширения не могут Не изменяйте SSL3, но openssl> = 1.0.0 (или некоторые 0.9.8, если настроены) реализует их в SSL3, рассматривая расширения как значения по умолчанию "без ограничений" - но только если одноранговый узел соглашается, что одноранговые узлы отличаются от преднамеренного Благородный недавний openssl, вероятно, не будет. Это единственное, возможно, полезное отличие шифра. Предполагая RSA cert & privatekey, вы можете использовать ECDHE-RSA и надеяться, что он работает только на TLS1+.
Вот почему утилита командной строки openssl ciphers -v [$cipherstring] показывает SSLv3 как "версию" для большинства шифров; это означает SSLv3 и выше.
TL-DR: ЕСЛИ ваши клиенты, использующие только SSL3, не согласовывают шифры ECC (а большинство очень старых клиентов, вероятно, этого не делают, хотя это могут делать более благородные новички), и ВСЕ ваши клиенты TLS1+ ДЕЛАЮТ (что гораздо менее определенно) и предполагают общий случай для сертификата RSA и частного ключа вы можете включить ECDHE-RSA- (3DES или AES) -CBC, но отключить DHE-RSA-что-нибудь-CBC и RSA-что-нибудь-CBC. Это также дает вам совершенную прямую секретность.
Если вы хотите, вы также можете включить RC4 для всех SSL3+, с PFS или нет, но есть и проблемы:
Ваш веб-сайт "старых приложений" или что-то еще? Если в Интернете вы не можете получить полуприличный браузер? Если пользовательское приложение не может повторно посылать одни и те же конфиденциальные данные ПОСЛЕ данных злоумышленника, оно не будет "в первую очередь".
