Escludendo le suite di crittografia contenenti SHA o AES128

3

Sono consapevole che questo potrebbe non essere visto come una domanda, ma qui va:

Una grande organizzazione con cui lavoro ha recentemente pubblicato una nuova serie di standard per suite di crittografia accettabili su tutti i siti Web pubblici. Gli standard si riducono a questo:

  • Se la suite di crittografia contiene SHA1, non è accettabile (ad es. ECDHE-RSA-AES256-SHA)
  • Se la suite di crittografia utilizza la crittografia a 128 bit - non è accettabile (ad esempio ECDHE-RSA-AES128-GCM-SHA256)

Per quanto posso dire, anche in presenza di recenti scoperte di vulnerabilità, questa non sembra una premessa valida per un insieme di standard TLS. HMAC con SHA è ancora considerato accettabile e AES128-GCM è considerato abbastanza robusto (per quanto ne so).

Ho una possibilità di argomentare per un'eccezione a questa regola (che mi piacerebbe fare, poiché la conformità implica la rimozione di un importante fornitore di CDN dal sito). Qualcuno ha qualche idea sul perché la rimozione delle suite di crittografia che soddisfano questi criteri sarebbe dannosa per l'utente finale del sito (compatibilità del client, prestazioni, ecc.).

    
posta Mark Kelly 11.08.2016 - 22:23
fonte

3 risposte

3

In primo luogo, non è necessario dal punto di vista della sicurezza. HMAC-SHA1 e AES-128 sono più o meno a posto. Questo è sciocco. Non scrivere politiche di sicurezza stupide.

Secondo, dovresti rovinare Firefox. Firefox 46 supporta AES-128 con HMAC-SHA1 o GCM e AES-256 con HMAC-SHA1. AES-256-GCM non è un'opzione.

Firefox 47 ha anche aggiunto ChaCha20-Poly1305, che è un grande codice a 256 bit, ma è abbastanza nuovo, non ampiamente supportato dai server, e non ne hai parlato.

Firefox 49, attualmente in programma per il rilascio il 13 settembre, dovrebbe avere AES-256-GCM, ma questo è il futuro, e vorrai continuare a supportare versioni precedenti per i dei sapere quanto tempo comunque.

In terzo luogo, è un buon motivo per preferire suite di crittografia non HMAC: HTTP / 2 lo incoraggia . L'implementazione della blacklist della suite di crittografia è facoltativa, ma Chrome e Firefox lo fanno entrambi. Se abiliti HTTP / 2, avrai assolutamente bisogno di pacchetti di crittografia accettabili (che includono AES-GCM con scambio di chiavi DHE o ECDHE, ma non HMAC, indipendentemente dalle dimensioni della chiave). Sei libero di mantenere abilitate le suite di crittografia obsolete, ma devi dare la preferenza a quelle migliori quando si negoziano con i client HTTP / 2.

ETA: potresti indirizzarli alla guida TLS lato server di Mozilla e SSL Configuration Generator e dire" È una buona idea copiare questo solido, ben studiato consiglio di esperti ". Sarebbe vero, e manterrebbe il supporto AES-128. (Alcune varianti rimuovono effettivamente HMAC-SHA1, ma mantengono tutte HMAC-SHA256 e HMAC-SHA384.)

    
risposta data 11.08.2016 - 23:34
fonte
3

L'aggiornamento a AES-256 sta accadendo e i nuovi server lo offrono come opzione 1-st. Per illustrarti come si fa qui, ecco la lista delle più recenti cifrature SSL httpd (test con nmap), vedi sotto.

Ora il fatto è che se il browser non fosse in grado di utilizzare alcuna variante strong, allora potrebbe utilizzare qualsiasi altro cifrario supportato più debole. I cipher vengono provati dal protocollo TLS più alto supportato e quindi dalle varianti dal primo all'ultimo all'ultimo.

La seguente configurazione fa sì che i buoni clienti utilizzino crittografi potenti ma mantengano la compatibilità con quelli più vecchi, quindi nessuno ne risente.

Dopo averlo modificato, puoi analizzare i registri SSL per vedere quali varianti possono essere rimosse e quanti utenti saranno interessati, ma se è una grande azienda la lista qui sotto dovrebbe funzionare per tutti per l'inizio.

Per quanto riguarda i CDN, il passaggio da AES-128 a 256 è un enorme cambiamento che costa un prezzo significativo. Tuttavia, tale cambiamento dovrà avvenire una volta aggiornato il software a quello più recente che sicuramente accadrà nei prossimi anni.

Quindi con questo server Firefox utilizza TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA , OpenSSL utilizza la migliore scelta TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 , Google Chrome dice TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA , il tutto con TLS 1.2.

Diversamente, ciò potrebbe sconvolgere molti utenti.

nmap --script ssl-enum-ciphers -p 443 127.0.0.1

443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|_  least strength: C
    
risposta data 11.08.2016 - 23:29
fonte
0

Si potrebbe rendere l'argomento che rimuovere la crittografia SHA1 e 128-bit causerà problemi di compatibilità, anche se SHA1 è attualmente in fase di eliminazione. Invitali a fare affidamento su NIST per le scelte dell'algoritmo.

    
risposta data 11.08.2016 - 23:15
fonte

Leggi altre domande sui tag