Re: [NSE] Incorrect SNI construct in tls.lua

[Daniel Miller <bonsaiviking () gmail com>]

Thanks so much for this! I had lost one layer of length-prefixing. TLS
extensions are confusing because you need the length of the extensions
section, then the length of each extension, then often the length of the
extension body, plus the data, which may be a length-prefixed string. Yikes!

Fixed in r32793

Dan


On Mon, Apr 7, 2014 at 7:42 PM, <nnposter () users sourceforge net> wrote:

> The current version of tls.lua implements the data structure of the
> SNI extension as a single name entry. The correct implementation, as
> specified in RFC 6066, is to treat it as a list (which typically
> consists of a single name entry).
>
> The effect of the bug is that the malformed extension is corrupting
> the tail of Client Hello, which in turn is causing some TLS server
> implementations reject the handshake. As an example, Windows Schannel
> is fine but IBM JSSE2 will abort.
>
>
> Cheers,
> nnposter
>
>
>
> Patch against revision 32792 follows:
>
> --- nselib/tls.lua.orig 2014-04-07 17:24:44.777719900 -0600
> +++ nselib/tls.lua      2014-04-07 18:19:02.820709700 -0600
> @@ -189,7 +189,7 @@
>    ["server_name"] = function (server_name)
>      -- Only supports host_name type (0), as per RFC
>      -- Support for other types could be added later
> -    return bin.pack(">CSA", 0, #server_name, server_name)
> +    return bin.pack(">P", bin.pack(">CP", 0, server_name))
>    end,
>    ["max_fragment_length"] = tostring,
>    ["client_certificate_url"] = tostring,
> _______________________________________________
> 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/