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

Hubert Kario hkario at redhat.com
Fri Apr 1 17:21:13 UTC 2016


On Friday 01 April 2016 12:35:49 Brian Reichert wrote:
> On Fri, Apr 01, 2016 at 12:19:21PM +0200, Hubert Kario wrote:
> > On Wednesday 30 March 2016 12:27:47 Brian Reichert wrote:
> > > Each failed conversation yields a 'TLSIllegalParameterException'
> > > error; e.g.
> > > 
> > >   Connect with SSLv2 EXP-RC4-MD5 ...
> 
> [snipped]
> 
> > >   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?
> 
> Attached; hopefully it won't get filtered out.

it got through, thanks!

So, the server behaves incorrectly.

On the first SSLv2 Client Hello message it replies with TLSv1.0 fatal 
alert with description of Illegal Parameter. That is OK and valid (and 
expected by the test script). What is not correct is that it does not 
close the connection (violation of RFC 5246 Section 7.2: "Alert messages 
with a level of fatal result in the immediate termination of the 
connection."). After alert message it sends a HTTP/1.0 302 reply.

Side note: it does sent data with no buffering, each line is in a 
separate packet - very bad if it behaves similarly while using TLS as 
that will leak lengths of lines in headers and maybe even content.

On second and third connection it doesn't reply with TLS at all, but 
goes straight to HTTP 302 (this is not handled by tlsfuzzer and will 
cause false positives).

On fourth it fails just like with the first connection.

So, while it doesn't look like it is vulnerable to DROWN, it doesn't 
instill a lot of confidence in me...
-- 
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/bf377faf/attachment.sig>


More information about the openssl-dev mailing list