Should I tunnel multiple TCP connections through a TLS/SSL tunnel or use TLS/SSL for each connection?

Question

I am developing an application that runs on Windows PCs. The application is able to connect to some kind of devices within a LAN. It can create multiple TCP-connections to the device it is connected to. I want to secure every single TCP-connection with TLS/SSL.

The naive solution for this would be to use TLS/SSL for every TCP-connection between my application and the device on the other side. However I am not sure on how much overhead this will produce since every TCP-connection will have to go through the whole TLS/SSL negotiation/authentication process. I don't see any need for that since the application/PC only needs to negotiate/authenticate. All TCP-connections will then use the same encryption. There is also an FTP-server on the device that I want to use (I am thinking of FTP over SSL).

Is it possible to create a single TLS/SSL connection from my PC to the device and then forward all of my TCP/FTP data through this tunnel? Is this the right solution, or would it be better to create a single TLS/SSL connection for every connection I intend to make between my application and the device?

Answer 1

You should use multiple TLS connection. However, you should make sure that your application opens the multiple connection using TLS abbreviated handshake and session resumption possibly with session tickets.

Using abbreviated handshake and session resumption allows your application to reuse encryption parameters and master key from a previous full handshake, massively reducing the cost of establishing new TLS connection. A full TLS handshake takes multiple round trips to negotiate the TLS version, ciphers, and master key, and involves expensive RSA certificate operations to authenticate the certificate chain; compared to abbreviated handshake which is just one roundtrip and a cheap symmetric encryption operation.

Additionally, you may also want to experiment with TLS False Start if your infrastructure supports it. TLS False Start allow you to start sending data much earlier, reducing time to first byte even further.

Answer 2

This sounds like you are looking for a VPN but want TLS to provide the security (instead of e.g. IPSec). If platform compatibility is not your concern, then Microsoft has developed a Secure Socket Tunneling Protocol which uses such an SSL-VPN scheme.
If the "some kind of devices" you are talking about are also Windows-based, then you might not even need additional software to implement SSTP.

I do not have any more knowledge about SSTP, but the Wikipedia link and the MSDN resources linked in said Wikipedia article should provide all needed information.

An alternative would be OpenVPN which can also use TLS as underlying connection protocol, supporting server side and client side certificates for authentication.

Answer 3

It depends on the kind of traffic you have or, in other words, on your application needs.

Is latency for new communications a critical point? Then you might want to keep that TCP connection opened and tunnel everything through the same SSL session. Or maybe you need to transfer lots of data and it can be parallelized? Then definitely go for multiple TCP connections with their own SSL layer on top.

Answer 4

If you're into bandwidth hogging, then multiple TLS/SSL at the same time would work. On the other hand, if you want to save connection tearing/setup then using one is the way to go.

Which brings up the question, how to do it with the minimal amount of fuss. You could, design your own protocol, or go with some kind of connection broker ... etc. What this means in a nutshell is, you're stuck with figuring out if you're in the early optimisation loop, where you might be overdesigning the solution.