Comments on: Testing for POODLE_TLS Manually

By: Jerome

Jerome — Tue, 17 Oct 2017 10:54:02 +0000

Hi – as the output says “no definitive result” and this is covered by both the message and the last line of this article…”one of the reasons for this is that the server does not support any of the small number of cipher suites offered by tlslite“. In other words the tlslite library only supports a handful of simple cipher suites and if the server you’re testing doesn’t support any of them, the connection fails. You can check this by comparing the cipher suites offered in the Client Hello issued by the tool with those known to be supported by the server.

By: jhone

jhone — Tue, 17 Oct 2017 07:23:05 +0000

i have made the require changes but this was showing the error i have posted

By: jhone

jhone — Tue, 17 Oct 2017 07:21:59 +0000

Attempting a normal TLS connection
- this failed with the error
Attempting a POODLE-style TLS connection
- this failed with the same error
Check the hostname, or this could be because the server does not support any of the cipher suites we have to offer
Sorry, no definitive result

By: Jerome

Jerome — Wed, 13 Jan 2016 09:47:48 +0000

Hi
You do get the theory right: the problem is that, while the TLS standard resolves the problem that plagued SSLv3, if the same code is re-used in the TLS implementation then the bug remains. In this case, whether or not TLS_FALLBACK_SCSV is supported is irrelevant as the attacker doesn’t have to knock the connection down to SSLv3.
My motivation for the post was just to figure out how to do a test – but it’s only one test, there may be other and/or better ways of doing it (and the library I’m using is much more restricted in terms of ciphers it knows about). Ivan from SSL Labs states that his check will “negotiate a connection with the server, but using broken CBC padding. If the handshake succeeds, the server is considered vulnerable. We also submit a HTTP request and expect a response. So it should be pretty accurate”. My script doesn’t make a HTTP request but it does attempt to send a message with corrupted padding. On buggy implementations, perhaps the result depends on the TLS version or cipher suite that’s negotiated even if in theory it shouldn’t make a difference. Overall I would favour SSL Lab’s result, it should be more thorough, but you could always post a question on the community forum about this specific example – Ivan is usually very responsive. Do let me know if you decide to put a question up.
Jerome

By: Hubert

Hubert — Fri, 08 Jan 2016 06:28:44 +0000

I tested both IPs with test_poodle_tls.py and the result is “The host does NOT appear to be vulnerable to POODLE_TLS” for both.
Qualys marks one as vulnerable and one not.
The one that is marked vulnerable supports TLS_FALLBACK_SCSV:
openssl s_client -connect 184.106.184.118:443 -fallback_scsv -no_tls1_2

If I get the theory right, TLS implementations that re-use the SSLv3 code for the padding bytes check can be vulnerable to poodle even on a TLS connection.

The question is: Does test_poodle_tls.py work and only trigger when a TLS-implementation is using the SSLv3 padding bytes check and does Qualys not check for the actual vulnerability but just for the possibility of downgrade attacks (which make the connection cryptographically less strong but don’t enable an attack by themselves).

It would be nice to have a test server somewhere which exposes this poodle-tls issue (all servers I tested – the ones that Qualys complains about too – have been tested as not vulnerable by test_poodle_tls.py)

~Hubert

By: Jerome

Jerome — Tue, 05 Jan 2016 13:05:13 +0000

Hi Ben
You’re testing two different IPs there – you tested http://www.finalsite.com which is 23.202.173.5, whereas judging by the URL SSL Labs was testing finalsite.com which is at 184.106.184.118.
Jerome

By: Ben

Ben — Sun, 03 Jan 2016 19:57:07 +0000

Hi Jerome, I do not know if you can see this, but this is something I’d still like to ask.

After running a test on http://www.finalsite.com , your script told me that it is not vulnerable. However, after executing the Qualys SSL Test: https://www.ssllabs.com/ssltest/analyze.html?d=finalsite.com&s=184.106.184.118 one of the IPs for this site resulted to be shown as “vulnerable to TLS POODLE attack”. I do not know whether it is a misdetection on the Qualys test or your script. Any insights?

Thanks,
Ben.

By: Jerome

Jerome — Thu, 13 Aug 2015 08:54:47 +0000

I’d be interested to hear of any examples you can share that you believe are false positives or negatives.

By: How to test POODLE over TLS? - BlogoSfera

How to test POODLE over TLS? - BlogoSfera — Mon, 03 Aug 2015 08:59:34 +0000

[…] There are already several ways to do this like Qualys SSLLabs for instance, but it is too restrictive (only TCP port 443 of servers available on the Internet). There is also this link, but I got a lot false positives/negatives when tested: http://www.exploresecurity.com/testing-for-poodle_tls-manually/ […]