[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nmap-dev
Subject:    Re: About SSL Support
From:       David Fifield <david () bamsoftware ! com>
Date:       2009-05-29 21:46:12
Message-ID: 20090529214611.GB2874 () gusto
[Download RAW message or body]

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

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

[prev in list] [next in list] [prev in thread] [next in thread]