BYOD и Google SSL
Я управляю школьной сетью с программой BYOD. У меня есть Linux-прокси (squid) с фильтрацией содержимого по Mind (форк dansguardian). Все работает отлично по HTTP, проблема, конечно, когда дети начинают использовать HTTPS. Моя самая большая проблема заключается в том, что Apple переключилась на использование HTTPS при поиске в Google в сафари. Это позволяет детям выполнять поиск без MinD принудительного безопасного поиска. Я хотел бы знать, что я мог бы сделать с этим. Есть ли способ остановить это? Заранее благодарю за любую помощь!
3 ответа
Теперь можно попросить Google перенаправить безопасный поиск на http - https://support.google.com/websearch/answer/186669?hl=en - страницу справки Google по этой теме. Они предлагают использовать хитрость DNS, это может быть сложно в Windows 2008r2 - лично я переписываю перезапись заголовка соединения для достижения той же цели, что можно сделать во всех хороших веб-фильтрах (и некоторых плохих).
Я работаю для Smoothwall, который предоставляет фильтр именно с такой возможностью, а также возможность выполнять некоторые другие SSL-фильтрации. Я предвзят, но я предлагаю вам взглянуть. Когда дело доходит до сложных вещей, это намного проще, чем кататься самостоятельно. В интересах беспристрастности существуют и другие веб-фильтры:)
Squid поддерживает функцию под названием SslBump с использованием Bump-Server-First. Это в основном означает, что браузеры будут пытаться установить безопасное соединение между ними и хостом. Кеш Squid получает перехваченное соединение, а Squid устанавливает внешнее соединение. Затем завершает безопасное соединение с пользователем. По сути, Squid является центром сертификации для части user/squid, поэтому он может расшифровать трафик и кэшировать / фильтровать его.
Поскольку это то, что разработчики SSL думали, что это может быть вектором атаки, есть некоторые препятствия, которые нужно преодолеть. Squid поддерживает динамическую генерацию сертификатов, поэтому сертификаты доменов совпадают на стороне клиента и передают часть исходной информации сертификата клиенту. Все это может пройти довольно легко, если ваши клиентские устройства могут доверять вашему сертификату CA. Это немного сложнее, если люди используют свои собственные устройства.
- iOS может добавить сертификаты CA с помощью утилиты iPhone Configuration
Не похоже, что это возможно на дроидах- Последние дроиды могут добавлять сертификаты CA
- Windows/ OSX конечно может.
- Linux немного сложнее в зависимости от приложений, которые вы используете, и того, что они используют в качестве хранилища ключей.
Стоит отметить, что ваш кэш теперь контролирует доверие третьих сторон к этим устройствам. Информация, которая имитируется в динамических сертификатах, помогает смягчить это, но можно настроить squid на слепое доверие к вещам, которые могут быть плохими для пользователей, если кто-то совершит настоящую атаку в середине атаки дальше от вашего прокси, например.
Вы ничего не можете сделать. Вы можете сгенерировать самоподписанный SSL-сертификат для google.com и MITM трафика, а затем сможете проверить его и заблокировать по мере необходимости, за исключением того, что зависит от того, насколько хитры дети и будут ли они участвовать в процессе принятия вашего самоподписанного сертификата.
Это также, вероятно, незаконно. Вы могли бы полностью блокировать трафик HTTPS, но это, вероятно, сломало бы все виды вещей.