Re: [NSE] ssl-enum-ciphers hosed?

[Mak Kolybabi <mak () kolybabi com>]

David Fifield wrote:
> I'm getting different results than before against Ncat, though: [snip] Before,
> it was giving me results from TLSv1.1 and TLSv1.2 also. Do you have an idea
> what might have caused the change, and which results are correct?

During the initial connection request (ClientHello), the client will state the
highest version of TLS it can handle. The server then responds with the highest
(or just preferred) version it can support, and the version that will apply to
the remainder of the connection. My initial version didn't check that the
version sent and the version received matched. It does now. The new results are
correct.

Dario Ciccarone wrote:
> In all cases, a tcpdump DID show traffic coming & going - wireshark tagged all
> SSL ClientHello as "malformed"

This was caused by a small bug in the placement of the protocol version field of
the ClientHello record. I had considered it part of the header, instead of the
body, and so the size of the record was incorrect.

> Well, don't know if this is a democracy or what, but yeah - my vote would also
> go to "old, but working" over "shiny new, but failing" :)

The problem with the thorough method is that it's so slow as to be impractical
except for a couple of hosts. I'm writing a patch that will have the fast
default, but can be set using script-args to do the slow-and-thorough method.

> While fixing the script - can the (old, deprecated) FIPS ciphersuites be
> added? The ones listed at
> http://www.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html?

Sure, I'll look into them.

Rob Nicholls wrote:
> I emailed Mak 2-3 weeks ago to let him know that I was having similar issues
> with the faster version of the script (I could see my certificate being
> returned in Nmap's packet trace, but the script wasn't reporting anything)
> against my own web server; the original version worked fine, albeit quite
> slowly. He said he'd fixed it to return some ciphers (possibly the SVN version
> you tried?), but "it still can't return all seven that ssllabs.com and the old
> version of my script report".

Sorry for taking so long to get back to you on this, but I've not forgotten.
I've simply not had a fully-working computer for three weeks.

Your server (IIS 7.0) has some behaviours that I had not seen elsewhere. First,
instead of failing a connection attempt with the Alert/Handshake Failed message,
it RSTs the connection. I had been treating such failures as fatal, which
resulting in no ciphers being found.

Secondly, sometimes the server won't even let me send data to it. It just RSTs
the connection partway through the TCP handshake. If you have an Intrusion
Prevention System in front of your web server, that might be the cause.

Another problem was that OpenSSL and IIS return the ServerHello messages
differently. OpenSSL separates them into separate records, while IIS
concatenates them into one. I've corrected the script to be able to read both
styles of responses.

I'm currently working on cleaning up the code to support the two modes (thorough
and fast) cleanly. I'll post it sometime this week, after I've tested it more,
which it seems it could use. :-)

--
Matthew Anthony Kolybabi (Mak)
<mak () kolybabi com>

() ASCII Ribbon Campaign | Against HTML e-mail
/\  www.asciiribbon.org  | Against proprietary extensions

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/