Il lato negativo del consentire certificati non certificati

Lo scopo dei certificati è di dimostrare l'identità della parte remota con la quale stai comunicando. In caso contrario, la rappresentazione potrebbe avere luogo: gli attaccanti MITM attivi potrebbero intercettare il traffico e alterarlo per farlo passare come se fossero i propri.

È abbastanza simile a verificare l'identità di qualcuno controllando un passaporto. Supponiamo che tu voglia verificare il nome della persona che ti sta di fronte, che ti sta mostrando il passaporto.

• Vuoi verificare che ti fidi dell'autenticità del passaporto stesso. Una tessera del club sportivo locale potrebbe non essere sufficiente. Il controllo di questo aspetto di un certificato è la creazione di un percorso di certificazione per una CA attendibile nella specifica PKIX (RFC 5280 / RFC 3280) è per; fornisce anche altri aspetti, come lo scopo per cui la CA era disposta a consentirglielo.

• Vuoi verificare che il passaporto appartenga alla persona di cui stai cercando di verificare l'identità. (In questa analogia, il nome del server è più simile all'immagine della persona, dal momento che stai cercando di trovare il nome della persona, sapendo che aspetto hanno (*).)

  Una cosa è fidarsi del fatto che il passaporto sia reale, ma dovrebbe essere rilasciato alla persona che ne rivendica l'utilizzo. In caso contrario, chiunque abbia ottenuto il passaporto di un Paese che riconosci lo può dichiarare di essere qualcuno in qualsiasi Paese tu riconosca.

  Nel mondo HTTPS, questo viene fatto seguendo le regole in RFC 2818 (Sezione 3.1) , e più in generale in SSL / TLS in RFC 6125 .

• L'ultimo punto non fa rigorosamente parte della verifica del certificato stesso. Vuoi verificare di legare l'immagine sul passaporto alla persona di fronte a te. In questa analogia, il link picture to person è garantito dallo scambio di chiavi autenticate in TLS , che garantisce che la parte remota abbia la chiave privata che corrisponde alla chiave pubblica in questo certificato.

Dopo aver eseguito correttamente questi tre passaggi, puoi associare il nome sul passaporto alla persona fisica di fronte a te.

I certificati in SSL / TLS hanno lo stesso ruolo: assicurati che il certificato provenga da una CA di cui ti fidi, assicurati che sia rilasciato sul server con cui vuoi comunicare e assicurati di parlare con parte a cui è stato rilasciato quel certificato.

Più precisamente nel tuo esempio, il certificato è stato emesso a DI-PRE-UFCG , che è un nome diverso da quello che stai cercando di contattare e sec_error_untrusted_issuer indica che il browser non lo riconosce nemmeno come emesso da un entità che si fida (che ha senso per un certificato autofirmato che non verrebbe importato esplicitamente).

(*) Sto solo facendo l'analogia in quell'ordine perché è più naturale nella mia esperienza. Raramente inizi a cercare una persona specifica per nome, dati da una folla e dai loro passaporti, ma in alcune circostanze questo potrebbe avere senso. Avresti problemi simili se qualcuno avesse più alias, ma quello che stai cercando non era quello del loro passaporto.

Noname,

La possibilità che qualcuno interferisca con la connessione è principalmente una preoccupazione per gli attacchi Man in the Middle (MITM). Quando l'utente tenta di connettersi al server se un utente malintenzionato è in grado di ottenere tra il server e il client sppofing dell'IP, del DNS o anche eventualmente dell'indirizzo MAC (se l'utente malintenzionato si trova sulla tua LAN), c'è un modo l'utente malintenzionato può presentare un certificato SSL fasullo e una facciata o un proxy del sito Web per la connessione al sito Web. Ora che l'utente ignaro clic si fida del certificato che non è firmato da un'autorità di certificazione (CA) legittima (cioè Verisign), l'utente malintenzionato avrà quindi accesso al testo in chiaro (dati non crittografati) e potrà annusare / registrare tutto il traffico tra l'utente e server web abilitato SSL.

Fortunatamente per la maggior parte di noi i brower vengono preinstallati con un elenco di CA di cui generalmente ci si può fidare e quando una di quelle CA che hanno firmato un certificato non si trova in tale elenco o se il certificato è autofirmato si otterrà quel tipo di errore chiedendo "Sei sicuro?".

Per quanto riguarda la stringa che hai menzionato, credo che DI-PRE-UFCG abbia probabilmente qualcosa a che fare con il sito Web SSL a cui ti stai collegando e un messaggio che questa eccezione è valida solo per CA DI-PRE-UFCG che ha firmato quel particolare certificato.

Spero che aiuti,

cc

Dipende dal sito in cui accedi. Se si tratta di una banca e di un certificato autofirmato, ovviamente c'è un problema di attacco MITM in corso. Se si tratta di un piccolo forum o qualcosa del genere e hanno appena generato il proprio certificato autofirmato, nessun problema.

Se vuoi un metodo SSL migliore, vai su convergence.io e installa il plugin firefox. Consulta la presentazione SSL BlackHat 2011 di Moxie Marlinspike per maggiori informazioni, verrai sorpreso di quante ruberie private rubate siano in giro da autorità cert che possono essere utilizzate per firmare il tuo sito MITM falso. Alcuni di loro li lasciano in bella vista perché qualcuno li possa scaricare. Sì, le chiavi di firma SSL private sono in giro.

link