Entendiendo los cifrados en lista negra para HTTP2

Question

Entendiendo los cifrados en lista negra para HTTP2

#1 de dave_thompson_085 (4 votos)
#2 de phyrfox (1 votos)

3

He estado trabajando en conseguir que el soporte HTTP2 se ejecute en un servidor Nginx desde hace algún tiempo. En este punto estoy atascado en la selección de cifrados para apoyar. Espero que me puedas ayudar a entender esto.

Antes de comenzar a hacer que HTTP2 funcionara, me convertí en un hobby para obtener las mejores calificaciones posibles en SSLlabs mientras mantenía el soporte para La mayoría de los navegadores. Por lo tanto, solo admití cifrados de 256 bits y no enumeré ningún cifrado de 128 bits.

Desde que habilité HTTP2, perdí la compatibilidad con Firefox en Windows (y probablemente también en otros navegadores / plataformas). Tenga en cuenta que estoy bien al haber perdido el soporte para Java, XP y Android 2.3 de acuerdo con las simulaciones del navegador SSLlabs, ya que este es un servidor privado.

Según SSLlabs, Firefox versión 45 y 46 en Windows no se pueden conectar al servidor. El mensaje que se muestra es: Servidor negociado HTTP / 2 con paquete en lista negra. De acuerdo con los resultados, estas versiones de Firefox habrán seleccionado el cifrado TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA . Una búsqueda rápida me llevó a este tema en ServerFault que explica que el RFC especifica una lista negra de cifrados.

Esta es la lista de cifrado que tenía configurada:

ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:kEDH+AESGCM:CAMELLIA256:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!CAMELLIA+RSA:!AES128:@STRENGTH;

Estoy convencido de que TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA es más fuerte que TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (que usa Firefox en mi configuración actual), ya que tiene una mayor preferencia por Nginx si agrego @STRENGTH a la directiva ssl_ciphers. Aún así, el primero aparece en la lista negra y el segundo no.

Soy consciente de que ya hay algunos temas aquí sobre qué cifrados deben elegirse para obtener el mejor soporte. Sin embargo, con esta publicación estoy tratando de entender mejor por qué algunas de las suites de cifrado enumeradas anteriormente están en la lista negra y varias cifras de 128 bits no lo están.

tls http2 ciphers

pregunta Evy Bongers 12.06.2016 - 00:19

fuente

2 respuestas

Lea otras preguntas en las etiquetas tls http2 ciphers

¿Qué hay que considerar de seguridad cuando se tiene una política de correo electrónico para todos? ¿Cómo se determina qué parámetro de fuerza se pasa a BCryptEncoder (el valor predeterminado es 10) en Spring Java?

score 4 · Answer 1

Como dice el apéndice rfc4880 al que enlazaste dice

  Note: This list was assembled from the set of registered TLS
  cipher suites at the time of writing.  This list includes those
  cipher suites that do not offer an ephemeral key exchange and
  those that are based on the TLS null, stream, or block cipher type
  (as defined in Section 6.2.3 of [TLS12]).  Additional cipher
  suites with these properties could be defined; these would not be
  explicitly prohibited.

Las suites de transmisión están en la lista negra porque el único cifrado de transmisión utilizado en TLS es RC4 y los ataques contra RC4 prácticamente han explotado en los últimos años; Consulte rfc 7465 .

Las suites CBC están en la lista negra porque ahora se reconoce TLS-nee-SSL (aunque antes del primer reconocimiento claro de esto, Bellare y Namprempre en Asiacrypt 2000) en parte porque MTE se combinó con CBC (que requiere relleno) en un protocolo en línea permite ataques oráculo de relleno como POODLE y Lucky13. POODLE rompe severamente SSL3, pero SSL3 ya estaba oficialmente obsoleto y POODLE finalmente motivó a las personas a eliminarlo. Lucky13 requiere una sincronización precisa y no es muy práctico ahora, pero muestra un enfoque que podría mejorar. (El uso de SSL y TLS1.0 de IV expuesto para CBC también permitió BEAST, pero esa parte se corrigió en 1.1 y 1.2).

Los cifrados nulos están en la lista negra porque, bueno, su inconveniencia debería ser obvia.

Esto deja solo las suites AEAD, y en la práctica solo GCM, al menos por ahora. Tenga en cuenta que AEAD requiere TLS1.2, que aún no está implementado universalmente, por lo que las pruebas genéricas como SSLLabs aún aceptan los modos CBC para permitir servidores y / o clientes que usan 1.1 y 1.0 (pero no SSL3 como se indicó anteriormente). Chrome solía describir cualquier otra cosa que no fuera 1.2 con AEAD y el intercambio de claves efímeras como 'criptografía obsoleta', y security.SX tiene bastantes Qs sobre eso, pero en retest (51.0.2704.84) parece haberse detenido. HTTP / 2, que aparece después de que TLS1.2 y AEAD "deberían" estar ya en su lugar, pueden ser razonablemente más exigentes.

A menos que obtengamos computadoras cuánticas prácticas, muy grandes a menos que la gente esté preocupada, la diferencia de fuerza entre AES-128 y AES-256 no tiene sentido . Es la diferencia entre 'irrompible en nuestra galaxia, pero alguien que controle el universo entero por miles de años podría romperlo' e 'irrompible incluso en todo el universo'. No importa lo perversa que sea tu colección de videos de gatos, no debería preocuparte si se descifra después de que hayas muerto hace mucho tiempo, todos tus descendientes están muertos, todos los seres humanos están muertos y nuestro planeta y nuestro sistema solar ya no existen.

(Aunque, dadas todas las demás funciones de medios agregadas en HTTP / 2, estoy decepcionado de que no agregaron ninguna capacidad para prohibir o al menos limitar y degradar seriamente los videos de gatos. Bueno, siempre hay X-)

score 1 · Answer 2

Los algoritmos de cifrado están diseñados para ocultar la entrada original de la salida sin el conocimiento de la clave. Lo ideal es que al cambiar cualquier bit en la clave se modifiquen varios bits en la salida, y se debe hacer en un patrón aparentemente impredecible. Los algoritmos de la lista negra se han sometido a un análisis cuidadoso y se encontró que carecen de esta característica para un número significativo de bits clave. Esta es la razón por la que a menudo verá una "fuerza de bits efectiva" para un algoritmo dado, y generalmente es más pequeña que los bits de la clave (porque muchos algoritmos invariablemente pierden algunos bits). En otras palabras, cuanto más aleatoria sea la salida, más efectiva será.

Por ejemplo, una clave de 256 bits en un determinado algoritmo puede producir solo 56 bits de seguridad, mientras que una clave de 128 bits en otro algoritmo puede proporcionar 96 bits de seguridad. Cuando se analiza de esta manera, es fácil ver que la clave de 128 bits es superior a la clave de 256 bits, a pesar de ser la mitad del tamaño, y por lo tanto 2 veces ¹²⁸ más pequeñas en términos de valores posibles. Esta es una de las razones por las que "xor encryption" se considera débil: puede aplicar fácilmente una función a la salida y adivinar la clave y entrada, a menos que se cumplan ciertas condiciones.

La razón por la que HTTP / 2 incluye en una lista negra ciertos algoritmos es comenzar con una base sólida de cifrados que serán viables en el futuro inmediato. No puede continuamente poner en la lista negra los algoritmos y esperar que todos los servidores y clientes se mantengan actualizados en tiempo real. Por lo tanto, al rechazar aquellos cifrados que ya están rotos o están en peligro de romperse en un futuro cercano, tiene más tiempo para hacer frente al crecimiento exponencial de la informática.