Perché un client, connettendosi a un server con SSL, usa il cifrario con il minor numero di bit?

Question

Perché un client, connettendosi a un server con SSL, usa il cifrario con il minor numero di bit?

#1 da (3 voti)
#2 da (1 voti)

1

Stavo testando due diverse impostazioni di Apache2.

Nel primo caso, ho utilizzato l'elenco offerto dal link che offre il certificato gratuito. L'elenco ha il seguente aspetto:

SSLHonorCipherOrder     on
SSLCompression          off
SSLCipherSuite 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
               :AES128-SHA256
               :AES256-SHA256
               :AES128-SHA
               :AES256-SHA
               :AES
               :CAMELLIA
               :DES-CBC3-SHA
               :!aNULL
               :!eNULL
               :!EXPORT
               :!DES
               :!RC4
               :!MD5
               :!PSK
               :!aECDH
               :!EDH-DSS-DES-CBC3-SHA
               :!EDH-RSA-DES-CBC3-SHA
               :!KRB5-DES-CBC3-SHA

ATTENZIONE: L'elenco dei cypher dovrebbe essere una lunga riga in Apache2, ma per renderlo leggibile qui, l'ho rotto con un codice per riga.

Quando provo quella lista con

https://www.ssllabs.com/ssltest/analyze.html?d=<domain.tld>

Ottengo:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1  FS  128 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1  FS  256 (eq. 3072 bits RSA)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256   (0x9e)   DH 2048 bits    FS  128
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384   (0x9f)   DH 2048 bits    FS  256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1  FS  128 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA    (0xc013) ECDH secp256r1  FS  128 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1  FS  256 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA    (0xc014) ECDH secp256r1  FS  256 (eq. 3072 bits RSA)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   (0x67)   DH 2048 bits    FS  128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA      (0x33)   DH 2048 bits    FS  128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   (0x6b)   DH 2048 bits    FS  256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA      (0x39)   DH 2048 bits    FS  256
TLS_RSA_WITH_AES_128_GCM_SHA256       (0x9c)                       128
TLS_RSA_WITH_AES_256_GCM_SHA384       (0x9d)                       256
TLS_RSA_WITH_AES_128_CBC_SHA256       (0x3c)                       128
TLS_RSA_WITH_AES_256_CBC_SHA256       (0x3d)                       256
TLS_RSA_WITH_AES_128_CBC_SHA          (0x2f)                       128
TLS_RSA_WITH_AES_256_CBC_SHA          (0x35)                       256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)   DH 2048 bits    FS  256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA     (0x84)                       256
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)   DH 2048 bits    FS  128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA     (0x41)                       128
TLS_RSA_WITH_3DES_EDE_CBC_SHA         (0xa)                        112

Ora capisco il concetto di mettere prima il DHE e l'ECDHE. Questi sono chiaramente contrassegnati con "FS" che significa Forward Secrecy (cioè i tuoi messaggi rimarranno segreti in futuro anche se un hacker può in qualche modo ottenere la tua chiave privata.) Almeno fino a quando i qubit sono una realtà.)

Quello che mi chiedo è la colonna con i numeri "128" e "256". Perché dovremmo prima mettere un cifrario con meno bit di cifratura? La crittografia è sicura ma sarà più veloce perché ha bisogno di meno bit per crittografare i dati? O dovremmo avere prima tutto il 256, poi il 128 e infine il 112 (se vogliamo mantenere quello brutto ...)

Oppure sto fraintendendo quel numero e l'ordine è già buono come può essere?

Più tardi ho provato con un setup che ho ottenuto eseguendo il controllo PCI Compliance su un server e ho trovato un setup che genera quell'elenco. Il setup è simile a questo:

SSLCipherSuite          HIGH:MEDIUM:!ADH:!MD5:!aNULL:!eNULL:!LOW:!EXP:!RC4

Semplicemente! Tuttavia, tale impostazione non supporta l'opzione SSLHonerCipherOrder . Se l'opzione è on o no, l'ordine viene detto non specificato dal server (che è probabilmente vero).

In questo caso, il sito Web Qualys SSL Labs termina l'ordinamento delle cifre come segue: tutti i più piccoli prima (112) e poi l'ultimo più grande (256). Sarebbe quello che i browser farebbero? Cercando di ottenere il minor numero di bit per procedere con la crittografia? Non sarebbe il modo meno sicuro di trasmettere dati?

TLS_RSA_WITH_3DES_EDE_CBC_SHA         (0xa)                        112
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA     (0x16)   DH 2048 bits    FS  112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA   (0xc012) ECDH sect571r1  FS  112 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_128_CBC_SHA          (0x2f)                       128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA      (0x33)   DH 2048 bits    FS  128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA     (0x41)                       128
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)   DH 2048 bits    FS  128
TLS_RSA_WITH_SEED_CBC_SHA             (0x96)                       128
TLS_DHE_RSA_WITH_SEED_CBC_SHA         (0x9a)   DH 2048 bits    FS  128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA    (0xc013) ECDH sect571r1  FS  128 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_128_CBC_SHA256       (0x3c)                       128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   (0x67)   DH 2048 bits    FS  128
TLS_RSA_WITH_AES_128_GCM_SHA256       (0x9c)                       128
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256   (0x9e)   DH 2048 bits    FS  128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH sect571r1  FS  128 (eq. 15360 bits RSA)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH sect571r1  FS  128 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_256_CBC_SHA          (0x35)                       256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA      (0x39)   DH 2048 bits    FS  256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA     (0x84)                       256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)   DH 2048 bits    FS  256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA    (0xc014) ECDH sect571r1  FS  256 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_256_CBC_SHA256       (0x3d)                       256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   (0x6b)   DH 2048 bits    FS  256
TLS_RSA_WITH_AES_256_GCM_SHA384       (0x9d)                       256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384   (0x9f)   DH 2048 bits    FS  256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH sect571r1  FS  256 (eq. 15360 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH sect571r1  FS  256 (eq. 15360 bits RSA)

apache cipher-selection ciphers

posta Alexis Wilke 16.09.2016 - 07:25

fonte

2 risposte

1

Penso che la tua domanda possa essere ridotta a queste domande:

Ha senso che il server preferisca i cifrari con meno bit? Ha senso che un server preferisca i cifrari utilizzare meno risorse sul lato server. Pertanto è opportuno preferire cifrari con meno bit se questi sono più veloci purché siano abbastanza sicuri. Ma nota che la forza e le prestazioni dei cipher non dipendono esclusivamente dai bit ma anche dall'algoritmo.
I clienti preferiscono i cifrari con meno bit, ad esempio nel caso in cui i server rispettino l'ordine di crittografia del client?
Questo dipende dal cliente. SSLLabs contiene ulteriori informazioni sul comportamento di clienti specifici . Qui puoi vedere ad esempio che sia Chrome che Firefox preferiscono AES con 128 bit prima di 256 bit, mentre Edge fa il contrario.

risposta data 16.09.2016 - 09:49

fonte

Leggi altre domande sui tag apache cipher-selection ciphers

Quale scopo serve la porta 1900 nel router domestico L'ordine soggetto nome alternativo ha importanza per i certificati TLS?

score 3 · Accepted Answer

Sembra che tu abbia sbagliato su SSLHonorCipherOrder . Doc dice "normalmente viene utilizzata la preferenza del client . Se questa direttiva è abilitato, al suo posto verrà utilizzata la preferenza del server . " Quindi l'opzione è erroneamente denominata, dovrebbe essere chiamata qualcosa come PICK_THE_CIPHER_PER_SERVER'S_ORDERING_AND_DONT_RESPECT_THE_CLIENT'S_ORDERING.

L'informazione importante è che la negoziazione di cifratura TLS / SSLv3 predefinita non funziona, come affermerebbe normalmente il nostro documento Apache. Beh, è una "negoziazione" tanto quanto negoziare Cuba con gli Stati Uniti. RFC dice che nel primo messaggio il cliente invia una lista di possibili cifrari. È una lista ordinata? Dipende dal server, davvero. Una delle cifre viene scelta dal server. Il server decide. Il cliente può solo procedere o riavviare l'intera sessione. Il server non mostra mai la sua lista completa , quindi in nessun caso permette al client di prelevare qualcosa da esso.

Il SSLHonorCipherOrder off (normale Apache) è quando il server abdica, inizia a considerare SSLCipherSuite come una lista non ordinata, e invece tratta la proposizione del client come un elenco ordinato autorevole: il primo cifrario supportato sarebbe usato ciecamente. Con on , il server considera la proposizione del client come non ordinata. La preferenza del server (sempre interna) è SSLCipherSuite list.

Quindi test di ssllabs senza SSLHonorCipherOrder è inutile in quanto dice semplicemente qual è l'ordine preferito di ssllabs. Quello che hai detto che l'opzione non era supportata con HIGH:MEDIUM:etc è non vero : funziona perfettamente con i miei siti e ssllabs mostra prima HIGH suite. Il rapporto mostra esattamente lo stesso ordine di crittografia del comando server openssl ciphers 'HIGH:MEDIUM:etcxxx' , non sorprendentemente.

E un ultimo punto. Le suite di crittografia "Debole-strong-strong" non hanno senso, sono sbilanciate. RSA 2048 è debole . Wikipedia dice che è stimato a 112 bit. E se RSA è rotto, ciao ciao https, ciao man-in-the-middle. Quindi non ha molto senso unirsi a AES256 che è incredibilmente strong, con un RSA 2048 molto debole. È uno spreco di CPU, davvero. Dovremmo iniziare a cestinare i certificati RSA e riemettere i nostri certificati come ECDSA il prima possibile, così potremmo avere il nostro primo pacchetto di crittografia sicuro, ben bilanciato, sicuro (e intendo ECDHE-ECDSA-AES128-GCM-SHA256).