Multiplex TLS Traffic with SNI Routing

Nginx configuration and HTTP/2 coalescing

Photo by Gene Gallin on Unsplash

Server Name Indication or SNI is a TLS extension originally designed for a single web server to serve multiple HTTPS sites configured with different TLS certificates. For example, when www.example.com uses TLS Certificate-A and www.example.net uses a different TLS Certificate-B, the web server can identify the domain with the help of SNI and establish a TLS session with correct certificate to serve the corresponding website.

Since the server name is in clear, ie., not encrypted, web server is able to choose the TLS certificate to establish a secure session. Interestingly, there are multiple use cases for having server name in clear, such as having a device in the middle for traffic filtering.

SNI Routing

Another use case for SNI is identifying the server name and routing the traffic to different origin servers. This allows for a single IP and port to receive traffic for several websites, applications, and intelligently route them to their corresponding origin servers.

The above diagram gives an example where an nginx server, acting as an SNI Router, accepts TLS connection requests for c.application.org, a.example.com and b.for-example.net. The nginx server can examine the server name in those requests, and with the help of an origin map, initiate a connection to the origin server and proxy the data.

This allows for origin servers to establish a secure TLS session with the client using their own TLS certificates. And, these origin servers can be located inside a private network, without any public interface, while the SNI router can reside on the edge.

nginx configuration

The stream_ssl_preread_module in nginx is required for it to function as a SNI router. Run nginx -V to get the list of configure arguments and make sure it includes the following,

--with-stream_ssl_preread_module

The example configuration below creates a stream listener on port 443, and proxies TLS connections to origin servers based on a static map of server name to IP address.

stream {
  map $ssl_preread_server_name $origin_https {
    hostnames;
    default           p8;
    a.example.com     p1;
    b.for-example.net p2;
    c.application.org p3;
  }
  upstream p8 {
    server 10.0.3.8:443;
  }
  upstream p1 {
    server 10.0.3.1:443;
  }
  upstream p2 {
    server 10.0.3.2:443;
  }
  upstream p3 {
    server 10.0.3.3:443;
  }
  server {
    listen 443;
    proxy_pass $origin_https;
    ssl_preread on;
  }
}

However, this approach has a drawback, the origin servers will not see the public IP address of the client, instead the private IP address of the nginx server. To avoid this, a different approach to multiplex TLS traffic will be needed which uses deep packet inspection (DPI) and destination network address translation (DNAT).

HTTP/2 Coalescing

Due to the way HTTP/2 clients reuse connections, there can be problems with SNI routing if there is an overlap of server name among the names (Common Name and Subject Alternate Name) in TLS certificate of origin servers.

In the above example, since the TLS certificate used by origin server 10.0.3.2 has wildcard name *.example.com, Web Browser can make a TLS connection with server name b.example.com and use the same connection for HTTP/2 requests to a.example.com. This can cause undefined behavior in web sites and applications.

Encrypted SNI

There are significant privacy concerns and censorship issues with SNI since server name is not encrypted. Encrypted SNI (ESNI) intends to solve some of these problems by encrypting the server name. While just encrypted server name is not sufficient to resolve all the privacy concerns, it can solve some of the other problems. Do note, there are also other solutions for these problems.

Enterprise products which rely on SNI may not be fully functional without an alternative. Hence, it is yet to be seen whether ESNI will have wide spread use. However, one way or the other, there will be solutions to these problems in the future. At 0th Root, we continue to follow such solutions and adopt them to improve security within our products.

Our product 0th Root Secure Network — 0SNet secures organization’s internal web applications with TLS client certificates. It is easy to deploy and is also available as images on AWS, GCP and Azure. Try it out today!