[openssl-dev] Could someone verify my efforts of a scan for the DROWN attack?

[Hubert Kario]

On Wednesday 30 March 2016 12:27:47 Brian Reichert wrote:
> I'm applying the advice from this post:
> 
>   https://mta.openssl.org/pipermail/openssl-dev/2016-March/005602.html
> 
> I've successfully downloaded and compiled this test utility.
> 
> I have a number of varying SSL services I'm scanned; some are Java
> apps, and some are linked against OpenSSL.
> 
> According to the above URL:
> 
>   In both cases all the individual tests in the scripts should print
> "OK" status if the specific cipher is not supported and report
> "failed: 0" together with exit status of 0 if you want to automate
> it.
> 
> From this, I infer that 'fail' means an SSL connection could indeed
> be established using that SSL version/cipher combination.  (The code
> uses the 'conversation' term, so I'll use that in this post.)

correct, that's the idea

> Each failed conversation yields a 'TLSIllegalParameterException'
> error; e.g.
> 
>   Connect with SSLv2 EXP-RC4-MD5 ...
>   Error encountered while processing node
> <tlsfuzzer.expect.ExpectServerHello2 object at 0x2b3e590> (child:
> <tlsfuzzer.messages.ClientMasterKeyGenerator object at 0x2b3e710>)
> with last message being: None
>   Error while processing
>   Traceback (most recent call last):
>     File "scripts/test-sslv2-force-export-cipher.py", line 109, in
> main runner.run()
>     File "/root/tlsfuzzer/tlsfuzzer/runner.py", line 129, in run
>       header, parser = self.state.msg_sock.recvMessageBlocking()
>     File "/root/tlsfuzzer/tlslite/messagesocket.py", line 100, in
>   recvMessageBlocking
>       for res in self.recvMessage():
>     File "/root/tlsfuzzer/tlslite/messagesocket.py", line 82, in
> recvMessage for ret in self.recvRecord():
>     File "/root/tlsfuzzer/tlslite/recordlayer.py", line 682, in
> recvRecord for result in self._recordSocket.recv():
>     File "/root/tlsfuzzer/tlslite/recordlayer.py", line 188, in recv
>       for record in self._recvHeader():
>     File "/root/tlsfuzzer/tlslite/recordlayer.py", line 165, in
> _recvHeader "Malformed record layer header")
>   TLSIllegalParameterException: Malformed record layer header

That may indicate that the server does not respond with a SSLv2 message 
to the client's message.

Could you provide a packet dump of the connection?
 
> When I test for each of these SSL version/ciphers individually using
> s_client, they all fail; e.g.:
> 
>   # openssl s_client -connect localhost:10000 -ssl2 \
>   -cipher EXP-RC4-MD5 > /dev/null; echo $?
>   error setting cipher list
>   140548678301512:error:1410D0B9:SSL
> routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1314:
>   1

OpenSSL has a 100% false negative rate for this test.

The openssl client won't force the server to accept a cipher, even if 
forcing would succeed. Tlsfuzzer does force the server to accept a 
cipher and expects the forcing to fail (in that the server closes the 
connection and make further communication impossible). That's why you 
need a custom tool for testing the vulnerability.

> So - are the python-based tests really failing in my case?
> 
> For example, hitting port 80, which isn't SSL-enabled at all, also
> yields the TLSIllegalParameterException error, and a non-zero exit
> status:
> 
>   # PYTHONPATH=. python scripts/test-sslv2-force-export-cipher.py \
>   -h localhost -p 80  | grep TLSIllegalParameterException
>   TLSIllegalParameterException: Malformed record layer header
>   TLSIllegalParameterException: Malformed record layer header
>   TLSIllegalParameterException: Malformed record layer header
>   TLSIllegalParameterException: Malformed record layer header
>   TLSIllegalParameterException: Malformed record layer header
>   TLSIllegalParameterException: Malformed record layer header

There is no sanity check in the test script, so yes, false positives are 
possible.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160401/b974516a/attachment.sig>