DHE_RSA Pubkey Length in TLS 1.2?

5

Resumen:

Parece que un cliente TLS no puede negociar cuando el servidor entrega una clave de pub de 127 bytes en el mensaje de intercambio de claves del servidor DHE_RSA, pero tiene éxito cuando entrega una clave de pub de 128 bytes. ¿Cuál es el problema con la longitud de la clave de publicación, y específicamente, es este comportamiento legítimo por parte del servidor?

Detalles sangrientos:

Tengo un cliente (software desconocido) que está experimentando fallas intermitentes al conectarse a mi servidor TLS (F5, TLS 1.2). Las conexiones exitosas y fallidas se establecen en Cipher Suite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) en el servidor Hola. Todos los intentos de conexión alcanzan el servidor Hello Done y el cliente ENCUENTRA FINALMENTE a las conexiones fallidas inmediatamente después.

En cuanto a las capturas de paquetes, todos los fallos parecen coincidir con un "Pubkey Length" de 127 en el protocolo de intercambio de claves del servidor:

Porotraparte,cadanegociaciónexitosaconesteclientehainvolucradouna"Longitud de Pubkey" de 128 en el protocolo de intercambio de claves del servidor:

Siemprequeelservidorenvíalaversiónde127bytes,elclienterespondeconunFIN/ACKenlugardelintercambiodeclavesdelcliente.Laconclusiónalaquehemosllegadoesquelalongituddelaclavedepublicaciónde127bytesnoesaceptableparaelcliente.Heleído RFC 5246 para ver si puedo obtener una idea de lo que está permitido y " No es útil (al menos para mí):

struct {
    opaque dh_p<1..2^16-1>;
    opaque dh_g<1..2^16-1>;
    opaque dh_Ys<1..2^16-1>;
} ServerDHParams;     /* Ephemeral DH parameters */

 struct {
     select (KeyExchangeAlgorithm) {
         case dhe_rsa:
             ServerDHParams params;
             digitally-signed struct {
                 opaque client_random[32];
                 opaque server_random[32];
                 ServerDHParams params;
              } signed_params;
    };
} ServerKeyExchange;

Por lo tanto, las preguntas específicas son:

  1. ¿Cuál es el problema con la longitud de la clave de publicación en el intercambio de claves del servidor DHE_RSA? Específicamente, ¿127 vs. 128 representan algo como el truncamiento cero para ahorrar longitud, o está realmente proporcionando una clave de 127 bytes?

  2. Más específicamente, es 127 una longitud de clave de publicación válida que el cliente debería poder manejar, o ¿podría esto representar un problema con el servidor que necesita direccionamiento?

Clarificación:

El servidor en cuestión es un equilibrador de carga F5 que ejecuta un software actualizado (11.6), por lo que no solo está disponible en el mercado, sino que también está disponible en un nivel relativamente alto cuando se trata de la procedencia TLS. Eso no quiere decir que no sea el problema, solo decir que no es como si estuviera lanzando mi propio servidor TLS Lua-over-Django-with-third-Rails en el backend :)

Lo que opina OpenSSL

Dejé una secuencia de comandos usando openssl s_client para golpear el servidor cada minuto durante el fin de semana, y capturé paquetes completos, para que pudiera ver qué opina OpenSSL de esta configuración de servidor en particular. Y en pocas palabras, con una longitud "Pubkey" de DHE de 127 bytes, OpenSSL considera la "clave temporal del servidor" de 1024 bits.

Aquí está el intercambio de claves del servidor como se muestra en Wireshark:

YaquíestálasalidadeOpenSSLparaesaconexión:

$tail-2520151107234244.txt---NoclientcertificateCAnamessentServerTempKey:DH,1024bits---SSLhandshakehasread2014bytesandwritten291bytes---New,TLSv1/SSLv3,CipherisDHE-RSA-AES256-GCM-SHA384Serverpublickeyis2048bitSecureRenegotiationISsupportedCompression:NONEExpansion:NONESSL-Session:Protocol:TLSv1.2Cipher:DHE-RSA-AES256-GCM-SHA384Session-ID:8C48CAD47FC01AF350CF618E21AE9C7E8764BB7C7243D8D6204F95634523EF2FSession-ID-ctx:Master-Key:FB80D1070A3BB2435C2D4E50D6633DA3DE4FDCFA5C8A922E17EC6FB0EDC41E259F55DFC33345B51F9A90568B36CFBB7CKey-Arg:NoneKrb5Principal:NonePSKidentity:NonePSKidentityhint:NoneStartTime:1446957764Timeout:300(sec)Verifyreturncode:21(unabletoverifythefirstcertificate)---$

Entonces,¿es1024o1016bits?¿Lalongitud'p'indicalaintensidaddelaclaveenlugardelalongituddelaclavedepublicación(ssl.handshake.ys_lenparalosquesiguenenWireshark)?¿Dóndesedefine"Server Key Exchange" para Diffie-Hellman? Alguien encontró suficiente documentación para escribir un analizador de Wireshark, si pudiera ver el doco que usaron, tal vez comprenda mejor las expectativas en torno a estos campos.

    
pregunta gowenfawr 06.11.2015 - 22:12
fuente

4 respuestas

5

En todos sus ejemplos, todas las claves DH son de tamaño "1024 bits", exactamente. En DH, están los parámetros (módulo p , generador g ), la clave privada ( x ) y la clave pública ( y ). La relación es y = gx mod p .

La "longitud de la clave" es el tamaño del primer p . En todos sus casos, p se encuentra entre 2 1023 y 2 1024 , por lo que es un "entero de 1024 bits" y este es el tamaño del par de claves DH. Ahora, la "clave pública" en sí misma es el entero y que se encuentra entre 1 y p -1; en particular, nada obliga a y a ser mayor que 2 1023 , y esto no es un problema . El campo "longitud de la clave de publicación" es el tamaño, en bytes, del valor codificado y (en notación sin signo big-endian). Dependiendo del valor exacto de p , se espera que entre 1 / 256th y 1 / 128th de todas las claves públicas DH solo necesiten 127 bytes para su codificación. En su último ejemplo, el valor y está codificado sobre 127 bytes, el primero es 06 , lo que implica que y es técnicamente un entero de 1011 bits; la longitud de la clave DH sigue siendo de 1024 bits ya que es el tamaño de p .

Por lo tanto, la "longitud de la clave de publicación" se relaciona con la longitud de la clave pública como en "la longitud de la codificación de y ", pero NO como en la "longitud" que indica si la clave se puede romper con poderosa atacantes ".

Aparentemente, algunos sistemas en su configuración (el cliente, o algún enrutador / cortafuegos entre el cliente y el servidor, tal vez el FIN mismo que usted observa en el servidor no es enviado por el cliente) está confundido y no distingue Dos nociones de "longitud pubkey". Configurar su F5 para usar un módulo más grande para DH puede solucionar el problema, y podría considerarse una buena idea de todos modos (1024 bits DH aún no se puede romper, pero teóricamente le gustaría usar 1024 bits DH no más que usted aceptaría utilizar RSA de 1024 bits).

    
respondido por el Thomas Pornin 09.11.2015 - 15:26
fuente
1

Solo quería resumir el estado actual de este problema:

  • Un ingeniero de F5 presentó un error en Microsoft con respecto a este problema que se puede encontrar aquí . Parece que MS lo ha aceptado y está trabajando en una solución, por lo que realmente parece ser un problema de SCHANNEL.
  • Actualmente, la única solución parece ser desactivar los cifrados DHE.
respondido por el piet.t 08.02.2016 - 09:30
fuente
1

Heads up: OpenSSL 1.1.0 tiene un cambio que envié para solucionarlo (consulte la PR aquí ) , y también se fusionó en la rama 1.0.2 a partir del 14 de diciembre de 2016, por lo que estará disponible en futuras versiones 1.0.2. Sería trivial para backport a 1.0.1 también, si necesita eso.

    
respondido por el russor 19.12.2016 - 07:36
fuente
0

La longitud de la clave pública depende del valor del campo principal. Supongo que, de hecho, el tamaño de la clave es menor que 128 bytes / 1024 bits. Eso significa que hay algo mal con el software en el servidor.

En principio, cualquier tamaño primo puede usarse para Diffie-Hellman; al final el valor será usado como un número. Sin embargo, usar una clave de 127 bytes / 1016 bits tiene algunos problemas:

  • no todo el software puede manejar un tamaño de clave en particular, a veces el software requiere un múltiplo de 8 bytes, por ejemplo;
  • 1024 bits ya es un tamaño muy pequeño para DH, hoy en día usted esperaría tamaños más grandes, como 2048 bits.

Sin embargo, primero me pondría en contacto con la organización que programó el servidor. Incluso si un tamaño de clave de 1016 bits no es directamente un problema, puede ser un indicio de problemas más serios.

    
respondido por el Maarten Bodewes 06.11.2015 - 23:58
fuente

Lea otras preguntas en las etiquetas