Why I don't believe in generic TLS terminator programs

December 8, 2014

In some security circles it's popular to terminate TLS connections with standalone generic programs such as stunnel (cf). The stated reason for this boils down to 'separation of concerns'; since TLS is an encrypted TCP session, we can split TLS termination from actually understanding the data streams that are being transported over. A weakness in the TLS terminator doesn't compromise the actual application and vice versa. I've seen people harsh on protocols that entangle the two issues, such as SMTP with STARTTLS.

I'm afraid that I don't like (and believe) in generic TLS terminator programs, though. The problem is their pragmatic impact; in practice you are giving up some important things when you use them. In specific, what you're giving up is easy knowledge of the origin IP address of the connection. A generic TLS terminator turns a TLS stream into the underlying data stream but by definition doesn't understand anything about the structure of the data stream (that's what makes it generic). This lack of understanding means it has no way to pass the origin IP address along to whatever is handling the actual data stream; to do so would require it to modify or augment the data stream somehow, and it has no idea how to do that.

You can of course log enough information to be able to reconstruct this information after the fact, which means that in theory you can recover it during the live session with suitably modified backend software. But this requires customization in both the TLS terminator and the backend software, which means that your generic TLS terminator is no longer a drop in part.

(Projects such as titus can apparently get around this with what is presumably a variant of NAT. This adds a lot of complexity to the process and requires additional privileges.)

I consider losing the origin IP address for connections to be a significant issue. There are lots of situations where you really want to know this information, which means that a generic TLS terminator that strips it is not suitable for unqualified general use; before you tell someone 'here, use this to support TLS' you need to ask them about how they use IP origin information and so on. As a result I tend to consider generic TLS terminators as suitable mostly for casual use, because it's exactly in casual uses that you don't really care about IP origin information.

(You can make a general TLS terminator that inserts this information at the start of the data stream, but then it's no longer transparent to the application; the application has to recognize this new information before the normal start of protocol and so on.)

(These issues are of course closely related to why I don't like HTTP as a frontend to backend transport mechanism, as you have the same loss of connection information.)


Comments on this page:

You don't just lose source IP. You lose everything from the layers under 7. You lose client cert, chosen cipher, etc.

If you just want to get the source IP, you can implement TLS terminator as a transparent proxy, at least on Linux. But, as you said, this terminator would require more privileges.

By Jan Schermer at 2015-04-24 09:49:07:

There's a PROXY protocol for this... not widely supported, sadly.

By Jan Schermer at 2015-04-24 12:53:34:

There's a PROXY protocol for this... not widely supported, sadly.

Written on 08 December 2014.
« How we install Ubuntu machines here
Why I do unit tests from inside my modules, not outside them »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Mon Dec 8 02:32:55 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.