Come funziona l'autenticazione bidirezionale con SSL?

Suppongo che il modello di minaccia sia che potrebbe esserci un aggressore man-in-the-middle tra Alice e Bob, e che Alice e Bob non si trovano nella stessa sub-rete di fiducia. Questo è ciò per cui SSL / TLS è progettato per la protezione, ed è per questo che Alice dovrebbe controllare il certificato di Bob nel tuo esempio (almeno).

Dal punto di vista di Bob, controllare che la richiesta di Alice provenga da un indirizzo IP conosciuto non è di grande utilità. Gli aggressori potrebbero forgiare e modificare i pacchetti per farli apparire come provengono dall'indirizzo IP che desiderano. In seguito, anche le ricerche DNS sono inutili: tutto ciò che serve è assicurarsi di forgiare i pacchetti per utilizzare un indirizzo IP con la voce DNS corretta.

Quando Bob richiede un certificato client da Alice durante l'handshake SSL / TLS, questo farà sì che Alice invii il suo certificato e utilizzi la sua chiave privata durante l'handshake SSL / TLS per affermare la sua identità. Quando l'handshake è stato completato con successo, Bob saprà che Alice ha la chiave privata per quel certificato e dovrà verificare che si fidi di questo certificato.

Indipendentemente dal fatto che la richiesta provenga o meno da un proxy o meno, non importa quando si utilizza SSL / TLS. Un proxy HTTP si limita a tunnelare la connessione SSL / TLS dal client originale al server di destinazione.

Ciò che importa a Bob è come verificherà il certificato di Alice. In genere, questo verrà eseguito utilizzando un PKI nello stesso modo in cui Alice ha verificato il certificato di Bob, anche se questo non deve essere la stessa CA di Bob (deve essere qualcosa che si fida di Bob). Nota che non è necessario che si stia utilizzando una PKI. È possibile verificare il certificato rispetto a un determinato elenco (se Alice e Bob si sono incontrati prima, ad esempio), ma questo può essere un po 'più complesso poiché Bob potrebbe dover modificare l'elenco degli emittenti accettati che invia (ad esempio, inviare uno vuoto, che è esplicitamente consentito da TLS 1.1, ma non specificato in alcun modo nelle versioni precedenti, vedere Messaggio richiesta certificato ) e utilizzare un codice personalizzato per verificare quel certificato. (Ho implementato questo tipo di schema in passato e funziona bene.)

C'è un'eccezione a questo quando si usano quelli che chiamerei "server proxy MITM", cioè i server proxy che sono configurati per falsificare l'effettivo server SSL / TLS inserendo il proprio certificato (vedi Squid's SSL Bump ). In questo caso il certificato che Alice vede non proviene da Diginotar, ma da un'altra CA (in genere una CA aziendale quando viene eseguita su una LAN aziendale).

Anche se Alice potrebbe permettersi di fidarsi di un simile proxy MITM, l'utilizzo dell'autenticazione con certificato client SSL / TLS farebbe capire a Bob che esiste un MITM e che la connessione fallirebbe. Questo perché Alice dovrebbe firmare l'intero handshake SSL / TLS (come visto sia da Alice che da Bob) nel suo CertificateVerify messaggio per l'autenticazione con un certificato client. Poiché il proxy MITM avrebbe sostituito il certificato di Bob, le firme inviate da Alice e Bob non corrispondevano.

Non proprio. Al termine dell'handshake SSL, Bob sa di parlare con qualcuno che Verisign ha certificato come alice.in.wonderland.com . Ciò che Bob fa con questa informazione a questo punto dipende da lui e dipenderà dalla particolare applicazione. Alcuni esempi:

• Bob potrebbe avere una whitelist di client a cui è consentito connettersi. Quindi Bob cercherebbe alice.in.wonderland.com in questa lista. (Bob potrebbe in alternativa avere una whitelist di chiavi pubbliche, ma i certificati client potrebbero rendere le cose più facili da gestire, perché ora può inserire valori leggibili dall'uomo nella sua whitelist.)

• Bob potrebbe trattare alice.in.wonderland.com come nome utente di Alice e registrarla nel suo account. In altre parole, Bob potrebbe avere un database con un elenco di utenti; per ogni utente, avrebbe il nome dell'utente (come trovato nel certificato dell'utente) e tutte le informazioni associate a quell'utente. Una volta che Bob riceve una connessione da qualcuno con il nome N, Bob può cercare N nella tabella e registrare automaticamente il client come N. Quando qualcuno crea un nuovo account, Bob può creare automaticamente un nuovo account con il nome trovato nel loro cert ( supponendo che uno non esiste già). Il risultato è che gli utenti possono accedere al servizio di Bob senza dover inserire un nome utente o una password; il loro cert client è usato per autenticarli.

Di nuovo, questo dipende dall'applicazione; dipende da ciò che Bob vuole sapere sull'identità del computer con cui sta parlando. Non c'è una risposta unica.

Dipenderà dall'implementazione specifica.

In generale, Alice agirebbe da cliente per Bob. Se Bob si aspetta che si colleghino solo altri server autorizzati, Bob controllerà la validità del certificato, inclusa la scadenza, contro il CRL degli emittenti ed eseguirà una ricerca inversa rispetto al nome. Se Bob si aspetta un client utente, la ricerca inversa verrà probabilmente ignorata o utilizzata solo per la registrazione.

Se Bob si aspetta che Alice si colleghi da un host trusted conosciuto, Bob si aspetterebbe che l'indirizzo IP di Alice corrisponda al record DNS. A Bob non importa che Alice sia dietro un proxy e Bob vedrà solo l'indirizzo IP del proxy. Quindi alice.in.wonderland.com dovrebbe essere configurato per l'indirizzo IP esterno del proxy.

La parte chiave tuttavia è questa:

1. Bob avrà la chiave pubblica di Alice già mappata su un ID di qualche tipo che verrà utilizzato per concedere l'accesso alle risorse di Bob.
2. Bob e Alice si sfidano a vicenda inviando un messaggio a vicenda che ciascuno può decifrare solo con la propria chiave privata. Dimostrando così di avere il certificato che è noto e fidato da entrambe le parti.

Nota anche: se Alice è dietro un proxy, il proxy deve avere la chiave privata di Alice (in modo che il proxy possa parlare con Bob per conto di Alice) o deve passare attraverso la connessione di Alice senza alterarne la sua contenuti.

Riferimento aggiuntivo link o link per dettagli tecnici specifici.

Spero che ti aiuti.