Re: [PATCH] Always list SSL in case any SSL connection succeeded

[David Fifield <david () bamsoftware com>]

On Sun, Feb 22, 2009 at 12:04:53AM +0100, Kristof Boeynaems wrote:
> A quick patch for the 'bug' described in  
> http://seclists.org/nmap-dev/2009/q1/0484.html.
>
> "There is still a 'bug', where all detected SSL information will be
> thrown away in case the SSL server does not respond at all, beyond the
> SSL handshake. However, because the SSL connections succeeded, Nmap
> should list these situations as 'ssl/unknown'.
>
> This bug can very easily be reproduced by setting up your own OpenSSL  
> server as follows:
>       openssl s_server -cert 
> /usr/share/doc/libssl-dev/demos/sign/cert.pem -key 
> /usr/share/doc/libssl-dev/demos/sign/key.pem
>
> This OpenSSL server will listen at 4433 by default, and will not return  
> anything beyond an SSL connection."

Thanks for finding the bug and for the patch. I can reproduce the
problem following your instructions. Scanning the s_server gives

PORT     STATE SERVICE  REASON  VERSION
4433/tcp open  unknown? syn-ack

with no indication that SSL was detected.

I think the bug could be fixed in a better way, though. The code already
passes (*svc)->tunnel in the case of no match, so the fact that SSL was
detected is already recorded. I think you should rather patch
getNmapServiceName in output.cc. That's the function that builds up a
name from the service info.

One more thing: In the test you described, the output should be
"ssl/unknown?", not "ssl/unknown". Leaving off the question mark makes
it look as if the port was positively identified. It's confusing in this
case because the port is named "unknown", but that name comes from the
nmap-services file. If you repeat the s_server experiment with port 80
you'll see what I mean. The output should be "ssl/http?", not "ssl/http"
or "http?".

So can you see if modifying getNmapServiceName will fix the bug?

David Fifield

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