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?

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
TrustNoOne
  • 261
  • 1
  • 8

2 Answers2

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.

piit79
  • 121
  • 5
  • @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. – Steve Sether Jan 13 '16 at 18:21
  • I think this bug report from 2015-07-24 might have the fix: [SSLDump-Bug-Report#68](http://sourceforge.net/p/ssldump/bugs/68/). But the SSLDump project looks rather abandoned, so I don't know if anyone will implement the fix. – StackzOfZtuff Jan 14 '16 at 05: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 '16 at 09: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 '16 at 09: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. – Steve Sether Jan 14 '16 at 15:09
  • @SteveSether Sure, I agree. What I meant by "complete" was that dreaded state when the software has all the features the authors needed and now nobody else cares enough to continue the development :) – piit79 Feb 25 '16 at 18:09
  • @piit79 Sure. There's kind of two sets of software people in the world. Innovators and Maintainers. Sometimes people will take on both roles, but a lot of the time the initial innovator hands the software off to a maintainer. It seems like that hasn't happened with ssldump. – Steve Sether Feb 25 '16 at 18:20
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.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • 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 '15 at 04: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 '15 at 04:59
  • @TrustNoOne: how does WireShark parse that dump? – StackzOfZtuff Oct 24 '15 at 06: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 '15 at 14:53
  • Can you add a WireShark screenshot? And/or upload the raw binary dump somewhere? – StackzOfZtuff Oct 24 '15 at 18:35