Server Name Indication

From HandWiki
Revision as of 22:42, 6 February 2024 by Gametune (talk | contribs) (link)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Short description: TLS extension for serve multiple HTTPS sites at the same IP address with different certificates

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

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

Main page: Social: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]

Implementation

In 2004, a patch for adding TLS/SNI into OpenSSL was created by the EdelKey project.[37] 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[38]). 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 Support ECH Support
Software Type Supported Notes Since Supported Notes
Alpine (email client) IMAP email client Yes Since version 2.22[39] 2019-02-18
Internet Explorer Web browser Yes Since version 7 on Vista (not supported on XP) 2006 No
Edge Web browser Yes All versions Yes Since v105 behind flag[40]
Mozilla Firefox Web browser Yes Since version 2.0 2006 Yes Introduced in v85 behind flag.[41] Enabled by default in v118 when DoH is enabled.[42]
cURL Command-line tool and library Yes Since version 7.18.1 2008 Partial [43][44]
Safari Web browser Yes Not supported on Windows XP No [45]
Google Chrome Web browser Yes 2010 Yes Since v105 behind flag.[41]
BlackBerry 10 Web browser Yes Supported in all BB10 releases 2013 No
BlackBerry OS No
Barracuda WAF Reverse Proxy Yes Supported since version 7.8[46] 2013
Barracuda ADC Load balancer Yes Frontend support since version 4.0 and backend support from v5.2[47] Frontend 2013 / Backend 2015
Windows Mobile Web browser Some time after 6.5 No
Android browser
(discontinued in Android 4.2)
Web browser Yes Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones 2011 No
Firefox for Android Web browser Yes Supported for browsing. Sync and other services support SNI only since version 86.[48] Only on Firefox Beta and Nightly is possible to enable DoH by a flag.
wget Command-line tool Yes Since version 1.14 2012
Nokia Browser for Symbian Web browser No No
Opera Mobile for Symbian Web browser No Not supported on Series60 No
Dillo Web browser Yes Since version 3.1 2016
IBM HTTP Server Web server Yes Since version 9.0.0[49][50]
Apache Tomcat Web server Yes Not supported before 8.5 (backport from 9)
Apache HTTP Server Web server Yes Since version 2.2.12 2009
Microsoft IIS Web server Yes Since version 8 (part of Windows Server 2012) 2012
nginx Web server Yes Since version 0.5.23 2007 No [51]
Jetty Web server Yes Since version 9.3.0 2015
HCL Domino Web server Yes Since version 11.0.1 2020
H2O Web server Yes Yes [52][53]
BoringSSL Library Yes Yes [54]
BSAFE Micro Edition Suite Library Yes Version 5.0[55]
GnuTLS Library Yes No Work in progress as July 2023.[56]
LibreSSL Library Yes No [57]
Mbed TLS Library Yes No
Mozilla NSS client side Library Yes Since version 3.11.1[58] 2006 Yes [59]
Mozilla NSS server side Library No [60] No
OpenSSL Library Yes No [61]
Picotls Library Yes Yes [62]
Rustls Library Yes No Work in progress as July 2023.[63][64]
SwiftNIO SSL Library Yes No [65]
wolfSSL Library Yes Yes Since v5.6.3[66]
4th Dimension Standard library No Not supported in 15.2 or earlier No
ColdFusion / Lucee Standard library Yes ColdFusion since Version 10 Update 18, 11 Update 7, Lucee since Version 4.5.1.019, Version 5.0.0.50 2015
Erlang Standard library Yes Since version r17 2013
Go Standard library Yes Since version 1.4 2011 Cloudflare/go fork provides support[67]
Java Standard library Yes Since version 1.7 2011
Perl Standard library Yes Since Net::SSLeay version 1.50 and IO::Socket::SSL version 1.56 2012
PHP Standard library Yes Since version 5.3 2014
Python Standard library Yes Supported 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 library Yes Since version 4.8 2011
Ruby Standard library Yes Since version 2.0 (in net/http) 2011
Hiawatha Web server Yes Since version 8.6 2012 No Depends on Mbed TLS.[68]
lighttpd Web server Yes Since version 1.4.24 2009 No
HAProxy Load balancer Yes Since version 1.5-dev12[69] 2012 No [70]
OpenBSD httpd Web server Yes Since OpenBSD version 6.1[71] 2017-04-11 No Depends on OpenSSL.[72]

References

  1. Blake-Wilson, Simon; Nystrom, Magnus; Hopwood, David; Mikkelsen, Jan; Wright, Tim (June 2003), Transport Layer Security (TLS) Extensions, IETF, p. 8. sec. 3.1, doi:10.17487/RFC3546, RFC 3546, ISSN 2070-1721, https://tools.ietf.org/html/rfc3546 
  2. "What is a Multiple Domain (UCC) SSL Certificate?". GoDaddy. https://www.godaddy.com/help/what-is-a-multiple-domain-ucc-ssl-certificate-3908. 
  3. "TLS Server Name Indication". Paul's Journal. http://journal.paul.querna.org/articles/2005/04/24/tls-server-name-indication/. 
  4. "Web Filter: SNI extension feature and HTTPS blocking". https://www3.trustwave.com/software/8e6/hlp/r3000/files/1system_filter.html. 
  5. "Sophos UTM: Understanding Sophos Web Filtering". https://community.sophos.com/kb/en-us/115865. 
  6. Chrisment, Isabelle; Goichot, Antoine; Cholez, Thibault; Shbair, Wazen M. (2015-05-11). "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. https://hal.inria.fr/hal-01202712/document. 
  7. "South Korea is Censoring the Internet by Snooping on SNI Traffic". https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/. 
  8. "Encrypted chat app Signal circumvents government censorship". https://www.engadget.com/2016/12/21/signal-egypt-uae-censorship-block-domain-fronting/. 
  9. "Amazon threatens to suspend Signal's AWS account over censorship circumvention". https://signal.org/blog/looking-back-on-the-front/. 
  10. Rescorla, Eric; Oku, Kazuho; Sullivan, Nick; Wood, Christopher A. (2023-10-09). TLS Encrypted Client Hello (Report). Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-ietf-tls-esni/. 
  11. Rescorla, Eric; Oku, Kazuho; Sullivan, Nick; Wood, Christopher A. (6 April 2023). "Draft-ietf-TLS-esni-14". https://tools.ietf.org/html/draft-ietf-tls-esni. 
  12. "ESNI: A Privacy-Protecting Upgrade to HTTPS". EFF DeepLinks Blog. 24 September 2018. https://www.eff.org/deeplinks/2018/09/esni-privacy-protecting-upgrade-https. 
  13. Claburn, Thomas (17 July 2018). "Don't panic about domain fronting, an SNI fix is getting hacked out". The Register. https://www.theregister.co.uk/2018/07/17/encrypted_server_names/. 
  14. "Encrypt it or lose it: how encrypted SNI works". 2018-09-24. https://blog.cloudflare.com/encrypted-sni/. 
  15. "1667743 - Clean up unused esni code" (in en). https://bugzilla.mozilla.org/show_bug.cgi?id=1667743. 
  16. 16.0 16.1 "ESNI -> ECHO · tlswg/draft-ietf-tls-esni". https://github.com/tlswg/draft-ietf-tls-esni/pull/207. 
  17. Eric, Rescorla (18 October 2018). "Encrypted SNI Comes to Firefox Nightly". https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/. 
  18. Daniel, Stenberg. "curl-library mailing list archive". https://curl.haxx.se/mail/lib-2019-03/0000.html. 
  19. Jacobs, Kevin (7 January 2021). "Encrypted Client Hello: the future of ESNI in Firefox". https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox. 
  20. "s/ECHO/ECH · tlswg/draft-ietf-tls-esni". https://github.com/tlswg/draft-ietf-tls-esni/pull/236. 
  21. Ghedini, Alessandro (2018-09-24). "Encrypt it or lose it: how encrypted SNI works" (in en). https://blog.cloudflare.com/encrypted-sni/. "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". https://github.com/tlswg/draft-ietf-tls-esni/issues/38. 
  23. Rescorla, Eric. "TLS Encrypted Client Hello" (in en). https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html. "The client ... MUST offer to negotiate TLS 1.3 or above." 
  24. Schwartz, Benjamin M.; Bishop, Mike; Nygren, Erik (2023-03-11). "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)". Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https. 
  25. Schwartz, Benjamin M.; Bishop, Mike; Nygren, Erik (2023-09-26). "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings". Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/. 
  26. Cimpanu, Catalin. "China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI". https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/. 
  27. "Почему Ростелеком блокирует ESNI трафик?" (in ru). 11 October 2020. https://qna.habr.com/q/862669. 
  28. "Russia's Digital Development Ministry wants to ban the latest encryption technologies from the RuNet" (in en). https://meduza.io/en/feature/2020/09/22/russia-s-digital-development-ministry-wants-to-ban-the-latest-encryption-technologies-from-the-runet. 
  29. Cimpanu, Catalin. "Russia wants to ban the use of secure protocols such as TLS 1.3, DoH, DoT, ESNI" (in en). https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/. 
  30. Sherman, Justin (2020-09-25). "Russia Is Trying Something New to Isolate Its Internet From the Rest of the World" (in en). https://slate.com/technology/2020/09/russia-internet-encryption-protocol-ban.html. 
  31. TLS Working Group (July 26, 2023). "Minutes IETF117: tls: Wed 20:00". https://datatracker.ietf.org/doc/minutes-117-tls-202307262000/. 
  32. TLS Working Group (July 26, 2023). IETF117-TLS-20230726-2000. YouTube (video). San Francisco: Internet Engineering Task Force. Retrieved 2023-08-02.
  33. "Encrypted Client Hello - the last puzzle piece to privacy". https://blog.cloudflare.com/announcing-encrypted-client-hello/. 
  34. "Understand Encrypted Client Hello (ECH) | Firefox Help". https://support.mozilla.org/en-US/kb/understand-encrypted-client-hello. 
  35. "Say (an encrypted) hello to a more private internet. | The Mozilla Blog" (in en-US). https://blog.mozilla.org/en/products/firefox/encrypted-hello/. 
  36. "Encrypted Client Hello (ECH) - Frequently asked questions | Firefox Help". https://support.mozilla.org/en-US/kb/faq-encrypted-client-hello#w_can-i-use-ech-without-doh. 
  37. "EdelKey Project". http://www.edelweb.fr/EdelKey/files/. 
  38. "OpenSSL CHANGES". //www.openssl.org/news/cl098.txt. 
  39. "Public Git Hosting - alpine.git/Commit". https://repo.or.cz/alpine.git/commit/08fcd1b86979b422eb586e56459d6fe15333e500. 
  40. "How to improve privacy in Microsoft Edge by enabling Encrypted Client Hello" (in en). 2023-07-25. https://www.neowin.net/guides/how-to-improve-privacy-in-microsoft-edge-by-enabling-encrypted-client-hello/. 
  41. 41.0 41.1 "Developing ECH for OpenSSL (DEfO)" (in en). 2022-08-24. https://defo.ie/. 
  42. "Understand Encrypted Client Hello (ECH) | Firefox Help". https://support.mozilla.org/en-US/kb/understand-encrypted-client-hello. 
  43. "curl/docs/ECH.md at cbe7fad20d969626a5c4eb0501a273dfe812bcd3 · curl/curl" (in en). https://github.com/curl/curl/blob/cbe7fad20d969626a5c4eb0501a273dfe812bcd3/docs/ECH.md. 
  44. "curl/docs/ROADMAP.md at 50490c0679fcd0e50bb3a8fbf2d9244845652cf0 · curl/curl" (in en). https://github.com/curl/curl/blob/50490c0679fcd0e50bb3a8fbf2d9244845652cf0/docs/ROADMAP.md?plain=1#L19. 
  45. "Feature: TLS Encrypted Client Hello (ECH)". https://chromestatus.com/feature/6196703843581952. "Safari: No signal" 
  46. "Release Notes Version 7.8". Campus@Barracuda. September 2013. https://campus.barracuda.com/product/webapplicationfirewall/doc/30114103/release-notes-version-7-8/. 
  47. "Release Notes Version 5.2". Campus@Barracuda. September 2015. https://campus.barracuda.com/product/loadbalanceradc/doc/42044491/release-notes-version-5-2-0-004. 
  48. "Bug 765064 – HttpClient in use by Sync and other services doesn't support SNI". Bugzilla@Mozilla. 29 October 2017. https://bugzilla.mozilla.org/show_bug.cgi?id=765064. 
  49. "IBM HTTP Server SSL Questions and Answers". IBM. https://publib.boulder.ibm.com/httpserv/ihsdiag/ssl_questions.html#SNI. 
  50. "IHS 8 powered by Apache 2.2.x ?". IBM. 17 October 2013. https://www.ibm.com/developerworks/forums/thread.jspa?threadID=412433&tstart=0. 
  51. "#2275 (Support Encrypted Client Hello) – nginx". https://trac.nginx.org/nginx/ticket/2275. 
  52. "ECH by kazuho · Pull Request #3164 · h2o/h2o" (in en). https://github.com/h2o/h2o/pull/3164. 
  53. "Base Directives - Configure". https://h2o.examp1e.net/configure/base_directives.html#ech. 
  54. "Update to draft-ietf-tls-esni-13". https://boringssl-review.googlesource.com/c/boringssl/+/48912. 
  55. "Dell BSAFE Micro Edition Suite 5.0 Release Advisory". https://www.dell.com/support/kbdoc/000204231/dell-bsafe-micro-edition-suite-5-0-release-advisory. Retrieved 2022-10-18. 
  56. "Support ECH (#595) · Issues · gnutls / GnuTLS · GitLab" (in en). 2018-10-27. https://gitlab.com/gnutls/gnutls/-/issues/595. 
  57. "Support ESNI · Issue #546 · libressl/portable" (in en). https://github.com/libressl/portable/issues/546. 
  58. "116168 - TLS server name indication extension support in NSS" (in en). https://bugzilla.mozilla.org/show_bug.cgi?id=116168. 
  59. "D101050 Bug 1681585 - Add ECH support to selfserv.". https://phabricator.services.mozilla.com/D101050. 
  60. "Bug 360421 – Implement TLS Server Name Indication for servers". Bugzilla@Mozilla. 11 November 2006. https://bugzilla.mozilla.org/show_bug.cgi?id=360421. 
  61. "Support Encrypted Client Hello (formerly known as ESNI) · Issue #7482 · openssl/openssl" (in en). https://github.com/openssl/openssl/issues/7482. 
  62. "[ech rewrite ESNI to ECH draft 15 by kazuho · Pull Request #437 · h2o/picotls"] (in en). https://github.com/h2o/picotls/pull/437. 
  63. "ECHConfig implementation · Issue #508 · rustls/rustls" (in en). https://github.com/rustls/rustls/issues/508. 
  64. "WIP: ECH Draft-10 by sayrer · Pull Request #663 · rustls/rustls" (in en). https://github.com/rustls/rustls/pull/663. 
  65. "Certificate selection for servers is missing · Issue #310 · apple/swift-nio-ssl" (in en). https://github.com/apple/swift-nio-ssl/issues/310#issuecomment-941970138. 
  66. "Adds support for TLS v1.3 Encrypted Client Hello (ECH) draft-ietf-tls… · wolfSSL/wolfssl@6b6ad38" (in en). https://github.com/wolfSSL/wolfssl/commit/6b6ad38e4f537c103785c75b5bbf7afd533efa24. 
  67. "crypto/tls: implement draft-ietf-tls-esni-13 · cloudflare/go@4c13101" (in en). https://github.com/cloudflare/go/commit/4c13101ea3bedab232d73791dc1dc5c1d89ec33a. 
  68. "src/tls.c · master · Hugo Leisink / Hiawatha web server · GitLab" (in en). 2023-04-05. https://gitlab.com/hsleisink/hiawatha/-/blob/master/src/tls.c. 
  69. "HAProxy 1.5 changelog". https://www.haproxy.org/download/1.5/src/CHANGELOG. 
  70. "ECH (Encrypted client hello) support · Issue #1924 · haproxy/haproxy" (in en). https://github.com/haproxy/haproxy/issues/1924. 
  71. "OpenBSD 6.1 What's New". https://www.openbsd.org/61.html#new. 
  72. "src/lib/libtls/tls.c at master · openbsd/src" (in en). https://github.com/openbsd/src/blob/master/lib/libtls/tls.c. 

External links