0

We are trying to build a TCP proxy that can forward to multiple virtual hosts. The idea is that a single IP address can be used to route inbound requests to multiple internal IP addresses. The initial thought was to craft a TCP proxy in two parts, a client that knows what SNI information to provide and a server that can translate the SNI to the appropriate private IP and make a connection.

Communication comes in-bound to the TCP proxy client without any SNI information. The client needs to open a TCP connection populating the SNI so the server can make intelligent decisions on how to route traffic.

It appears this approach requires reading the TLS clienthello and mutating it in flight. We are currently wanting to do this without SSL termination, if possible. Does this approach make sense?

Drew
  • 121
  • 1
  • 6
  • I don't understand your concept of having the proxy in two parts and the client coming in without SNI but the somehow "populating the SNI". But in short based on the title: if your client is using TLS without SNI then you cannot use SNI to determine where to forward the traffic. If the proxy terminates the SSL connection (and has the appropriate certificate to do this) it can try to extract the ultimate target from the application data inside the TLS connection, for example from the `Host` header in case of HTTPS. If the proxy does not terminate SSL it has no access to this application data. – Steffen Ullrich Jun 06 '18 at 16:04
  • It looks possible to read the clienthello and retransmit it, without terminating SSL. That's the approach I am investigating – Drew Jun 06 '18 at 17:01
  • It is possible to route TLS traffic without SSL termination based on the SNI from the ClientHello and that's what other [systems like haproxy do](https://serverfault.com/questions/625362/can-a-reverse-proxy-use-sni-with-ssl-pass-through). But, the title of this question suggests that the client does not use SNI so this option is not available. – Steffen Ullrich Jun 06 '18 at 17:12

0 Answers0