Identifying cipher mode in TLS

Question

I'm trying to check my private server for TLS poodle attack. In Microsoft's article it says:

"TLS 1.0, TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected"

How can I identify the cipher mode which is used by TLS?

Answer 1

How can I identify the cipher mode which is used by TLS?

There are many ways to enumerate your cipher suites and protocols enabled on your sever. Here are solutions that are assessment or script based that have little overhead and are light on the technical requirements.

If it is externally available:

Try out SSL Labs' test here: https://www.ssllabs.com/ssltest/. They have all your needs for cipher suites, as well as guidance for any issues they may find in your configuration beyond just CBC findings.

If it is not available externally:

https://github.com/nabla-c0d3/sslyze provides a good command line script to enumerate, but does not provide guidance.

https://github.com/drwetter/testssl.sh is bash based, and does provide guidance similar to SSL Labs but on command line.

Answer 2

For checking your cipher suites offline, please see @lancnorden's answer!

For testing POODLE vulnerabilities in particular, keep reading:

The article in the OP from Microsoft are reading appears incorrect or old; Poodle can attack TLS 1.0 and 1.1 also.

You can follow some of the steps in the Exploresecurity manual cheatsheet to look for POODLE.

For the easy SSLv3 POODLE case, just don't enable SSLv3 at all.

openssl s_client -ssl3 -connect host:port

Secure result

It doesn't connect!

If you've disabled TLSv1.0 and TLSv1.1, and only allow TLSv1.2, use the openssl command above, with -tls1 and -tls1_1 flags instead of -ssl3 (and -tls1_2, which should connect).

If you have enabled one or both of TLSv1.0 and/or TLSv1.1, the much more difficult TLS 1.0 and 1.1 POODLE tests are listed in A separate posting on ExploreSecurity.com, though it appears that the SSLLabs.com test is better.

Changes to tlslite

It seemed a bit crazy to fork the original project as my changes were tiny. I also thought that working through the changes here may be helpful to anyone else who wants to do the same sort of thing.

So to begin with I needed to signal to tlslite that I wanted to send TLS messages with invalid padding. You get things going with tlslite through the TLSConnection class so I changed how that was instantiated. TLSConnection inherits from TLSRecordLayer, which is where the padding code lives, so that needed changing too. Within the “tlslite” folder I made the following changes (obviously line numbers will be version dependent so I’ve added the original code too; my version was 0.4.8):

tlsconnection.py Line 52 was: def init(self, sock): Now: def init(self, sock, check_poodle_tls=False):

now i can signal whether or not I want to perform the test

if you already have tlslite, you can change it safely because check_poodle_tls defaults to False so it’s backward-compatible with any existing code that makes use of tlslite

Line 61 was: TLSRecordLayer.init(self, sock) Now: TLSRecordLayer.init(self, sock, check_poodle_tls)

I need to pass that signal on to the parent

tlsrecordlayer.py Line 102 was: def init(self, sock): Now: def init(self, sock, check_poodle_tls):

After line 103 self.sock = sock added new line: self.check_poodle_tls = check_poodle_tls

After line 600 paddingBytes = bytearray([paddingLength] * (paddingLength+1)) added new lines: if self.check_poodle_tls == True: paddingBytes = bytearray(x ^ 42 for x in paddingBytes[0:-1]) paddingBytes.append(paddingLength)

change all but the last of the padding bytes to be invalid (just XOR with 42, the answer to everything)

make the last byte of padding valid = the number of padding bytes

And that’s it! Remember, as it’s Python, that tabs are important and the new code needs to be properly aligned.