For context: SNI is a header in the TLS session which indicates which service you intend to communicate with on the other side. Why? Usually, you reach a reverse proxy and firewall) terminating the TLS connection on the publicly-routable IP of the remote server, and from there follow a route on a local network unencrypted.

However, in some situations it’s not very practical for your architecture, and you have a single public IP for many services/servers each with their own domain names and TLS keys, so you need to be able to route the TLS traffic to its intended destination. That’s why your browser sends a “SNI” header indicating it would like to reach “foobar.com”, and that header is not encrypted because it’s meaningful before the TLS connection is terminated.

Lately, there’s been a push for encrypted SNI. The idea is by establishing an encrypted session with the reverse proxy specifically for SNI-based proxying, that header can be concealed to its intended destination without being readable by any person-in-the-middle on the network.