Server Name Indication

Last updated

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. [1] The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other service over TLS) to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC   3546

Contents

Background of the problem

Prior to SNI, when making a TLS connection, the client had no way to specify which site it was trying to connect to. Hence, if one server hosts multiple sites on a single listener, the server has no way to know which certificate to use in the TLS protocol. In more detail, when making a TLS connection, the client requests a digital certificate from the web server. Once the server sends the certificate, the client examines it and compares the name it was trying to connect to with the name(s) included in the certificate. If a match occurs, the connection proceeds as normal. If a match is not found, the user may be warned of the discrepancy and the connection may abort as the mismatch may indicate an attempted man-in-the-middle attack. However, some applications allow the user to bypass the warning to proceed with the connection, with the user taking on the responsibility of trusting the certificate and, by extension, the connection.

However, it may be hard – or even impossible due to lack of a full list of all names in advance – to obtain a single certificate that covers all names a server will be responsible for. A server that is responsible for multiple hostnames is likely to need to present a different certificate for each name (or small group of names). It is possible to use subjectAltName to contain multiple domains controlled by one person [2] in a single certificate. Such "unified communications certificates" must be reissued every time the list of domains changes.

Name-based virtual hosting allows multiple DNS hostnames to be hosted by a single server (usually a web server) on the same IP address. To achieve this, the server uses a hostname presented by the client as part of the protocol (for HTTP the name is presented in the host header). However, when using HTTPS, the TLS handshake happens before the server sees any HTTP headers. Therefore, it was not possible for the server to use the information in the HTTP host header to decide which certificate to present and as such only names covered by the same certificate could be served from the same IP address.

In practice, this meant that an HTTPS server could only serve one domain (or small group of domains) per IP address for secured and efficient browsing. Assigning a separate IP address for each site increases the cost of hosting, since requests for IP addresses must be justified to the regional Internet registry and IPv4 addresses are now exhausted. For IPv6, it increases the administrative overhead by having multiple IPs on a single machine, even though the address space is not exhausted. The result was that many websites were effectively constrained from using secure communications.

Technical principles

SNI addresses this issue by having the client send the name of the virtual domain as part of the TLS negotiation's ClientHello message. [3] 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.

Security implications

Server Name Indication payload is not encrypted, thus the hostname of the server the client tries to connect to is visible to a passive eavesdropper. This protocol weakness was exploited by security software for network filtering and monitoring [4] [5] [6] and governments to implement censorship. [7] Presently, there are multiple technologies attempting to hide Server Name Indication.

Domain fronting

Domain fronting is a technique of replacing the desired host name in SNI with another one hosted by the same server or, more frequently, network of servers known as Content Delivery Network. When a client uses domain fronting, it replaces the server domain in SNI (unencrypted), but leaves it in the HTTP host header (which is encrypted by TLS) so that server can serve the right content. Domain fronting violates the standard defining SNI itself, so its compatibility is limited (many services check that SNI host matches the HTTP header host and reject connections with domain-fronted SNI as invalid). While domain fronting was used in the past to avoid government censorship, [8] its popularity dwindled because major cloud providers (Google, Amazon's AWS and CloudFront) explicitly prohibit it in their TOS and have technical restrictions against it. [9]

Encrypted Client Hello

Encrypted Client Hello (ECH) is a TLS 1.3 protocol extension that enables encryption of the whole Client Hello message, which is sent during the early stage of TLS 1.3 negotiation. [10] ECH encrypts the payload with a public key that the relying party (a web browser) needs to know in advance, which means ECH is most effective with large CDNs known to browser vendors in advance.

The initial 2018 version of this extension was called Encrypted SNI (ESNI) [11] and its implementations were rolled out in an "experimental" fashion to address this risk of domain eavesdropping. [12] [13] [14] Firefox 85 removed support for ESNI. [15] In contrast to ECH, Encrypted SNI encrypted just the SNI rather than the whole Client Hello. [16] Opt-in support for this version was incorporated into Firefox in October 2018 [17] and required enabling DNS over HTTPS (DoH). [18]

In March 2020, ESNI was reworked into the ECH extension, after analysis demonstrated that encrypting only the SNI is insufficient. For example, specifications permit the Pre-Shared Key extension to contain any data to facilitate session resumption, even transmission of a cleartext copy of exactly the same server name that is encrypted by ESNI. Also, encrypting extensions one-by-one would require an encrypted variant of every extension, each with potential privacy implications, and even that exposes the set of extensions advertised. Lastly, real-world deployment of ESNI has exposed interoperability limitations. [19] The short name was ECHO in March 2020 [16] and changed to ECH in May 2020. [20]

Both ESNI and ECH are compatible only with TLS 1.3 because they rely on KeyShareEntry which was first defined in TLS 1.3. [21] [22] Also, to use ECH, the client must not propose TLS versions below 1.3. [23]

Another Internet Draft, incorporates a parameter for transmitting the ECH public keys via HTTPS and SVCB DNS record types, shortening the handshake process. [24] [25]

In August 2020, the Great Firewall of China started blocking ESNI traffic, while still allowing ECH traffic. [26]

In October 2020, Russian ISP Rostelecom and its mobile operator Tele2 started blocking ESNI traffic. [27] In September of the same year, Russian censorship ministry Roscomnadzor planned to ban a range of encryption protocols, among which were TLS 1.3 and ESNI, which hindered web site access censorship. [28] [29] [30]

In July 2023, in the IETF117 meeting, members working on ECH informed Chrome and Firefox were doing a 1% sample trial, and the team expects the final draft to be submitted to the IESG evaluation by January 2024. [31] [32]

In Sep 2023, Cloudflare started to support ECH for hosted domains. [33]

In October 2023, Mozilla enabled ECH by default in Firefox v118, provided that DNS over HTTPS (DoH) is also enabled [34] [35] to keep DNS requests for HTTPS Resource Record protected from eavesdropping on the computer network. [36] In September 2023, Chromium version 117 (used in Google Chrome, Microsoft Edge, Samsung Internet, and Opera) enabled it by default, also requiring keys to be deployed in HTTPS DNS records. [37] [38]

Implementation

In 2004, a patch for adding TLS/SNI into OpenSSL was created by the EdelKey project. [39] In 2006, this patch was then ported to the development branch of OpenSSL, and in 2007 it was back-ported to OpenSSL 0.9.8 (first released in 0.9.8f [40] ). First web browsers with SNI support appeared in 2006 (Mozilla Firefox 2.0, Internet Explorer 7), web servers later (Apache HTTP Server in 2009, Microsoft IIS in 2012).

For an application program to implement SNI, the TLS library it uses must implement it and the application must pass the hostname to the TLS library. Further complicating matters, the TLS library may either be included in the application program or be a component of the underlying operating system. Because of this, some browsers implement SNI when running on any operating system, while others implement it only when running on certain operating systems.[ citation needed ]

Support

Support
SNI SupportECH Support
SoftwareTypeSupportedNotesSinceSupportedNotes
Alpine (email client) IMAP email client YesSince version 2.22 [41] 2019-02-18
Internet Explorer Web browserYesSince version 7 on Vista (not supported on XP)2006No
Edge Web browserYesAll versionsYesSince v105 behind flag [42]
Mozilla Firefox Web browserYesSince version 2.02006YesIntroduced in v85 behind flag. [43] Enabled by default in v118 when DoH is enabled. [44]
cURL Command-line tool and libraryYesSince version 7.18.12008Partial [45] [46]
Safari Web browserYesNot supported on Windows XP No [47]
Google Chrome Web browserYes2010YesSince v105 behind flag. [43]
BlackBerry 10 Web browserYesSupported in all BB10 releases2013No
BlackBerry OS No
Barracuda WAF Reverse ProxyYesSupported since version 7.8 [48] 2013
Barracuda ADC Load balancerYesFrontend support since version 4.0 and backend support from v5.2 [49] Frontend 2013 / Backend 2015
Windows Mobile Web browserSome time after 6.5No
Android browser
(discontinued in Android 4.2)		Web browserYes Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones2011No
Firefox for Android Web browserYesSupported for browsing. Sync and other services support SNI only since version 86. [50] Only on Firefox Beta and Nightly is possible to enable DoH by a flag.
wget Command-line toolYesSince version 1.142012
Nokia Browser for Symbian Web browserNoNo
Opera Mobile for Symbian Web browserNoNot supported on Series60No
Dillo Web browserYesSince version 3.12016
IBM HTTP Server Web serverYesSince version 9.0.0 [51] [52]
Apache Tomcat Web serverYesNot supported before 8.5 (backport from 9)
Apache HTTP Server Web serverYesSince version 2.2.122009
Microsoft IIS Web serverYesSince version 8 (part of Windows Server 2012)2012
nginx Web serverYesSince version 0.5.232007No [53]
Jetty Web serverYesSince version 9.3.02015
HCL Domino Web serverYesSince version 11.0.12020
HCL Notes Workflow clientYesSince version 14.02023 [54]
H2O Web serverYesYes [55] [56]
BoringSSL LibraryYesYes [57]
BSAFE Micro Edition SuiteLibraryYesVersion 5.0 [58]
GnuTLS LibraryYesNoWork in progress as July 2023. [59]
LibreSSL LibraryYesNo [60]
Mbed TLS LibraryYesNo
Mozilla NSS client sideLibraryYesSince version 3.11.1 [61] 2006Yes [62]
Mozilla NSS server sideLibraryNo [63] No
OpenSSL LibraryYesNo [64]
PicotlsLibraryYesYes [65]
RustlsLibraryYesNoWork in progress as July 2023. [66] [67]
SwiftNIO SSLLibraryYesNo [68]
wolfSSL LibraryYesYesSince v5.6.3 [69]
4th Dimension Standard libraryNoNot supported in 15.2 or earlierNo
ColdFusion / Lucee Standard libraryYesColdFusion since Version 10 Update 18, 11 Update 7, Lucee since Version 4.5.1.019, Version 5.0.0.502015
Erlang Standard libraryYesSince version r172013
Go Standard libraryYesSince version 1.42011Cloudflare/go fork provides support [70]
Java Standard libraryYesSince version 1.72011
Perl Standard libraryYesSince Net::SSLeay version 1.50 and IO::Socket::SSL version 1.562012
PHP Standard libraryYesSince version 5.32014
Python Standard libraryYesSupported in 2.x from 2.7.9 and 3.x from 3.2 (in ssl, urllib[2] and httplib modules)2011 for Python 3.x and 2014 for Python 2.x
Qt Standard libraryYesSince version 4.82011
Ruby Standard libraryYesSince version 2.0 (in net/http)2011
Hiawatha Web serverYesSince version 8.62012NoDepends on Mbed TLS. [71]
lighttpd Web serverYesSince version 1.4.242009No
HAProxy Load balancerYesSince version 1.5-dev12 [72] 2012No [73]
OpenBSD httpdWeb serverYesSince OpenBSD version 6.1 [74] 2017-04-11NoDepends on OpenSSL. [75]

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the device examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

Datagram Transport Layer Security (DTLS) is a communications protocol providing security to datagram-based applications by allowing them to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees. The DTLS protocol datagram preserves the semantics of the underlying transport—the application does not suffer from the delays associated with stream protocols, but because it uses UDP or SCTP, the application has to deal with packet reordering, loss of datagram and data larger than the size of a datagram network packet. Because DTLS uses UDP or SCTP rather than TCP, it avoids the "TCP meltdown problem", when being used to create a VPN tunnel.

<span class="mw-page-title-main">Secure Hypertext Transfer Protocol</span> Web encryption method similar to HTTPS

Secure Hypertext Transfer Protocol (S-HTTP) is an obsolete alternative to the HTTPS protocol for encrypting web communications carried over the Internet. It was developed by Eric Rescorla and Allan M. Schiffman at EIT in 1994 and published in 1999 as RFC 2660.

Opportunistic encryption (OE) refers to any system that, when connecting to another system, attempts to encrypt communications channels, otherwise falling back to unencrypted communications. This method requires no pre-arrangement between the two systems.

<span class="mw-page-title-main">Network Security Services</span> Collection of cryptographic computer libraries

Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted connection instead of using a separate port for encrypted communication. Several protocols use a command named "STARTTLS" for this purpose. It is a form of opportunistic encryption and is primarily intended as a countermeasure to passive monitoring.

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone. HSTS is an IETF standards track protocol and is specified in RFC 6797.

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

The Transport Layer Security (TLS) protocol provides the ability to secure communications across or inside networks. This comparison of TLS implementations compares several of the most notable libraries. There are several TLS implementations which are free software and open source.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

QUIC is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google, implemented, and deployed in 2012, announced publicly in 2013 as experimentation broadened, and described at an IETF meeting. QUIC is used by more than half of all connections from the Chrome web browser to Google's servers. Microsoft Edge, Firefox and Safari support it.

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 300 million websites, with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan (U-M), and the Linux Foundation.

<span class="mw-page-title-main">Automatic Certificate Management Environment</span> Communications protocol for automating interactions between certificate authorities and web servers

The Automatic Certificate Management Environment (ACME) protocol is a communications protocol for automating interactions between certificate authorities and their users' servers, allowing the automated deployment of public key infrastructure at very low cost. It was designed by the Internet Security Research Group (ISRG) for their Let's Encrypt service.

DNS over HTTPS (DoH) is a protocol for performing remote Domain Name System (DNS) resolution via the HTTPS protocol. A goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver. By March 2018, Google and the Mozilla Foundation had started testing versions of DNS over HTTPS. In February 2020, Firefox switched to DNS over HTTPS by default for users in the United States.

HTTP/3 is the third major version of the Hypertext Transfer Protocol used to exchange information on the World Wide Web, complementing the widely-deployed HTTP/1.1 and HTTP/2. Unlike previous versions which relied on the well-established TCP, HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP. On 6 June 2022, IETF published HTTP/3 as a Proposed Standard in RFC 9114.

References

  1. ↑ Blake-Wilson, Simon; Nystrom, Magnus; Hopwood, David; Mikkelsen, Jan; Wright, Tim (June 2003). "Server Name ssl_ocsp_responderIndication". Transport Layer Security (TLS) Extensions. IETF. p. 8. sec. 3.1. doi: 10.17487/RFC3546 . ISSN   2070-1721. RFC 3546.
  2. ↑ "What is a Multiple Domain (UCC) SSL Certificate?". GoDaddy.
  3. ↑ "TLS Server Name Indication". Paul's Journal.
  4. ↑ "Web Filter: SNI extension feature and HTTPS blocking". www3.trustwave.com. Retrieved 20 February 2019.
  5. ↑ "Sophos UTM: Understanding Sophos Web Filtering". Sophos Community. Retrieved 20 February 2019.
  6. ↑ Chrisment, Isabelle; Goichot, Antoine; Cholez, Thibault; Shbair, Wazen M. (11 May 2015). "Efficiently Bypassing SNI-based HTTPS Filtering". 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM). pp. 990–995. doi:10.1109/INM.2015.7140423. ISBN   978-1-4799-8241-7. S2CID   14963313.
  7. ↑ "South Korea is Censoring the Internet by Snooping on SNI Traffic". BleepingComputer. Retrieved 18 February 2019.
  8. ↑ "Encrypted chat app Signal circumvents government censorship". Engadget. Retrieved 4 January 2017.
  9. ↑ "Amazon threatens to suspend Signal's AWS account over censorship circumvention". Signal. Retrieved 2 May 2018.
  10. ↑ Rescorla, Eric; Oku, Kazuho; Sullivan, Nick; Wood, Christopher A. (9 October 2023). TLS Encrypted Client Hello (Report). Internet Engineering Task Force.
  11. ↑ Rescorla, Eric; Oku, Kazuho; Sullivan, Nick; Wood, Christopher A. (6 April 2023). "Draft-ietf-TLS-esni-14".
  12. ↑ "ESNI: A Privacy-Protecting Upgrade to HTTPS". EFF DeepLinks Blog. 24 September 2018.
  13. ↑ Claburn, Thomas (17 July 2018). "Don't panic about domain fronting, an SNI fix is getting hacked out". The Register. Retrieved 10 October 2018.
  14. ↑ "Encrypt it or lose it: how encrypted SNI works". The Cloudflare Blog. 24 September 2018. Retrieved 13 May 2019.
  15. ↑ "1667743 - Clean up unused esni code". bugzilla.mozilla.org. Retrieved 7 April 2022.
  16. 1 2 "ESNI -> ECHO · tlswg/draft-ietf-tls-esni". GitHub .
  17. ↑ Eric, Rescorla (18 October 2018). "Encrypted SNI Comes to Firefox Nightly". Mozilla Security Blog. Retrieved 15 June 2020.
  18. ↑ Daniel, Stenberg. "curl-library mailing list archive". curl.haxx.se. Retrieved 15 June 2020.
  19. ↑ Jacobs, Kevin (7 January 2021). "Encrypted Client Hello: the future of ESNI in Firefox". Mozilla Security Blog. Retrieved 9 January 2021.
  20. ↑ "s/ECHO/ECH · tlswg/draft-ietf-tls-esni". GitHub .
  21. ↑ Ghedini, Alessandro (24 September 2018). "Encrypt it or lose it: how encrypted SNI works". The Cloudflare Blog. Retrieved 11 July 2021. this is an extension to TLS version 1.3 and above, and doesn't work with previous versions of the protocol
  22. ↑ "Make ESNI TLS 1.2 compatible · Issue #38 · tlswg/draft-ietf-tls-esni". GitHub. Retrieved 9 August 2020.
  23. ↑ Rescorla, Eric. "TLS Encrypted Client Hello". tlswg.org. Retrieved 24 February 2021. The client ... MUST offer to negotiate TLS 1.3 or above.
  24. ↑ Schwartz, Benjamin M.; Bishop, Mike; Nygren, Erik (11 March 2023). "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)". Internet Engineering Task Force. Retrieved 25 July 2023.
  25. ↑ Schwartz, Benjamin M.; Bishop, Mike; Nygren, Erik (26 September 2023). "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings". Internet Engineering Task Force. Retrieved 1 October 2023.
  26. ↑ Cimpanu, Catalin. "China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI". ZDNet. Retrieved 9 August 2020.
  27. ↑ "Почему Ростелеком блокирует ESNI трафик?". qna.habr.com (in Russian). 11 October 2020. Retrieved 30 October 2020.
  28. ↑ "Russia's Digital Development Ministry wants to ban the latest encryption technologies from the RuNet". Meduza. Retrieved 18 June 2021.
  29. ↑ Cimpanu, Catalin. "Russia wants to ban the use of secure protocols such as TLS 1.3, DoH, DoT, ESNI". ZDNet. Retrieved 18 June 2021.
  30. ↑ Sherman, Justin (25 September 2020). "Russia Is Trying Something New to Isolate Its Internet From the Rest of the World". Slate Magazine. Retrieved 18 June 2021.
  31. ↑ TLS Working Group (26 July 2023). "Minutes IETF117: tls: Wed 20:00". IETF Datatracker. Archived from the original on 2 August 2023. Retrieved 2 August 2023.
  32. ↑ TLS Working Group (26 July 2023). IETF117-TLS-20230726-2000. YouTube (video). San Francisco: Internet Engineering Task Force. Retrieved 2 August 2023.
  33. ↑ Achiel van der Mandele; Alessandro Ghedini; Christopher Wood; Rushil Mehra. "Encrypted Client Hello - the last puzzle piece to privacy". The Cloudflare Blog. Retrieved 1 October 2023.
  34. ↑ "Understand Encrypted Client Hello (ECH) | Firefox Help". support.mozilla.org. Retrieved 4 October 2023.
  35. ↑ "Say (an encrypted) hello to a more private internet. | The Mozilla Blog". blog.mozilla.org. Retrieved 4 October 2023.
  36. ↑ "Encrypted Client Hello (ECH) - Frequently asked questions | Firefox Help". support.mozilla.org. Retrieved 25 November 2023.
  37. ↑ "How to disable TLS Encrypted ClientHello in Google Chrome using PowerShell". Chaser Systems Ltd. 9 October 2023.
  38. ↑ "Feature: TLS Encrypted Client Hello (ECH)". Chrome Platform Status. Google. 12 December 2023. Retrieved 21 February 2024.
  39. ↑ "EdelKey Project". www.edelweb.fr. Retrieved 20 February 2019.
  40. ↑ "OpenSSL CHANGES". Archived from the original on 20 April 2016.
  41. ↑ "Public Git Hosting - alpine.git/Commit".
  42. ↑ "How to improve privacy in Microsoft Edge by enabling Encrypted Client Hello". Neowin. 25 July 2023. Archived from the original on 5 December 2022. Retrieved 25 July 2023.
  43. 1 2 "Developing ECH for OpenSSL (DEfO)". defo.ie. Tolerant Networks Limited. 24 August 2022. Archived from the original on 1 September 2022.
  44. ↑ "Understand Encrypted Client Hello (ECH) | Firefox Help". support.mozilla.org. Retrieved 4 October 2023.
  45. ↑ "curl/docs/ECH.md at cbe7fad20d969626a5c4eb0501a273dfe812bcd3 · curl/curl". GitHub. Retrieved 26 July 2023.
  46. ↑ "curl/docs/ROADMAP.md at 50490c0679fcd0e50bb3a8fbf2d9244845652cf0 · curl/curl". GitHub. Retrieved 26 July 2023.
  47. ↑ "Feature: TLS Encrypted Client Hello (ECH)". Chrome Platform Status. Archived from the original on 28 May 2023. Retrieved 25 July 2023. Safari: No signal
  48. ↑ "Release Notes Version 7.8". Campus@Barracuda. September 2013. Retrieved 5 January 2021.
  49. ↑ "Release Notes Version 5.2". Campus@Barracuda. September 2015. Retrieved 5 January 2021.
  50. ↑ "Bug 765064 – HttpClient in use by Sync and other services doesn't support SNI". Bugzilla@Mozilla. 29 October 2017. Retrieved 9 November 2017.
  51. ↑ "IBM HTTP Server SSL Questions and Answers". IBM . Retrieved 8 March 2011.
  52. ↑ "IHS 8 powered by Apache 2.2.x ?". IBM. 17 October 2013. Archived from the original on 26 December 2015. Retrieved 9 November 2017.
  53. ↑ "#2275 (Support Encrypted Client Hello) – nginx". trac.nginx.org. Retrieved 6 July 2023.
  54. ↑ "Performance improvements". help.hcltechsw.com. Retrieved 6 February 2024.
  55. ↑ "ECH by kazuho · Pull Request #3164 · h2o/h2o". GitHub. Retrieved 6 July 2023.
  56. ↑ "Base Directives - Configure". H2O - the optimized HTTP/2 server. Archived from the original on 29 May 2023. Retrieved 18 July 2023.
  57. ↑ "Update to draft-ietf-tls-esni-13". BoringSSL code repository. Retrieved 6 July 2023.
  58. ↑ "Dell BSAFE Micro Edition Suite 5.0 Release Advisory" . Retrieved 18 October 2022.
  59. ↑ "Support ECH (#595) · Issues · gnutls / GnuTLS · GitLab". GitLab. 27 October 2018. Retrieved 26 July 2023.
  60. ↑ "Support ESNI · Issue #546 · libressl/portable". GitHub. Retrieved 26 July 2023.
  61. ↑ "116168 - TLS server name indication extension support in NSS". bugzilla.mozilla.org. Retrieved 6 July 2023.
  62. ↑ "D101050 Bug 1681585 - Add ECH support to selfserv". phabricator.services.mozilla.com. Retrieved 6 July 2023.
  63. ↑ "Bug 360421 – Implement TLS Server Name Indication for servers". Bugzilla@Mozilla. 11 November 2006. Retrieved 30 October 2012.
  64. ↑ "Support Encrypted Client Hello (formerly known as ESNI) · Issue #7482 · openssl/openssl". GitHub. Retrieved 6 July 2023.
  65. ↑ "[ech] rewrite ESNI to ECH draft 15 by kazuho · Pull Request #437 · h2o/picotls". GitHub. Retrieved 6 July 2023.
  66. ↑ "Support Encrypted ClientHellos (ECH, formerly ESNI) · Issue #199 · rustls/rustls". GitHub. Retrieved 5 February 2024.
  67. ↑ "Encrypted client hello configuration messages and serialization by cpu · Pull Request #1568 · rustls/rustls". GitHub. Retrieved 5 February 2024.
  68. ↑ "Certificate selection for servers is missing · Issue #310 · apple/swift-nio-ssl". GitHub. Retrieved 26 July 2023.
  69. ↑ "Adds support for TLS v1.3 Encrypted Client Hello (ECH) draft-ietf-tls… · wolfSSL/wolfssl@6b6ad38". GitHub. Retrieved 25 July 2023.
  70. ↑ "crypto/tls: implement draft-ietf-tls-esni-13 · cloudflare/go@4c13101". GitHub. Retrieved 25 July 2023.
  71. ↑ "src/tls.c · master · Hugo Leisink / Hiawatha web server · GitLab". GitLab. 5 April 2023. Retrieved 26 July 2023.
  72. ↑ "HAProxy 1.5 changelog" . Retrieved 28 December 2020.
  73. ↑ "ECH (Encrypted client hello) support · Issue #1924 · haproxy/haproxy". GitHub. Retrieved 26 July 2023.
  74. ↑ "OpenBSD 6.1 What's New" . Retrieved 13 June 2021.
  75. ↑ "src/lib/libtls/tls.c at master · openbsd/src". GitHub. Retrieved 26 July 2023.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.