Confronto tra TLS e crittografia

Tieni presente che le nuove versioni di Google Chrome non supportano DHE. Personalmente non sono d'accordo con la loro decisione, ma hanno deciso [1] che il caso di un server con RSA a 2048 bit e DHE a 1024 bit è tristemente troppo comune (particolarmente triste è il DHE che usa un primo comune che molti credono che l'NSA abbia precalcolato per abilitare veloce bruteforcing dello scambio di chiavi), e dal momento che non è possibile specificare la forza minima di DHE durante l'handshake, per ottenere i migliori risultati in termini di sicurezza è necessario provare l'handshake con DHE, verificare la dimensione dei parametri offerti dal server, confrontarli alla dimensione della chiave RSA nel certificato, quindi decidere se si desidera procedere o riprovare senza DHE per provare a ottenere lo scambio di chiavi RSA non PFS (che a sua volta potrebbe essere disabilitato sul server forzandolo a utilizzare DHE). Questo handshake "probing" introduce troppa latenza (anche se si memorizza nella cache la coppia ciphersuite per dominio + ip address). Quindi hanno deciso di non supportare DHE e hanno raccomandato a tutti di passare a ECDHE su NIST P-256.

Quindi tra 1024 bit DHE e lo scambio di chiavi RSA semplice a 2048 bit, con Google Chrome si ottiene lo stesso in entrambi i casi mentre con altri client è necessario compensare la possibilità che l'avversario possa bruteforce 1024 DHE (alcune persone pensano che al momento solo l'NSA possa ) rispetto alla possibilità che qualcuno registri tutto il traffico crittografato, attende la scadenza del certificato, quindi recupera la chiave privata per il certificato scaduto da un dumpster e decrittografa tutto il traffico registrato, un anno o più dopo il fatto. Preferirei avere PFS, ma entrambe le opzioni sono pessime.

Suppongo che entrambi i siti abbiano certificati sha256 a 2048 bit con catene corrette da CA rispettabili, quindi non c'è differenza.

Se entrambi utilizzano suite di crittografia CBC e i client sono moderni e hanno contromisure BEAST che rendono TLS 1.0 non peggiore di TLS 1.1, quindi sono ugualmente male.

Il sito B che utilizza TLS 1.2 ha l'opzione di utilizzare GCM anziché CBC, che è particolarmente importante perché il costrutto MAC-then-encrypt in TLS è ridicolmente difficile [2] [3] [4] da implementare correttamente. Il sito B utilizza TLS_RSA_WITH_AES_256_CBC_SHA , TLS_RSA_WITH_AES_256_CBC_SHA256 o TLS_RSA_WITH_AES_256_GCM_SHA384 ? Nel caso in cui il sito B utilizzi GCM, è più sicuro del sito A.

1 - link

2 - link

3 - link

4 - link

La versione TLS e la suite di crittografia sono i parametri rilevanti per la sicurezza della connessione di una connessione TLS. Le informazioni sopra non mostrano la piena ciphersuite, ad es. manca l'algoritmo hash.

Tuttavia, invece di ottenere opinioni da individui qui su questo sito, puoi ottenere una sorta di valutazione ufficiale della qualità inviando il nome host al "Controllo SSL" su link . Ti darà una valutazione (A, B, C) e controlla un sacco di cose.