Nmap Development mailing list archives
Re: About SSL Support
From: Joao Correa <joao () livewire com br>
Date: Sat, 6 Jun 2009 23:18:53 -0300
Hello Guys, I've included some new functions to enable transparent tcp/ssl connection opening on the comm API. I've also used them on irc-info.nse and http-trace scripts, enabling SSL support on both. The tries the best protocol option first, based #1 on service version, #2 on protocol port and name (if the ports matches a port which is usually used with or without ssl) and, as a last resource, #3 it attempts tcp first, since it is more usual than ssl. I'm sending attached a new version of comm.lua, with the new functions, and also the scripts. I'm not sure if comm is the best API for holding the functions, I've used it since it looked as the best one suited. Since it is a new API, it is not hard to moving it to a different API or even to a new one. Thanks, Joao Correa On Fri, May 29, 2009 at 6:46 PM, David Fifield<david () bamsoftware com> wrote:
On Fri, May 29, 2009 at 03:28:39PM -0300, Joao Correa wrote:I´m working on the SSL support for some scripts, making them work correctly under normal TCP connections or under SSL connections. I´ve been facing situations where using connect with TCP flag to estabilish a connection with a SSL service returns true as status, but the connection itself cannot be handled. In the irc-info script, for example, I had to first try connect with SSL flag, if the server does not support SSL it returns false, and so I try connect again with TCP flag. Doing the other way (TCP first and SSL if false) won´t work, since connect with TCP returns true. I have some ideas, but I´m not pretty sure about what is the cause of this problem. Anyway, since I´ve found a way out I think is isn´t a big problem (trying SSL fisrt, and TCP second works pretty fine for all cases). I´ve been wondering If I should work on a new flag for connect, maybe TRYSSL, to enable trying SSL first, and if not possible, trying TCP automatically. I could also try to work on connect function, to return false if the flag is TCP but the service requires SSL.Another layer of abstraction sounds like a good idea. You could "subclass" the type of object returned by nmap.new_socket. It would default to a plain TCP connect, and essentially just pass on all function calls to the underlying socket object. But if the very first send fails, it would reconnect using SSL and try sending again. If a send fails after that then it will be reported to the caller. You could also give it a hint to start with SSL if you know it from version detection. You could probably implement something like this in pure Lua. Patrick, what do you think of this idea? David Fifield
Attachment:
comm.lua
Description:
Attachment:
http-trace.nse
Description:
Attachment:
irc-info.nse
Description:
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- About SSL Support Joao Correa (May 29)
- Re: About SSL Support Fyodor (May 29)
- Re: About SSL Support David Fifield (May 29)
- Re: About SSL Support Joao Correa (Jun 06)