Proxy de salida, ¿qué listas blancas por certificado de servidor?

Hay dos cosas en las que puedo pensar, ninguna de ellas se ajusta a la perfección, y se requiere cierto montaje.

1. squid con sslBump y Validador de certificado de servidor SSA Esto es básicamente una configuración de proxy MITM SSL, y puede proporcionar un "ayudante" externo que aumenta la verificación normal. Los bloques de tropiezos incluyen la confianza del certificado y la gestión de sus propios CA / certificados. Aunque nunca he usado esto.

2. Apache httpd como un proxy hacia adelante, con mod_rewrite , mod_proxy y un script de validación externo. El enfoque aquí es utilizar un mod_rewrite mapa del programa para validar previamente el certificado del objetivo antes de permitir el acceso.

La opción Apache se puede probar fácilmente: httpd.conf

LoadModule proxy_module           modules/mod_proxy.so
LoadModule proxy_connect_module   modules/mod_proxy_connect.so
LoadModule rewrite_module         modules/mod_rewrite.so
[...]
Listen 10.0.0.16:3128

<VirtualHost 10.0.0.16:3128>
    ServerName   proxy.domain.com
    ErrorLog  ...
    CustomLog ...

    ProxyRequests on
    RewriteEngine on

    RewriteMap sslval prg:/usr/local/apache2/bin/sslval

    <Proxy>
        RewriteEngine on

        ## parse CONNECT
        RewriteCond %{THE_REQUEST} "^(CONNECT) ([^:]+)(:([0-9]+))? HTTP/"   [NC]
        RewriteRule .          -   [env=CHOST:%2,env=CPORT:%4]

        ## hand over to sslval
        RewriteCond  ${sslval:%{ENV:CHOST}:%{ENV:CPORT}}          ok
        RewriteRule  .                            -               [P,L]

        RewriteRule   .                           -               [F]

    </Proxy>
</VirtualHost>

Este es un script externo "sslval" que usa gnutls-cli debido a su soporte de almacenamiento en caché de certificados, y le permite especificar exactamente qué certificado espera:

#!/bin/bash
export HOME=/usr/local/apache2
while read key; do
    timeout 10 gnutls-cli --tofu \
        --port=${key##*:}  ${key%%:*}  >/dev/null 2>&1 <<<Q
    [ $? = 0 ] && echo ok || echo fail
done

Ahora todo lo que necesita hacer es agregar los certificados esperados a ~apache/.gnutls/known_hosts interactivamente con gnutls-cli --tofu ... , e ingresar "y" para confirmar.

Este método de confianza en el primer uso puede parecer familiar, es exactamente como known_hosts de OpenSSH. Este enfoque no es diferente de la opción OpenVPN --tls-verify .

Se puede usar una variación en el script sslval para comparar con una base de datos de CA seleccionada, por ejemplo. con s_client de OpenSSL y una base de datos de archivos% CA_de% CA (mantenidos con .pem ), por ejemplo:

timeout 10 openssl s_client \
         -connect "$key" -servername "${key%%:*}" \
         -verify 5 -CApath /usr/local/etc/CA <<< Q |
   gawk '/Verify return code: (19|0) /{ok=1} 
      END{print ok?"ok":"fail"}'

La comprobación de errores, el bloqueo, la configuración y el control de acceso, el almacenamiento en caché y todas esas cosas agradables son un ejercicio para el lector ... ;-)

Con Apache (2.2.2x), descubrí que las solicitudes normales de proxy (no CONECTAR) se ven afectadas por la técnica mod_rewrite anterior, necesitarás un segundo VirtualHost para esas.

Puede filtrar por certificado usando un proxy de terminación SSL, como explica bien el Sr. Spuratic.

Sin embargo, convertir un proxy de paso a través de SSL en un proxy de terminación de SSL es un gran problema, y no es algo que haría solo por la motivación que describe.

Su mejor opción pragmática es filtrar por nombre de host.

Blue Coat ProxySG puede hacer la mayoría, si no todo, de esto.

Si entiendo esto correctamente, entonces quieres protegerte contra el riesgo de un ataque basado en el envenenamiento de DNS y la falsificación de certificados.

El problema con el método Squid descrito por mr spuratic es que envía un certificado falso al cliente; en el caso de un proceso de daemon, debe rechazar la conexión, mientras que el navegador mostrará un feo mensaje de advertencia (y fallará). para conectarse a sitios que implementan HSTS) a menos que también instale su certificado CA de snake-oil en los clientes, lo que probablemente no sea una buena idea desde el punto de vista de seguridad.

Si estuviera buscando implementar esto, entonces probablemente iría con un proxy personalizado donde pueda poner en espera la solicitud CONECTAR mientras el certificado del servidor se sondea desde la dirección IP resuelta (es fácil de scripts openssl para recuperar y manipular certificados). Eso parece ser lo que mr spuratic continúa describiendo usando Apache, pero no estoy lo suficientemente familiarizado con mod_rewrite / gnutls para poder decir si este es el caso / si su enfoque es válido.

Agregue a esto la necesidad de aceptar la caducidad del certificado y la posibilidad de que haya más de un certificado válido para un nombre de host en particular (particularmente con una organización grande como Microsoft) y esto comienza a parecer un ejercicio bastante complejo.

Mi primer pensamiento sería que podría ser más efectivo centrarse en proteger los datos del DNS en lugar de aplicar una validación más extensa al certificado. Una solución obvia es usar DNSSEC, pero veo que aunque Microsoft proporciona soporte de cliente DNSSEC, parece que no parece estar implementado en sus servidores .

¿Quizás una solución más práctica es mantener localmente los datos de DNS para los hosts en cuestión mucho más tiempo que su TTL?