Re: [PATCH] Extended SSL support in Nmap, review

[David Fifield <david () bamsoftware com>]

On Tue, Mar 03, 2009 at 08:10:16PM +0100, Kristof Boeynaems wrote:
> > I don't think implementing this solution will be easy. I briefly looked
> > into doing it myself but gave up when it wasn't as simple as I
> > anticipated. A sensible default would be to try all three methods on
> > every SSL connection. There could be a way to control which method is
> > tried first, or to disable the fallbacks, but it would have to be done
> > in a nice way. I don't think either of those features is worth adding an
> > extra parameter to nsock_connect_ssl, unless it's a structure that can
> > express a lot of options at once.
>
> It sounds indeed rather straightforward. In fact, you made a short
> test program doing something like that earlier, see
> http://seclists.org/nmap-dev/2009/q1/0430.html.
> What difficulties did you encounter this time?

I just had trouble making it work in the Nsock model. When you request
an SSL connection in Nsock, first it schedules a TCP connection, then
when that connects, it starts an SSL connection. For various reasons the
connection usually can't be made right away so the callback has to be
re-entered later. It uses one of the SSL variables as state to indicate
whether the connection is just started or continuing. It just needs some
more state, to control which SSL connection method is being used and
which one is next.

I think the right design is to have the SSL connection try all the
methods internally, without reporting an error until all three methods
fail (or the TCP connection fails). After all, nsock_connect_ssl is
already hiding the detail that it has to make a TCP connection first. If
that turns out to be too inflexible, then we can add a way to control
whether to fall back to other methods.

David Fifield

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