it-swarm.dev

Quale meccanismo di scambio di chiavi dovrebbe essere usato in TLS?

Esistono molti meccanismi di scambio chiave che possono essere utilizzati in TLS. Tra questi ci sono RSA, ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, ECDHE_RSA e altri. Quali di questi sono più crittograficamente sicuri e possono essere utilizzati per proteggere la connessione con il sito Web?

31
Andrei Botalov

È possibile utilizzare uno scambio di chiavi (come parte di una suite di crittografia) solo se il tipo di chiave del server e il certificato corrispondono. Per vedere questo in dettaglio, diamo un'occhiata alle suite di cifratura definite nella specifica TLS 1.2 . Ogni suite di cifratura definisce l'algoritmo di scambio delle chiavi, nonché gli algoritmi di crittografia simmetrica e controllo di integrità successivamente utilizzati; ci concentriamo qui sulla parte di scambio chiave.

  • RSA: lo scambio di chiavi funziona con crittografia un valore casuale (scelto dal client) con la chiave pubblica del server. Ciò richiede che la chiave pubblica del server sia una chiave RSA, e che il certificato del server non proibisca la crittografia (principalmente attraverso l'estensione del certificato "Uso chiave": se tale estensione è presente, deve includere il flag "keyAgreement").

  • DH_RSA: lo scambio di chiavi è a static Diffie-Hellman: la chiave pubblica del server deve essere una chiave Diffie-Hellman; inoltre, tale certificato deve essere stato emesso da un'autorità di certificazione che stessa utilizzava una chiave RSA (la chiave CA è la chiave utilizzata per firmare il certificato del server).

  • DH_DSS: come DH_RSA, tranne per il fatto che la CA ha usato una chiave DSA.

  • DHE_RSA: lo scambio di chiavi è un effimero Diffie-Hellman: il server genera dinamicamente una chiave pubblica DH e la invia al client; anche il server firma cosa invia. Per DHE_RSA, la chiave pubblica del server deve essere di tipo RSA e il relativo certificato deve essere appropriato per firme (l'estensione dell'utilizzo della chiave, se presente, deve includere il flag digitalSignature).

  • DHE_DSS: come DHE_RSA, tranne per il fatto che la chiave del server ha il tipo DSA.

  • DH_anon: non esiste un certificato server. Il server utilizza una chiave Diffie-Hellman che potrebbe aver generato dinamicamente. Le suite di crittografia "anon" sono vulnerabili agli attacchi impersonali (incluso, ma non limitato a "Man in the Middle" ) poiché mancano di qualsiasi tipo di autenticazione del server. In generale, non è necessario utilizzare una suite di crittografia "anon".

Gli algoritmi di scambio di chiavi che utilizzano la crittografia a curva ellittica sono specificati in n altro RFC e propongono quanto segue:

  • ECDH_ECDSA: come DH_DSA, ma con curve ellittiche: la chiave pubblica del server deve essere una chiave ECDH, in un certificato emesso da una CA che a sua volta utilizzava una chiave pubblica ECDSA.

  • ECDH_RSA: come ECDH_ECDSA, ma la CA emittente ha una chiave RSA.

  • ECDHE_ECDSA: il server invia una chiave Diffie-Hellman EC generata dinamicamente e la firma con la propria chiave, che deve avere il tipo ECDSA. Ciò equivale a DHE_DSS, ma con curve ellittiche sia per la parte Diffie-Hellman che per la parte della firma.

  • ECDHE_RSA: come ECDHE_ECDSA, ma la chiave pubblica del server è una chiave RSA, utilizzata per firmare la chiave Diffie-Hellman a curva ellittica effimera.

  • ECDH_anon: una suite di cifratura "anon", con Diffie-Hellman a curva ellittica dinamica.


Quindi, cosa sceglieresti per un sito Web? I tuoi principali vincoli sono:

  • Volete una suite di cifratura supportata dalla maggior parte dei client; in pratica, questo esclude la crittografia della curva ellittica (le curve ellittiche sono potentemente fredde, ma non ancora ben supportate sul campo - considera che secondo gs.statcounter , a settembre 2011, il 40% del cliente i sistemi usano ancora Windows XP e quasi il 5% usa IE 7.0).

  • Desideri una suite di crittografia compatibile con il tipo di chiave e il certificato del tuo server. Questo, a sua volta, dipende da ciò che la CA accetta (la CA che ti ha venduto il certificato). Il 99,9% delle volte, questo significa RSA. Tutti fanno RSA. Le chiavi Diffie-Hellman nei certificati e nelle firme DSA erano promosse dal NIST (l'agenzia federale americana che si occupa di tali questioni) perché esisteva un brevetto su RSA; ma quel brevetto è scaduto nel 2000. Diffie-Hellman (come parte dei certificati) è specificato da ANSI X9.42 , uno standard che non è gratuito (quindi gli sviluppatori di open-time free-time sono riluttanti a implementarlo) e non è neanche così chiaro. Quindi nessuno usa davvero Diffie-Hellman nei certificati. DSA è più ampiamente supportato (il suo standard di definizione è gratuito e abbastanza leggibile) ma non al punto di essere non aneddotico rispetto a RSA.

  • Non si desidera utilizzare una suite "anon" perché non è sicura contro gli aggressori attivi e la maggior parte dei browser client ha le suite "anon" disattivate per impostazione predefinita.

Quindi la tua scelta è fondamentalmente tra "RSA" e "DHE_RSA". Quest'ultimo potrebbe avere un costo computazionale leggermente più alto, anche se per vedere effettivamente la differenza dovresti avere almeno alcune centinaia di nuove connessioni al secondo (insisto sul "nuovo": poiché TLS include una stretta di mano abbreviata che può basarsi sul scambio di chiavi di una connessione precedente, l'effettivo scambio di chiavi con crittografia asimmetrica avviene solo una volta per nuovo browser client nell'ultimo minuto). Quindi, in pratica, nessuna differenza misurabile sul carico della CPU tra RSA e DHE_RSA.

DHE_RSA offre qualcosa di noto come Perfect Forward Secrecy , un nome pomposo per la seguente proprietà: se il tuo server viene completamente violato, al punto che l'attaccante ottiene una copia della chiave privata del server, allora essere in grado di decrittografare passato sessioni TLS (che ha registrato) se queste sessioni hanno usato RSA, mentre non sarà in grado di farlo se queste sessioni hanno usato DHE_RSA. In pratica, se l'attaccante potrebbe rubare la tua chiave privata, probabilmente potrebbe leggere i 10000 numeri di carta di credito nel database del tuo sito, quindi ci sono pochi motivi per cui dovrebbe anche preoccuparsi di registrare e decrittografare le sessioni precedenti perché ciò produrrebbe solo una dozzina in più numeri o così. PFS è matematicamente elegante, ma overhyped. Se è ancora un acronimo elegante e può fare una grande impressione sui deboli di mente, come parte di una campagna di pubbliche relazioni ben ponderata.


Riepilogo: usa DHE_RSA.

62
Thomas Pornin