Quali opzioni SSL non dovrebbero essere utilizzate?

Devi evitare le suite di crittografia "deboli":

• Suite di crittografia senza crittografia (con NULL nel nome).
• Suite di cifratura con tasti simmetrici a 40 o 56 bit ( DES , DES40 , RC4_40 , RC2_CBC_40 ) ( 3DES va bene, però).
• Suite di cifratura contrassegnate da "per l'esportazione" (con EXPORT nel nome: sono indebolite per essere conformi alle normative di esportazione degli Stati Uniti precedenti al 2000).
• Suite di crittografia senza autenticazione del server ( DH_anon ).

Nessun software corretto abiliterà questi di default, o del tutto. Ma è più sicuro controllare esplicitamente ...

Potresti voler evitare RC4 a causa della cattiva stampa (ci vogliono ancora alcuni milioni di connessioni con gli stessi dati crittografati per colmare i noti punti deboli, che non è un enorme margine di sicurezza, ma il l'attacco non è ancora molto pratico). Alcune persone vogliono evitare i codici a blocchi basati su CBC perché temono il BEAST, ma non funziona più . Allo stesso modo, l'uso di MD5 in SSL / TLS è sicuro, ma l'idea che "MD5 è rotto" è talmente diffusa che l'uso di MD5 tende a scatenare domande e giustificazioni e un dibattito senza fine. In pratica, il tuo sistema non verrà interrotto perché hai usato RC4 o MD5 o AES-CBC o qualsiasi altra suite di crittografia non debole; siamo nel regno di pubbliche relazioni qui.

Tra le possibili opzioni, dovresti evitare compressione a meno che non ti assicuri che non si applica al tuo contesto esatto; questo perché la crittografia nasconde i dati contenuti ma non i dati lunghezza e la compressione rende la lunghezza dipendente dal contenuto. In un contesto Web (HTTPS), questo è chiamato Attacco CRIME .

Se possibile (a seconda del software del server e del certificato del server), prova a utilizzare le suite di crittografia DHE : forniscono Perfect Forward segretezza . Detto altrimenti: se si utilizza una suite di crittografia non DHE e alcuni malintenzionati riescono a rubare la propria chiave privata del server, allora sarà in grado di decodificare le connessioni passate (connessioni che l'attaccante ha osservato passivamente, da l'esterno, prima del vero furto di chiavi). PFS sta evitando quello. (Ma, naturalmente, PFS o non PFS, è molto meglio se la tua chiave privata del server non viene rubata affatto.)

Non utilizzare SSL 2.0 . In pratica, SSL 2.0 offre ancora una protezione decente contro gli attaccanti passivi , ma gli attaccanti attivi possono giocare brutti scherzi. Se il tuo software client e server supporta SSL 2.0 ma non SSL 3.0 o TLS (1.0 o successivi), il tuo software ha più di 15 anni e quasi certamente ha molti altri problemi.

Oltre alle risposte di cui sopra, uno dei servizi che puoi utilizzare è link , che testerà le impostazioni SSL / TLS e subito segnala violazioni. In questo modo puoi controllare rapidamente le tue impostazioni rapidamente (a meno che tu non abbia alcuni script pronti a farlo).

Nota: non sono associato a SSLLabs.

L'opzione RC4 non dovrebbe essere usata.

Non solo è vecchio (dal 1987, anche antico), ma soffre anche di piccoli problemi di sicurezza.

Ancora è spesso abilitato dal momento che altri algoritmi (più moderni e più pesantemente attaccati) hanno recentemente ricevuto cattive notizie. RC4 è piuttosto prevedibile e ripetutamente (diciamo 20 mila volte) la richiesta delle stesse pagine web tramite https mostrerà i pattern, consentendo così di compromettere la sicurezza.

[Modifica] Aggiunto link all'attacco -di-week-rc4-è-tipo-di-rotto-in.html