Support SSL and non-SSL on the same port

2
votes

I'm working on adding SSL support into our existing application and have started to think about backwards compatibility.

The one special case that makes this different than other posts I've read is the server may not necessarily be updated with SSL code. So I'll have an SSL client connecting to a server that knows nothing about SSL.

For the sake of this discussion, the application sends keystrokes one at a time to the server, and for each keystroke a new socket is created. So I need to figure out a way to make this work on the existing port number and not use timeouts to determine if the server supports SSL or not.

Any suggestions on a graceful way to handle this?

(I'm using Winsock and OpenSSL)

1
sslopenssl
Since SSL is a protocol on top of TCP, they are always running on the same port. - Niels Keurentjes
Oops. I worded my subject wrong. Fixed. - BigHands79
Insufficient data here. You need to think about how the server is going to be upgraded, when/if that happens. How is the server going to handle clients that have/haven't been upgraded to SSL? Are you going to use StartTLS for example? - user207421
Assume the server will never be updated. I know, it's a little weird, but that's my current requirement. - BigHands79

1 Answers

2
votes

Usually applications accept plain connections and direct SSL connections on different ports, e.g. smtp port 25 and smtps port 465, http port 80 and https port 443 etc. Other ways are to use the same port and then have a specific command from the client to upgrade to SSL, e.g. like STARTTLS with smtp or AUTH TLS with ftp.

If these common ways are not an option for you and the client sends the first packet in your protocol anyway (like with http, but not with smtp or ftp) you might do an recv(..MSG_PEEK) after the initial accept to see, what kind of data the client sends without removing the data from the socket buffer yet. If the peeked data look like your plain application protocol you continue there, if they look like a client hello from SSL (see https://security.stackexchange.com/questions/34780/checking-client-hello-for-https-classification) you do an SSL upgrade.