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
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:
-
¿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?
-
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.