Verifica SSL del nome host del server https

link crittografia a chiave pubblica / privata . Quindi il client utilizza la chiave pubblica del server per crittografare le informazioni che solo il server può decrittografare.

Su questo semplice livello, l'attaccante può ingannare il cliente a parlare con lui invece del server reale, usando la chiave pubblica dell'attaccante. L'utente malintenzionato decodifica quindi le informazioni inviate utilizzando la sua chiave privata e la inoltra al server reale. Questo è chiamato Man in the middle attack .

Per prevenire questo tipo di attacco, SSL utilizza il certificato. Un certificato è fondamentalmente una chiave pubblica con alcune informazioni di identità allegate ad esso. Questi certificati possono essere firmati dalle autorità di certificazione per confermare le informazioni sull'identità.

Il client deve verificare che il nome nel certificato corrisponda al server con cui vuole parlare. Nel caso di un normale browser Web, il nome del dominio viene visualizzato nella barra degli indirizzi. Senza questa verifica l'utente malintenzionato potrebbe semplicemente inviare qualsiasi certificato.

Il DNS non è sicuro, quindi in molte situazioni può essere facilmente manipolato. Se il browser rilassa la verifica per accettare un indirizzo IP che appartiene al nome di dominio in questione, si fiderebbe del DNS non sicuro .

A parte questo, l'uso di indirizzi IP nei certificati SSL non è valido. Quindi, anche se si digita l'indirizzo IP nella barra degli indirizzi, il browser deve rifiutare il certificato. Ma un certificato può contenere un elenco di nomi di dominio per i quali è valido.

Sì, ritengo che ti sia sbagliato pensare che il processo di convalida del nome del certificato possa eseguire qualsiasi risoluzione dei nomi, risoluzione inversa o altra mappatura per te. La corrispondenza che si verifica è praticamente una cosa letterale eseguita a livello di applicazione (scusa, etichetta errata. Intendo il codice della libreria SSL chiamato dall'applicazione quando dico "livello applicazione"; in OSI, questo sarebbe probabilmente il livello Sessione o Presentazione , ma fa tutto parte dell'eseguibile dell'applicazione.

Non credo che troverai un gestore di librerie java per aggiungere la mappatura dei nomi che stai cercando, perché il protocollo SSL / TLS riguarda davvero la corrispondenza dei nomi letterali (e quindi assicurati che la crittografia e la certificazione aspetti di autorità sono a posto).

Credo che tu possa usare il tag subjectAltName per generare un certificato che corrisponda validamente a più nomi, ma è una specie di approccio opposto rispetto a quello che stai guardando.

Il punto di SSL è che il mondo esterno è ostile (almeno potenzialmente). Non è possibile aspettarsi che il DNS restituisca risposte vere e inalterate, poiché qualsiasi utente malintenzionato che potrebbe influire sulla connessione (e si ritiene che ci siano tali persone, poiché questo è il motivo per cui si utilizza SSL) potrebbe anche alterare le risposte DNS. L'intero esercizio consiste nel fidarsi di un insieme specifico di "trust anchors" (ovvero "root CA") e di costruire da questo - e solo da quello.

Quindi il client SSL richiederà che il nome del server previsto sia effettivamente presente nel certificato del server, non qualcosa di indiretto come un indirizzo IP su cui il suddetto nome è stato mappato attraverso un meccanismo potenzialmente insicuro come DNS.

Nota: concettualmente, potrebbe essere usato qualsiasi tipo di "identità", a patto che ciò che il cliente si aspetta sia uguale a ciò che si trova nel certificato . In HTTPS , si presume che "ciò che il cliente si aspetta" sia adeguatamente descritto da l'URL più precisamente la parte nome server dell'URL. I browser Web mostrano questo nome in modo proeminente (sto usando Chromium in questo momento: visualizza l'URL nella barra degli URL come un testo grigio, con il nome del server evidenziato in una tonalità più scura). Si potrebbe immaginare una convenzione in cui il client "conosce" l'indirizzo IP di destinazione (hardcoded, o noto da una fonte affidabile, non da una richiesta DNS), e si aspetta che l'indirizzo IP appaia nel certificato; I certificati X.509 possono infatti contenere indirizzi IP (vedi il tipo di nome iPAddress nel Subject Alt Name estensione). Tuttavia, le implementazioni esistenti non corrispondono agli indirizzi IP, corrispondono ai nomi. Quindi è stato scritto , e ha senso, perché i nomi possono essere verificati dagli umani, e gli indirizzi IP possono cambiare parecchio durante la migrazione o l'espansione delle infrastrutture.