ssl bumping что это
Перехват и раскрытие HTTPS-запросов на прокси-сервере Squid при помощи SSL-Bump
В корпоративной среде клиентские устройства могут быть настроены на использование прокси, и HTTPS-запросы идут через прокси-сервер, используя метод CONNECT, который преобразует запрос в прозрачный TCP/IP-туннель. Чтобы перехватывать и анализировать такой трафик, Squid должен иметь свой собственный СА сертификат, используемый для подписывания динамически генерируемых сертификатов для серверов, к которым подключаются клиенты. Клиентские устройства при этом должны быть настроены на доверие этому СА-сертификату, чтобы проверка сертификатов, созданных Squid, завершалась с положительным результатом.
Схема работы клиента с сервером в этом случае выглядит так:
1. Клиент обращается к серверу, и его запрос приходит на прокси.
2. Прокси возвращает клиенту сгенерированный сертификат для сервера, подписанный CA-сертификатом самого прокси, которому клиент доверяет.
3. Прокси-сервер устанавливает HTTPS-соединение с сервером, который запросил клиент.
4. Прокси-сервер проверяет сертификат сервера, если с ним что-то не так, то клиенту возвращается ошибка.
5. Прокси получает ответ от сервера, расшифровывает его и повторно шифрует с помощью сгенерированного на шаге 2 сертификата, после чего пересылает ответ клиенту.
6. Клиент получает ответ на запрос к серверу.
Приступим к реализации вышеописанного на прокси сервере Squid версии 4.1. Создаем необходимые каталоги для сертификатов
Готовим базу для генерируемых сертификатов
Приводим в порядок права доступа
Создадим СА сертификат и ключ
И подготовим его для импорта в клиентские браузеры
Редактируем squid.conf, директиву http_port приводим к виду
Значение директивы visible_hostname должно совпадать с именем сервера, которое вводилось на стадии генерации сертификата (Common Name)
Настраиваем хелпер генерации сертификатов для сайтов
Дальше будет немного магии.
В Squid есть такая вещь, как ssl-bump. Её настройки определяют, как Squid будет обращаться с HTTPS-запросами. Если ничего не настраивать, то получив запрос на доступ к https-серверу, прокси будет просто устанавливать с ним соединение, используя метод CONNECT. Но если мы настроили наш входящий порт для клиентских запросов на использование ssl-bump (см. выше, что указано в директиве http_port), то Squid получает ряд дополнительных возможностей. Соединение клиента с сервером разбивается на три этапа или «шага»:
И для каждого из этих этапов можно определить, что Squid будет делать c запросами клиентов, а делать можно следующее:
peek — подсмотреть всю доступную информацию без «влезания» в соединение
terminate — закрыть соединение
bump — «влезть» в соединение, сделать https видимым как http
Cоздаем acl с шагами bump.
Теперь определимся, как поступать с клиентскими запросами
«Прозрачный» Squid с фильтрацией HTTPS ресурсов без подмены сертификатов (x86)
Не секрет, что в больших конторах тема фильтрации Интернета довольно актуальная. С этой задачей справляется немало программных и аппаратных решений. Но в настоящее время все те сайты, которые мы резали ранее, работают по протоколу HTTPS, т.е. порт 443. Как известно, данный протокол проследить, прослушать и т. п., невозможно. А любой кеширующий фильтрующий прокси-сервер, редиректор и т. п. фильтрует только HTTP, т.е. порт 80. Как же резать Вконтакте, Одноклассники, iphide.info и многие другие подобные сайты? Как блокировать доступ к личной почте в организации, если использование оной запрещено порядками в организации? Да, можно фильтровать по IP адресам, но они частенько меняются, да и на многих ресурсах несколько IP адресов. Блокировать их на уровне файрвола как-то совсем не православное решение, и не совсем удобное.
И вот, совсем недавно, мне один товарищ рассказал, что он поднимает у себя в конторе кеширующий прокси с фильтрацией HTTPS, меня это заинтересовало.
А поднимал он Squid 3.5.8. Как выяснилось, в нем переработана организация перехвата шифрованных HTTPS-сеансов (ssl_bump), вместо режимов перехвата («modes») введены в обиход действия («actions»), которые в том числе можно использовать в ACL. Режим «server-first», при котором вначале осуществляется соединение с целевым сервером, а потом создаётся защищённое соединение между клиентом и прокси, теперь доступен как действие «bump». Режим «none», при котором создаётся TCP-туннель без дешифровки трафика, теперь доступен как действие «splice».
Для обеспечения обратной совместимости добавлено действие «peek-and-splice», при котором решение о типе создаваемого вначале соединения (клиент-прокси или прокси-сервер) принимается на основе SSL hello-сообщений. Добавлены действия «peek» и «stare» для получения клиентского или серверного сертификата с сохранением возможности дальнейшего применения режимов «splice» и «bump» для соединений. Добавлено действие «terminate» для закрытия соединений к клиенту или серверу. Вот как раз SSL BUMP, PEEK-and-SPLICE и Terminate нам и нужны. Вообще, схема работы на самом деле довольно простая. Squid подключается к HTTPS ресурсу, получает его сертификат, и может «посмотреть» некоторые данные о ресурсе, в частности имя сервера, которое нам как раз и нужно для блокировки! Все мануалы, которые есть в Интернете, то и дело описывают Man in the middle (MITM) атаку с подменой сертификатов, при которой в принципе не работают некоторые сайты и банк-клиенты, да и юзеры явно видят, что за ними следят. Мы же с товарищем совместными усилиями добились сбособа фильтрации и отслеживания HTTPS без подмены сертификатов, без MITM и прочего, и все это в прозрачном режиме без настройки браузеров!
Впоследствии я столкнулся с некоторыми сложностями, в частности Squid начинал сегфолтиться на большой нагрузке. Но проблема была решена. Дело в том, что в Openssl имеются кое какие баги, которые исправлены в библиотеке Libressl. Поэтому необходимо сначала интегрировать в систему Libressl, потом уже после внесения патча в файл bio.cc в исходниках Squid приступать к компиляции последнего. Поехали! Оговорюсь, что у меня используется дистрибутив Debian Jessie x86, и Squid я в итоге собрал версии 3.5.9 (последняя на данный момент версия), и статья рассчитана на более-менее опытного пользователя Linux, так как некоторые моменты опускаются, а говорится лишь самое главное, так как мне лень все разжевывать.
Для начала, подготовимся к сборке пакетов:
Не забудьте перейти в ту папку, где вы будете собирать исходники, чтобы не засрать себе Хоум. Далее скачаем, скомпилируем и установим Libressl:
Собираем и устанавливаем, после чего перечитаем хеши библиотек:
Ну и надо настроить использование LibreSSL по-умолчанию:
Проверим, получилось ли поставить Libressl:
После выполнения этих действий, необходимо отредактировать sources.list, включив туда исходники из ветки testing (это необходимо, так как нам нужно компилировать новый libecap, который в свою очередь необходим для сборки Squid):
Обновим кеш пакетов:
А теперь скачаем из Testing нужные исходники:
Далее соберем libecap:
Удалим старье, и установим новье:
Качаем последний самый свежий и работающий снэпшот Squid’a:
Обновим полученные ранее исходники Squid’a до новых, и далее будем работать уже в директории с новоиспеченными исходниками:
Чтобы все нужные нам плюшки заработали, надо компилировать Squid с нужными опциями, поэтому внесем в debian/rules следующие опции компиляции:
Скачаем патч для bio.cc, который нужен для корректной работы с Libressl, отсюда bugs.squid-cache.org/attachment.cgi?id=3216 и применим его
Теперь можно приступать к компиляции и сборке Squid’а. Но не так быстро! Все скомпилируется без проблем, по крайней мере на х86 архитектуре, но в самом конце, на этапе сборки пакетов deb, вам любезно скажут в консоли: «ай ай ай, не могу понять, какие зависимости нужны для libssl.so.32» (это версия библиотеки из Libressl). Оно и понятно, откуда Debian’у знать о ней. Мы обманем систему, указав опцию «не проверять зависимости», вот так:
А вот теперь приступим к компиляции и сборке:
После сборки установим пакет с языками для Squid’a:
Далее установим новоиспеченные пакеты:
Если система заматерилась на неудовлетворенные зависимости, сделаем:
Почти готово. Перейдем в каталог /etc/squid, кое-что там изменим. Создадим pem файлик, необходимый для SSL-Bump’инга:
И приведем squid.conf к следующему виду:
Немного расскажу про конфиг. Документация по ssl_bump, peek-n-splice довольно обширная, но для нашей задачи необходимо знать следующее. Есть несколько этапов «handshaking» (т.е. рукопожатие, взаимодействие с сервером). Описаны они в оф.документации. Нас интересует пример Peek at SNI and Bump. То есть, как следует из названия, мы смотрим SNI-информацию и бампим соединение. Перед этим, мы указываем опцией DONT_VERIFY_PEER, что необходимо принимать сертификаты даже, если они не прошли проверку и опцией sslproxy_cert_error указываем, что нужно отключить проверку сертификатов на сервере. Указанное правило «acl step1 at_step SslBump1» — это есть первый из трех возможных шагов ssl_bump’а. При выполнении этого шага мы получаем только SNI, и ничего более. Нам этого достаточно. Дальше мы используем этот ACL строкой ssl_bump peek step1, то есть непосредственно смотрим SNI, а уже после этого блокируем соединение, если в SNI найден server_name из списка blocked.
Далее завернем файрволом нужные порты на Squid:
Все готово! Можно торжественно запускать Squid:
Посмотрим, все ли со Squid’ом нормально:
Если ошибок нет, можно работать. К сожалению, при блокировке HTTPS ресурсов, не появляется сообщение Squid’a «Доступ запрещен», а вместо этого браузер выдает ошибку о невозможности создания соединения. Если кто-то подскажет, как это сделать, буду очень рад.
UPD: в версии Кальмара, которую компилировал я изначально, т.е. 3.5.9, найден досадный баг (или фича), из-за которого спустя время перестают открываться некоторые HTTPS сайты. Решение: компилировать версию 3.5.8.
UPD2: создал очередной багрепорт по проблеме в 3.5.9, тему буду обновлять, если что-то прояснится.
UPD3: вышла версия 3.5.10 с исправленными багами, по крайней мере, патч на файл bio.cc там уже применен. Не тестировал пока-что
UPD4: подредактировал статью немного.
UPD5: прямая ссылка для скачивания архива со всеми нужными пакетами (SQUID 3.5.8), пока-что это единственная рабочая версия! Остальные, которые версиями выше, имеют баг, из-за которого Squid перестает работать при прозрачном проксировании HTTPS. ВЕРСИЯ ДЛЯ Х86.
ВНИМАНИЕ. Во избежание недоразумений, ставьте версию 3.5.8! На ней нет никаких проблем, и если сделано все точно по статье, то все будет работать! Если ставите версию выше, то я не гарантирую правильной работы прозрачной фильтрации!
Очередное Update. в src-репозитарии Debian Testing теперь 3.5.10. добавляйте в sources.list src-репозитарий squeeze. Там версия 3.1, но ничего страшного, все обновится до версии 3.5.8 как надо, только пути к каталогам измените в соответствии с версией скачанных исходников!
UPD 02.12.15: Я прошу прощения, если заставил кого-то костылить. Перезалил архив squid 3.5.8, там не хватало одного deb пакета! squid 3.5.8_all.
UPD 02.12.15: Внимание! Если у вас проблема с установкой libressl, то нужно сделать так: сначала поставить openssl, а затем уже ставить libressl (если ставите версию из архива с пакетами, то не забывайте сделать замену openssl на libressl, как в статье!). Это решит проблему «невидения» библиотеки libssl.so.32
UPD 10.12.15: Появилась следующая версия статьи, с немного другим подходом к компиляции Кальмара и сборке пакетов. Вот тут
UPD 14.12.15: спешу поделиться с коллегами отличной новостью! Я нашел способ заставить работать новые версии Squid’а без особых танцев с бубном! Необходимо, чтобы у клиентов и в настройках Squid’а были одинаковые DNS! В моем случае, на шлюзе с Кальмаром крутится Bind. Назначил клиентам именно его, и Кальмару директивой:
. После чего все успешно заработало. Проверено на Squid 4.0.3, собрана БЕЗ Libressl!
UPD 14.12.15: не знаю почему, но в данный момент на Debian 8.2 при сборке Squid’a описанным выше способом выдается сообщение о том, что файл mime.conf не найден. И действительно, ведь в исходниках Кальмара есть mime.conf.default. Я нашел решение. Необходимо отредактировать два файлика:
1) debian/squid-common.install, и привести строку
2) Также необходимо сделать так, чтобы после установки пакета файл переименовался автоматом в «сквидочитаемый вид», т.е. в mime.conf. Для этого отредактируем файл debian/squid-common.postinst, приведя его в такой вид:
То есть добавим строку переименования файла, а остальное оставляем, как есть, не трогаем.
Все, после этого формируем пакеты, они сформируются и поставятся.
UPD 19.06.17: так как у меня спёрли домен linux-admin.tk, пришлось создать новый, уже «нормальный» домен, соответственно ссылку на скачивание архива изменил.
UPD 04.05.18: написал новую статью, где решается проблема глюков новых версий Squid + в логах красивые доменные имена вместо ip адресов + обход блокировок РКН.
Хочу сказать спасибо товарищу Дмитрию Рахматуллину, без него бы не получилось сделать то, что написано выше. Также, отдельное спасибо разработчикам Squid’а, которые оперативно ответили на мой баг-репорт об ошибке в libssl. И спасибо ребятам Nadz Goldman и gmax007 с Тостера, которые направили в нужное русло мои идеи по переносу Squid’а на физически отдельный от основного шлюза сервер.
Net-Labs.in
Network, ISP
Использование squid ssl_bump для просмотра содержимого https-трафика
Эта заметка является пошаговой инструкцией для осуществления расшифровки https-трафика и повторного шифрования с целью просмотра (и, при необходимости, фильтрации или изменения) его содержания при условии установки дополнительно корневого(CA) сертификата на конечное устройство. Перехват https-трафика может быть применён в следующих целях:
В первых трёх случаях мы сами устанавливаем CA-сертификат на своё устройство и делаем это целенаправленно. В четвёртом случае, это делается администраторами корпоративной сети. В последнем же случае CA-сертификат попадает в устройство либо в результате действий вредоносного ПО или путём обмана пользователя, либо производителем самого устройства предустановлено на заводе.
Схема подключения устройств для этой статьи выполнена следующим образом: 
Базовая настройка роутера выглядит следующим образом:
– включена маршрутизация (net.ipv4.ip_forward=1)
– на порту eth0 (в сторону LAN-свитча) работает isc-dhcp-server, раздаёт адреса 192.168.1.1-192.168.1.127, ip интерфейса eth0 192.168.1.128, маска сети /24
– через порт eth1 (в сторону Internet) настроено WAN-подключение к интернет-провайдеру, включен iptables SNAT (в случае, если IP-адрес, выдаваемый провайдером динамический, вместо SNAT используется MASQUERADE)
Т.е. роутер в своей базовой конфигурации делает тоже самое, что делают обычные домашние CPE, на просторах интернета есть тысячи инструкций как это настроить.
Для того, чтобы заняться расшифровкой https и повторным шифрованием нужно установить PROXY-сервер SQUID 3.4 (на текущий момент актуальная версия 3.4.10), который умеет работать в прозрачном режиме (в самом деле, в двух прозрачных режимах, но мы будем использовать более простой – intercept). Прописывать прокси-сервер в настройках сетевого подключения на конечных устройствах не придётся.
Чаще всего, в репозиториях популярных дистрибутивов Linux, Squid поставляется без ssl_bump, поэтому его придётся собирать из исходных кодов:
Файл squidCA.pem содержит CA-сертификат и приватный ключ в BASE64-кодировке, файл squidCA.der содержить только CA-сертификат в DER(бинарной) кодировке, этот файл предназначен для импорта конечными устройствами.
Запуск Squid осуществляется командой “/opt/squid/sbin/squid”, выключение “killall squid” (3 раза). Проверить, что Squid запущен нужно следующим образом:
Логи squid хранятся в файлах /opt/squid/var/log/cache.log и /opt/squid/var/log/access.log
На роутере остаётся дело за малым, завернуть https-трафик на локальный SQUID:
Однако, прежде чем перенаправлять трафик на Squid, нужно установить дополнительный корневой сертификат на конечные устройства (файл squidCA.der). Например, для Mac OS X 10.9 это делается с помощью утилиты Keychain Access(File->Import Items, Destination Keychain=login, Always Trust), результат выглядит следующим образом: 
Для Android(начиная с 4.0) тоже есть встроенный механизм импорта корневых сертификатов (в версии 4.4 Настройки->Безопасность->Хранилище учётных данных->Установить из памяти(установить сертификаты с носителя)). Результат установки: 
В более старых версиях Android возможно добавить свой CA-сертификат в общее хранилище при условии наличия root-привилегий на устройство. Добавление в общее хранилище является более удобным способом, т.к. это не требует установки PIN-кода/пароля на телефон, не появляется предупреждение безопасности при включении устройства.
Теперь запустим браузер(Chrome 39.0.2171.95) на PC и проверим, что осуществляется перехват https-трафика с подменой сертификата: 
В некоторых случаях, браузер может отображать устаревшую информацию о сертификате, если вы ранее посещали запрашиваемый сайт (в этом случае можно очистить кеш(не всегда помогает) или запустить браузер с чистым профилем).
Содержимое https-запросов (в зависимости от уровня логирования) можно увидеть в лог-файле access.log Squid-а, но куда более удобный способ анализа – использование Wireshark(запущенный на router). Для того, чтобы расшифровывать трафик, передаваемый в сторону конечных устройств, нужно указать Wireshark-у где находится приватный ключ. Для версии 1.99.2 (development version) настройка осуществляется так: Edit->Preferences->Protocols->SSL->RSA Key List->Edit, далее как на скриншоте: 
После чего запустим wireshark на интерфейсе eth0 с capture filter “port 443 and host 192.168.1.29” и посмотрим какие https-запросы отправляются с мобильного телефона на Android-е: 
На скриншоте изображено взаимодействие приложения Яндекса.Почта с их сервером посредством https. Кроме этого взаимодействия, был обнаружен ещё такой запрос к одному из серверов Яндекс (IP 213.180.204.58, в поле Host analytics.mobile.yandex.net):
А в самом теле POST-запроса содержится текущий список видимых Wifi-сетей (хотя в системных настройках геолокации разрешено использование только GPS).
Я понимаю зачем им нужны эти данные и даже передача списка wifi-сетей не удивляет, но интересно, зачем Яндекс хочет знать, что мой телефон рутирован? (is_rooted=1)
Ssl bumping что это
Шифрованный веб-трафик вещь хорошая, но порой совершенно не ясно что пользователь там, внутри, делает. При заходе на любой 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. Тут всё довольно просто и никакой магии:
Что бы не было конфликтов с уже установленной версией openssl, указываем новый путь:
2. squid
Сборка прокси сервера аналогична сборке любой программы (configure && make && make install), единственное это указание определённых ключей при компиляции:
—enable-ssl — включает поддержку ssl режима
—enable-ssl-crtd — генерацией сертификатов занимается отдельный процесс, а не сам прокси сервер.
—with-openssl — путь куда был установлен кастомный openssl
make all
make install
Так, squid прокси сервер собран.
3. Генерируем self-signed сертификат
Сертификат будет использоваться прокси сервером для создания динамических сертификатов веб сайтов.
Так как файл squidCA.pem содержит приватный ключ, делаем его читаемым только для пользователя root:
chmod 400 squidCA.pem
4.Настраиваем squid
Добавим следующие строки в squid.conf файл
данную настройку нежелательно использовать в продукционной системе, так как доступ разрешён на все https сайты с любыми сертификатами.
Стоит заметить, что если по какой-то причине вы поменяли ваш сертификат для squid’а, то надо полностью очистить каталог /opt/squid/var/lib/ssl_db и заново инициализировать сертификатную базу данных.
5. пользовательские проблемы
Так как в данном случае мы используем self-signed сертификат, любые посещения https сайтов через прокси будут показывать пользователям ошибку сертификата. Причина ошибки — Issuer нашего сертификата не находится в списке Trusted CA в браузере.
Что бы ошибок не было, выполняем следующее действие.
Теперь полученный файл 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. Ну и возможность проверять на вирусы.
Прозрачный прокси для HTTPS в Squid
Протокол HTTPS был разработан для обеспечения безопасного соединения между браузером пользователя и удаленным веб сервером. Для этого все данные проходящие через соединение шифруются таким образом что их может расшифровать только получатель с помощью специального ключа. Изначально в стандартном протоколе HTTP не было предусмотрено защиты информации и HTTPS был разработан для обеспечения безопасности пользователей на сайтах финансовых организаций, банков и государственных учреждений.
В наше время все больше и больше сайтов используют HTTPS для обеспечения конфиденциальности своих пользователей. Нет никаких сомнений в том что шифрование это хорошая вещь для безопасности, но оно также создает ряд проблем для контролируемых сетей, часто используемых в офисах. Основной проблемой есть то что кроме пользователя и сервера никто не может видеть и тем более фильтровать зашифрованные данные. Для решения этой проблемы можно использовать прозрачную фильтрацию HTTPS в Squid с помощью расширения ssl_bump.
Как это работает?
Когда пользователь пытается открыть сайт iptables перенаправляет запрос на наш прокси Squid. Обязательно чтобы трафик от пользователей проходил через машину с настроенным iptables и squid. Если используется протокол HTTPS, прокси сервер устанавливает шифрованное соединение с запрашиваемым сервером выдавая себя за браузер, а затем на основе собственного корневого сертификата подписывает новый SSL сертификат для запрашиваемого доменного имени и отправляет его браузеру пользователя выдавая себя за сервер. Таким образом устанавливается два шифрованных соединения и прокси получает полный доступ к проходимому трафику. Получается такая себе подмена сертификата HTTPS Squid.
Установка Squid и OpenSSL в Gentoo
Для работы с SSL сертификатами в системе должен быть установлен пакет openssl, если еще нет, установите:
Если вы работаете в Gentoo, то теперь squid нужно собрать с поддержкой SSL и динамической генерации сертификатов, а это соответственно опции: —enable-ssl и —enable-ssl-crtd, поэтому:
net-proxy/squid ssl-crtd ssl
Затем осталось установить Squid:
Установка Squid и OpenSSL в Ubuntu
Прежде чем будет выполнятся настройка HTTPS Squid, надо установить правильный прокси сервер и OpenSSL. Для Ubuntu и других дистрибутивов, основанных на Debian команда установки OpenSSL будет выглядеть вот так:
sudo apt install openssl
С Squid дела обстоят сложнее. Версия, которая есть в репозиториях не поддерживает работу с SSL. Поэтому придется собрать её вручную. Для этого сначала установите зависимости, необходимые для сборки:
sudo apt build-dep squid
Затем установите библиотеку для SSL:
sudo apt install libssl-dev
Создайте папку для сборки в домашней директории и перейдите в неё:
Скачайте в эту папку исходники Squid:
sudo apt source squid
В текущей папке появится ещё одна папка с исходниками, перейдите в неё.
Затем надо отредактировать файл debian/rules и добавить в него следующие флаги компиляции:
sudo vi debian/rules
—enable-ssl \
—enable-ssl-crtd \
—with-openssl
Эти опции надо вставить в переменную BUILD_CXX, она там одна такая. Затем останется только собрать и установить полученный пакет:
После установки вы можете убедится, что ваша версия Squid теперь поддерживает SSL выполнив:
Настройка Squid
Сначала создадим папку для хранения сертификатов, например в /etc/squid/ssl:
Теперь генерируем корневой сертификат собственного CA (Центра сертификации) на основе которого будут подписываться сертификаты для сайтов:
Генерируем корневой сертификат который затем нужно будет добавить в браузер:
Далее надо дать права на папку с сертификатами для Squid:
В файл конфигурации надо добавить такие настройки:
sudo vi /etc/squid/squid.conf
Дальше нужно пересоздать базу данных сертификатов:
Сервис Squid должен обязательно иметь права на директорию /var/lib/ssl_db. Следующим шагом включаем ip_forwarding для разрешения проходящего трафика через узел:
echo 1 >> /proc/sys/net/ipv4/ip_forward
Затем можно перезапускать Squid:
sudo systemctl restart squid
Прозрачный прокси Squid HTTPS настроен, осталось настроить редирект и браузер.
Настройка iptables
Перенаправляем весь проходящий через узел трафик с целевыми портами http и https на squid:
Если вы хотите тестировать прокси с локальным трафиком, то надо перенаправлять на Squid весь трафик, кроме трафика от Squid, это можно сделать такими правилами:
Настройка браузера
Затем нажмите кнопку Импортировать и выберите файл squid.der, находящейся в директории /etc/squid/ssl. Отметьте галочки, что следует доверять этому сертификату.
Фильтрация трафика
Теперь откройте какой-либо сайт. Если всё сделано верно, то сайт откроется, но сертификат будет не его, а ваш:
Прозрачный прокси для https заработает и в логе /var/log/squid/access.log вы увидите куда и зачем ходит пользователь:
Завершение
В этой статье мы разобрали как выполняется настройка HTTPS Squid 4. Как видите мы можем узнать какие страницы и изображения запрашивает пользователь, а этого более чем достаточно для нормального контроля трафика. Далее можно настраивать правила блокировки и фильтрации как это обычно делается для Squid.