Non-SSL cryptographic tunnels

Cryptographic tunnels are used to secure traffic between a client and server that communicate using a protocol that would normally be vulnerable to eavesdropping or man-in-the-middle attacks, where an attacker impersonates the other party. Instead of the client and server communicating directly they communicate via a local proxy and the traffic between the proxies is secured. Normally the client and server do not need to be changed, other than to configure where they connect to. Probably the best known software for securing TCP-based protocols is Stunnel.

Stunnel establishes a secure TCP tunnel using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols. SSL/TLS has a handshake at the beginning of the connection where the client and the server authenticate each other using their public/private keypairs and agree on the symmetric cipher and session key to use for encrypting subsequent packets. This handshake is relatively resource and time consuming so SSL/TLS connections work best if the connection is left open for a relatively long period of time so that the handshake costs are not incurred very often. SSL/TLS does not work very well if the TCP-based protocol connects and disconnects for every transaction, for example. The overhead of re-establishing the TCP socket for each transaction is much much lower than re-establishing an SSL/TLS connection.

Another thing to consider is that when the tunnel endpoints are fixed or under the same entity's control, the overhead of the SSL/TLS handshake is unnecessary and just slows down the initial transactions sent over the tunnel. One of the main benefits of SSL/TLS is that the server and optionally the client are authenticated, but if the tunnel endpoints are known and trusted then authentication is not necessarily required. A symmetric cipher and session key can be agreed on beforehand, eliminating the need for this to be negotiated on each connection. Man-in-the-middle attacks are still not possible because all the traffic is encrypted and an attacker would not have access to the symmetric key. Denial-of-service is still possible, as it is with SSL/TLS, but this may be mitigated by the TCP-based protocol itself.

Cryptographic tunnels that rely solely on symmetric encryption with a pre-agreed cipher and key are thus useful in some scenarios. One of the simplest and best implementations I have found is Jess Mahan's ctunnel which is just a single C file linked to the OpenSSL crypto library.

I'd eventually like to write (or more likely cobble together using other people's code :-) an UCSPI compliant secure TCP proxy that works similarly to ucspi-proxy but can be used to provide secure tunnels based on various technologies - perhaps: SSL/TLS, SRP SASL, public-key algorithms like Curve25519, message authentication codes like Poly1305-AES, symmetric ciphers like AES-256 etc. and combinations of these. While hopefully being useful this will allow experimentation.