Re: SSL support in Ncat - confusing server parameters and client version issue

[Kristof Boeynaems <kristof.boeynaems () gmail com>]

David Fifield wrote:
> On Sun, Feb 08, 2009 at 02:38:18PM +0100, Kristof Boeynaems wrote:
>   
> > Based on some testing, this type of problem does not seem to return a
> > very specific error. In these cases, the SSL_connect() call in
> > nsock_core.c seems to fail with sslerr == SSL_ERROR_SYSCALL and rc ==
> > 0. We might try to act on that.
> >     
>
> In my testing I did see SSL_ERROR_SYSCALL but also other values. See
> below.
>
>   

Yes, you are right. The SSLv23_client_method always fails with rc==0 and 
ssl_err==5 (==SSL_ERROR_SYSCALL).  But in order to differentiate between 
TLSv1-only and SSLv3-only, you have to do one more guess 
(SSLv3_client_method or TLSv1_client_method), and a wrong guess in this 
stage will give you a different error. I forgot about that in my initial 
post.

> > Additionally, we might use the SSL_set_ssl_method() method
> > (http://www.openssl.org/docs/ssl/SSL_CTX_set_ssl_version.html) to
> > change the connection method of the current SSL object (and thus
> > reusing the object). This seems to be the best idea.
> > Alternatively, we might use the SSL_CTX_set_ssl_version() method (also
> > listed on that page) to change the sslnfo->ctx and then create a new
> > SSL object from this new context. This will affect all new SSL objects
> > created based on this context though, which is more likely to have
> > repercussions on other functionality.
> >     
>
> I made a small test program to test out this strategy. Compile it with
>
>         cc -g  ssl_method.c -lssl -o ssl_method
>
> Here's a sample of its output against different server versions.
>
> $ openssl s_server -key test-key.pem -cert test-cert.pem
> $ ./ssl_method localhost 4433
> Attempting connection with method SSLv23_client_method.
> Connected to 127.0.0.1:4433.
> SSL handshake completed.
>
> $ openssl s_server -key test-key.pem -cert test-cert.pem -tls1
> $ ./ssl_method localhost 4433
> Attempting connection with method SSLv23_client_method.
> Connected to 127.0.0.1:4433.
> Error in SSL_connect (rc 0, err 0, ssl_err 5, errno 0).
> error:00000005:lib(0):func(0):DH lib
> Attempting connection with method TLSv1_client_method.
> Connected to 127.0.0.1:4433.
> SSL handshake completed.
>
> $ openssl s_server -key test-key.pem -cert test-cert.pem -ssl3
> $ ./ssl_method localhost 4433
> Attempting connection with method SSLv23_client_method.
> Connected to 127.0.0.1:4433.
> Error in SSL_connect (rc 0, err 0, ssl_err 5, errno 0).
> error:00000005:lib(0):func(0):DH lib
> Attempting connection with method TLSv1_client_method.
> Connected to 127.0.0.1:4433.
> Error in SSL_connect (rc -1, err 336130315, ssl_err 1, errno 0).
> error:00000005:lib(0):func(0):DH lib
> Attempting connection with method SSLv3_client_method.
> Connected to 127.0.0.1:4433.
> SSL handshake completed.
>
> The technique of calling SSL_set_ssl_method with each different client
> method does work. It is fairly awkward as you have to bring up a new
> socket every time. For that reason it would not be easy to build into
> Nsock, but the idea is still sound.
>
>   

Thanks for trying this out!
This cycling implementation might be a good idea for Ncat. For Nmap it 
is probably not performant enough.

For Nmap, the implementation that I am currently thinking of would 
actually not cycle through all possibilities, but extract the SSL 
version from the version probing phase (see other posts on this 
subject), and directly connect using a supported method. Not sure 
whether in these circumstances this kind of "reuse" still makes sense; 
it might be better to simply create a separate SSL object.

Cheers,

Kristof


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