Improved STARTTLS Logic

[danhunsaker]

As far as I recall, each of these protocols has a method for checking whether STARTTLS is even available, which should be used prior to attempting it. It would be good to see such checks in place.

Additionally, it should also be possible to autodetect which of these STARTTLS protocols to attempt based on initial messages from the server, which should identify which protocol it expects. This would remove the need to manually identify the protocol on the commandline at all, something the OpenSSL team could also implement, but likely won't. It would simplify security-testing scripts calling this one.

Finally, the STARTTLS switch could likely be removed altogether if a TLS header check was implemented. If we're already in TLS mode, skip STARTTLS and run the test. Otherwise, check for STARTTLS support - if supported, enter TLS mode and continue the test; if not, quit gracefully, informing the user that the target doesn't support TLS.

Just some thoughts.

[danhunsaker]

Looks like I was mistaken about XMPP at least. The others seem to report their protocol in a message sent on connect; XMPP doesn't send anything until the client does, first. I'm confident a detection method exists here, as well, but they certainly made it trickier by not having any sort of header for this.

[decal]

Yeah, according to RFC's it's supposed to be advertised by the protocol as part of a banner/reply/handshake, but not everyone writes to spec. Why base your attempt of the exploit of off that when it could be vulnerable, regardless?

[danhunsaker]

That's fair for the first point. The second and third are still valid, though. Protocol detection would simplify use of the script, and it's easy to tell if we're already in TLS mode and try STARTTLS if not.