SSL Tutorial part 0.

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!

"FTPS" document finally makes it to RFC status.

News I’ve been waiting for for years – the document formally known as draft-murray-auth-ftp-ssl-16.txt has finally been released by the RFC editor as RFC 4217 – “Securing FTP with TLS


What exactly does this mean?  Technically, not very much – FTPS has been implemented by several FTP clients, servers and wrappers for several years.  I added FTPS support to WFTPD Pro back in 2001, after first expressing interest in doing so in 1997, but being held back by the lack of crypto support in Windows.


I nearly had it ready in 2000, but spent some time trying to debug an issue that turned out to be caused by a corrupted certificate issued by the Windows 2000 Server CA that I was testing against.  Let that be a lesson to you crypto developers – sometimes the code is right, and it’s the certs that are wrong!


A few minor things have changed since then in the document that is now RFC 4217, but almost nothing significant to the compatibility of FTPS offerings.


I will end with a brief FAQ for you – please let me know if there are any other questions you’d like to see answered:


1. What’s TLS, and what is its relation to SSL?


TLS is Transport Layer Security, and is the name of the protocol that grew from Netscape’s SSL and Microsoft’s PCT.  Most people still use the term “SSL”, but TLS is where all ongoing work is carried out by the IETF.


2. Is FTPS the official term?


No – the RFC is “Securing FTP with TLS”, and perhaps the official term should be “AUTH TLS”.  However, with the general public already familiar with the concept of “https” being the secured equivalent of “http”, the term “ftps” has sprung up in general use to describe an FTP transfer, or session, encrypted and/or authenticated with SSL or TLS.


3. How different is FTPS from HTTPS?


Quite significantly – HTTPS uses a separate port for incoming SSL connections (usually port 443), compared to the port for unprotected HTTP connections (usually port 80).  Because FTP is (and has always been) a session-based protocol, it allows the client to “negotiate up” to SSL or TLS security through the use of the AUTH command described in RFC 2228.


Note also that FTP uses two channels – a control channel and a data channel, and that these channels can be secured – or left unsecured – almost independently.  HTTPS is secured from the moment you connect to the HTTPS port, until you close down the connection.  FTP is secured on the control channel from the moment you send an “AUTH TLS” or “AUTH SSL” command, until you log out; the data channel is not necessarily secured by default, and security on the data channel can be turned on or off using the PROT command, with parameters “C” for “Clear” or “P” for “Private”.


FTPS always authenticates the server through its certificate, and can be configured to authenticate the client by certificate, or by USER / PASS commands supplying username and password.  HTTP and HTTPS have several other methods of authentication (none of which bear much examination at the moment) – NTLM CHAP, Basic, Digest, etc, etc.


4. What about SFTP?  What’s that?


I get to answer this question a lot.  With all these acronyms getting thrown around, it’s easy to get confused.  Many people automatically assume that any acronym including the letters “FTP” refer to protocols based on FTP.  Obviously, that’s why “FTPS” was chosen as an informal description of “Securing FTP with TLS”.  Unfortunately, others may create confusing acronyms by including the FTP letters, either by accident or on purpose.  One such confusion was always “TFTP – Trivial File Transfer Protocol”.  This is about as far from FTP as you can get, and still be associated with transferring files from one machine to the other.


The same is true of “SFTP” – it’s a file transfer extension to “SSH”.  As that sentence implies, to do an SFTP file transfer, you need to have an SSH connection in place.  This isn’t always practical.