Quali cifrari SSL / TLS possono essere considerati sicuri?

Le suite di crittografia con " NULL " non offrono la crittografia dei dati, ma solo il controllo di integrità. Questo significa "non sicuro" per la maggior parte degli usi.

Le suite di crittografia con " EXPORT " sono, per definizione, deboli. Sono sono crittografati, ma solo con chiavi abbastanza piccole da essere incrinate anche con hardware amatoriale (ad esempio, un PC di base - crittografia simmetrica che si basa su chiavi a 40 bit). Queste suite sono state definite in conformità con le regole di esportazione degli Stati Uniti sui sistemi crittografici, regole che erano piuttosto rigide prima del 2000. Oggi queste restrizioni sono state eliminate e non ha molto senso supportare le suite di crittografia " EXPORT ".

Le suite di crittografia con " DES " (non " 3DES ") si basano sulla crittografia simmetrica su DES , un vecchio codice a blocchi che utilizza una chiave a 56 bit ( tecnicamente , usa una chiave a 64 bit, ma ignora 8 di quei bit, quindi la dimensione della chiave effettiva è di 56 bit). Una chiave a 56 bit è fendibile, anche se non in cinque minuti con un PC. Deep crack era una macchina per scopi speciali costruita nel 1998 per circa 250.000 $, e poteva crackare una chiave DES a 56 bit all'interno 4,5 giorni in media. La tecnologia è progredita e può essere riprodotta con qualche dozzina di FPGA . Hardware non ancora disponibile in commercio, ma accessibile a molte persone.

Tutte le altre suite di crittografia supportate da OpenSSL non sono deboli; se hai un problema con loro, non sarà dovuto a una debolezza crittografica negli algoritmi stessi. Puoi evitare le suite di crittografia che presentano " MD5 ", non a causa di una reale debolezza nota, ma per le pubbliche relazioni. MD5 , come funzione di hash, è "rotto" perché possiamo trovare in modo efficiente molte collisioni per quella funzione. Questo non è un problema per MD5 in quanto è utilizzato in SSL; tuttavia, questo è sufficiente per MD5 per avere una cattiva reputazione, e è meglio evitarlo.

Si noti che la suite di cifratura non impone nulla sulla dimensione della chiave del server (la chiave pubblica nel certificato del server), che deve essere sufficientemente grande da fornire una robustezza adeguata (per RSA o DSS, andare per almeno 1024 bit 1536 bit sono migliori, ma non spingerlo troppo, perché l'overhead computazionale si alza bruscamente con le dimensioni della chiave).

NIST , un'organizzazione federale statunitense accettata e nota come qualsiasi organizzazione di sicurezza può essere, ha pubblicato alcune raccomandazioni (si vedano in particolare le tabelle alle pagine 22 e 23); questo è del 2005 ma è ancora valido oggi. Si noti che il NIST opera su base "approvata / non approvata": non pretendono in alcun modo che gli algoritmi "non approvati" siano deboli in alcun modo; solo che loro, come organizzazione, non garantiscono per loro.

Hai letto SSL e TLS: progettazione e creazione di sistemi sicuri , di Eric Rescorla? È il classico accettato su SSL, scritto da uno dei principali contributori al gruppo di lavoro sugli standard IETF su SSL. Mi aspetterei che potrebbe contenere dichiarazioni appropriate sulla forza di varie cipheresi SSL.

Se ciò non soddisfa le tue esigenze, puoi andare a visitare la tua biblioteca amichevole e controllare tutti i libri di testo di crittografia e sicurezza che hanno e leggere le sezioni scritte su SSL / TLS.

Fondamentalmente, se stai cercando un riferimento per documentare fatti che già conoscono tutti gli esperti di sicurezza, potresti dover fare un po 'di lavoro per trovare la citazione migliore.

Alcune piccole aggiunte alla risposta di Thomas Pornin: mentre il NIST SP800-52 rimane ufficiale (se un po 'obsoleto) per TLS in generale, per le dimensioni chiave in particolare è sostituito da SP800-57: part1 copre le dimensioni delle chiavi e le durate in generale, rivisto solo l'anno scorso 2012; part3 copre alcune applicazioni specifiche tra cui TLS emessa nel 2010. In breve, hanno cercato di richiedere RSA DSA e DH 2048 bit e ECC 224 bit nel 2011, ma c'era troppa pushback quindi ora è il 2014 - in arrivo! (DSA a 2048 o 3072 bit è specificato da FIPS 186-3 nel 2009, ma non vedo ancora molta implementazione. Persino openssl lo ha fatto piuttosto goffamente.) Www.CABforum.org concorda con RSA 2048 nel 2014; mentre non devi ottenere il tuo certificato da una CA "ufficiale", fare visibilmente meno della pratica "standard" comune tende a farti trattare con scetticismo. FWIW NIST attualmente dice che la forza (Z_n 2048, ECC 224, simmetrica 112) è "accettabile" fino al 2030, dopo di che è richiesto il 3072/256/128; anche se si rivelano sbagliati, se vai con loro hai una buona scusa che riesci a trovare, e sicuramente avrai tanta buona compagnia. Infine, csrc.nist.gov è un migliore URL di partenza per cybsersecurity (il NIST nel suo insieme fa molte altre cose).

Ritrovare le raccomandazioni ufficiali potrebbe essere un compito scoraggiante per la maggior parte degli utenti.

Il modo più rapido per ottenere un elenco aggiornato di codici moderni consiste nel controllare periodicamente Mozilla SSL Configuration Generator .

A partire da agosto 2016, la lista (ordinata) è:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256

Oltre a semplicemente applicare questi codici, assicurati di:

• imposta la versione TLS su 1.2 (o successiva)
• utilizza i parametri DH personalizzati (> = 3072 bit)
• usa una curva sicura a 384 bit (come definito su safecurves.cr.yp.to ) .

Nota: tutti questi cifrari sono compatibili con il (imminente) TLS1.3.