BYOD и Google SSL

John,

Посмотрите в своем апачском conf файле на старом сервере под разделом SSL. Вы ищете подобные записи. Это в основном говорит Вам путь сертификата и файла ключей.

SSLCertificateFile/etc/apache2/ssl/server.crt

SSLCertificateKeyFile/etc/apache2/ssl/server.key

Скопируйте сертификат (.crt файл) и ключ к Вашему новому серверу и выполните шаги конфигурирования SSL с апачем. Ниже упомянутой ссылки имеет шаги для установки SSL w/Apache на Ubuntu. Можно пропустить раздел по генерации сертификата.

http://www.linode.com/wiki/index.php/Apache2_SSL_in_Ubuntu

3
задан 21 February 2013 в 18:37
3 ответа

Теперь можно попросить Google перенаправить защищенный поиск на http - https://support.google.com/websearch/answer/186669?hl=en is страницу справки Google по этой теме. Они предлагают использовать хитрость DNS, это может быть сложно в Windows 2008r2 - я лично предпочитаю переписать заголовок подключения для достижения той же цели, что можно сделать во всех хороших веб-фильтрах (и некоторых плохих).

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

1
ответ дан 3 December 2019 в 05:28

Squid supports a feature called SslBump using Bump-Server-First. This basically means browsers will attempt to establish a secure connection between them and the host. The Squid cache gets the intercepted connection and Squid establishes the external connection. Then completes the secure connection to the user. Squid is essentially the certificate authority for user/squid portion so it can decrpyt the traffic and cache/filter it.

As this is something the people who designed SSL thought could be an attack vector there's some bumps to get over. Squid does support dynamic cert generation so cert domains match on the client end and have some of the original cert information go through to the client. All this can go fairly seamlessly if your client devices can trust your CA certificate. That bits a little harder if people are using their own devices.

The thing to note is your cache is now in control of third party trust for these devices. The information that is mimicked in the dynamic certs goes some way to mitigating this but it's possible to configure squid to blindly trust things which could be bad for the users, if someone were to do a real man in the middle attack further out from your proxy, for instance.

4
ответ дан 3 December 2019 в 05:28

Вы мало что можете сделать .. Вы можете создать само- подписанный SSL-сертификат для google.com и MITM трафик, и тогда вы сможете проверить его и заблокировать по мере необходимости, за исключением того, что это зависит от того, насколько хитры дети, и подпадут ли они на процесс принятия вас -подписанный сертификат.

Это тоже вероятно незаконно. Вы можете полностью заблокировать HTTPS-трафик, но это, вероятно, сломает множество вещей.

1
ответ дан 3 December 2019 в 05:28

Теги

Похожие вопросы