Riepilogo:
Sembra che un client TLS non riesca a negoziare quando il server consegna un pubkey di 127 byte nel messaggio di scambio di chiavi del server DHE_RSA, ma riesce quando passa su un pubkey da 128 byte. Qual è l'accordo con la lunghezza di pubkey, e in particolare, questo comportamento legittimo è da considerarsi parte del server?
Dettagli cruenti:
Ho un client (software sconosciuto) che sta sperimentando guasti intermittenti connessi al mio server TLS (F5, TLS 1.2). Le connessioni riuscite e non riuscite si applicano a Cipher Suite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) nel server Hello. Tutti i tentativi di connessione raggiungono il server Ciao fatto e le connessioni non riuscite vengono FINNATE dal client immediatamente successivo a quello.
Guardando le acquisizioni di pacchetti, tutti i guasti sembrano coincidere con una "Lunghezza Pubkey" di 127 nell'handshake di Exchange Server Key:
D'altraparte,ogninegoziazioneriuscitaconquestoclienthacomportatouna"lunghezza Pubkey" di 128 nell'handshake di Exchange Server Key:
Ognivoltacheilserverinvialaversionea127byte,ilclientrispondeconunFIN/ACKinvecedelloScambiochiaviclient.Laconclusionecuisiamogiuntièchelalunghezzadelpubkeydi127bytenonèaccettabileperilclient.Holetto
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;
Quindi le domande specifiche sono:
-
Qual è l'accordo con la lunghezza di Pubkey nello scambio di chiavi del server DHE_RSA? Nello specifico, 127 vs 128 rappresenta qualcosa come il troncamento a zero per il salvataggio della lunghezza, oppure fornisce veramente una chiave a 127 byte?
-
Più specificamente, 127 è una lunghezza Pubkey valida che il client dovrebbe essere in grado di gestire, oppure potrebbe rappresentare un problema con il server che richiede l'indirizzamento?
Chiarimento:
Il server in questione è un sistema di bilanciamento del carico F5 che esegue un software aggiornato (11.6), quindi non è solo off-the-shelf ma off-a-reason-high-shelf quando si tratta della provenienza TLS. Questo non vuol dire che non può essere il problema, solo per dire che non è come se stessi rotolando il mio server TLS Lua-over-Django-con-terzo-Rails nel back-end:)
Cosa pensa OpenSSL
Ho lasciato uno script usando openssl s_client per colpire il server ogni minuto durante il fine settimana e ho catturato i pacchetti completi, in modo da poter vedere cosa pensa OpenSSL di questa particolare configurazione del server. E in poche parole, con una lunghezza DHE "Pubkey" di 127 byte, OpenSSL considera la "Chiave temporanea del server" 1024-bit.
Ecco lo scambio di chiavi del server come visualizzato in Wireshark:
Edeccol'outputOpenSSLperquellaconnessione:
$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)---$Quindiè1024o1016bit?Lalunghezza'p'indicalaforzadellachiaveinvecedellalunghezzadiPubkey(ssl.handshake.ys_lenperquellicheseguonoinWireshark)?Doveèdefinito"Server Key Exchange" per Diffie-Hellman? Qualcuno ha trovato abbastanza documentazione per scrivere un parser di Wireshark, se potessi dare un'occhiata al documento che hanno usato forse farò meglio a capire le aspettative intorno a questi campi.