Проблема сложилась такая:

В SQUIDе разрешено использование только HTTP (порт 80, обычные нешифрованные страницы) и HTTPS (порт 443, соответсвенно шифрованные страницы), все остальные порты закрыты файерволом. Для HTTPS разрешён метод CONNECT для нормальной работы шифрованных страниц.
При такой конфигурации существует возможность создавать туннели в обход файервола, открывая соединение на разрешённый порт (443) через прокси при использовании метода CONNECT.

Пользуются этим в основном продвинутые пользователи, создавая туннели до своих компьютеров и далее используя их, как посредника, имея уже неограниченный Интернет.
Первое, что было сделано - запрещён метод CONNECT на IP, не имеющие доменные имена (этим шагом заодно была прикрыта возможность использования Skype через прокси). Со временем это начало обходиться регистрацией доменного имени на бесплатных серверах, предоставляющих сервис динамического ДНС. По возможности (по факту так сказать), эти домены заносились в чёрный список и запрещался метод CONNECT на хосты из этих доменов. Так как сервисов этих много, а доменов ещё больше, борьба ведётся, как было сказано выше, по факту.

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

Лично мне видится 2 варианта:
1. Разбор ответа на телнет на запрашиваемый хост (логично они будут отличаться для WEB-сервера и для SSH-сервера);
2. Проверка сертификата (для разрешённых ресуров в моём случае сертификат должен быть подписан кем-то из авторитетных CA).

Что по этому поводу думают форумчане?

P.S. Сразу оговорюсь, что не являюсь провайдером. Организация предоставляет финансовые услуги (назовём это так), поэтому озабочены контролем доступа работников к ресурсам Интернета.

• Запрет туннелирования (в частности SSH), используя метод CON...,rakis, 10:06 , 19-Май-08
  • Запрет туннелирования (в частности SSH), используя метод CON...,deadmoroz2, 12:14 , 19-Май-08
    • Запрет туннелирования (в частности SSH), используя метод CON...,rakis, 13:48 , 19-Май-08
      • Запрет туннелирования (в частности SSH), используя метод CON...,deadmoroz2, 14:40 , 19-Май-08
        • Запрет туннелирования (в частности SSH), используя метод CON...,rakis, 23:18 , 20-Май-08

1. Решать вопрос административными мерами
2. Купить Websense

>1. Решать вопрос административными мерами
>2. Купить Websense

А почему именно WebSense? Есть опыт использования или это пиар?

>А почему именно WebSense? Есть опыт использования или это пиар?

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

>>А почему именно WebSense? Есть опыт использования или это пиар?
>
>я не работаю ни в одной и контор его продающих :-)
>опыт использования есть.
>при полной инсталяции и правильной настроке лучше найти трудно.
>один минус - дорого.
>в любом случае, без административных мер это поможет только на половину.
>когда человек знает что его могут оштрафовать или уволить, энтузиазма на такие
>эксперименты как правило не хватает.

Да без каких-либо претензий лично к Вам.
Через некоторе время вводим BlueCoat, будем надеятся, что там с этим можно будет бороться.

>Через некоторе время вводим BlueCoat, будем надеятся, что там с этим можно
>будет бороться.

тоже достойное решение. только уже "сильно дорого".