So how come the original SNI couldn’t be encrypted before, but now it can? Where does the encryption key come from if client and server haven’t negotiated one yet? If the chicken must come before the egg, where do you put the chicken?Īs with many other Internet features the answer is simply “DNS”. That allows the observer to track which sites a user is visiting.īut with SNI encryption the client encrypts the SNI even though the rest of the ClientHello is sent in plaintext.
This means that an on-path observer (say, an ISP, coffee shop owner, or a firewall) can intercept the plaintext ClientHello message, and determine which website the client is trying to connect to. Unfortunately the ClientHello message is sent unencrypted, due to the fact that client and server don’t share an encryption key at that point. It sends the ClientHello to the server during the TLS handshake. The client adds the SNI extension containing the hostname of the site it’s connecting to to the ClientHello message. Without SNI the server wouldn’t know, for example, which certificate to serve to the client, or which configuration to apply to the connection.
The TLS Server Name Indication (SNI) extension, originally standardized back in 2003, lets servers host multiple TLS-enabled websites on the same set of IP addresses, by requiring clients to specify which site they want to connect to during the initial TLS handshake.
Today we announced support for encrypted SNI, an extension to the TLS 1.3 protocol that improves privacy of Internet users by preventing on-path observers, including ISPs, coffee shop owners and firewalls, from intercepting the TLS Server Name Indication (SNI) extension and using it to determine which websites users are visiting.Įncrypted SNI, together with other Internet security features already offered by Cloudflare for free, will make it harder to censor content and track users on the Internet.
0 kommentar(er)
