Adding an option to specify custom explicit TLS kickstart bytes

[maaaaz]

Hello @rbsec,

Well first, let me thank you for bringing back the good old sslscan tool.

Then, I'm suggesting a new option which could allow the user to specify a custom trail of bytes to kickstart an explicit TLS connection: I'm facing more and more that situation, mostly for proprietary protocols which are not based on starttls or equivalent.

The idea is to be able to assess the security of ciphersuites for such TLS implementations, by replaying the observed (through wireshark/tcpdump) sequence of bytes needed to kickstart the further TLS session. From my experience, this sequence of custom is often invariable, and basically plays the role of a dumb starttls command.

To be clear, I'm thinking about an option that could look like that: --kickstart \x00\x11\x22\x33... (or whatever else format to specify bytes)

Do you find that useful ? Do you think you could implement it ?

Cheers !

[rbsec]

This is certainly an intersting idea for a feature - it's not really one that I've personally had a need for, but there have been a couple of PRs made in the past to add support for additional protocols (such as RDP or PostgreSQL).

I think the main problem is that most of the protocols will send some kind of response to tell you whether or not the TLS setup is acceptable before you can actually begin the handshake - so the code may need to understand what response is expected before it tries to handshake, otherwise you're just going to get junk results back. I suppose we could just read a response from the socket, discard it and try and handshake, but I'm not sure how reliable that would be, especially given you don't know how much information the server is going to return to you,

I'll have a think if there's a nice way to do this, but I think that trying to build in support for arbitrary protocols with either be very limited or very complicated.

If you run into an unknown protocol then it may be easier just to patch sslscan to add support for it. Commit 19a6ec727015acf8574629ae9d181cac5e835435 has the code for PostgreSQL support, and as you can see it's pretty simple to add a new protocol (in this case we send 8 bytes, then read a single byte response back which should be 'S' if the server is happy to proceed with TLS).

[maaaaz]

In most of the cases I faced, the answer after the kickstart wasn't useful for the rest of the connection (wasn't like an challenge-response). But you are right, it might be used in some other cases.

That aside, thank for the commit link, that is totally what I want to do !

In my imagination, the arguments given for a simple and generic --kickstart (without answer processing) is directly injected in the statement line 465 : send(socketDescriptor, [kickstart_arguments], [size_of_kickstart_arguments], 0);

Even if it can't ensure reliability for any custom explicit-TLS protocol, adding the kickstart option would avoid editing and compiling the source :)

I'll try to see if I can provide a PR, but I used to be awful at C dev.

Cheers @rbsec !