Как мне исправить / обойти уязвимость SSLv3 POODLE (CVE-2014-3566)?

После Нападение ЗВЕРЯ и Кровоточащий жук, теперь я услышал о новой уязвимости в SSL / TLS под названием ПУДЕЛЬ. Как мне защитить себя от эксплуатации?

  • Затронуты ли только серверы или также клиенты?
  • Является ли это специфичным для OpenSSL / GnuTLS?
  • Какие услуги затронуты? Только HTTPS или также IMAPS, SMTPS, OpenVPN и т.д.?

Пожалуйста, покажите мне примеры того, как избежать этой уязвимости.

Справочная информация

SSL предназначен для обеспечения безопасности транспортного уровня в Интернете. Для "интернета", известного как HTTP, вы будете знать это как HTTPS, но он также используется для других прикладных протоколов. SSLv2 был первым широко используемым протоколом транспортной безопасности, но вскоре после этого был признан небезопасным. Преемники SSLv3 и TLSv1 в настоящее время широко поддерживаются. TLSv1.1 и TLSv1.2 являются более новыми и также получают большую поддержку. Большинство, если не все веб-браузеры, выпущенные с 2014 года, поддерживают его.

Недавнее открытие инженеров Google указывает на то, что SSLv3 больше не следует использовать (например, SSLv2 давно устарел). Клиенты, которые не смогут подключиться к вашему сайту / сервису, вероятно, очень и очень ограничены. Облачная вспышка объявленный что менее 0,09% их посетителей по-прежнему полагаются на SSLv3.

Простое решение: отключите SSLv3.

Предоставляет ли Ubuntu какие-либо обновления?

Да, через usn-2385-1 с добавлением функции SCSV, но это не смягчает проблему полностью поскольку это не отключает SSLv3, и исправление будет работать только в том случае, если обе стороны соединения были исправлены. Вы получите его через регулярные обновления безопасности в вашем диспетчере пакетов.

Итак, все еще ВЫ вы должны сами принять меры, чтобы отключить SSLv3 (это настраивается). Будущие версии клиентов / браузеров, скорее всего, отключат SSLv3. Например, Firefox 34 сделает это.

Полное отключение SSLv3 по умолчанию в Ubuntu на уровне реализации, вероятно, приведет к нарушению некоторых функций и для использования SSL, отличного от HTTPS, что не так уж и уязвимо, поэтому я предполагаю, что сопровождающие этого не сделают, и будет применен только этот патч SCSV.

Почему обновление SCSV в OpenSSL через usn-2385-1 не устраняет проблему?

Действительно, перестаньте задавать такие вопросы и просто пропустите несколько абзацев и отключите SSLv3. Но эй, если ты не уверен, держи:

ПУДЕЛЬ показывает, что SSLv3 с шифрами CBC сломан, реализация SCSV этого не меняет. SCSV только гарантирует, что вы не перейдете с какого-либо протокола TLS на любой более низкий протокол TLS / SSL по мере необходимости с помощью атаки "Человек посередине", необходимой для обычных случаев.

Если вам нужно получить доступ к какому-либо серверу, который вообще не предлагает TLS, а только SSLv3, то у вашего браузера на самом деле нет выбора, и он должен взаимодействовать с сервером, используя SSLv3, который затем уязвим без какой-либо атаки на понижение.

Если вам нужно получить доступ к какому-либо серверу, который также предлагает TLSv1 + и SSLv3 (что не рекомендуется), и вы хотите быть уверены, что ваше соединение не будет понижено до SSLv3 злоумышленником, то оба серверу и клиенту нужен этот патч SCSV.

Для полного устранения проблемы достаточно отключить SSLv3 с вашей стороны, и вы можете быть уверены, что ваш рейтинг не будет понижен. И вы не сможете общаться с серверами, использующими только SSLv3.

Итак, как мне отключить SSLv3?

Смотрите ниже в разделах, посвященных конкретным приложениям: на данный момент рассматриваются Firefox, Chrome, Apache, Nginx и Postfix.

Затронуты ли только серверы или также клиенты?

Уязвимость существует, если и сервер, и клиент принимают SSLv3 (даже если оба поддерживают TLSv1/TLSv1.1/TLS1.2 из-за атаки с понижением рейтинга).

Как администратор сервера вы должны отключить SSLv3 сейчас для безопасности ваших пользователей.

Как пользователь, вы должны отключить SSLv3 в своем браузере сейчас чтобы обезопасить себя при посещении веб-сайтов, которые все еще поддерживают SSLv3.

Является ли это специфичным для OpenSSL / GnuTLS / браузера?

Нет. Это ошибка протокола (дизайна), а не ошибка реализации. Это означает, что вы действительно не можете его исправить (если только вы не меняете дизайн старого SSLv3).

И да, есть новый Версия безопасности OpenSSL, но читайте ниже (Но мне действительно очень нужна поддержка SSLv3... по причинам X, Y, Z!) о том, почему вам лучше сосредоточиться на полном отключении SSLv3.

Могу ли я отключить SSLv3 на уровне сети (брандмауэра)?

Ну, да, наверное. Я поместил это в отдельный пост в блоге для дальнейших размышлений и работы. У нас может быть какая-то магия iptables правило, которое вы можете использовать!

Мой пост в блоге: Как отключить SSLv3 в вашей сети с помощью iptables для POODLE?

Актуально ли это только для HTTPS или также для IMAP / SMTP / OpenVPN и других протоколов с поддержкой SSL?

Текущий вектор атаки, как показали исследователи, работает с управлением открытым текстом, отправляемым на сервер с помощью Javascript, запускаемого на компьютере жертвы. Этот вектор не применяется к сценариям, отличным от HTTPS, без использования браузера.

Кроме того, обычно SSL-клиент не позволяет понизить рейтинг сеанса до SSLv3 (наличие TLSv1 + видно в возможностях рукопожатия), но браузеры хотят быть очень обратно совместимыми, и они это делают. Комбинация с управлением открытым текстом и специфическим способом создания HTTP-заголовка делает его пригодным для использования.

Вывод: отключите SSLv3 для HTTPS сейчас, отключите SSLv3 для других служб в следующем окне службы.

Каково это влияние? Нужно ли мне отзывать и восстанавливать сертификат моего сервера? (Как в случае с Сердечным кровотечением)

Нет, для этого вам не нужно менять свои сертификаты. Уязвимость предоставляет возможность восстановления открытого текста из данных сеанса, она не предоставляет доступа к каким-либо секретам (ни к сеансовому ключу, ни к ключу сертификата).

Злоумышленник, скорее всего, способен украсть только заголовки открытого текста, такие как файлы cookie сеанса, для выполнения перехват сеанса. Дополнительным ограничением является необходимость полного (активного) Атака MitM.

Есть ли что-нибудь еще, что я могу сделать, чтобы улучшить свою конфигурацию SSL в целом?

Как пользователь, помимо отключения SSLv3 в вашем браузере, на самом деле нет. Что ж, просто всегда устанавливайте последние обновления для системы безопасности.

Для серверов следуйте инструкциям Руководство по TLS-серверу Mozilla. И протестируйте с Тест SSL Labs от Qualys. На самом деле не так уж сложно получить рейтинг A+ на вашем сайте. Просто обновите свои пакеты и выполните рекомендации из руководства Mozilla.

Но мне действительно очень нужна поддержка SSLv3... по причинам X, Y, Z! Что теперь?

Что ж, есть исправление, которое позволяет обойти атаку на понижение версии клиентов, поддерживающих TLSv1, называемую резервной защитой SSLv3. Кстати, это также улучшит безопасность TLSv1 + (атака с понижением рейтинга сложнее / невозможна). Он предлагается в качестве бэкпорта из более поздней версии OpenSSL в руководстве по безопасности Ubuntu usn-2385-1.

Большой подвох: для работы этот патч нужен как клиентам, так и серверам. Итак, на мой взгляд, пока вы обновляете как клиентов, так и серверы, вам все равно следует просто перейти на TLSv1 +.

Однако, пожалуйста, пожалуйста, просто отключите SSLv3 в своей сети на данный момент. Приложите усилия к повышению стандартов безопасности и просто откажитесь от SSLv3.

Я слышал о поддержке SCSV для устранения атаки на понижение протокола. Нужно ли мне это?

Только если вам действительно нужен SSLv3 по какой-то странной причине, но он также повышает безопасность в TLSv1 +, так что да, я бы рекомендовал вам установить его. Ubuntu предоставляет обновление для этой функции в usn-2385-1. Вы получите его через регулярные обновления безопасности в вашем диспетчере пакетов.

Тестирование уязвимости для частных сайтов (например, интранет/оффлайн).

Ваши серверы уязвимы просто в том случае, если они поддерживают SSLv3. Здесь есть несколько вариантов:

  • С помощью OpenSSL s_client:

    openssl s_client -connect <server>:<port> -ssl3

    Если соединение выполнено успешно, sslv3 включен. Если это не удается, он отключается. Когда это не удается, вы должны увидеть что-то вроде:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
  • С помощью nmap:

    nmap --script ssl-enum-ciphers -p 443 myhostname.tld

    Он должен выводить 'SSLv3: No supported ciphers found'. Настройте свое имя хоста/порт.

  • С помощью шифровальщик. Клонируйте/загрузите двоичный файл и выполните его:

    ./cipherscan myhostname.tld

    Это должно нет перечислите все, что имеет SSLv3, в столбце "протоколы".


Браузер Firefox

Открыть about:config, найти security.tls.version.min и установите значение равным 1. Затем перезапустите свой браузер, чтобы удалить все открытые SSL-соединения.

Firefox начиная с версии 34 и далее по умолчанию отключает SSLv3 и, следовательно, не требует никаких действий (источник). Однако на момент написания статьи 33 только что выпущен, а 34 назначен на 25 ноября.


Google Chrome (Linux)

Отредактируйте /usr/share/applications/google-chrome.desktop файл, например

sudo nano /usr/share/applications/google-chrome.desktop

Редактировать все линии начиная с Exec= включать --ssl-version-min=tls1.

Например, строка, подобная

Exec=/usr/bin/google-chrome-stable %U

становится

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

Затем убедитесь, что вы полностью закрыли браузер (приложения Chrome могут поддерживать активность вашего браузера в фоновом режиме!).

Примечание: Возможно, вам придется повторять это при каждом обновлении пакета Google-chrome, перезаписывая это .desktop файл запуска. Браузер Google Chrome или Chromium с отключенным по умолчанию SSLv3 на момент написания статьи еще не анонсирован.


Сервер Apache HTTPD

Если вы используете веб-сервер Apache, который в настоящее время поддерживает SSLv3, вам нужно будет отредактировать конфигурацию Apache. В системах Debian и Ubuntu файл является /etc/apache2/mods-доступно/ssl.conf. В CentOS и Fedora файл является /etc/httpd/conf.d/ssl.conf. Вам нужно будет добавить следующую строку в вашу конфигурацию Apache с другими директивами SSL.

SSLProtocol All -SSLv2 -SSLv3

Это позволит использовать все протоколы, кроме SSLv2 и SSLv3.

Пока вы этим занимаетесь, вы можете рассмотреть возможность улучшения конфигурации ciphersuite для вашего веб-сервера, как описано в Руководство по TLS-серверу Mozilla. Добавьте, например:

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHASSLHonorCipherOrder     onSSLCompression          off# Read up on HSTS before you enable it (recommended)# Header add Strict-Transport-Security "max-age=15768000"

Затем проверьте правильность новой конфигурации (отсутствие опечаток и т.д.):

sudo apache2ctl configtest

И перезагрузите сервер, например

sudo service apache2 restart

На CentOS и Fedora:

systemctl restart httpd

Дополнительная информация: Документация Apache

Теперь протестируйте его: если ваш сайт общедоступен, протестируйте его с помощью Инструмент SSL Labs от Qualys.


Сервер Nginx

Если вы используете Nginx, просто включите следующую строку в свою конфигурацию среди других директив SSL:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Пока вы этим занимаетесь, вы можете рассмотреть возможность улучшения конфигурации ciphersuite для вашего веб-сервера, как описано в Руководство по TLS-серверу Mozilla. Добавьте, например:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';ssl_prefer_server_ciphers on;# Read up on HSTS before you enable it (recommended)# add_header Strict-Transport-Security max-age=15768000;

И перезагрузите сервер, например

sudo service nginx restart

Ссылка: Документация Nginx

Теперь протестируйте его: если ваш сайт общедоступен, протестируйте его с помощью Инструмент SSL Labs от Qualys.


Веб-сервер Lighttpd

>Версии Lighttpd 1.4.28 поддерживают опцию конфигурации для отключения SSLv2 и v3. Версии Lighttpd, выпущенные до версии 1.4.28, позволяют отключать только SSLv2. Пожалуйста, обратите внимание, что Ubuntu 12.04 LTS и более ранние версии устанавливаются в лучшем случае lighttpd v1.4.28, и поэтому простое исправление недоступно для этих дистрибутивов. Поэтому это исправление следует использовать только для версий Ubuntu, превышающих 12.04.

Для Ubuntu версии 12.04 или Debian 6 обновленный пакет lighttpd доступен из репозитория openSUSE:http://download.opensuse.org/repositories/server:/http/Debian_6.0

Пакет предназначен для Debian 6 (squeeze), но работает также на 12.04 (точный)

Отредактируйте свой /etc/lighttpd/lighttpd.conf чтобы добавить следующие строки после ssl.engine = "enable" директива

ssl.use-sslv2          = "disable"ssl.use-sslv3          = "disable"

Затем вы должны перезапустить службу lighttpd с помощью sudo service lighttpd restart и выполните тест рукопожатия ssl3, как описано в предыдущих разделах, чтобы убедиться, что изменение было успешно реализовано.

Взято из http://redmine .lighttpd.net/projects/lighttpd/wiki/Docs_SSL.


Постфиксный SMTP

Для "оппортунистического SSL" (политика шифрования не применяется, и обычная тоже приемлема) вам не нужно ничего менять. Даже SSLv2 лучше, чем обычный, поэтому, если вам нужно защитить свой сервер, вы все равно должны использовать режим "обязательного SSL".

Для уже настроенного режима "обязательного SSL" просто добавьте /измените smtpd_tls_mandatory_protocols настройка для входящих подключений и smtp_tls_mandatory_protocols для исходящих подключений:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

При желании, если вы хотите отключить SSLv3 и для оппортунистического шифрования (даже если в этом нет необходимости, как объяснено выше), сделайте это следующим образом:

smtpd_tls_protocols=!SSLv2,!SSLv3smtp_tls_protocols=!SSLv2,!SSLv3

и перезапустить Postfix:

sudo service postfix restart

Отправить почту

(Непроверенная правка анонимного пользователя, мне не нравится Sendmail, пожалуйста, проверьте.)

Эти параметры настраиваются в LOCAL_CONFIG раздел вашего sendmail.mc

LOCAL_CONFIGO CipherList=HIGHO ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCEO ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

Голубятня

В Dovecot v2.1+ добавьте следующее в свой /etc/dovecot/local.conf (или новый файл в /etc/dovecot/conf.d):

ssl_protocols = !SSLv2 !SSLv3

и перезапустить Голубятню:

sudo service dovecot restart

Для более старых версий вам придется исправьте исходный код.


Курьер-imap (imapd-ssl)

Courier-imap по умолчанию разрешает SSLv3 в Ubuntu 12.04 и других. Вы должны отключить его и вместо этого использовать STARTTLS для принудительного использования TLS. Отредактируйте свой /etc/courier/imapd-ssl конфигурационный файл, отражающий следующие изменения

IMAPDSSLSTART=NOIMAPDSTARTTLS=YESIMAP_TLS_REQUIRED=1TLS_PROTOCOL=TLS1TLS_STARTTLS_PROTOCOL=TLS1TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"

Сервер HAProxy

>SSL поддерживается в HAProxy = 1.5.

Отредактируйте /etc/haproxy.cfg файл и найдите свой bind линия. Добавлять no-sslv3. Например:

bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3

Ссылка: Документация HAProxy


OpenVPN

По-видимому, это не повлияло (источник).

>OpenVPN использует TLSv1.0 или (с =2.3.3) необязательно TLSv1.2 и, таким образом, не подвержен влиянию POODLE.


Марионетка

Puppet использует SSL через HTTPS, но он не используется клиентами "браузера", только агентами Puppet, которые не уязвимы для показанного вектора атаки. Тем не менее, лучше всего просто отключить SSLv3.

Моя рекомендация состоит в том, чтобы использовать стивен Джонсон/кукольный модуль Кукольный модуль для настройки вашего кукловода, в котором Я убил SSLv3 некоторое время назад.

Возможно, это не относится к ubuntu, но для того, чтобы обойти уязвимость Poodle в Node.js вы можете установить secureOptions к require('constants').SSL_OP_NO_SSLv3 когда вы создаете сервер https или tls.

Видеть https://gist.github.com/3rd-Eden/715522f6950044da45d8 для получения дополнительной информации

"Исправление" для courier отключает tls 1.1 и tls 1.2. Похоже, что нет способа запустить courier с tls 1.1 или выше.Сканирование PCI на вашем сервере может выдать следующую рекомендацию:

Настройте серверы SSL/TLS так, чтобы они использовали только TLS 1.1 или TLS 1.2, если они поддерживаются.Настройте серверы SSL/TLS так, чтобы они поддерживали только наборы шифров, которые не используют блочные шифры.

Поскольку уязвимость POODLE является недостатком дизайна в самом протоколе, а не ошибкой реализации, исправлений не будет. Единственный способ смягчить это - отключить SSLv3 на сервере apache. Добавьте приведенные ниже строки в ssl.conf и выполните изящный перезапуск apache.

SSLProtocol all -SSLv2 -SSLv3SSLHonorCipherOrder onSSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

А? Как вы ожидаете более практичного решения, чем “Если вы не установите патчи, то Нидхеггр сожрет вашу селезенку”?

Более подробную информацию можно найти здесь Уязвимость SSL3 “Poodle”

@Braiam Прежде всего: ** патча нет ** (прочтите мой ответ). Я думаю, что Томас имеет в виду бытовую технику, а не хостинг веб-серверов DIY-Ubuntu. Устройства, такие как балансировщики нагрузки, обычно предлагают обновления встроенного ПО для изменения настроек по умолчанию или предлагают функциональность, позволяющую его настроить. Однако в Ubuntu все зависит от пользователя / администратора.

@Braiam Да, я знаю, снова блестящий Томас! Тем не менее, это очень криптографически ориентированные вопросы и ответы. Предполагается, что эти вопросы и ответы по AU содержат практическую и ориентированную на Ubuntu информацию. :slight_smile:

На самом деле так оно и есть: поставщики могут отключить / удалить весь код, связанный с SSLv3, поэтому вам вообще не нужно ничего трогать.

@Braiam О да, конечно. Например, то, что сделано с SSLv2. Я полностью понимаю, что это то, что операционная система может решить за вас. Но на самом деле, полное отключение его в коде, таком как OpenSSL, скорее всего, сломает больше, чем исправит материал для этого конкретного случая и на данный момент. Пожалуйста, обратите внимание, что HTTPS отображается только как вектор атаки, а OpenSSL используется не только на вашем веб-сервере, для которого SSLv3 может быть “прекрасным” (просто не очень хорошим).

а? SSLv3 устарел уже более… ммм… более 10 лет? Кроме того, не кажется ли вам, что если бы влияние отключения в исходном коде SSLv3 было настолько важным, Google (и другие интернет-гиганты) отключили бы его на стороне сервера? В любом случае, все соединения SSLv3 представляют “только 0,3% от transactions” таким образом, решение, в котором пользователь даже не участвует, кажется лучшим подходом.

@Braiam Для любого будущего выпуска Ubuntu: да! Релиз точки LTS? может быть.