0

Say that I have a program that needs to communicate with my own server.

I use TLS to secure the connection, however the program is running within a network, which sends all TLS traffic through a TLS inspection proxy and the computer where the program runs trusts the CA certificate of the TLS inspection proxy.

Everything works, however the proxy on the TLS inspection server has access to plaintext sent between my program and my server.

To prevent this I thought that we could wrap the plaintext as follows:

  • The plaintext is wrapped inside a TLS session (inner)
  • This TLS session is then wrapped inside another TLS session (outer)

With this setup the TLS inspection proxy will only terminate and replace the certificate for the outer TLS session but not the inner session, and thus the server will not have access to the plaintext. (Assuming the TLS inspection software doesn't do this recursively).

My program could then use the computers default root store for verifying the outer session, but either bundle its own trusted root store for the inner session or use certificate pinning for the inner session. The server would also need to be modified to use this double-TLS.

Of course after installation of my program a user could modify the trusted root store used for the inner session, by modifying the compiled program, but I think this is not a very likely scenario.

Are there any other flaws with this approach?

1
  • You could do authentication with something like SCRAM-SHA-256-PLUS, which does channel binding to the TLS session, so authentication will fail if there's a MITM. There's a way to circumvent this for TLS 1.2, but if you use TLS 1.3, it should work.
    – bk2204
    Dec 14, 2021 at 23:41

1 Answer 1

2

There is nothing inherently insecure with the concept of TLS inside TLS - and it is even done already. For example some HTTP proxies like squid support connecting to the proxy with HTTPS and then having inside this protected connection to the proxy the real connection. Also using TLS inside a VPN is a similar concept of having multiple encryption and authentication layers inside each other.

As for the actual implementation one might run into problems though with a simple TLS inside TLS approach. TLS inspection proxies commonly expect a specific protocol like HTTP spoken inside the TLS - because to get to the plain data is the main point of TLS interception in the first place. If these proxies don't see the expected protocol they might simply break the connection. Thus it might be necessary to layer the inner TLS again inside the expected protocol, like layering the inner TLS inside HTTP which then gets layer inside the outer TLS.

Of course after installation of my program a user could modify the trusted root store used for the inner session, by modifying the compiled program, but I think this is not a very likely scenario.

Having the end user running the program as enemy is a completely different scenario than trying to pass through some untrusted proxy - i.e. endpoint vs. man in the middle. TLS inside TLS might make it a bit harder to reverse engineer and change the application, but it does not prevent it. So while it is suitable as a protection against an intercepting MITM it is not suitable as a protection against the end user.

1
  • I'd wager that this could be considered a form of End-to-End Encryption actually.
    – user163495
    Dec 14, 2021 at 21:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .