Can a Reverse Proxy use SNI with SSL pass through?

I need to serve several applications over https using one external ip address.

The ssl certificates should not be managed on the reverse proxy. They are installed on the application servers.

Can a reverse proxy be configured to use SNI and pass ssl through for termination at the endpoint?

Is this possible using something like Nginx or Apache? What does the configuration look like?

Solution 1:

This IS possible with Haproxy. You can setup a TCP proxy and extract the SNI and do routing based on the SNI. Here's an example:

backend be.app1
    mode tcp
    no option checkcache
    no option httpclose
    tcp-request inspect-delay 5s
    tcp-request content accept if { req.ssl_hello_type 1 }
    tcp-request content reject
    use-server server1 if { req.ssl_sni -m beg app1. }
    server server1 server1:8443 check id 1 weight 0

It is essential to delay the request until you get the SSL hello, otherwise haproxy will try to make a connection before receiving the SNI header.

I am using servers with weight 0 because, in my current configuration, I only have one server running for each SNI and I don't want them to receive random requests. You can probably find better ways to play with this.

I hope this helps.

Solution 2:

You can use sniproxy : https://github.com/dlundquist/sniproxy

An example configuration :

listener 0.0.0.0:443 {
    protocol tls
    table TableHTTPS
    fallback 127.0.0.1:8443
}

listener 0.0.0.0:80 {
    protocol http
    table TableHTTP
    fallback 127.0.0.1:8080
}

table TableHTTPS {
    domain1.com backend1:443
    domain2.org backend2:443
}

table TableHTTP {
    domain1.com backend1:80
    domain2.org backend2:80
}

Solution 3:

This is certainly possible, even now in 2021 with more and more widespread TLS 1.3! Many web servers or specialized reverse proxies provide this functionality out of the box:

• Nginx ≥ 1.11.5 (Debian ≥ buster or stretch-backports)
• HAProxy ≥ 1.5 (Debian ≥ jessie)
• Sniproxy (Debian ≥ buster)
• etc.

This is an example configuration for Nginx, which is a very popular choice for setups that require a reverse proxy:

stream {
  map $ssl_preread_server_name $selected_upstream {
    example.org upstream_1;
    example.net upstream_2;
    example.com upstream_3;
    default upstream_4;
  }
  upstream upstream_1 { server 10.0.0.1:443; }
  upstream upstream_2 { server 10.0.0.2:443; }
  upstream upstream_3 { server 10.0.0.3:443; }
  upstream upstream_4 { server 10.0.0.4:443; }
  server {
    listen 10.0.0.5:443;
    proxy_pass $selected_upstream;
    ssl_preread on;
  }
}

The relevant Nginx modules are stream_core and stream_ssl_preread. Manuals:

• https://nginx.org/en/docs/stream/ngx_stream_core_module.html
• https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html

Solution 4:

Be aware that if the target servers use the same certificate (which is not very unlikely when wildcard certificates are in use), then HTTP/2 can not be used. It will route your traffic to the wrong server.

Sample:

• a.example.com with certificate *.example.com
• b.example.com with certificate *.example.com

If a.example.com and b.example.com are handled by the same reverse proxy then a single connection will be opened - and streamed to the server that is called for the first time. So if you call a.example.com, future requests to b.example.com may reach the wrong web server.

For reference, see

• https://www.perimeterx.com/tech-blog/2019/http2/
• https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/
• https://bugzilla.mozilla.org/show_bug.cgi?id=1420777
• https://webplatform.news/issues/2017-11-27
• https://medium.com/bbc-design-engineering/http-2-is-easy-just-turn-it-on-34baad2d1fb1