So you want to protect your TCP application’s traffic?
You’ve been writing network code for a while, using TCP, and you’ve faced the bugbears of reliability and performance, but now you’re looking for a real challenge.
You want to secure your network traffic; you want to securely authenticate the server and maybe even the client.
Or perhaps your users are simply screaming for the protection of SSL, even if they don’t know what that means, but because “everyone else has it”.
There are obviously several reasons you might have to use SSL to protect your network traffic – and over the next few blog entries, I’m going to advise you on how you might add SSL to your client or server, and what benefits you’ll get from doing so.
I’m going to start with a brief run-down of what SSL can provide, in its most common configuration.Â There are some pedants that will tell you all about using Diffie-Hellman (DH) key exchange, so that noone needs a certificate, or a NULL encryption cipher, so that you can read the SSL-wrapped communication, but neither of those apply in the general case that we’re going to talk about.Â When you have finished reading this set of columns, you’ll be able to take an HTTP client or server and turn it into HTTPS, or an FTP client or server, and make it support FTPS.
So, to begin, here’s a list of what SSL gives you over and above what you already have with your TCP application.
- Server Authentication: SSL requires that the server send a certificate to the client, identifying itself.
- Client Authentication: SSL allows the server to ask the client for a certificate, which will identify it.
- Communication privacy: Apart from the first few bytes of the exchange, all traffic is encrypted with a symmetric cipher.
- Communication integrity: A special checksum, called an HMAC, is used to ensure that bits within the ciphered text have not been altered, extra text has not been added, and that the communications stream has not been closed early by a hacker (or by network faults).
Now, here’s a list of some interesting changes that SSL makes to your TCP traffic:
- Session initialisation requires a significant amount of traffic (certificate exchange) before the first byte of your data can flow.
- TCP is a stream-based protocol, with no suggestion of message boundaries; SSL encrypts your data stream as a series of discrete messages within the TCP stream, and a message must be fully received before being decrypted (otherwise it is not protected by the HMAC).
- You have to think carefully about closure issues – what does a TCP RST mean, or a TCP FIN?Â You thought you understood those terms already, but they may have a different interpretation when you’re trying to secure a communication.
- In a client, in addition to resolving the server’s name to an IP address, you also have to check that the server’s certificate matches the name of the server you thought you were trying to reach.
- Your carefully-calculated performance-enhancing measures are all going to go up the spout; the overhead of encryption, plus the requirement to work within the message size of SSL is going to seriously impact performance.
Until next time, happy coding!