Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Ncat SSL regressions
From: Daniel Roethlisberger <daniel () roe ch>
Date: Mon, 8 Jun 2009 09:37:42 +0200

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]