Re: Ncat SSL regressions

[Daniel Roethlisberger <daniel () roe ch>]

David Fifield <david () bamsoftware com> 2009-06-07:
> On Sun, Jun 07, 2009 at 01:27:55AM +0200, Daniel Roethlisberger wrote:
> > Here's more information on the regressions in the Ncat SSL code:
> >
> > -   openssl s_server works with openssl s_client.
> >
> > -   ncat -l --ssl from the -listen branch works with openssl
> >     s_client
> >
> > -   ncat -l --ssl from /nmap does not work with openssl s_client:
> >
> > -   ncat -l --ssl from either branch does not work with
> >     ncat --ssl:
> >
> > -   ncat -l --broker --ssl from either branch doesn't work with
> >     ncat --ssl:
> >
> > -   ncat -l --broker --ssl from either branch doesn't always work
> >     with openssl s_client, first connection doesn't work, second
> >     connection works:
>
> I can reproduce all these on Mac OS X, except that I could not get -l
> --broker --ssl to work with s_client at all. I tried back to r12700 and
> it still didn't work. Has --ssl ever worked for you on BSD?

Since I've been doing a lot of testing on Linux at around the
time when I was playing with --ssl, I cannot say for sure.
I /thought/ it had worked on BSD at one point, but I could be
mistaken.

> I think I've found the cause of this, see below.
>
> > -   openssl s_server does not work with ncat --ssl from either
> >     branch:
>
> This always works for me.

Not for me.  Using r13611, it does not work, while using r13612,
it now works.  Note that Ncat r13611 at first appears to have
connected fine, but after sending a few bytes, openssl s_server
begins spewing out SSL handshake errors.

> I think the cause of the problem for Ncat in listen mode is that OpenSSL
> is working on a non-blocking socket. In gdb I found that the error was
> happening in the call to SSL_accept. The man page says:
>
>        If the underlying BIO is non-blocking, SSL_accept() will also
>        return when the underlying BIO could not satisfy the needs of
>        SSL_accept() to continue the handshake, indicating the problem by
>        the return value -1. In this case a call to SSL_get_error() with
>        the return value of SSL_accept() will yield SSL_ERROR_WANT_READ
>        or SSL_ERROR_WANT_WRITE.
>
> Where does the non-blocking socket come from? It is inherited through
> accept from the non-blocking listening socket. The Linux man page says:
>
>       On Linux, the new socket returned by accept() does not inherit
>         file status flags such as O_NONBLOCK and O_ASYNC from the
>         listening socket. This behaviour differs from the canonical BSD
>         sockets implementation. Portable programs should not rely on
>         inheritance or non-inheritance of file status flags and always
>         explicitly set all required flags on the socket returned from
>         accept().
>
> In r13612 sockets are made blocking once a connection is made. Would you
> try it out? Also please see if client connections are not working,
> because I don't know why that wouldn't be working.

Your fix in r13612 seems to have fixed both server and client SSL
on FreeBSD 6.4 and 7.2.  Excellent, thanks.

-- 
Daniel Roethlisberger
http://daniel.roe.ch/

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