Examine individual changes

[ 0 => '{{short description|TLS extension for serve multiple HTTPS sites at the same IP address with different certificates}}', 1 => '{{Use dmy dates|date=February 2021}}', 2 => ''''Server Name Indication''' ('''SNI''') is an extension to the Transport Layer Security (TLS) computer networking protocol by which a [[Client (computing)|client]] indicates which [[hostname]] it is attempting to connect to at the start of the handshaking process.<ref name="rfc3546">{{Cite IETF|title=Transport Layer Security (TLS) Extensions|rfc=3546|sectionname=Server Name ssl_ocsp_responderIndication|section=3.1|page=8|last1=Blake-Wilson|first1=Simon|last2=Nystrom|first2=Magnus|last3=Hopwood|first3=David|last4=Mikkelsen|first4=Jan|last5=Wright|first5=Tim|date=June 2003|publisher=[[Internet Engineering Task Force|IETF]]|issn=2070-1721}}</ref> This allows a server to present one of multiple possible [[public key certificate|certificates]] on the same [[IP address]] and [[TCP port]] number and hence allows multiple secure ([[HTTP Secure|HTTPS]]) websites (or any other [[Server (computing)#Purpose|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 [[Shared web hosting service|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.', 3 => '', 4 => '==Background of the problem==', 5 => 'Prior to SNI, when making a TLS connection, the client had no way to specify which site it is trying to connect to. Hence, if one physical server hosts multiple sites, 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.', 6 => '', 7 => '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<ref>{{cite web |url=https://www.godaddy.com/help/what-is-a-multiple-domain-ucc-ssl-certificate-3908 |title=What is a Multiple Domain (UCC) SSL Certificate? |publisher=[[GoDaddy]] }}</ref> in a single certificate. Such "unified communications certificates" must be reissued every time the list of domains changes.', 8 => '', 9 => '[[Virtual hosting#Name-based|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 [[list of HTTP header fields#Requests|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.', 10 => '', 11 => '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 address exhaustion|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.', 12 => '', 13 => '== Technical principles ==', 14 => 'SNI addresses this issue by having the client send the name of the virtual domain as part of the TLS negotiation's ''ClientHello'' message.<ref name="Paul's Journal">{{cite web', 15 => ' | url = http://journal.paul.querna.org/articles/2005/04/24/tls-server-name-indication/', 16 => ' | work = Paul's Journal', 17 => ' | title = TLS Server Name Indication', 18 => '}}</ref> 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.', 19 => '', 20 => 'SNI was added to the [[IETF]]'s [[Request for Comments|Internet RFCs]] in June 2003 through RFC 3546, ''Transport Layer Security (TLS) Extensions''. The latest version of the standard is RFC 6066.', 21 => '', 22 => '== Security implications ==', 23 => '', 24 => '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<ref>{{Cite web|url=https://www3.trustwave.com/software/8e6/hlp/r3000/files/1system_filter.html|title=Web Filter: SNI extension feature and HTTPS blocking|website=www3.trustwave.com|access-date=2019-02-20}}</ref><ref>{{Cite web|url=https://community.sophos.com/kb/en-us/115865|title=Sophos UTM: Understanding Sophos Web Filtering|website=Sophos Community|access-date=2019-02-20}}</ref><ref>{{Cite book|last1=Chrisment|first1=Isabelle|last2=Goichot|first2=Antoine|last3=Cholez|first3=Thibault|last4=Shbair|first4=Wazen M.|title=2015 IFIP/IEEE International Symposium on Integrated Network Management (IM)|date=2015-05-11|chapter=Efficiently Bypassing SNI-based HTTPS Filtering|chapter-url=https://hal.inria.fr/hal-01202712/document|pages=990–995|doi=10.1109/INM.2015.7140423|isbn=978-1-4799-8241-7|s2cid=14963313}}</ref> and governments to implement censorship.<ref>{{Cite web|url=https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/|title=South Korea is Censoring the Internet by Snooping on SNI Traffic|website=BleepingComputer|access-date=2019-02-18}}</ref> Presently, there are multiple technologies attempting to hide Server Name Indication.', 25 => '', 26 => '=== Domain fronting ===', 27 => '{{Main|Domain fronting}}', 28 => '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,<ref>{{Cite web|url=https://www.engadget.com/2016/12/21/signal-egypt-uae-censorship-block-domain-fronting/|title=Encrypted chat app Signal circumvents government censorship|website=Engadget|access-date=2017-01-04}}</ref> 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.<ref>{{Cite web|url=https://signal.org/blog/looking-back-on-the-front/|title= Amazon threatens to suspend Signal's AWS account over censorship circumvention|website=Signal|access-date=2018-05-02}}</ref>', 29 => '', 30 => '=== Encrypted Client Hello ===', 31 => ''''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. 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 [[Content delivery network|CDNs]] known to browser vendors in advance.', 32 => '', 33 => 'The initial 2018 version of this extension was called '''Encrypted SNI''' ('''ESNI''')<ref>{{cite web | url=https://tools.ietf.org/html/draft-ietf-tls-esni | title=Draft-ietf-TLS-esni-14 }}</ref> and its implementations were rolled out in an "experimental" fashion to address this risk of domain eavesdropping.<ref name="EFF ESNI acticle">', 34 => '{{cite web|title=ESNI: A Privacy-Protecting Upgrade to HTTPS|url=https://www.eff.org/deeplinks/2018/09/esni-privacy-protecting-upgrade-https|work=EFF DeepLinks Blog|date=24 September 2018}}</ref><ref>{{cite news|last1=Claburn|first1=Thomas|date=17 July 2018|title=Don't panic about domain fronting, an SNI fix is getting hacked out|work=The Register|url=https://www.theregister.co.uk/2018/07/17/encrypted_server_names/|access-date=10 October 2018}}</ref><ref>{{Cite web|date=2018-09-24|title=Encrypt it or lose it: how encrypted SNI works|url=https://blog.cloudflare.com/encrypted-sni/|access-date=2019-05-13|website=The Cloudflare Blog}}</ref> Firefox 85 removed support for ESNI.<ref>{{Cite web |title=1667743 - Clean up unused esni code |url=https://bugzilla.mozilla.org/show_bug.cgi?id=1667743 |access-date=2022-04-07 |website=bugzilla.mozilla.org |language=en}}</ref> In contrast to ECH, Encrypted SNI encrypted just the SNI rather than the whole Client Hello.<ref name=":1" /> Opt-in support for this version was incorporated into Firefox in October 2018<ref>{{cite web|last1=Eric|first1=Rescorla|title=Encrypted SNI Comes to Firefox Nightly|url=https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/|access-date=15 June 2020|website=Mozilla Security Blog}}</ref> and required enabling DNS-over-HTTPS.<ref>{{cite web|last1=Daniel|first1=Stenberg|title=curl-library mailing list archive|url=https://curl.haxx.se/mail/lib-2019-03/0000.html|access-date=15 June 2020|website=curl.haxx.se}}</ref>', 35 => '', 36 => '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.<ref>{{Cite web|last=Jacobs|first=Kevin|title=Encrypted Client Hello: the future of ESNI in Firefox|url=https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox|access-date=2021-01-09|website=Mozilla Security Blog}}</ref> The short name was ECHO in March 2020<ref name=":1">{{cite web|title=ESNI -> ECHO · tlswg/draft-ietf-tls-esni|website=[[GitHub]]|url=https://github.com/tlswg/draft-ietf-tls-esni/pull/207}}</ref> and changed to ECH in May 2020.<ref>{{cite web|title=s/ECHO/ECH · tlswg/draft-ietf-tls-esni|website=[[GitHub]]|url=https://github.com/tlswg/draft-ietf-tls-esni/pull/236}}</ref>', 37 => '', 38 => 'Both ESNI and ECH are compatible only with TLS 1.3 because they rely on KeyShareEntry which was first defined in TLS 1.3.<ref>{{Cite web|last=Ghedini|first=Alessandro|date=2018-09-24|title=Encrypt it or lose it: how encrypted SNI works|url=https://blog.cloudflare.com/encrypted-sni/|url-status=live|access-date=2021-07-11|website=The Cloudflare Blog|language=en|quote=this is an extension to TLS version 1.3 and above, and doesn’t work with previous versions of the protocol}}</ref><ref>{{Cite web|title=Make ESNI TLS 1.2 compatible · Issue #38 · tlswg/draft-ietf-tls-esni|url=https://github.com/tlswg/draft-ietf-tls-esni/issues/38|access-date=2020-08-09|website=GitHub}}</ref> Also, to use ECH, the client must not propose TLS versions below 1.3.<ref>{{Cite web|last=Rescorla|first=Eric|title=TLS Encrypted Client Hello|url=https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html|url-status=live|access-date=2021-02-24|website=tlswg.org|language=en|quote=The client ... MUST offer to negotiate TLS 1.3 or above.}}</ref>', 39 => '', 40 => 'In August 2020, the [[Internet censorship in China|Great Firewall of China]] started blocking ESNI traffic, while still allowing ECH traffic.<ref>{{Cite web|last=Cimpanu|first=Catalin|title=China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI|url=https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/|access-date=2020-08-09|website=ZDNet}}</ref>', 41 => '', 42 => 'In October 2020, Russian ISP [[Rostelecom]] and its mobile operator [[Tele2 Russia|Tele2]] started blocking ESNI traffic.<ref>{{Cite web|title=Почему Ростелеком блокирует ESNI трафик?', 43 => '|url=https://qna.habr.com/q/862669|language=ru|date=11 October 2020|access-date=30 October 2020|website=qna.habr.com}}</ref> 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.<ref>{{Cite web|title=Russia's Digital Development Ministry wants to ban the latest encryption technologies from the RuNet|url=https://meduza.io/en/feature/2020/09/22/russia-s-digital-development-ministry-wants-to-ban-the-latest-encryption-technologies-from-the-runet|access-date=2021-06-18|website=Meduza|language=en}}</ref><ref>{{Cite web|last=Cimpanu|first=Catalin|title=Russia wants to ban the use of secure protocols such as TLS 1.3, DoH, DoT, ESNI|url=https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/|access-date=2021-06-18|website=ZDNet|language=en}}</ref><ref>{{Cite web|last=Sherman|first=Justin|date=2020-09-25|title=Russia Is Trying Something New to Isolate Its Internet From the Rest of the World|url=https://slate.com/technology/2020/09/russia-internet-encryption-protocol-ban.html|access-date=2021-06-18|website=Slate Magazine|language=en}}</ref>', 44 => '', 45 => '== Implementation ==', 46 => 'In 2004, a patch for adding TLS/SNI into [[OpenSSL]] was created by the EdelKey project.<ref>{{Cite web|url=http://www.edelweb.fr/EdelKey/files/|title=EdelKey Project|website=www.edelweb.fr|access-date=2019-02-20}}</ref> 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<ref name="openssl-098-changelog">{{cite web |url=//www.openssl.org/news/cl098.txt |title=OpenSSL CHANGES |url-status=dead |archive-url=https://web.archive.org/web/20160420213610/https://www.openssl.org/news/cl098.txt |archive-date=20 April 2016}}</ref>).', 47 => '', 48 => '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|date=March 2021}}', 49 => '', 50 => '== Support ==', 51 => '', 52 => '{| class="wikitable sortable mw-collapsible"', 53 => '|+Support for SNI', 54 => '! Software !! Type !! Supported !! Notes !! Supported since', 55 => '|-', 56 => '| [[Alpine (email client)]] || [[IMAP]] [[email client]] || {{yes}} || Since version 2.22<ref>{{Cite web|url=https://repo.or.cz/alpine.git/commit/08fcd1b86979b422eb586e56459d6fe15333e500|title = Public Git Hosting - alpine.git/Commit}}</ref> || 2019-02-18', 57 => '|-', 58 => '| [[BSAFE]] Micro Edition Suite || Library || {{yes}} || || Version 5.0<ref>{{cite web|url=https://www.dell.com/support/kbdoc/000204231/dell-bsafe-micro-edition-suite-5-0-release-advisory|title=Dell BSAFE Micro Edition Suite 5.0 Release Advisory|accessdate=2022-10-18}}</ref>', 59 => '|-', 60 => '| [[Internet Explorer]] || Web browser || {{yes}} || Since version 7 on Vista (not supported on XP) || 2006', 61 => '|-', 62 => '| [[Microsoft Edge|Edge]] || Web browser || {{yes}} || All versions || ', 63 => '|-', 64 => '| [[Mozilla Firefox]] || Web browser || {{yes}} || Since version 2.0 || 2006', 65 => '|-', 66 => '| [[cURL]] || Command-line tool and library || {{yes}} || Since version 7.18.1 || 2008', 67 => '|-', 68 => '| [[Safari (web browser)|Safari]] || Web browser || {{yes}} || Not supported on [[Windows XP]] ||', 69 => '|-', 70 => '| [[Google Chrome]] || Web browser || {{yes}} || || 2010', 71 => '|-', 72 => '| [[BlackBerry 10]] || Web browser || {{yes}} || Supported in all BB10 releases || 2013', 73 => '|-', 74 => '| [[BlackBerry OS]] ', 75 => '|', 76 => '|', 77 => '| ||', 78 => '|-', 79 => '| [[Barracuda Networks|Barracuda]] [[Web application firewall|WAF]] || Reverse Proxy || {{yes}} || Supported since version 7.8<ref>{{cite web |url=https://campus.barracuda.com/product/webapplicationfirewall/doc/30114103/release-notes-version-7-8/ |title=Release Notes Version 7.8 |work=Campus@Barracuda |date=September 2013 |access-date=5 January 2021 }}</ref> || 2013', 80 => '|-', 81 => '| [[Barracuda Networks|Barracuda]] [[Application delivery controller|ADC]] || Load balancer || {{yes}} || Frontend support since version 4.0 and backend support from v5.2<ref>{{cite web |url=https://campus.barracuda.com/product/loadbalanceradc/doc/42044491/release-notes-version-5-2-0-004 |title=Release Notes Version 5.2 |work=Campus@Barracuda |date=September 2015 |access-date=5 January 2021 }}</ref> || Frontend 2013 / Backend 2015', 82 => '|-', 83 => '| [[Windows Mobile]] || Web browser || || Some time after 6.5 ||', 84 => '|-', 85 => '| [[Android (operating system)|Android]] default browser || Web browser || {{yes}} || Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones || 2011', 86 => '|-', 87 => '| [[Firefox for Android]] || Web browser || {{yes}} || Supported for browsing. Sync and other services support SNI only since version 86.<ref>{{cite web |url=https://bugzilla.mozilla.org/show_bug.cgi?id=765064 |title=Bug 765064 – HttpClient in use by Sync and other services doesn't support SNI |work=Bugzilla@Mozilla |date=29 October 2017 |access-date=9 November 2017 }}</ref> ||', 88 => '|-', 89 => '| [[wget]] || Command-line tool || {{yes}} || Since version 1.14 || 2012', 90 => '|-', 91 => '| [[Nokia Browser for Symbian]] || Web browser || {{no}} || ||', 92 => '|-', 93 => '| [[Opera Mobile|Opera Mobile for Symbian]] || Web browser || {{no}} || Not supported on Series60 ||', 94 => '|-', 95 => '| [[Dillo]] || Web browser || {{yes}} || Since version 3.1 || 2016', 96 => '|-', 97 => '| [[IBM HTTP Server]] || Web server || {{yes}} || Since version 9.0.0<ref>{{cite web |url=http://publib.boulder.ibm.com/httpserv/ihsdiag/ssl_questions.html#SNI |title=IBM HTTP Server SSL Questions and Answers |publisher=[[IBM]] |access-date=8 March 2011 }}</ref><ref>{{cite web |url=http://www.ibm.com/developerworks/forums/thread.jspa?threadID=412433&tstart=0 |title=IHS 8 powered by Apache 2.2.x ? |publisher=[[IBM]] |archive-url=https://web.archive.org/web/20151226083713/https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014769679 |url-status=dead |date=17 October 2013 |archive-date=26 December 2015 |access-date=9 November 2017 }}</ref> ||', 98 => '|-', 99 => '| [[Apache Tomcat]] || Web server || {{yes}} || Not supported before 8.5 (backport from 9) ||', 100 => '|-', 101 => '| [[Apache HTTP Server]] || Web server || {{yes}} || Since version 2.2.12 || 2009', 102 => '|-', 103 => '| [[Microsoft IIS]] || Web server || {{yes}} || Since version 8 (part of [[Windows Server 2012]]) || 2012', 104 => '|-', 105 => '| [[nginx]] || Web server || {{yes}} || Since version 0.5.23 || 2007', 106 => '|-', 107 => '| [[Jetty (web server)|Jetty]] || Web server || {{yes}} || Since version 9.3.0 || 2015', 108 => '|-', 109 => '| [[HCL Notes|HCL Domino]] || Web server || {{yes}} || Since version 11.0.1 || 2020', 110 => '|-', 111 => '| [[Qt (framework)|Qt]] || Library || {{yes}} || Since version 4.8 || 2011', 112 => '|-', 113 => '| Mozilla [[Network Security Services|NSS]] server side || Library || {{no}} ||<ref>{{cite web |url=https://bugzilla.mozilla.org/show_bug.cgi?id=360421 |title=Bug 360421 – Implement TLS Server Name Indication for servers |work=Bugzilla@Mozilla |date=11 November 2006 |access-date=30 October 2012 }}</ref> ||', 114 => '|-', 115 => '| [[4th Dimension (software)|4th Dimension]] || Library || {{no}} || Not supported in 15.2 or earlier ||', 116 => '|-', 117 => '| [[Java (software platform)|Java]] || Library || {{yes}} || Since version 1.7 || 2011', 118 => '|-', 119 => '| [[Adobe ColdFusion|ColdFusion]] / [[Lucee]] || Library || {{yes}} || ColdFusion since Version 10 Update 18, 11 Update 7, Lucee since Version 4.5.1.019, Version 5.0.0.50 || 2015', 120 => '|-', 121 => '| [[Erlang (programming language)|Erlang]] || Library || {{yes}} || Since version r17 || 2013', 122 => '|-', 123 => '| [[Go (programming language)|Go]] || Library || {{yes}} || Since version 1.4 || 2011', 124 => '|-', 125 => '| [[Perl]] || Library || {{yes}} || Since <code>Net::SSLeay</code> version 1.50 and <code>IO::Socket::SSL</code> version 1.56 || 2012', 126 => '|-', 127 => '| [[PHP]] || Library || {{yes}} || Since version 5.3 || 2014', 128 => '|-', 129 => '| [[Python (programming language)|Python]] || Library || {{yes}} || Supported in 2.x from 2.7.9 and 3.x from 3.2 (in <code>ssl</code>, <code>urllib[2]</code> and <code>httplib</code> modules) || 2011 for Python 3.x and 2014 for Python 2.x', 130 => '|-', 131 => '| [[Ruby (programming language)|Ruby]] || Library || {{yes}} || Since version 2.0 (in <code>net/http</code>) || 2011', 132 => '|-', 133 => '| [[Hiawatha (web server)|Hiawatha]] || Web server || {{yes}} || Since version 8.6 || 2012', 134 => '|-', 135 => '| [[lighttpd]] || Web server || {{yes}} || Since version 1.4.24 || 2009', 136 => '|-', 137 => '| [[HAProxy]] || Load balancer || {{yes}} || Since version 1.5-dev12<ref>{{cite web |url=https://www.haproxy.org/download/1.5/src/CHANGELOG |title=HAProxy 1.5 changelog |access-date=28 December 2020 }}</ref> || 2012', 138 => '|-', 139 => '| [[OpenBSD]] httpd || Web server || {{yes}} || Since OpenBSD version 6.1<ref>{{cite web |url=https://www.openbsd.org/61.html#new |title=OpenBSD 6.1 What's New |access-date=13 June 2021 }}</ref> || 2017-04-11', 140 => '|}', 141 => '', 142 => '== References ==', 143 => '{{Reflist}}', 144 => '', 145 => '== External links ==', 146 => '* {{IETF RFC|6066|link=no}} (obsoletes {{IETF RFC|4366|link=no}}, which obsoleted {{IETF RFC|3546|link=no}})', 147 => '', 148 => '{{SSL/TLS}}', 149 => '', 150 => '[[Category:Internet protocols]]', 151 => '[[Category:Secure communication]]', 152 => '[[Category:Web hosting]]', 153 => '[[Category:Transport Layer Security]]' ]