Editing HTTPS (section)

===Limitations===
SSL (Secure Sockets Layer) and TLS (Transport Layer Security) encryption can be configured in two modes: ''simple'' and ''mutual''. In simple mode, authentication is only performed by the server. The mutual version requires the user to install a personal [[client certificate]] in the web browser for user authentication.<ref>{{cite web |url=https://support.google.com/chrome/a/answer/6080885?hl=en |title=Manage client certificates on Chrome devices – Chrome for business and education Help |website=support.google.com |access-date=2018-10-20 |archive-url=https://web.archive.org/web/20190209055127/https://support.google.com/chrome/a/answer/6080885?hl=en |archive-date=2019-02-09 |url-status=live }}</ref> In either case, the level of protection depends on the correctness of the [[implementation]] of the software and the [[cipher|cryptographic algorithms]] in use.{{fact|date=April 2024}}

SSL/TLS does not prevent the indexing of the site by a [[web crawler]], and in some cases the [[Uniform resource identifier|URI]] of the encrypted resource can be inferred by knowing only the intercepted request/response size.<ref>{{cite web |url=https://www.exploit-db.com/docs/english/13026-the-pirate-bay-un-ssl.pdf |title=The Pirate Bay un-SSL |last=Pusep |first=Stanislaw |date=2008-07-31 |access-date=2018-10-20 |archive-url=https://web.archive.org/web/20180620001518/https://www.exploit-db.com/docs/english/13026-the-pirate-bay-un-ssl.pdf |archive-date=2018-06-20 |url-status=live }}</ref> This allows an attacker to have access to the [[plaintext]] (the publicly available static content), and the [[ciphertext|encrypted text]] (the encrypted version of the static content), permitting a [[Chosen-ciphertext attack|cryptographic attack]].{{fact|date=April 2024}}

Because [[Transport Layer Security|TLS]] operates at a protocol level below that of HTTP and has no knowledge of the higher-level protocols, TLS servers can only strictly present one certificate for a particular address and port combination.<ref>{{cite web |url=https://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts |title=SSL/TLS Strong Encryption: FAQ |work=apache.org |access-date=2018-10-20 |archive-url=https://web.archive.org/web/20181019105423/http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts |archive-date=2018-10-19 |url-status=live }}</ref> In the past, this meant that it was not feasible to use [[Virtual hosting#Name-based|name-based virtual hosting]] with HTTPS. A solution called [[Server Name Indication]] (SNI) exists, which sends the hostname to the server before encrypting the connection, although older browsers do not support this extension. Support for SNI is available since [[Firefox]] 2, [[Opera (web browser)|Opera]] 8, [[Safari (web browser)|Apple Safari]] 2.1, [[Google Chrome]] 6, and [[Internet Explorer 7]] on [[Windows Vista]].<ref>{{cite web |url=https://blogs.msdn.microsoft.com/ie/2005/10/22/upcoming-https-improvements-in-internet-explorer-7-beta-2/ |title=Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2 |last=Lawrence |first=Eric |publisher=[[Microsoft]] |date=2005-10-22 |access-date=2018-10-20 |archive-url=https://web.archive.org/web/20180920113838/https://blogs.msdn.microsoft.com/ie/2005/10/22/upcoming-https-improvements-in-internet-explorer-7-beta-2/ |archive-date=2018-09-20 |url-status=live }}</ref><ref>{{cite web |url=https://blog.ebrahim.org/2006/02/21/server-name-indication-sni/ |title=Server Name Indication (SNI) |work=inside aebrahim's head |date=2006-02-21 |access-date=2018-10-20 |archive-url=https://web.archive.org/web/20180810173628/https://blog.ebrahim.org/2006/02/21/server-name-indication-sni/ |archive-date=10 August 2018 |url-status=live }}</ref><ref>{{cite web |url=https://bugzilla.mozilla.org/show_bug.cgi?id=116169 |title=Browser support for TLS server name indication |access-date=2018-10-20 |last=Pierre |first=Julien |date=2001-12-19 |work=Bugzilla |publisher=Mozilla Foundation |archive-url=https://web.archive.org/web/20181008070112/https://bugzilla.mozilla.org/show_bug.cgi?id=116169 |archive-date=2018-10-08 |url-status=live }}</ref>

A sophisticated type of [[man-in-the-middle attack]] called SSL stripping was presented at the 2009 [[Black Hat Briefings|Blackhat Conference]]. This type of attack defeats the security provided by HTTPS by changing the {{code|https:}} link into an {{code|http:}} link, taking advantage of the fact that few Internet users actually type "https" into their browser interface: they get to a secure site by clicking on a link, and thus are fooled into thinking that they are using HTTPS when in fact they are using HTTP. The attacker then communicates in clear with the client.<ref>{{cite web |url=https://moxie.org/software/sslstrip/index.html |title=sslstrip 0.9 |access-date=20 October 2018 |archive-url=https://web.archive.org/web/20180620042059/https://moxie.org/software/sslstrip/index.html |archive-date=20 June 2018 |url-status=live }}</ref> This prompted the development of a countermeasure in HTTP called [[HTTP Strict Transport Security]].{{fact|date=April 2024}}

HTTPS has been shown to be vulnerable to a range of [[traffic analysis]] attacks. Traffic analysis attacks are a type of [[side-channel attack]] that relies on variations in the timing and size of traffic in order to infer properties about the encrypted traffic itself. Traffic analysis is possible because SSL/TLS encryption changes the contents of traffic, but has minimal impact on the size and timing of traffic. In May 2010, a research paper by researchers from [[Microsoft Research]] and [[Indiana University Bloomington|Indiana University]] discovered that detailed sensitive user data can be inferred from side channels such as packet sizes. The researchers found that, despite HTTPS protection in several high-profile, top-of-the-line web applications in healthcare, taxation, investment, and web search, an eavesdropper could infer the illnesses/medications/surgeries of the user, his/her family income, and investment secrets.<ref>{{cite journal |url=https://www.microsoft.com/en-us/research/publication/side-channel-leaks-in-web-applications-a-reality-today-a-challenge-tomorrow/ |title=Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow |journal=Microsoft Research |publisher=[[Institute of Electrical and Electronics Engineers|IEEE]] Symposium on Security & Privacy 2010 |date=2010-05-20 |author1=Shuo Chen |author2=Rui Wang |author3=XiaoFeng Wang |author4=Kehuan Zhang |access-date=2018-10-20 |archive-url=https://web.archive.org/web/20180722120329/https://www.microsoft.com/en-us/research/publication/side-channel-leaks-in-web-applications-a-reality-today-a-challenge-tomorrow/ |archive-date=22 July 2018 |url-status=live }}</ref>

The fact that most modern websites, including Google, Yahoo!, and Amazon, use HTTPS causes problems for many users trying to access public Wi-Fi hot spots, because a [[captive portal]] Wi-Fi hot spot login page fails to load if the user tries to open an HTTPS resource.<ref>{{cite web |first=Matthew |last=Guaay |url=https://zapier.com/blog/open-wifi-login-page/ |title=How to Force a Public Wi-Fi Network Login Page to Open |date=2017-09-21 |access-date=2018-10-20 |archive-url=https://web.archive.org/web/20180810143254/https://zapier.com/blog/open-wifi-login-page/ |archive-date=2018-08-10 |url-status=live }}</ref> Several websites, such as NeverSSL,<ref name="neverssl">{{cite web |url=http://neverssl.com |title=NeverSSL }}</ref> guarantee that they will always remain accessible by HTTP.<ref>{{cite web |url=http://neverssl.com/ |title=NeverSSL |access-date=2018-10-20 |archive-url=https://web.archive.org/web/20180901224536/http://neverssl.com/ |archive-date=2018-09-01 |url-status=live }}</ref>