1

I added a virtual domain to our mail server today then did a check of the Dovecot TLS connection security. The test was done from a remote host using Thunderbird. I captured the connection with tcpdump and then passed that to ssldump. I also used nmap to verify the allowed ciphers. That all can be found in a pastebin here.

I do not understand the server->client ChangeCipherSpec (where it says using TLS_RSA_WITH_RC4_128_MD51 10 0.5695) I may just be confused about how the TLS connection is setup but I have no RC4 type ciphers enabled so how (or why) is this happening?

1
  • I think there is a line break missing between TLS_RSA_WITH_RC4_128_MD5 and 1 10 0.5695 there. Nov 23, 2015 at 14:42

2 Answers 2

2

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.

7
  • @pit79 I was about to ask you if you filed a bug report. Then I noticed that ssldump hasn't been updated since September of 2002. Jan 13, 2016 at 18:21
  • I think this bug report from 2015-07-24 might have the fix: SSLDump-Bug-Report#68. But the SSLDump project looks rather abandoned, so I don't know if anyone will implement the fix. Jan 14, 2016 at 5:53
  • @SteveSether I briefly looked at the ways of submitting a bug report but haven't yet. You're quite right that SSLDump hasn't been updated in a long time - but then again, it's sort of "complete" :) I'll try to file the bug anyway and contact somebody responsible. If I can't get the fix upstream I might try contacting the Debian maintainer at least.
    – piit79
    Jan 14, 2016 at 9:03
  • @StackzOfZtuff Looking at the patch in the bug report I don't think it fixes this issue. It adds/updates ciphers in the cipher_suite_decoder array but doesn't fix the termination of the HandshakeType_decoder array.
    – piit79
    Jan 14, 2016 at 9:06
  • @piit79 Software is more like a living thing than it is a cake or a roast. It's never really done, and always need to be maintained as the world around it changes. If it's neglected, it dies, though sometimes slowly. Anything that hasn't been updated in 13+ years is very suspect in my mind. Jan 14, 2016 at 15:09
0

I have no idea what SSLDump is doing there.

But the client only signals support for two cipher suites and then the server picks the one labeled

cipherSuite         Unknown value 0xc014

And this hex value decodes to:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

So there is no RC4 there.

5
  • I tend to think you are right but its still a little bit disconcerting. I guess its some kind of bug in SSLDump?
    – TrustNoOne
    Oct 24, 2015 at 4:35
  • Just a bit more follow up.... you can see whats going on by running ssldump at the same time as openssl s_client -connect hostname:955 Interesting that quite a few servers print the rc4 message. It seems to do with the original cipher chosen - but it is interesting to compare say pop.gmx.net to pop.mail.yahoo.com gmx does not get the rc4 message, yahoo does
    – TrustNoOne
    Oct 24, 2015 at 4:59
  • @TrustNoOne: how does WireShark parse that dump? Oct 24, 2015 at 6:05
  • Wire shark does not make a similar pronouncement in that handshake data but I'm not sure absence in Wireshark confirms that SSLDump has a bug (but certainly seems to point that way)
    – TrustNoOne
    Oct 24, 2015 at 14:53
  • Can you add a WireShark screenshot? And/or upload the raw binary dump somewhere? Oct 24, 2015 at 18:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .