¿Por qué un cliente, al conectarse a un servidor con SSL, usará el cifrado con la menor cantidad de bits?

Question

¿Por qué un cliente, al conectarse a un servidor con SSL, usará el cifrado con la menor cantidad de bits?

#1 de kubanczyk (3 votos)
#2 de Steffen Ullrich (1 votos)

1

Estaba probando dos configuraciones diferentes de Apache2.

En el primer caso, usé la lista ofrecida por enlace que ofrece un certificado gratuito. La lista se ve así:

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

ADVERTENCIA: Se supone que la lista de cifrados es una línea larga en Apache2, pero para que sea legible aquí, la dividí con un cifrado por línea.

Cuando pruebo esa lista con

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

me sale:

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

Ahora, entiendo el concepto de poner el DHE y el ECDHE primero. Estos están claramente marcados con "FS", que significa secreto en el futuro (es decir, sus mensajes se mantendrán secretos en el futuro, incluso si un pirata informático puede obtener su clave privada de alguna manera. Al menos hasta que los qubits sean una realidad).

Lo que me pregunto es la columna con los números "128" y luego "256". ¿Por qué pondríamos primero un cifrado con menos bits de cifrado? ¿El cifrado es seguro pero será más rápido porque necesita menos bits para cifrar los datos? O deberíamos tener todos los 256 primero, luego el 128, y finalmente el 112 (si queremos mantener ese feo ...)

¿O no entiendo bien ese número y la orden ya es tan buena como puede ser?

Más tarde probé con una configuración que obtuve al hacer una verificación de cumplimiento de PCI en un servidor y encontré una configuración que genera esa lista. La configuración se ve así:

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

Bastante simple! Sin embargo, esa configuración no admite la opción SSLHonerCipherOrder . Ya sea que esa opción esté activada o no, se dice que el servidor no especifica la orden (lo que probablemente sea cierto).

En ese caso, el sitio web de Qualys SSL Labs termina clasificando los cifrados de la siguiente manera: todos los más pequeños primero (112) y luego el más grande último (256). ¿Sería eso lo que harían los navegadores? ¿Intenta obtener el menor número de bits para continuar con el cifrado? ¿No sería esa la forma menos segura de transmitir datos?

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

pregunta Alexis Wilke 16.09.2016 - 07:25

fuente

2 respuestas

1

Creo que tu pregunta se puede reducir a estas preguntas:

¿Tiene sentido que el servidor prefiera cifrados y menos bits?
Tiene sentido que un servidor prefiera que los cifrados utilicen menos recursos en el lado del servidor. En la medida en que tiene sentido preferir cifrados con menos bits si son más rápidos, siempre y cuando sean lo suficientemente seguros. Pero tenga en cuenta que la fuerza y el rendimiento de los cifrados no dependen únicamente de los bits, sino también del algoritmo.
¿Los clientes prefieren cifrados con menos bits también, es decir, en caso de que los servidores respeten el orden de cifrado del cliente?
Esto depende del cliente. SSLLabs tiene más información sobre el comportamiento de clientes específicos . Allí puede ver, por ejemplo, que actualmente Chrome y Firefox prefieren AES con 128 bits antes de 256 bits, mientras que Edge hace lo contrario.

respondido por el Steffen Ullrich 16.09.2016 - 09:49

fuente

Lea otras preguntas en las etiquetas apache cipher-selection ciphers

¿Es posible y / o seguro el SSO sin SSL? ¿Importa el orden del nombre alternativo del sujeto para los certificados TLS?

score 3 · Accepted Answer

Parece que estás equivocado con SSLHonorCipherOrder . Doc dice "normalmente se usa la preferencia de cliente . Si esta directiva está habilitado, en su lugar se utilizará la preferencia de servidor . " Por lo tanto, la opción tiene un nombre erróneo, debería llamarse algo así como PICK_THE_CIPHER_PER_SERVER'S_ORDERING_AND_DONT_RESPECT_THE_CLIENT'S_ORDERING.

La información importante es que la negociación de cifrado TLS / SSLv3 predeterminada no funciona, como diría nuestro documento Apache, normalmente. Bueno, es tanto una "negociación" como Cuba negociando con Estados Unidos. RFC dice que en el primer mensaje el cliente envía una lista de posibles cifrados. ¿Es una lista ordenada? Depende del servidor, de verdad. Uno de los cifrados es elegido por el servidor. El servidor decide. El cliente solo puede continuar o reiniciar la sesión completa. El servidor nunca muestra su lista completa , por lo que en ningún caso le permite al cliente elegir nada de él.

El SSLHonorCipherOrder off (Apache normal) es cuando el servidor renuncia, comienza a tratar su propio SSLCipherSuite como una lista desordenada, y en su lugar trata la propuesta del cliente como una lista autorizada ordenada: el primer cifrado admitido se usaría a ciegas. Con on , el servidor trata la propuesta del cliente como desordenada. La preferencia del servidor (siempre interna) es SSLCipherSuite list.

Por lo tanto, la prueba de ssllabs sin SSLHonorCipherOrder es inútil ya que simplemente dice cuál es el orden preferido de ssllabs. Lo que dijiste que la opción no era compatible con HIGH:MEDIUM:etc es no es cierto : funciona muy bien con mis sitios y ssllabs muestra primero HIGH suites. El informe muestra exactamente el mismo orden de cifrado que el comando de servidor openssl ciphers 'HIGH:MEDIUM:etcxxx' , como era de esperar.

Y un último punto. Las suites de cifrado "Débil-Fuerte-Fuerte" no tienen sentido, están desequilibradas. RSA 2048 es débil . Wikipedia dice que se estima en 112 bits. Y si se rompe el RSA, adiós https, hola hombre en el medio. Por lo tanto, tiene poco sentido unirse a AES256, que es ridículamente fuerte, con un RSA 2048 muy débil. Es un desperdicio de CPU, en realidad. Deberíamos comenzar a descartar los certificados RSA y volver a emitir nuestros certificados como ECDSA lo antes posible, para que podamos tener nuestro primer conjunto de cifrado seguro, amigable y bien equilibrado (y me refiero a ECDHE-ECDSA-AES128-GCM-SHA256).