вторник, 27 октября 2015 г.

Squid: SSL Bump и Windows Update

Администраторы новых версий Squid - 3.5.x и 4.x.x - неожиданно для себя выяснили, что Windows Update с использованием SSL Bump не работают.

Для Squid 3.4.x проблема решалась относительно просто. Достаточно было вычислить все IP-диапазоны авторизационных серверов MS, добавить их в ACL no-bump, и порядок. Ну, и время от времени, обновлять эти диапазоны по необходимости. В какой-то момент обеспечивалось достаточное перекрытие сетей MS и бОльшая часть обновлений кэшировалась, а проблем у клиентов не возникало.

С новыми версиями Squid, однако, картинка не настолько радостная. no-bump по dst уже не работает, так как используется принципиально иная алгортимтическая схема peek-n-splice.

И, для того, чтобы выполнить no-bump, а, точнее, splice, нужно указывать не IP, а имя сервера/серверов.

Допустим, что вы - умная маша, сделали sniffing сессии WU, и увидели некоторые адреса авторизационных серверов до получения ошибки WindowsUpdate_80072F8F или чего-то подобного. Вы видите IP, скажем, 191.234.72.190. Делаете реверсивный запрос - обана! - и получаете примерно вот это:


Чешете репу и пытаетесь запихнуть адрес в no-bump. Опа! - не работает.

Все просто, мальчики и девочки. Вам нужно добавить в ACL splice всего три сервера:
 fe1.update.microsoft.com.akadns.net  
 fe2.update.microsoft.com.akadns.net  
 fe2.update.microsoft.com  

Сделайте так. Напишите файл url.nobump:

 # WU (Squid 3.5.x and above with SSL Bump)  
 # Only this three sites must be spliced.  
 fe1\.update\.microsoft\.com\.akadns\.net  
 fe2\.update\.microsoft\.com\.akadns\.net  
 fe2\.update\.microsoft\.com  

Добавьте его в свой squid.conf в группу правил SSL Bump:

 acl DiscoverSNIHost at_step SslBump1  
 acl NoSSLIntercept ssl::server_name_regex -i "/usr/local/squid/etc/url.nobump"  
 ssl_bump splice NoSSLIntercept  
 ssl_bump peek DiscoverSNIHost
 ssl_bump bump all  

Все. Ошибка ушла навсегда. Вам больше не надо вылавливать сети MS, используя сниффер и tcpiputils.com

Одно предупреждение напоследок: Часть обновлений Windows может не кэшироваться ввиду попадания CDN на адреса диапазонов данных серверов. Я вас предупредил.

UPDATE

Не совсем все. Как оказалось, WU в некоторых случаях все еще использует в стартовых соединениях HTTPS с сайферами, использующими RC4 и 3DES. Если вы сконфигурировали свой набор сайферов на прокси по рекомендациям Мозиллы, вы рискуете получить ошибку  WindowsUpdate_80072F8F снова и сразу в момент начала процесса обновления. Чтобы избежать этого, вам необходимо модифицировать список используемых сайферов прокси сделующим образом:

 sslproxy_cipher HIGH:MEDIUM:RC4:3DES:!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!SRP:!DSS  

Такой же набор надо выбрать и на стороне прокси, обращенной к клиенту:

 http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/usr/local/squid/etc/rootCA2.crt key=/usr/local/squid/etc/rootCA2.key cafile=/usr/local/squid/etc/rootCA12.crt options=SINGLE_ECDH_USE tls-dh=prime256v1:/usr/local/squid/etc/dhparam.pem cipher=HIGH:MEDIUM:RC4:3DES:!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!SRP:!DSS