SSL / TLS: meccanismo di autenticazione

non posso commentare, ma sono d'accordo con la risposta di @ Tom, con alcuni punti da aggiungere:

L'autenticazione del server SSL / TLS dipende dalla "forza" della chiave del server - sia la sua dimensione, che puoi vedere, e che è stata sufficientemente casuale, a differenza, ad esempio, dei pacchetti Debian openssl alcuni anni fa che usavano un RNG paralizzato o migliaia di dispositivi apparentemente non presidiati che il sondaggio sul web EFF (penso che fosse) ha trovato "randomly" primari RSA duplicati, permettendo il banale factoring GCD - e anche la "forza" del certificato - è stato emesso da un'autorità di certificazione che ha adeguatamente verificato l'identità del soggetto e ha protetto l'intestazione del suo privato.

Per RSA keyexchange, il client crittografa premaster-secret e invia al server che decodifica ma NON restituisce; invece entrambe le parti la usano in derivazione chiave per produrre tra l'altro MAC finiti che vengono controllati. Per gli scambi di chiavi DH ed ECDH, non c'è crittografia (fino ai dati di massa), ma per i casi effimeri, server firma ServerKeyExchange che prova il possesso della chiave privata (modulo il recente bug "goto fail" di Apple) .

Le dimensioni di un tasto intero DSA (o DH statico ma nessuno lo usa) devono essere quasi le stesse di RSA - attualmente per una buona sicurezza 2048 o giù di lì, e tutti usano il round power-of-two. FIPS 186 non ha mai consentito meno di 512 per DSA e oggi non meno di 1024 e solo in casi limitati. * EC * DSA o * EC * DH è molto più piccolo, attualmente 224-256.

L'uso dei cifrari di esportazione NON indebolisce l'autenticazione, o persino l'integrità dei dati, cioè l'HMAC, solo la riservatezza - che è già abbastanza grave. Del resto esistono anche suite di "null encryption" che fanno autenticazione e HMAC ma nessuna crittografia - quasi sempre una cattiva idea, e raramente implementate o utilizzate, ma ancora discutibilmente migliori del testo in chiaro.

Il tuo browser Web cercherà sempre di autenticare il certificato del server; si lamenterà rumorosamente quando non può. Il punto sull'autenticazione opzionale è per le suite di crittografia "DH_anon" in cui non vi è alcuna autenticazione. Tali suite di crittografia sono, per definizione, insicuri contro gli attaccanti attivi e, pertanto, non dovrebbero essere utilizzate. I browser Web non li supportano per impostazione predefinita, o addirittura affatto.

Alcuni server potrebbero anche richiedere alcuni certificati dal client, ma questo è piuttosto raro perché i certificati client sono una rarità e la maggior parte delle persone non ne ha. Questo si verifica principalmente con alcuni siti bancari e, se questo è il tuo caso, dovresti già saperlo.

Le dimensioni della chiave non influiscono sull'autenticazione o meno dell'autenticazione. Naturalmente, se il server utilizza una chiave pateticamente piccola, ciò potrebbe compromettere la sicurezza delle comunicazioni, ma in questo caso il tuo browser aggiornato dovrebbe avvisarti.

La dimensione della chiave indicata nel nome della suite di crittografia (come "128" in "TLS_RSA_WITH_RC4_128_SHA") non si riferisce a RSA / DSA / a qualsiasi altra chiave utilizzata per la crittografia asimmetrica, ma all'algoritmo di crittografia simmetrica usato in seguito per in realtà crittografare la maggior parte dei dati.

Più in generale, sembri un po 'confuso su cosa significhi "autenticazione". Nelle solite connessioni SSL, tra un browser Web (il client) e un server Web, lungo il protocollo HTTPS, ci sono due "autenticazioni" che avvengono:

1. Durante la creazione iniziale della connessione ("handshake"), il server mostra la sua chiave pubblica asimmetrica al client come parte del suo certificato e il client convalida quel certificato. Il processo di convalida è il metodo con cui il client si assicura che la chiave pubblica che vede sia effettivamente posseduta dal server previsto. Una volta che il client ha ottenuto la garanzia che la chiave pubblica è corretta, accetta di utilizzarla per gli elementi crittografici dell'handshake, che autentica indirettamente il server per l'intero scambio di dati successivo.

2. Una volta stabilita l'handshake e stabilito il tunnel SSL / TLS, il server potrebbe richiedere una sorta di autenticazione dal client (password, cookie ...). Questo accade a livello HTTP, non a livello SSL; questo non è completamente correlato a SSL, tranne per il fatto che la maggior parte dei meccanismi di autenticazione da client a server può essere considerata "sicura" solo quando si verificano all'interno di un tunnel protetto, ad es. qualche connessione SSL stabilita.

La relazione tra la suite di crittografia e le autenticazioni è la seguente:

• La suite di crittografia può richiedere un tipo di chiave specifico (ad esempio RSA o DSA) e le cose funzioneranno solo se la chiave pubblica, come trovata nel certificato del server, è di quel tipo.

• L'autenticazione da client a server è sicura solo nella misura in cui il tunnel SSL / TLS garantisce riservatezza e integrità; ci sono suite di cifratura debole che non lo fanno bene. Fortunatamente, queste suite di crittografia sono state definite in conformità con le vecchie norme statunitensi sull'esportazione e non sono più attivate di default o supportate dai moderni browser Web (tranne forse in alcuni paesi, che potrebbero insistere sui loro cittadini utilizzando suite di crittografia deboli).