4

I'd like to secure my application's traffic using TLS with pre-distributed self-signed certificates (as a drop-in replacement of plain TCP).

In some cases, two clients won't be able to talk to each other directly because of presence of NAT and will have to resort to an accessible relay to tunnel their traffic between each other. I'd like to protect the connection between client and relay, and I also don't want the relay to see the plain text intended for clients.

It seems that a client would have to connect to relay via TLS and then estabilish another TLS session to the second client over the existing TLS connection. I know that encrypting twice isn't stronger than encrypting once, but how much would a client be in trouble in this case?

  • Does the actual traffic need to go over the NAT-penetrating relay? The timing and approximate sizes of the messages will leak information to the relay server. I was under the impression that usually with this sort of thing you can use the relay to establish a direct connection between two NAT-ed endpoints, but I could be wrong. – Paul Jan 20 '17 at 11:50
  • @Paul, it's usually possible to ask a relay for endpoints' external addresses and then reuse existing sockets (A->relay, B->relay) to make another connect() to each other. I just started with the most pessimistic case when a NAT would assign different outbound ports for these new connections and make this type of hole punching impossible, thus requiring tunneling. – aitap Jan 21 '17 at 17:35
3

If I understand it correctly, this is a rough network diagram of your situation:

A connected to Relay; Relay connected to B

You're saying A and B want to talk, but they can't directly so they use Relay. You are thinking of having A set up an encrypted connection (TLS) to Relay and then using Relay as a proxy for connecting (over yet another TLS tunnel) to B.

This sounds complicated, but basically if you use an https proxy or any VPN server (say, mycompany.example) and connect to another https site (say, bank.example), you are already layering encryption on encryption. Let's see how the possible options work out (layering or not layering).

Option 1: encrypt A<->B but not A<->Relay nor B<->Relay

If you don't tunnel inside of the tunnel, you would be sending packets from A to Relay and from Relay to B unencrypted. But since they are destined for B, the traffic will be encrypted for B, nobody can read the connection contents (only A and B themselves). The only information you are leaking to anyone listening on the path between A<->Relay and Relay<->B is that A and B are communicating. The Relay will not be able to read the connection contents.

Option 2: encrypt A->Relay and A->B

If, like you're asking, there is a tunnel between A and Relay and between A and B, then people listening on A<->Relay can only see that A is communicating with Relay; and people listening on Relay<->B will again only see Relay communicating with B. The Relay will not be able to read the connection contents.

Option 3: encrypt A->Relay and B->Relay

Finally there is the option of encrypting the connection from A to Relay but not from A to B (and assuming B still sets up a (TLS) connection to Relay because it's behind NAT). In that case the traffic is transparent for Relay, but anyone observing will only see the connection from A to Relay and from B to Relay.

So it depends on whether it's an issue if people intercepting the lines can see the destination of the packets (namely A and B). Double encryption means double CPU power for A and B (only singular for Relay since it doesn't decrypt the contents, only the outer layer), but I'm not sure that makes a big difference or you would have mentioned it.


(Credits: the image was made with https://draw.io. The XML is in the source of this post.)

  • Yes, my only concern was possible weakening from layering encryption upon encryption. Apparently, since noone complains about HTTPS over VPN, I shouldn't worry either. Thanks for your answer! – aitap Jan 18 '17 at 17:58
  • 1
    @aitap I don't see how it could weaken it. In Tor's case it might, but that's because of the number of relays that can observe your traffic (if I remember correctly); it doesn't have anything to do with the encryption itself (the confidentiality or integrity of the communication). – Luc Jan 20 '17 at 9:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.