Re: [NSE] tls-nextprotoneg

[Hani Benhabiles <kroosec () gmail com>]

On 07/08/2012 10:10 PM, Toni Ruottu wrote:
> Not really. However a browser vendor may experiment with new protocols 
> despite other browsers not supporting that protocol. It is also a 
> question of maintainability. Parsing the headers would remove the need 
> to update the script when new protocols are introduced.
>
> On Sunday, 8 July 2012, Hani Benhabiles wrote:
>
>     On 07/08/2012 11:01 AM, Toni Ruottu wrote:
>
>         By reading the script I get that it is currently searching the
>         header
>         for known protocol names. The problem here is that the not so well
>         known extensions are often more likely to have security
>         problems. To
>         report custom protocols the script would need to parse the
>         header for
>         protocol fields rather than search for specific names. This
>         might also
>         make the script faster and more reliable, but I am not
>         familiar with
>         the header format and do not know how much work that would be.
>
>         On Sat, Jul 7, 2012 at 6:13 PM, Toni Ruottu
>         <toni.ruottu () iki fi> wrote:
>
>             One more thing. Would it make sense to also report custom
>             protocols
>             that have not been reported to IANA? Is that possible?
>
>             On Sat, Jul 7, 2012 at 5:42 PM, Hani Benhabiles
>             <kroosec () gmail com> wrote:
>
>                 On 07/07/2012 03:31 PM, Henri Doreau wrote:
>
>                     2012/7/7 Hani Benhabiles <kroosec () gmail com>:
>
>                         Hi Henri,
>
>                         Thanks for all the remarks, I have made the
>                         according changes to the
>                         script.
>                         As for the random string,
>                         stdnse.generate_random_string with the default
>                         charset is good enough.
>
>
>                         Cheers,
>                         Hani.
>
>                         --
>                         Hani Benhabiles
>
>                     Looks good. Go ahead and commit. If anyone has
>                     concerns about having
>                     this script "default", please speak up.
>
>                 Thanks. Committed as r29144.
>
>
>                 Cheers,
>                 Hani.
>
>                 --
>                 Hani Benhabiles
>
>                 Twitter: https://twitter.com/#!/kroosec
>                 <https://twitter.com/#%21/kroosec>
>                 Blog: http://kroosec.blogspot.com
>
>                 _______________________________________________
>                 Sent through the nmap-dev mailing list
>                 http://cgi.insecure.org/mailman/listinfo/nmap-dev
>                 Archived at http://seclists.org/nmap-dev/
>
>     Hi Toni,
>
>     Do you have any examples of unknown protocols or servers that do
>     so ? This wouldn't make much sense given that clients too have
>     static values (from the specification) and wouldn't be able to
>     recognize them (See Chromium as an example [1].)
>
>     [1]
>     
> https://code.google.com/searchframe#OAMlx_jo-ck/src/net/socket/ssl_client_socket.cc&q=kProtoUnknown&exact_package=chromium&l=19
>
>     Cheers,
>     Hani.
>
>     -- 
>     Hani Benhabiles
>
>     Twitter: https://twitter.com/#!/kroosec
>     <https://twitter.com/#%21/kroosec>
>     Blog: http://kroosec.blogspot.com
Although Google is pushing NPN specifically for Spdy, maintanibility for 
future protocols is a good argument. Here is an updated version of the 
script.

Cheers,
Hani.

--
Hani Benhabiles

Twitter: https://twitter.com/#!/kroosec
Blog: http://kroosec.blogspot.com

Attachment: tls-nextprotoneg.nse
Description:

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