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

После атаки BEAST и ошибки Heartbleed теперь я слышал о новой уязвимости в SSL / TLS под названием POODLE . Как я могу защитить себя от эксплуатации?

• Это касается только серверов или клиентов?
• Это специфично для OpenSSL / GnuTLS?
• На какие услуги это влияет? Только HTTPS или также IMAPS, SMTPS, OpenVPN и т. Д.?

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

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

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

Недавнее открытие, проведенное инженерами Google, указывает на то, что SSLv3 больше не следует использовать (например, SSLv2 давно устарел). Клиенты, которые не смогут подключиться к вашему сайту / услуге, вероятно, очень и очень ограничены. CloudFlare объявила, что менее 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. Но, эй, если вы не уверены, вот и вы:

POODLE показывает, что 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 для других служб в следующем окне службы.

Какое влияние? Нужно ли отозвать и восстановить свой сертификат сервера? (Как с Heartbleed)

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

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

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

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

Для серверов следуйте руководству сервера TLS Mozilla . И тест с тестом Qualys SSL Labs . Получить рейтинг 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-available/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-SHA
SSLHonorCipherOrder     on
SSLCompression          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

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

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

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

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 с помощью a 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,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

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

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

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

sudo service postfix restart

Отправить письмо

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

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

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

голубятня

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

ssl_protocols = !SSLv2 !SSLv3

и перезапустите Dovecot:

sudo service dovecot restart

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

Курьер-имап (imapd-ssl)

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

IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"

HAProxy Server

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

Отредактируйте /etc/haproxy.cfgфайл и найдите свою bindстроку. Append 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.

Я рекомендую использовать модуль Puppet stephenrjohnson / puppetmodule для настройки вашего мастера Puppet, в котором я убил SSLv3 некоторое время назад.

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

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

«Исправление» для курьера отключает tls 1.1 и tls 1.2. Кажется, нет способа запустить курьера с TLS 1.1 или выше. Сканирование PCI на вашем сервере может вернуться с рекомендацией:

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

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

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "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"