Lecture
Server Name Indication (SNI) is an extension of the TLS computer protocol that allows a client to indicate the hostname it wishes to connect to during the "handshake" process. This allows a server to present multiple certificates on the same IP address and TCP port, and therefore allows multiple secure (HTTPS) websites (or other services over TLS) to be served from the same IP address without using the same certificate for all of them. It is equivalent to the name-based virtual hosting of HTTP/1.1. The requested hostname is not encrypted, which allows an attacker to intercept it.
For practical use, SNI requires that the vast majority of users use browsers that support this feature. Users whose browsers do not support SNI will receive the default certificate (implementation-dependent, usually the first one in the list), and consequently a certificate error, unless the server is equipped with a wildcard certificate and it does not contain the site name requested by the client.
Since autumn 2018, experiments have been under way to introduce Encrypted SNI from the TLS 1.3 protocol, which encrypts the name of the requested site using the site's public key obtained from the DNS domain name system.
Thanks to ESNI, the information about which domain you are sending a request to is encrypted. In standard HTTPS, headers containing domain names are not encrypted and can be viewed by the provider or another "man in the middle". Now they see only the IP address. Since in the modern internet hundreds of domains can be hosted on a single IP address, ESNI effectively hides which domain the user is visiting.
Thus, blocking by names stops working, and internet censorship becomes much more difficult. Censors will have to block IP addresses, which is a dubious practice. Such blocking may affect uninvolved sites, while the blocked service easily (and automatically) switches to another IP address.
Why are hostnames "exposed" in ordinary TLS SNI? The point is that before encryption begins, the server needs to know which domain the client is addressing in order to present the right certificate. For this reason the hostname is transmitted in plain text (see the illustration below).
In encrypted SNI (ESNI) this problem is solved as follows: the client takes the server's public key from DNS and uses it to encrypt all data before the TLS session is established.
When a TLS connection is being created, the client requests a digital certificate from the web server; after the server sends the certificate, the client verifies its validity and compares the name it was trying to connect to with the names contained in the certificate. If the comparison succeeds, the connection proceeds in encrypted mode. If no match is found, the user may be warned about the mismatch and the connection is aborted, since the mismatch may indicate an attempted "man in the middle" attack. However, some applications allow the user to ignore the warning and continue the connection, shifting to the user the question of whether to trust the certificate and, accordingly, whether to connect to the site.
However, it can be difficult — or even impossible, for lack of a complete list of all names prepared in advance — to obtain a single certificate that covers all the names the server will be responsible for. A server responsible for multiple hostnames will probably need to present a different certificate for each name (or small group of names). Since 2005, CAcert has been running experiments on various methods of using TLS on virtual servers. Most of the experiments have been unsatisfactory and impractical. For example, subjectAltName can be used to hold multiple domains controlled by one person in a single certificate. Such "unified certificates" must be reissued every time the list of domains changes.
Name-based virtual hosting allows multiple hostnames to be hosted on a single server (usually a web server) at the same IP address. To achieve this, the server uses the hostname presented by the client as part of the protocol (for HTTP the name is presented in the Host header). However, when HTTPS is used, the TLS handshake takes place before the server sees any HTTP headers. Consequently, the server cannot use the information in the HTTP Host header to decide which certificate to present, and accordingly only names listed in a single certificate can be served on one IP address.
In practice this means that an HTTPS server can serve only one domain (or a small group of domains) per IP address for secure and efficient browsing. Assigning a separate IP address to each site increases hosting costs, because requests for IP addresses must be justified to the regional internet registry, and IPv4 addresses are already exhausted. As a result, many websites are effectively unable to use a secure protocol when using IPv4. The IPv6 address space is not exhausted, so websites served over IPv6 are not affected by this problem.
The SNI extension solves this problem by adding the hostname (domain) to the TLS handshake protocol. The server, knowing exactly which domain the request will be for, can thus present the certificate for that domain only.
The IETF added SNI to its "requests for comments" ( RFC ). The document is RFC 3546 (June 2003), titled "Transport Layer Security (TLS) Extensions". The most recent version of the standard (as of early 2018) is RFC 6066 .
SNI addresses this issue by having the client send the name of the virtual domain as part of the ClientHello message of the TLS negotiation. This enables the server to select the correct virtual domain early and present the browser with the certificate containing the correct name. Therefore, with clients and servers that implement SNI, a server with a single IP address can serve a group of domain names for which it is impractical to get a common certificate.
SNI was added to the IETF 's Internet RFCs in June 2003, through RFC 3546, Transport Layer Security (TLS) Extensions . The latest version of the standard is RFC 6066.
The Server Name Indication payload is not encrypted, so the hostname of the server the client is trying to connect to is visible to a passive eavesdropper. This weakness of the protocol has been exploited by security software for network filtering and monitoring and by governments to impose censorship. Currently there are several technologies attempting to encrypt the server name indication.
Domain fronting is a technique of replacing the desired hostname in SNI with another hostname hosted on the same server or, more commonly, on a network of servers known as a content delivery network. When a client uses domain fronting, it replaces the server's domain in the SNI (unencrypted) but leaves it in the HTTP Host header (which is encrypted by TLS), so that the server can serve the correct content. Domain fronting violates the standard that defines SNI itself, so its compatibility is limited (many services check that the SNI host matches the host of the HTTP header and reject connections with domain-fronted SNI as invalid). Although in the past domain fronting was used to avoid government censorship, its popularity has fallen because major cloud providers (Google, Amazon AWS and CloudFront) explicitly forbid it in their terms of service and have technical restrictions against it. [10]
Encrypted Client Hello ( ECH ) is an extension of the TLS 1.3 protocol that encrypts the entire Client Hello message, which is sent early in the TLS 1.3 negotiation. ECH encrypts the payload with a public key that the relying party (the web browser) must know in advance, which means that ECH is most effective with large CDNs that are known to browser vendors ahead of time.
The original 2018 version of this extension was called Encrypted SNI ( ESNI ) [11], and its implementations were deployed in an "experimental" mode to reduce the risk of domain fronting interception. Unlike ECH, Encrypted SNI encrypts only the SNI, not the entire Client Hello. [15] Support for this version was enabled in Firefox in October 2018 [16] and required DNS-over-HTTPS to be enabled. [17]
In March 2020, ESNI was reworked into the ECH extension after analysis showed that encrypting only the SNI is not sufficient. For example, the specifications allow the Pre-Shared Key extension to contain arbitrary data to facilitate session resumption, even carrying a plaintext copy of exactly the same server name that ESNI encrypts. In addition, encrypting the extensions one by one would require an encrypted variant of each extension, each with potential privacy implications, and even then the set of advertised extensions would be revealed. Finally, real-world deployment of ESNI exposed interoperability limitations. [18] The short name was ECHO in March 2020 and was changed to ECH in May 2020. [19]
Both ESNI and ECH are compatible only with TLS 1.3, because they rely on KeyShareEntry, which was first defined in TLS 1.3. [20] In addition, to use ECH, the client must not offer TLS versions below 1.3. [21]
In August 2020, the Great Firewall of China began blocking ESNI traffic, but still allowed ECH traffic.
In October 2020, the Russian internet provider Rostelecom and its mobile operator Tele2 began blocking ESNI traffic. [23
A patch that adds TLS / SNI support to the OpenSSL package appeared in 2004, as part of the EdelKey project. Within two years it was ported to the OpenSSL development branch, and in 2007 it was ported to OpenSSL 0.9.8 (first appearing in version 0.9.8f ).
For an application to support SNI, this extension must be implemented in the TLS library, whose new functions accept the domain name to which the request will be made.
Since August 2020, ESNI and TLSv1.3 traffic has been blocked in China.
Since October 2020 and earlier, providers in Russia have likewise begun blocking ESNI traffic, which ultimately makes ordinary, non-banned websites inaccessible to users, considering that there are no laws in force on blocking this technology.[11] The first providers to block ESNI were Rostelecom and then its subsidiary company OOO "T2 RTK Holding" (trademark "Tele2 Russia").
|
TLS and SSL
|
|||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Protocols and technologies |
|
||||||||
|
Public key infrastructure |
|
||||||||
| See also |
|
||||||||
| History |
|
||||||||
| Implementations |
|
||||||||
| Notaries |
|
||||||||
| Vulnerabilities |
|
Comments