TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 è una suite di crittografia sicura da utilizzare?

10

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 è una suite di crittografia sicura da utilizzare per una connessione TLS 1.2 a un server Tomcat? Quali sono i potenziali punti deboli o le alternative migliori? Sto cercando una crittografia supportata da Java 8.

    
posta JRA_TLL 14.11.2014 - 15:14
fonte

2 risposte

18

I nomi di cipheruite di TLS sono strutturati in modo tale che è possibile stabilire quali algoritmi e dimensioni di chiave sono utilizzati per ciascuna parte dell'handshake e della sessione crittografata. Interrompiamo questo e vediamo se ci sono miglioramenti che possiamo apportare:

  • TLS - Questo non significa nulla di per sé, ma mi consente di menzionare che TLS 1.2 è l'ultima versione di TLS e non ha alcuna vulnerabilità nota.
  • ECDHE - Curva ellittica Diffie-Hellman con chiavi effimere. Questo è il metodo di scambio chiave. Gli scambi di chiavi Diffie-Hellman che utilizzano chiavi effimere (generate per sessione) forniscono la segretezza avanzata, il che significa che la sessione non può essere decifrata dopo il fatto, anche se la chiave privata del server è nota. La crittografia a curva ellittica fornisce una resistenza equivalente alla crittografia a chiave pubblica tradizionale, mentre richiede dimensioni di chiavi più piccole, che possono migliorare le prestazioni. Inoltre, servono come una scommessa di copertura contro una pausa in RSA.
  • RSA - Il certificato del server deve contenere una chiave pubblica RSA e la chiave privata corrispondente deve essere utilizzata per firmare i parametri ECDHE. Questo è ciò che fornisce l'autenticazione del server. L'alternativa sarebbe ECDSA, un altro algoritmo di curva ellittica, ma potresti essere limitato dai tipi di certificati che la tua CA firmerà.
  • AES_128 - Il codice di crittografia simmetrica è AES con chiavi a 128 bit. Questo è ragionevolmente veloce e non è rotto (a meno che non si pensi che la NSA abbia un backdoor AES, un argomento per un'altra volta). A parte AES_256 (che può essere troppo costoso per le prestazioni), è la scelta migliore delle cifrature simmetriche definite in RFC 5246 , gli altri sono RC4 (che ha alcuni punti deboli noti e potrebbe essere rotto in tempi relativamente brevi) e 3DES_EDE (che ha una forza di bit pratica da 108 a 112, a seconda della fonte).
  • CBC - Modalità concatenamento blocco cifrario. Ecco dove puoi probabilmente migliorare la tua scelta. La modalità CBC è un modo di utilizzare un codice a blocchi per crittografare una porzione di dati a lunghezza variabile, ed è stata la fonte dei problemi TLS in passato: BEAST, Lucky-Thirteen e POODLE erano tutti attacchi a TLS in modalità CBC. Una scelta migliore per prestazioni e sicurezza è AES_128_GCM, che è uno dei nuovi algoritmi AEAD introdotti in TLS 1.2 e presenta buone prestazioni e caratteristiche di sicurezza.
  • SHA256 - Questa è la funzione di hash che sta alla base della funzionalità di codice di autenticazione dei messaggi (MAC) della crittografia TLS. Questo è ciò che garantisce che ogni messaggio non sia stato manomesso durante il trasporto. SHA256 è un'ottima scelta ed è l'algoritmo hash predefinito per varie parti di TLS 1.2. Sono abbastanza sicuro che usare SHA-1 sarebbe ok qui, poiché la finestra per lo sfruttamento è molto più piccola di, ad es. la firma del certificato. Le cipherite elettroniche AEAD sono autenticate per cominciare, quindi questo passo MAC aggiuntivo non è necessario o implementato.

Essenzialmente, hai scelto una buona ciphersuite che al momento non ha problemi pratici, ma potresti voler passare a una ciphersuite di tipo AEAD (AES-GCM o ChaCha20-Poly1305 di Google) per prestazioni e protezione migliorate contro il futuro CBC vulnerabilità correlata.

    
risposta data 14.11.2014 - 16:40
fonte
7

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 è "sicuro" come qualsiasi suite di crittografia può essere: non esiste alcuna debolezza del protocollo nota relativa a TLS 1.2 con quella suite di crittografia. Qualsiasi particolare implementazione può, naturalmente, ingannare le cose e introdurre punti deboli di per sé. Puoi anche calpestare la tua sicurezza a terra, ad esempio, non riuscendo a proteggere adeguatamente la memoria della chiave RSA del tuo server; o utilizzando una coppia di chiavi debole per quella chiave RSA; o disattivazione della convalida del certificato nel client; o qualsiasi altra di una zillion di azioni stupide che sono fattibili se non ti prendi cura .

    
risposta data 14.11.2014 - 15:24
fonte

Leggi altre domande sui tag