Chiedere un certificato SSL dal cliente

Il problema è che con HTTPS, SSL si verifica prima e quindi HTTP entro il tunnel SSL. Quando il server viene contattato e deve inviare il suo certificato, non sa ancora il nome del server con cui il cliente vuole parlare (il nome dell'URL che vede il client).

Per la maggior parte ci sono tre metodi:

1. Utilizza un IP diverso per ciascun nome. Quando si verifica la connessione, l'indirizzo IP utilizzato dal client è noto al server, quindi il server potrebbe pubblicare un certificato diverso basato su tale indirizzo.

2. Utilizza un certificato con diversi nomi. Il client desidera vedere il nome del server previsto nel certificato, ma può esserci più di un nome in un certificato. L'estensione del certificato Subject Alt Name può contenere molti nomi (i certificati di Google contengono più di 70 nomi!).

3. Chiedi al cliente di annunciare il nome del server previsto con sufficiente anticipo nell'handshake SSL. C'è un'estensione SSL per questo: Indicazione del nome del server . La buona notizia è che la maggior parte dei browser Web la implementano. La cattiva notizia è che solo i più browser Web lo implementano; in particolare, Internet Explorer su Windows XP no (IE 8 su Vista e versioni successive lo supporta, ma non su XP).

Vedi questo sito per le statistiche sull'utilizzo del browser Web su Internet (utilizzale come stima, non come gospel, qualsiasi comunità di utenti fornita può esibire diversi modelli di utilizzo). Ad oggi (ottobre 2013), IE 8 è annunciato con una quota di mercato inferiore al 10% (il sito non dice quanti di questi funzionano su WinXP, ma scommetto che la maggior parte di questi lo fanno).

Il Metodo 3 è la "migliore pratica", o almeno sarà la migliore pratica nel prossimo futuro. È anche l'unico metodo che puoi implementare immediatamente senza chiedere al tuo grosso cliente di cambiare il suo DNS o di richiedere un certificato con il nome extra.

Soluzione 1

C'è un modo per farlo, ma è così esoterico che staresti meglio aspettando che la compagnia cliente ti dia un certificato appropriato (o vedi Soluzione 2 ). Tanto più che la Soluzione 1 * potrebbe aprire certi rischi di revisione, in quanto gli auditor sono notoriamente prudenti in merito a soluzioni tecniche alternative.

Ma se voi e i tecnici della società cliente preferite chiedere perdono invece di autorizzazione, potete fare quanto segue:

1. I tecnici del cliente impostano un servizio Web sicuro che ha accesso a uno dei loro certificati SSL che corrisponde al dominio del cliente in questione. Questo servizio Web è bloccato per alcuni livelli insani specifici del tuo server.
2. Il tuo server supporta l' Indicazione del nome del server per TLS.
3. Se il browser arriva con una percentuale diserver_name di RFC-6066 corrispondente al tuo dominio, procedi come al solito. Il browser ottiene felicemente il certificato per il dominio che si aspettavano, tutto è allegro nel mondo.
4. Se il browser arriva con una percentuale di co-id RFC-6066% corrispondente al dominio del cliente , passa l'handshake TLS in modalità proxy trasparente e inoltra tutto il traffico al servizio web speciale del cliente **. Ora stai agendo come router proxy / packet - niente cose man-in-the-middle divertenti in corso.
5. Il servizio web del cliente fa affari con il certificato che il browser si aspetta e restituisce un reindirizzamento temporaneo 302 crittografato al tuo dominio. per esempio. %codice%. È tutto ciò che questo servizio web client deve fare.
6. La connessione TLS è stata interrotta. E in seguito avrai una richiesta di connessione diversa per HTTPS per il tuo dominio da quel browser. Non che tu abbia mai saputo di avere un'istruzione di reindirizzamento, in quanto quello era il traffico che non puoi decifrare ma semplicemente proxy. ; -)

A. Browser ===[client.com]==> https://vendor.com ==(client W/S)==> https://client.com

B. https://client.com ==[302 redirect]==> http://vendor.com ==[302 redirect]==> Browser

C. Browser ==[vendor.com]==> https://vendor.com

_{* Soluzione 1 mi è venuto in mente per primo e consente al CNAME (mal configurato) di rimanere puntato sull'IP del venditore; altrimenti farei Soluzione 2 la prima soluzione.
** Non l'ho mai visto in natura, quindi non sono sicuro se un proxy trasparente a metà strada attraverso un handshake SSL funzionerebbe nella pratica.}

Soluzione 2

La soluzione 1 presuppone ovviamente che non nascondano il tuo servizio al di sotto del loro dominio per XSS o altri motivi di aggregazione dei contenuti.

Se lo sono, la soluzione più comune è chiedergli di non di impostare il proprio dominio CNAME sul proprio IP * ma di configurare un proxy HTTPS inverso che comunica con il tuo sito sotto il cofano.

_{* Stupida cosa da fare per HTTPS - a causa dell'ambiguità di proprietà e controllo che causa i venditori.}

Sì, è possibile eseguire più certificati SSL tramite più nomi host sullo stesso server.

Quale server web usi? Penso che questo sia piuttosto un argomento per serverfault.