4 ms·
> (I think it makes more sense for TLS vs non-TLS to be distinguished by the first byte that the client sends to the server (and the client distinguishes them
by geocar 2y ago
> (I think it makes more sense for TLS vs non-TLS to be distinguished by the first byte that the client sends to the server (and the client distinguishes them by the URI scheme); using separate port numbers is not required.)
The beginning of a TLS session begins with a "client hello" message[1] which is pretty easy to collect, parse (even without OpenSSL). A few pieces of software I've run into do this check before deciding which protocol to use and I find it nice to have a single port open I can speak TLS and non-TLS to.
[1]: https://tls12.xargs.org/#client-hello/annotated https://tls12.xargs.org/#client-hello/annotated
- zzo38computer 2y agoYes, although it might be unnecessary to do all of that. I would think that calling recv with MSG_PEEK could be used to read the first byte; if it is 0x16 then it can continue with TLS (using OpenSSL or other libraries to wrap the connection), and if it is anything else then it will continue without TLS. (This should work with any protocol that expects the client to send data first before the server does, and that 0x16 is not a valid first byte of the request.) However, I have not actually tried this (since I have not set up any servers with TLS yet).