Si su software de filtrado se implementa como un proxy HTTP (posiblemente transparente), entonces la única forma en que puede filtrar las conexiones HTTPS es realizar una inspección SSL de Man-in-the-the-Middle. Esta es una técnica un tanto complicada e intrusiva, pero algunos proxies de filtrado lo admiten. La forma en que básicamente funciona es la siguiente:
-
Cuando el proxy intercepta un protocolo de enlace SSL, no lo reenvía al sitio de destino, sino que lo responde directamente, utilizando su propio certificado autofirmado que dice ser válido para el sitio de destino.
-
Una vez que se establece la conexión SSL entre el proxy y el navegador (que cree que está hablando con el sitio de destino), el proxy crea su propia conexión SSL con el sitio de destino.
-
El proxy recibe la solicitud HTTP a través de SSL desde el navegador, la filtra y la reenvía al sitio de destino. A continuación, hace lo mismo con la respuesta del sitio de destino al navegador.
Por supuesto, dado que el certificado enviado por el proxy al navegador en el paso 1 no es en realidad válido para el sitio de destino, y en particular no ha sido firmado por una CA de confianza, el navegador normalmente abortaría la conexión y le mostraría al usuario una gran alerta sobre un certificado no confiable.
El truco, sin embargo, es que usted, como administrador de la red, debe agregar el certificado de firma del proxy en la lista de certificados raíz de confianza del navegador. De esa manera, el navegador, de hecho, confiará en los certificados falsos devueltos por el proxy.
Por supuesto, el usuario puede eliminar el certificado del proxy de la lista de confianza del navegador, o simplemente usar su propio navegador que no está configurado para confiar en el proxy. Pero esto solo significa que recibirán una alerta de seguridad y no podrán conectarse a los sitios HTTPS; no les ayudará a pasar por alto el proxy.
Dicho todo esto, le recomendaría seriamente que piense detenidamente antes de usar tales trucos para socavar la infraestructura de confianza de SSL y que solo lo haga si cree que es absolutamente necesario. Incluso entonces, recomendaría solo aplicarlo a algunos sitios específicos que desea filtrar y dejar las conexiones HTTPS a otros sitios solo. Es posible que a sus usuarios no les importe que estén indagando en sus búsquedas de Google, pero no querrán que usted curiosee sus actividades bancarias en línea, por ejemplo.
Por otra parte, si su software de filtrado se ejecuta en la computadora del usuario, por ejemplo. como una extensión del navegador, entonces no debería tener problemas para filtrar solicitudes HTTPS tan fácilmente como HTTP simple; Al insertarse entre la interfaz de usuario del navegador y el backend de la red, puede volver a escribir las solicitudes HTTPS antes que estén encriptadas.
(Esto es, por ejemplo, cómo funciona el complemento HTTPS Everywhere para Firefox: intercepta las solicitudes HTTP y las vuelve a escribir en solicitudes HTTPS, a veces modificando las URL de otras maneras también. No hay razón por la que esto no funcionaría tan bien en la otra dirección también.)
Sin embargo, hay dos problemas con este enfoque. La primera es que los diferentes navegadores tienen diferentes API de extensión, y no todos son igualmente convenientes para la reescritura de solicitudes. (Por ejemplo, la extensión de la API de Chrome es aparentemente particularmente mal adaptada para él, debido a su diseño asíncrono).
El segundo problema es simplemente que hay una manera fácil de sortear un filtro implementado de esta manera: simplemente instale un navegador que el filtro no admita. Por lo tanto, dicho filtrado no será muy efectivo a menos que se combine con otras restricciones para evitar este tipo de soluciones.