Пользователь
0,0
рейтинг
7 февраля 2013 в 14:32

Администрирование → Squid3 в режиме SSLBump с динамической генерацией сертификатов tutorial

Приветствую.

Шифрованный веб-трафик вещь хорошая, но порой совершенно не ясно что пользователь там, внутри, делает. При заходе на любой https ресурс через squid, в логи записывается достаточно строк подобного вида:

1330231066.104 10 172.26.27.8 TCP_MISS/200 390 CONNECT mail.google.com:443 — HIER_DIRECT/173.194.32.54 —
1330241192.883 9 172.26.27.97 TCP_MISS/200 390 CONNECT mc.yandex.ru:443 — HIER_DIRECT/213.180.193.119 —

Видно, что в определённое время пользователи зашли на gmail и яндекс. В принципе вот и всё что мы видим из логов. Но не понятно выполнялся ли GET или POST запрос, не видно полных урлов, ни размеров файлов. Так же нет возможности проверить ssl трафик антивирусной программой либо какими content inspection программами.

В этой статье я хочу описать возможность squid'а «разламывать» ssl соединение и иметь хоть какой-то обзор происходящего в https трафике.



Так как на CentOS стоит «усиленный» openssl, то сборка squid'а c необходимыми нам ключам не получается.
Есть два варианта решения данной проблемы.
Первый — это лезть в инклюд файлы установленного openssl, потом в исходники сквида и менять некоторые строки. И второй — это собирать сквид с кастомным openssl.

Первый вариант слишком хардкорный и оставим его в стороне.

1. openssl

Итак, для начала нам надо собрать свой openssl. Тут всё довольно просто и никакой магии:

wget www.openssl.org/source/openssl-1.0.0k.tar.gz
tar -zxf openssl-1.0.0k.tar.gz
cd openssl-1.0.0k

Что бы не было конфликтов с уже установленной версией openssl, указываем новый путь:

./config shared --prefix=/opt/squid/openssl --openssldir=/opt/squid/openssl
make
make install
Всё, openssl собран и готов к использованию.

2. squid

Сборка прокси сервера аналогична сборке любой программы (configure && make && make install), единственное это указание определённых ключей при компиляции:

wget www.squid-cache.org/Versions/v3/3.2/squid-3.2.7.tar.gz
tar -zxf squid-3.2.7.tar.gz
cd squid-3.2.7
./configure --prefix=/opt/squid --enable-ssl --enable-ssl-crtd --with-openssl=/opt/squid/openssl

--enable-ssl — включает поддержку ssl режима
--enable-ssl-crtd — генерацией сертификатов занимается отдельный процесс, а не сам прокси сервер.
--with-openssl — путь куда был установлен кастомный openssl

make all
make install
Так, squid прокси сервер собран.

3. Генерируем self-signed сертификат

Сертификат будет использоваться прокси сервером для создания динамических сертификатов веб сайтов.

cd /opt/squid/etc/
openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout squidCA.pem -out squidCA.pem

Так как файл squidCA.pem содержит приватный ключ, делаем его читаемым только для пользователя root:
chmod 400 squidCA.pem

4.Настраиваем squid

Добавим следующие строки в squid.conf файл
http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/opt/squid/etc/squidCA.pem
always_direct allow all
ssl_bump allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

данную настройку нежелательно использовать в продукционной системе, так как доступ разрешён на все https сайты с любыми сертификатами.

Подготавливаем кэширование сертификатов:
mkdir /opt/squid/var/lib
/opt/squid/libexec/ssl_crtd -c -s /opt/squid/var/lib/ssl_db
chown -R nobody /opt/squid/var/lib/ssl_db
Если у вас в настройке cache_effective_user стоит другое UID, то вместо nobody следует использовать его.

Стоит заметить, что если по какой-то причине вы поменяли ваш сертификат для squid'а, то надо полностью очистить каталог /opt/squid/var/lib/ssl_db и заново инициализировать сертификатную базу данных.

Выставляем необходимые права, инициализируем и запускаем прокси сервер:
chown -R nobody /opt/squid/var/logs
/opt/squid/sbin/squid -z
/opt/squid/sbin/squid
проверяем файл /opt/squid/var/logs/cache.log на наличие ошибок, если ошибок нет и имеется строка "Accepting SSL bumped HTTP Socket connections at local=[::]:3128 remote=[::] FD 21 flags=9", то прокси сервер в режиме SSLBump запущен.

5. пользовательские проблемы

Так как в данном случае мы используем self-signed сертификат, любые посещения https сайтов через прокси будут показывать пользователям ошибку сертификата. Причина ошибки — Issuer нашего сертификата не находится в списке Trusted CA в браузере.
Что бы ошибок не было, выполняем следующее действие.

openssl x509 -in squidCA.pem -outform DER -out squid.der

Теперь полученный файл squid.der надо импортировать в клиентский браузер.
Для Internet Explorer:
Tools->Internet Options->Content->Certificates
Выбираем закладку «Trusted Root Certificate Authorities»
Жмём Import, выбираем файл squid.der и завершаем импорт.

Для Firefox:
Tools->Options->Advanced->Encryption->View Certificates
Выбираем закладку «Authorities»
Жмём Import, выбираем файл squid.der и завершаем импорт.

Ну вот в общем то всё. В зависимости от ваших фантазий, теперь у вас есть возможность в https трафике запретить делать POST запросы, скачивать большие файлы, закрыть доступ к определённым файлам/папкам. Так же можно запретить доступ на сайты, сертификаты которых выданы не доверенными CA. Ну и возможность проверять на вирусы.

Спасибо за внимание,
@timukas
карма
14,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (17)

  • +1
    «Береги корневые сертификаты смолоду» © народная мудрость
    • 0
      Корневой сертификат обычно уже в публичном доступе. Вот с приватными ключами да — надо беречь.
  • +2
    нет возможности проверить ssl трафик антивирусной программой

    какие мы заботливые…

    p.s.
    ./chrome --no-running-insecure-content --no-displaying-insecure-content
    • 0
      А как же без заботы в нашё время?

      В добавок к антивирусу ещё можно DLP прикрутить. Что б не выносился «сор из избы».
  • +1
    Десктопным браузерам можно подсунуть корневой сертификат, а как быть с другим П.О., Айосами и Андроидами?

    Например, Dropbox при таком варианте не работает.
    • 0
      Для iOS есть iPhone Configuration Utility, которая умеет добавлять корневые CA, настраивать профили VPN и делать подобные вещи. Для Android должно быть что-то похожее.
      А небезопасный софт можно запретить либо использовать более навороченный DPI.
      • 0
        Это ключи для VPN, доступ к корневым сертификатам получить сложнее, для android надо потрошить прошивку и менять там 1 файл.
        • 0
          Тут пишут, что в 4.0 появился мастер импорта сертификатов.
          • 0
            Спасибо!
            Как я понял, все равно надо рутованный андроид для этого.
            • 0
              Там специально выделено: NO root-access is required, а ниже уже идут инструкции по рутованию предыдущих версий.
    • 0
      У меня при таком варианте не работает Dropbox, qip — icq и есть проблема с фесбуком на Mozilla (на хроме работает нормально), а на планшете под Android почему-то не открывается gmail.com, но работает фейсбук.
      Я так понимаю Dropbox нужно пускать мимо squid?
  • –1
    Подскажите, Squid умеет проверять https-трафик в прозрачном режиме, а не только в режиме прокси?
  • 0
    Хорошая статья.

    Порты в прокси лучше разнести, т.к были замечены глюки/ошибки загрузок страниц, и сквидовские сообщения loop-detected, например так:
    http_port local_ip:3128
    http_port local_ip:3129 intercept
    https_port local_ip:3130 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/tmp/squid.pem key=/tmp/squid.pem
    


    Ещё добавлю — проксирование без подмены сертификата (и соответственно заморочки с установкой пользователям
    самописного сертификата) можно избежать, если прописать
    ssl_bump none
    В этом случае генерация сертификата и его подмена производится не будет, и сквид просто пропустить HTTPS-соединение.

    Для сгенерированных сертификатов актуальная опция:
    ssl_bump server-first all # Для того, чтобы в CN был домен, а не IP

    Прозрачное проксирование работает нормально, к примеру, для freebsd остаточно строк:
    #
    ipfw add 50 allow tcp from me to any 80,443 out via ${extif} keep-state uid squid
    #http
    ipfw add 51 fwd local_ip,3129 tcp from ${lan} to any 80 out via ${extif}
    #https
    ipfw add 52 fwd local_ip,3130 tcp from ${lan} to any 443 out via ${extif}
    

    А вот с фильтрацией https-трафика в этом году возникла новая неприятная ситуация. Оригинал:

    === выдержка из документации сквида ===
    Примерный перевод:
    Некоторые браузеры отправляют IP-адреса в запросы на подключение, даже если пользователь ввел имя сервера (url — не ip) в адресной строке. Ничего не можем с этим поделать, т.к мы не отвечаем за исходный код браузеров.

    Оригинал:
    Some browsers (e.g., Rekonq browser v0.7.x) send IP addresses in CONNECT requests even when the user typed a host name in the address bar. Squid cannot handle both such browsers and URLs with IP addresses instead of host names because Squid cannot distinguish one case from another. There is nothing we can do about it until somebody contributes code to reliably detect CONNECT requests from those «unusual» browsers.
    === выдержка из документации сквида ===

    И эти «некоторые браузеры» — это все современные (хром, ie11 и прочие) просто перестали обращатся в сайтам по доменному имени, передавая в строке не URL, а исключительно IP :(

    Соответственно, если мы хотим запретить, например, вход на mail.ru по домену — то мы можем это сделать только для пользователей с Win XP, и максимально IE8.

    Пример из лога сквида (вырезка 1 строчки из входа на mail.ru):
    === https-запрос от пользователя на XP с IE8 ===
    1409725807.296 317 192.168.21.6 TCP_MISS/200 341 CONNECT rs.mail.ru:443 — HIER_DIRECT/94.100.181.196 — === https-запрос от пользователя на XP с IE8 ===

    === https-запрос от пользователя на XP с IE11 ===
    1409733165.939 2034 192.168.21.77 TCP_MISS/200 1392 CONNECT 94.100.181.196:443 — HIER_DIRECT/94.100.181.196 — === https-запрос от пользователя на XP с IE11 ===

    Возможно здесь кто подскажет, как выкрутится из ситуации?
    • 0
      Вы уверены что есть проксирование без подмены сертификата?
      Я ничего не нашел по этому поводу.
      Просто в таком случае решится проблема с Android девайсами, не нужно будет устанавливать на них сертификаты и принудительно блокировать экран паролем.
  • 0
    Подскажите есть ли возможность логировать POST запросы(целиком) в сквиде, особенно в режиме ssl_bumping'a?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.