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?

  • 3
    If it's on a public IP address, you can scan it with SSL Labs
    – gowenfawr
    Feb 1, 2016 at 12:39
  • @gowenfawr You should write that as an answer, I would +1 it
    – Purefan
    Feb 1, 2016 at 13:05
  • @Purefan, I chose not to because it doesn't answer the question ("How do I identify the cipher mode?") but I put it as a comment because it might help the poor guy out in the short term :)
    – gowenfawr
    Feb 1, 2016 at 14:13
  • @gowenfawr It actually does show the ciphers :P
    – Purefan
    Feb 1, 2016 at 14:30
  • That MS(?) statement is technically correct but misleading. In SSL3 the only suites that are not CBC and not already broken use RC4-128 -- which is not vulnerable to POODLE but is so weak against other attacks nearly everyone forbids it. Thus in practice the only fix for POODLE is to disable SSL3. For TLS1.0 and 1.1, RC4-128 is unacceptable but CBC is fixed and is mostly acceptable; Paterson's "lucky 13" is still a minor issue. Only in TLS1.2+ are better modes available: often AES-GCM, sometimes AES-CCM and ChaCha20-Poly1305. Feb 4, 2016 at 13:54

2 Answers 2


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.

  • This answer should also include use of the OpenSSL s_client tool. A good write up feistyduck.com/library/openssl-cookbook/online/…
    – jas-
    Feb 2, 2016 at 2:27
  • @jas- I think your suggestion warrants its own answer. Mine relies heavier on automation and scripting, yours is at a lower level but less requirements overhead.
    – user84662
    Feb 2, 2016 at 15:56

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.

You must log in to answer this question.

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