Re: ssl-enum-ciphers support for TLS extensions

[Daniel Miller <bonsaiviking () gmail com>]

David,

This is really cool! I had forgotten about your previous message,
though I'm sure it was subconsciously influencing me as I split out
the tls.lua library. I'm pretty busy at the moment, but I'll give a
shot to merging the two concepts. Hopefully I can have it done within
a week or so.

Dan

On Mon, Jan 27, 2014 at 8:35 PM, David Fifield <david () bamsoftware com> wrote:
> On Sat, Dec 28, 2013 at 02:03:05PM -0800, David Fifield wrote:
> > Here are some patches that add support for some TLS extensions in
> > ssl-enum-ciphers.nse.
> >
> > The server_name extension (RFC 6066), also known as Server Name
> > Indication or SNI, indicates the name of the virtual host you are trying
> > to contact. The value is taken from the host.targetname field and is
> > omitted if you are scanning an IP address. It may be that servers change
> > their offered ciphersuites depending on the virtual host you are trying
> > to contact; for example https://wiki.apache.org/httpd/NameBasedSSLVHosts
> > has an SSLCipherSuite specification inside a VirtualHost.
> >
> > The elliptic_curves and ec_point_formats extensions (RFC 4492) describe
> > elliptic curve crypto parameters supported by the client. It may be that
> > servers may change the ciphersuites offered to the client based on the
> > curves and point formats the client claims to support. I made the script
> > claim to support every curve and point format mentioned in RFC 4492.
>
> In running some big scans using these extensions, we found that many
> servers issue a warning alert when they get an SNI they don't expect.
> This happens often when scanning a www target versus a non-www target or
> vice versa. The script treats all alerts as a fatal error, so there
> would be no output shown for these hosts, even though they were fine
> other than the alert.
>
> Here are some new patches to make ssl-enum-ciphers ignore warning
> alerts.
>
> The new tls.lua library also implements extensions, in a way
> incompatible with these patches. I'm not sure what to do about that.
> I've only rebased these patches up to r32649, before tls.lua was split
> out and modified.
>
> David Fifield
>
> _______________________________________________
> Sent through the dev mailing list
> http://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/