I came across this issue myself recently. We would run ssldump
and openssl s_client
at the same time - openssl
would show that the active cipher is AES256-SHA
yet ssldump
would still print TLS_RSA_WITH_RC4_128_MD5
in its output.
I believe I found a bug in ssldump
. Looking through the source code I found the following:
- The SSL handshake packets are decoded in the function
decode_ContentType_handshake()
in ssl/ssl_enum.c:20
- This function then calls
ssl_decode_switch(ssl,HandshakeType_decoder,t,dir,seg,data)
, where HandshakeType_decoder
is an array of decoder
structs\
ssl_decode_switch(ssl,dtable,value,dir,seg,data)
(ssl/ssl_print.c:204
) iterates through the dtable
array until it finds the decoder
entry with type == value
or type == -1
("not found")
- However, looking at the definition of
HandshakeType_decoder
in ssl/ssl_enum.c:212
the array is not terminated with a decoder
struct with type == -1
- there's a 0
at the end
- Also, immediately following the
HandshakeType_decoder
definition is the definition of cipher_suite_decoder
(ssl/ssl_enum.c:266
) which is an array of the same struct decoder
. This array contains a list of ciphers.
- This means that if the SSL handshake type is not found in
HandshakeType_decoder
, ssl_decode_switch()
will continue searching in cipher_suite_decoder
as it will (most probably) be in memory directly following the HandshakeType_decoder
data
- And this turns out to be happening in my case. For some reason
decode_ContentType_handshake()
decoded the handshake packet to be of type 4
which ssl_decode_switch()
couldn't find in the HandshakeType_decoder
. However, by coincidence 4
is the type
value of the cipher_suite_decoder
entry with name == TLS_RSA_WITH_RC4_128_MD5
I run out of time to investigate this issue so I don't know why ssldump
is trying to decode a handshake packet with invalid type. I'm however convinced that the HandshakeType_decoder
array should be terminated with a -1
to prevent the overrun.