it-swarm.dev

Quali cifre devo usare nel mio server web dopo aver configurato il mio certificato SSL?

Ci sono molti grandi domande che chiedono qual è il miglior certificato da usare per un sito Web; ma una volta acquistato il certificato, c'è anche la possibilità di scegliere o modificare l'elenco di cifratura.

Sebbene ogni fornitore possa definire questa impostazione in modo leggermente diverso, la mia comprensione è che l'elenco di crittografia viene utilizzato per negoziare i protocolli di crittografia tra il client e il server.

  1. Quali sono le basi per scegliere un elenco di cifrature per il mio sito Web? Se è necessario modificare le impostazioni predefinite Dove dovrebbero andare i "principianti" per ottenere una consulenza affidabile?

  2. Alcune delle raccomandazioni tradizionali sono cambiate a partire dalla BEAST di settembre 2011 o dall'attacco CRIME del 2012?

  3. Qualcuno mantiene un elenco di cifre supportate dal sistema operativo/fornitore/e versione? È corretto dire che qualcosa del genere sarebbe utile?

  4. Alcuni certificati sono incompatibili o non preferiti con determinate cifre?

  5. Dove posso saperne di più? In particolare, come posso ottenere un'abilità superficiale per confrontare i Cipher senza dover ripetere alcune classi di matematica post-secondarie?

30

In SSL/TLS , la suite di cifratura seleziona una serie di algoritmi, per diverse attività: accordo chiave, crittografia simmetrica, controllo di integrità.

Il tipo di certificato influisce sulla scelta dell'accordo chiave. Devono essere presi in considerazione due parametri: il tipo di chiave e il utilizzo della chiave:

  • Con una chiave RSA è possibile utilizzare nominalmente la suite di crittografia "RSA" e "DHE_RSA". Ma se il certificato del server ha un'estensione di utilizzo chiave che include non include il flag "keyEncipherment", allora si è nominalmente limitati a "DHE_RSA".
  • Con una chiave DSA è possibile utilizzare solo una suite di crittografia "DHE_DSS".
  • Con una chiave Diffie-Hellman, è possibile utilizzare solo uno di "DH_RSA" o "DH_DSS", a seconda del tipo di chiave dell'autorità di certificazione emittente.

La maggior parte dei certificati del server SSL ha una chiave RSA che non è limitata tramite un'estensione Utilizzo chiave, quindi è possibile utilizzare entrambi i tipi di chiave "RSA" e "DHE_RSA".

"DHE" sta per "Diffie-Hellman Ephemeral". Ciò consente Perfect Forward Secrecy . PFS significa che se un utente malintenzionato ruba la chiave privata del server (quella memorizzata in un file, quindi plausibilmente vulnerabile a ulteriori furti), non sarà ancora in grado di decrittografare le transazioni registrate in passato. Questa è una proprietà desiderabile, specialmente quando vuoi che il tuo sistema abbia un bell'aspetto durante un controllo.

Per il controllo di integrità , non utilizzare MD5 e, se possibile, evitare anche SHA-1. Nessuno dei punti deboli attualmente conosciuti di MD5 e SHA-1 influisce sulla sicurezza di TLS (tranne se possibile se utilizzato all'interno di un certificato, ma scelto dall'autorità di certificazione, non da te). Tuttavia, l'uso di MD5 (o, in misura minore, SHA-1) è dannoso per le pubbliche relazioni. MD5 è "rotto". Se usi MD5, potresti dover giustificare te stesso. Nessuno metterebbe in dubbio la scelta di SHA-256. Il consenso generale è che SHA-1 è "tollerabile" per motivi legacy.

Per crittografia simmetrica , puoi scegliere tra (principalmente) RC4, 3DES e AES (per quest'ultimo, la versione a 256 bit è eccessiva; AES- 128 va già bene). È possibile formulare i seguenti punti:

  • RC4 e 3DES saranno supportati ovunque. I client meno recenti potrebbero non supportare AES (ad esempio Internet Explorer 6.0 non sembra essere in grado di negoziare suite di crittografia basate su AES).

  • Ci sono punti deboli noti in RC4. Nessuno è fatale subito. La situazione è in qualche modo simile a quella di SHA-1: accademicamente "rotta", ma non è un problema in questo momento. Questa è ancora una buona ragione per non usare RC4 se può essere evitato.

  • 3DES è un codice a blocchi a 64 bit. Ciò implica alcune debolezze (accademiche) quando si crittografano più di alcuni gigabyte in una singola sessione.

  • 3DES può essere pesante per la tua CPU. Su un Intel i7 a 2,7 GHz, OpenSSL raggiunge una velocità di crittografia di 180 MB/s con AES-128 (potrebbe fare molto meglio se usasse istruzioni AES-NI ) ma solo 25 MB/s con 3DES. 25 MB/s è ancora buono (è 2,5 volte quello che può gestire un collegamento a 100 Mbits/s e usando un singolo core) ma potrebbe non essere trascurabile, a seconda della situazione.

  • L'attacco BEAST è una vecchia debolezza accademica che è stata recentemente dimostrata applicabile nella pratica. Richiede che l'aggressore spii il collegamento e esegua codice ostile sul client (e tale codice deve comunicare con il sistema di spionaggio esterno); gli autori di BEAST sono riusciti a eseguirlo quando il codice interno ostile utilizza Java o Javascript. La soluzione generica è quella di passare a TLS 1.1 o 1.2, che sono immuni. Inoltre, ciò riguarda solo i cifrari a blocchi in modalità CBC; RC4 è immune.

  • In una stretta di mano SSL/TLS, il client annuncia le sue suite di crittografia supportate (le suite preferite vengono prima), quindi il server sceglie la suite che verrà utilizzata. È tradizionale che il server rispetta le preferenze del client, ovvero sceglie la prima suite nell'elenco inviata dal client che il server può gestire. Ma un server potrebbe imporre il proprio ordine di preferenze.

  • DHE implica un consumo della CPU leggermente più elevato sul server (ma non farà alcuna differenza evidente a meno che non si stabiliscano diverse centinaia di nuove sessioni SSL al secondo).

  • Non esiste una suite di crittografia DHE che utilizza RC4.

Riepilogo: questo mi porta al seguente elenco preferito di suite di cifratura. Se l'attacco BEAST può applicarsi a te (ovvero il client è un browser Web), utilizza questo:

  • Se la sessione utilizza SSL-3.0 o TLS-1.0, prova a utilizzare TLS_RSA_WITH_RC4_128_SHA.
  • Se il client supporta TLS 1.1+ o se non supporta TLS_RSA_WITH_RC4_128_SHA o se ritieni che PFS sia più importante per te degli attacchi attivi simili a BEAST (ad esempio, sei più preoccupato per la riservatezza a lungo termine, non per le violazioni immediate), quindi usa TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (fallback a TLS_DHE_RSA_WITH_AES_128_CBC_SHA se il client non supporta SHA-256).
  • Se le suite di crittografia DHE non sono supportate dal client, utilizzare la suite non DHE corrispondente.
  • Il fallback generico è TLS_RSA_WITH_3DES_EDE_CBC_SHA che dovrebbe funzionare ovunque.

Si noti che le scelte sopra presuppongono che è possibile modificare la selezione della suite in base alla versione del protocollo negoziato, che potrebbe essere o meno un'opzione disponibile per il proprio server SSL.

Se BEAST non si applica a te (il client non eseguirà il codice ostile), elimina del tutto il supporto RC4; concentrarsi su AES-128 e SHA-256; fallback su 3DES e SHA-1, rispettivamente; usare DHE se disponibile.

29
Thomas Pornin

Mi piace la suite di crittografia proposta da Mozilla (a gennaio 2014):

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

fonte: https://wiki.mozilla.org/Security/Server_Side_TLS

cerca di bilanciare prestazioni e sicurezza. Tuttavia, come consigliato il mio Microsoft , starei lontano da RC4

2
VP.

Dove sono le correzioni e come potrebbero apparire? L'unica soluzione sarebbe che tutti i browser su tutte le piattaforme pertinenti avrebbero implementato TLS 1.1 o 1.2. Tuttavia, non credo che ciò accadrà per le piattaforme legacy come.

Quindi per ora ho visto RC4 solo come una soluzione, dato che la maggior parte degli sviluppatori SW non ha implementato gli ultimi standard TLS in passato e ora siamo colti dalla situazione così com'è.

2
Jui

Aggiornamento 2016 tramite SSL Labs:

Dovresti fare affidamento principalmente sulle suite AEAD che forniscono autenticazione forte e scambio di chiavi, segretezza in avanti e crittografia di almeno 128 bit. Alcune altre suite più deboli possono ancora essere supportate, a condizione che vengano negoziate solo con client più vecchi che non supportano nulla di meglio.

Esistono diverse primitive crittografiche obsolete che devono essere evitate:

Le suite anonime Diffie-Hellman (ADH) non forniscono autenticazione.

  • Le suite di crittografia NULL non forniscono crittografia.
  • Le suite di crittografia di esportazione non sono sicure quando vengono negoziate in una connessione, ma possono anche essere utilizzate contro un server che preferisce suite più potenti (l'attacco FREAK).
  • Le suite con cifre deboli (in genere di 40 e 56 bit) utilizzano una crittografia che può essere facilmente interrotta.
  • RC4 non è sicuro.
  • 3DES è lento e debole.

Utilizzare la seguente configurazione della suite, progettata per le chiavi RSA ed ECDSA, come punto di partenza:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
EDH-RSA-DES-CBC3-SHA

Nota Questa configurazione di esempio utilizza nomi di suite non standard richiesti da OpenSSL. Per la distribuzione in altri ambienti (ad es. IIS), è necessario utilizzare i nomi delle suite TLS standard.

Riferimento: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites

1
bhushan5640

Diamo un'occhiata alle cifre che ignorano prima l'attacco BEAST.

Consiglierei di usare solo cifre "attuali" con chiavi forti e di non supportare cifre storiche che nessuno usa comunque. Quindi nessun RC4 per esempio. Inoltre, raccomanderei contro le cifre a livello di esportazione, queste hanno chiavi molto deboli in modo che il governo degli Stati Uniti possa essere in grado di romperle. Anche se credo che l'esportazione di crittografia di livello superiore non sia più illegale, il concetto esiste ancora nella configurazione del tuo server. Infine, evita gli algoritmi di hashing che hanno grossi problemi, come MD5.

Ora l'attacco BEAST .. apparentemente, AES in modalità CBC come usato in TLS 1.0 è vulnerabile a un attacco di recupero testo in chiaro scelto. mail.google.com ha difeso contro questo passaggio rapidamente a 128 bit RC4 questa settimana. Se sei molto preoccupato per questo attacco nelle prossime 2 settimane (come sarebbe google), potresti applicare la stessa soluzione alternativa. In altri casi, aspetterei semplicemente una correzione e configuro le tue cifre senza considerare questo attacco.

0
chris

Puoi trovare alcune configurazioni interessanti per Apache2 e una forte selezione dell'algoritmo SSL qui:

Generatore di configurazione SSL Mozilla https://mozilla.github.io/server-side-tls/ssl-config-generator/

La raccomandazione 2019.02 per i browser moderni è:

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: ECDHE-ECDSA-RS25: ECDHE-ECDSA-RS25 -AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384: ECDHE-ECDSA-AES128-SHA256: ECDHE-RSA-AES128-SHA256

leggibile:

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
0
amprantino