Фильтрация с открытым исходным кодом трафика HTTPS

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

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

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

Вот очень ужасное решение, это реализовано коммерческим поставщиком:

• Замените сертификаты CA браузеров своим собственным внутренним

• Когда соединение требуют к неизвестному адресу, подключениям прокси с его собственным клиентом, и выбирает сертификат сайтов

• Затем генерируйте поддельный сертификат для того сайта, подписанного Вашим собственным CA

• Прокси затем эффективно действует как MITM (man-in-the-middle)

Вы не можете сделать этого со Сквидом запаса, но мне потребовался бы приблизительно день взламывания mod_perl для реализации этого с Apache.

Какое решение могло бы состоять в том, чтобы сделать, какие серверы IRC иногда делает, если они будут видеть соединение от XXX.XXX.XXX.XXX, то они попытаются соединиться с тем IP и видеть, является ли это сервер открытого прокси и если это, они блокируют тот IP.

Это - самая близкая вещь, о которой я могу думать, который был бы полностью автоматическим решением, но потребует работы над Вашим концом. Это объединилось с другим suggetions относительно белого списка, или просто вручную посмотрите на журналы, чтобы видеть и затем проверить удаленный IP https и видеть, мог ли его хостинг сайта быть единственным soltion

Вы не должны контролировать содержание Трафика HTTPS, даже если Вы можете, с помощью man-in-the-middle методы. Это ослабит безопасность всей вещи и просто уничтожит точку использования HTTPS во-первых. Можно, однако, контролировать Трафик HTTPS внешне.

Например, можно знать, какие сайты они подключают с тем, потому что весь Трафик HTTPS через веб-прокси использует метод ПОДКЛЮЧЕНИЯ для инициирования, который является начальным битом, переданным в ясном. Эта информация может использоваться, чтобы помочь решить, позволить ли соединению продолжаться.

Можно также контролировать использование пропускной способности Трафика HTTPS. Это может дать Вам понимание, используют ли они его для потоковых видео, или они используют его для транзакций онлайн, таких как банковское дело.

Вам, возможно, понадобится http ssl прокси как DeleGate как прокси Man-In-The-Middle

Править: Добавьте, что новый путь, вероятно, работает

Возможно, можно попробовать, передают весь трафик в ssl порте, затем к среднему времени запускают процесс, чтобы обнаружить, если целевой сервер является прокси ssl или не (это может быть обнаружено, если никакая аутентификация не потребовала), то блок это.

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

Я знаю, что этот вопрос стар, но я полагаю, что необходимо использовать прокси DNS. Можно поэтому поместить в черный список все домены, которые Вы не хотите (быть этим SSL или не).

dnsmasq работает хорошо, например. Можно настроить его как прозрачный прокси DNS. Существует дистрибутив Linux с открытым исходным кодом, названный "Брандмауэр Порядка байтов". Можно использовать его для этого, и ЧРЕЗВЫЧАЙНО легко настроить.

То, что Вы, конечно, не сможете обойтись без MITM, имеет сообщения о сайтах HTTPS (насколько их посетили, как часто, кого, и т.д.).