[Feature request] Add "hybrid starttls" mode for starttls protocols not handled by openssl

[klaus-vb]

Please check this repo whether this is a known feature request

Done, nothing remotely similar found.

Describe your feature request (if it's a technical feature)

It's quite straightforward to add a new protocol to the "non-native" code path. However, there are a few places where the native openssl starttls protocol handling is used unconditionally, in determine_optimal_proto(), run_fs() and ciphers_by_strength().

But it's annoying redundant effort to extend openssl's starttls support in the context of testssl.sh. Additionally one needs to ship such extended binaries to the users.

This issue popped up when I've looked into ciphersuite scanning for the RDP protocol. Something which turned out to be quite little effort to add in testssl.sh except for some errors from the code paths which insist using openssl.

Describe the solution you'd like

The fundamental idea is using the same approach (socat + openssl s_client with unix domain socket) as used in a single place already, run_starttls_injection(). There fd_socket is used to handle the dialog, and after that socat hooks things up to openssl s_client without using starttls). Perfectly modular code: starttls dialog using sockets, and openssl is used purely for "vanilla SSL/TLS".

What worries me somewhat is that the change is implicitly replicated to at least 3 places, because I can't see a straightforward solution which can wrap such openssl usage variants in vastly differing use cases.

I'm happy to discuss alternatives and once the direction is clear it should be possible to provide a patch to start towards integration.

Which version are you referring to
3.3dev

[drwetter]

Thanks @klaus-vb .

To get started: I don't know much about RDP. It sounds to me though that run_starttls_injection() may have a little overlap but not much.

Maybe a good start is, based on some code fragments within run_starttls_injection(), to start with a PoC. That can be completely separate function (i.e. outside of testssl.sh) or just additional code within testssl.sh. Then we could figure out what the common code is and look whether we rather want to have a separate function.

[drwetter]

One amendment: If you feel run_starttls_injection() is similar, copy the function first and make it work. Then we look for common code.

[klaus-vb]

OK, will see when I have a sufficient PoC of the suggested "hybrid starttls" mode of operation. I'll keep it minimal (not adding the RDP bits which I have floating around locally).

About RDP: the protocol in general is both old and highly complex (as one would expect when Microsoft uses it). It predates the invention of SSL/TLS and therefore needs a bit of negotiation to make it use SSL/TLS. It is a binary protocol, which means that there isn't a literal "starttls" command like in many others. The negotiation needed by testssl.sh is fortunately rather simple and works by sending a 19 byte request (has 3 protocols layered on top of each other...). There's a 19 byte response which indicates if the server will do SSL/TLS hello next (or not).

[drwetter]

ok. If it's only the 19 bytes, you could open a socket, send them over and use sockets for the rest. But the rest then needs to be SSL/TLS when you want to use, what is already there. That's a bit like starttls_postgres_dialog() or starttls_ldap_dialog()

PS: can you recommend a readme for the protocol?

[klaus-vb]

Not really aware of a good summary, but Microsoft's spec is OK if one knows what to look for. For the negotiation request it's https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/902b090b-9cb3-4efc-92bf-ee13373371e3 (and the previous sections, reminding of the other protocol layers) and for the response it's https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/b2975bdc-6d56-49ee-9c57-f2ff3a0b6817

Getting the dialog implemented was a matter of copy/pasting from various similar enough protocols and an hour or 2 debugging what the RDP servers accept in reality to make the scan reasonably reliable.

This gets the bulk of testtls.sh working nicely, except the real topic of this issue: getting the connection check and other places to work, which currently use "openssl s_client ... -starttls rdp" which simply fails. The failed connection check is especially annoying, as it gets one into a path which requires user input, which won't work in the overall solution I'm aiming at which has some additional scripting around testssl.sh which can't handle such input.