Proxy in uscita quali whitelist dal certificato del server?

Ci sono due cose che posso pensare, o non si adatta perfettamente al disegno di legge, e c'è bisogno di un assemblaggio.

1. squid con sslBump e Convalida certificato server SSL Si tratta fondamentalmente di una configurazione del proxy SSL MITM e si ottiene un "helper" esterno che aumenta la normale verifica. I blocchi di incertezza includono il certificato di fiducia e la gestione della propria CA / certs. Non ho mai usato questo però.

2. Apache httpd come proxy forward, con mod_rewrite , mod_proxy e uno script di convalida esterno. L'approccio qui è di utilizzare una mod_rewrite mappa del programma per pre-validare il certificato della destinazione prima di consentire l'accesso.

L'opzione Apache può essere testata facilmente: 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>

Questo è uno script "sslval" esterno che usa gnutls-cli a causa del supporto per la memorizzazione nella cache dei certificati e ti consente di specificare esattamente quale certificato ti aspetti:

#!/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

Ora tutto ciò che devi fare è aggiungere i certificati previsti a ~apache/.gnutls/known_hosts in modo interattivo con gnutls-cli --tofu ... e inserendo "y" per confermare.

Questo metodo di trust al primo utilizzo potrebbe sembrare familiare, è esattamente come known_hosts di OpenSSH. Questo approccio non è diverso dall'opzione OpenVPN --tls-verify .

Una variante sullo script sslval può essere utilizzata per verificare un database CA selezionato, ad es. con s_client di OpenSSL e un database di .pem file CA (gestito con c_rehash ), ad es.

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"}'

Il controllo degli errori, il blocco, la configurazione e il controllo degli accessi, il caching e tutte quelle belle cose sono un esercizio per il lettore ...; -)

Con Apache (2.2.2x) ho scoperto che il proxy delle richieste normali (non CONNECT) è influenzato dalla tecnica mod_rewrite di cui sopra, sarà necessario un secondo VirtualHost per quelle.

Puoi filtrare per certificato usando un proxy che termina SSL, come spiega bene Spuratic.

Tuttavia, trasformare un proxy pass-through SSL in un proxy che termina SSL è un grosso problema, e non qualcosa che farebbe puramente per la motivazione che descrivi.

La tua migliore opzione pragmatica è filtrare per nome host.

Blue Coat ProxySG può fare la maggior parte, se non tutte, di questo.

Se sto capendo correttamente questo, allora vuoi proteggerti dal rischio di un attacco basato su avvelenamento del DNS e falsificazione del certificato.

Il problema con il metodo Squid come descritto da mr spuratic è che invii un certificato falso al client - nel caso di un processo demone dovrebbe rifiutare la connessione mentre un browser visualizzerà un brutto messaggio di avviso (e fallirà per collegarti ai siti che implementano HSTS) a meno che tu installi anche il tuo CA CA snake-oil sui client - che probabilmente non è una buona idea dal punto di vista della sicurezza.

Se volessi implementarlo, probabilmente utilizzerei un proxy personalizzato in cui posso mettere in attesa la richiesta CONNECT mentre il certificato del server viene interrogato dall'indirizzo IP risolto (è facile scrivere script openssl per recuperare e manipolare i certs). Questo sembra essere ciò che il signor spuratic continua a descrivere usando Apache - ma non sono abbastanza familiare con mod_rewrite / gnutls per poter dire se questo è il caso / se il suo approccio è valido.

Aggiungete a questo la necessità di attendere la scadenza del certificato e la possibilità che ci possa essere più di un certificato valido per un particolare nome host (in particolare con una grande organizzazione come Microsoft) e questo inizia a sembrare un esercizio piuttosto complesso. / p>

Il mio primo pensiero sarebbe che potrebbe essere più efficace concentrarsi sulla protezione dei dati DNS piuttosto che applicare una convalida più ampia al certificato. Una soluzione ovvia è usare DNSSEC, ma vedo che sebbene Microsoft fornisca il supporto client DNSSEC, esso non sembra implementato sui loro server .

Forse una soluzione più pratica è quella di mantenere localmente i dati DNS per gli host in questione molto più a lungo del loro TTL?