Imagine the following communication diagram:

C1-----\ /--B1
...----/ \--...

We have multiple C(lients), call them C1, C2, etc. They connect to a single P(roxy), using the SNI extension of the TLS protocol. The proxy uses the SNI metadata to decide, to which backend (B1, B2, etc) the connections should be forwarded to.

The proxy has no information about the used keys, thus it has no way to intercept/eavesdrop the transfered data. More clearly: the backends are using heavily client/server certs which are used for authentication/authorization. This information can't be lost by an (unneeded) decrypt/re-encrypt by the P.

On this reason, the P(roxy) has to

  • do the TLS handshake, until the SNI information arrives,
  • choose the required B(ackend),
  • replicate the TLS handshake to it,
  • and then do the common bi-directional forwarding as proxies work in general.

The question is: is it possible with TLS, if the P does not know any of the keys?


1 Answer 1


is it possible with TLS, if the P does not know any of the keys?

Sure. SNI is part of the ClientHello message extensions, which is the first TLS message the client sends. At this point you do not yet have key material on the client side to encrypt this in all cases and even for session resumption, SNI is usually included to tell the server which old key material to use.

Though it may be that this setup breaks in the future if and when encrypted SNI (currently only a draft standard) is enforced.

A (rather minimal) example implementation of such a multiplexer is the dedicated slt package, but this functionality should be achievable with most standard reverse proxy setups, e.g. Apache.


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.