среда, 2 сентября 2015 г.

Squid 3: Харденинг при использовании SSL Bump

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

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

Не поленитесь зайти из-за прокси с включенным бампом вот сюда https://www.ssllabs.com/ssltest/viewMyClient.html . Узнаете массу нового о ваших внешних соединениях.

Прежде всего, вы можете увидеть экспортное шифрование - да-да, то самое, 56 бит. Как вы считаете, в 2015 году это нормально? Ах, вы не знали....


И даже 40-битное:

Ну а про SSLv3 я просто умолчу.

Итак.

Поднимая бампинг SSL, стоит сразу же - сразу же! - позаботиться о харденинге.

Думаю, вы уже знаете, что опции сервера в Squid задаются в sslproxy_* параметрах, а опции соединений от прокси до клиента - в http(s)_port.

Первое, что посоветовал бы вам лично я - отключить SSLv3 на обеих сторонах, совсем, и задать набор сайферов покруче умолчания. Выбрав, хотя бы, вот такие (от Мозиллы):

sslproxy_options NO_SSLv3,SINGLE_DH_USE
sslproxy_cipher 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

(строка sslproxy_cipher пишется в одну строчку, вы помните, да?)

Обратите внимание - sslproxy_options разделяет опции запятыми ',' или ':'. Это не документировано (на данный момент) и совершенно не очевидно. В случае, если вы напишете опции через пробел, действовать будет только первая и сквид при запуске или проверке конфигурации даже не гавкнет на эту строку.

После перезапуска прокси и проверки клиента вы должны увидеть примерно следующее:


То есть никаких экспортных шифров, никаких SSLv3 и так далее. В идеале соединение от клиента до веб-сервера идет с использованием TLSv1.2.

Все?

Как бы не так. Если вы с клиента посмотрите на замочек, то увидите надпись "Соединение зашифровано с использованием устаревших наборов шифров". Да-да, несмотря на зеленый замочек - а иногда он будет вполне себе перечеркнутый красным.

В чем дело?

Дело в том, что по умолчанию, если вы явно не задали в строке http(s)_port параметров DH-обмена, используются действительно устаревшие пары, не EDH, а DH. Вы, конечно, понимаете, насколько эфемеральные DH-пары на данный момент безопаснее.

Итак, вы открываете squid.cache.documented, внимательно его читаете и видите следующее:


# dhparams= File containing DH parameters for temporary/ephemeral
# DH key exchanges. See OpenSSL documentation for details
# on how to create this file.
# WARNING: EDH ciphers will be silently disabled if this
# option is not set.



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

Ладно, это ваши проблемы.

В любом случае нас не устраивает тот факт, что мы по-прежнему используем устаревшую аутентификацию.

Как это исправить?

Во-первых, надо создать этот самый файл DH-параметров. Он небольшой (хотя создаваться может довольно долго):


openssl dhparam -outform PEM -out dhparam.pem 2048


После его создания его надо положить в место, доступное прокси и задать в http(s)_port строчках (тех из них, для которых включен SSL-бамп):



https_port 3129 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/usr/local/squid/etc/rootCA.crt key=/usr/local/squid/etc/rootCA.key options=NO_SSLv3 dhparams=/usr/local/squid/etc/dhparam.pem

Теперь надо реконфигурировать прокси и - вуаля! Готово.


Обратите внимание - SSLv3 отключен на обеих сторонах соединения. Старые версии клиентов и серверов будут отказывать в соединении - будьте готовы к жалобам пользователей. Пусть обновляют софт и свои предпочтения. Потому что SSLv3 в 2015м году никто не использует - как небезопасный.

К вашему большому сожалению, это не все.

Совместимость

Во-первых, осталось достаточно большое количество сайтов, в цепочке сертификатов которых исторически остались подписанные SHA-1. Вы будете их видеть. Как правило. И пользователи будут видеть. Особенно пользователи Хрома. Он гавкает на сколько-нибудь небезопасное в TLS.

Во-вторых, ваш прокси будет посылать пользователей подальше на весьма многих сайтах. Или не отображать часть контента. Начиная с mail.ru и java.com. Ввиду несовместимости набора сайферов. Да, там тоже сидят рукосуи. И там посейчас используется старье.

Вам придется добавить набор сайферов HIGH в вашу конфигурацию. Вот так:



sslproxy_cipher EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

Все остальное оставляете без изменений.

Не забудьте, что именно добавили. Со временем это придется убирать.

Вот теперь действительно все.

PS. Я остаюсь при своем мнении, что HTTPS-зло. И все вышеописанное не более, чем театр безопасности.