mailing list archives
Re: [Ncat] hang on ongoing ssl negotation in brokering mode
From: Shinnok <admin () shinnok com>
Date: Mon, 13 Jun 2011 18:56:55 +0300
On 06/11/2011 09:33 PM, David Fifield wrote:
This patch looks very nice, Shinnok. Please change the name "ssldone" to
something more descriptive; it doesn't mean "SSL done," it means "SSL
Renamed to ssl_accept_done. Commited.
I don't think the patch works when the server runs --sh-exec. For
ncat --ssl --sh-exec "date" -lk
Connecting with a non-SSL client prevents SSL clients from receiving any
data. I added a new test for this case. Would you look into it?
Indeed it doesn't work with --exec modes, since they take a different
path in code. Fixed for that path too in r23946.
As for the test case, both ssl blocking tests are wrong because they
don't specify neither brokering nor -k in order for the second connect
to be accepted. Revision r23947 fixes your test case and the previous
one by adding -k(--keep-open), as well as making your test case more
in-depth like the other exec tests.
./ncat-test.pl issues no additional fails from svn current besides the
UNEXPECTED PASS SSL server doesn't block during handshake
Great, it's nice when a test works. Remove the xfail whenever you make a
known-bad test start passing.
Removed the xfail attribute for the afferent tests. They are now
Off-topic question: In the context of ncat issues without --keep-open,
the server doesn't really block new incoming connections, instead it
accepts them and quits as soon as one of the connections is closed. Is
this the desired/planned behavior? Wouldn't it be more *correct* if we
refuse any further connections just like nc(netcat) does, when not in
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/