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
- ncat -l --ssl from /nmap does not work with openssl s_client:
- ncat -l --ssl from either branch does not work with
- ncat -l --broker --ssl from either branch doesn't work with
- ncat -l --broker --ssl from either branch doesn't always work
with openssl s_client, first connection doesn't work, second
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
I think I've found the cause of this, see below.
- openssl s_server does not work with ncat --ssl from either
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
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
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.
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org