HTTPS:修订间差异
Created page with "Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL. Category:Network Category:RFC Category:Protocol Category:HTTP" |
|||
(未显示同一用户的14个中间版本) | |||
第1行: | 第1行: | ||
Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). | Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). | ||
The protocol is therefore also referred to as HTTP over [[TLS]], or HTTP over [[SSL]]. | The protocol is therefore also referred to as HTTP over [[TLS]], or HTTP over [[SSL]]. | ||
= Implemention = | |||
HTTP/1.0 : | |||
[[Image:http-request-over-tcp-tls.png|400px]]<ref>https://blog.cloudflare.com/http3-the-past-present-and-future</ref> | |||
HTTP/3 | |||
[[Image:http-request-over-quic.png|400px]] | |||
= HTTP vs HTTPS = | |||
an unencrypted HTTP request reveals not just the body of the request, but the full URL, query string, and various HTTP headers about the client and request: | |||
[[Image:With-http-headers.png|600px|border]] | |||
An encrypted HTTPS request protects most things<ref>https://https.cio.gov/faq/</ref>: | |||
[[Image:With-https-headers.png|600px|border]] | |||
== What information does HTTPS not protect? == | |||
While HTTPS encrypts the entire HTTP request and response, the DNS resolution and connection setup can reveal other information, such as the full domain or subdomain and the originating IP address, as shown above. | |||
Additionally, attackers can still analyze encrypted HTTPS traffic for “side channel” information. This can include the time spent on site, or the relative size of user input. | |||
The domain name is not protected, this is primarily to support Server Name Indication ([[SNI]]), a TLS extension that allows multiple hostnames to be served over HTTPS from one IP address. | |||
== How difficult is it to attack an HTTPS connection?== | |||
Attacks on HTTPS connections generally fall into 3 categories: | |||
* Compromising the quality of the HTTPS connection, through cryptanalysis or other protocol weaknesses. | |||
* Compromising the client computer, such as by installing a malicious root certificate into the system or browser trust store. | |||
* Obtaining a “rogue” certificate trusted by major browsers, generally by manipulating or compromising a certificate authority. | |||
These are all possible, but for most attackers they are very difficult and require significant expense. Importantly, they are all targeted attacks, and are not feasible to execute against any user connecting to any website. | |||
By contrast, plain HTTP connections can be easily intercepted and modified by anyone involved in the network connection, and so attacks can be carried out at large scale and at low cost. | |||
== HTTPs and HTTP/2 == | |||
While [[HTTP/2]] does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections. | |||
This means that in practice, '''the major performance benefits of HTTP/2 first require the use of HTTPS'''. | |||
== Performance == | |||
[[Image:http vs https.png|600px]]<ref>https://www.httpvshttps.com/</ref> | |||
[[Image:http vs https vs http2.png|600px]]<ref>https://www.tunetheweb.com/performance-test-360/</ref> | |||
== See also == | |||
* [https://http2.github.io/faq/| HTTP2 FAQ] | |||
* [https://tools.ietf.org/html/rfc7540| RFC7540: Hypertext Transfer Protocol Version 2 (HTTP/2)] | |||
2024年1月24日 (三) 08:10的最新版本
Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.
Implemention
HTTP/1.0 :
HTTP/3
HTTP vs HTTPS
an unencrypted HTTP request reveals not just the body of the request, but the full URL, query string, and various HTTP headers about the client and request:
An encrypted HTTPS request protects most things[2]:
What information does HTTPS not protect?
While HTTPS encrypts the entire HTTP request and response, the DNS resolution and connection setup can reveal other information, such as the full domain or subdomain and the originating IP address, as shown above.
Additionally, attackers can still analyze encrypted HTTPS traffic for “side channel” information. This can include the time spent on site, or the relative size of user input.
The domain name is not protected, this is primarily to support Server Name Indication (SNI), a TLS extension that allows multiple hostnames to be served over HTTPS from one IP address.
How difficult is it to attack an HTTPS connection?
Attacks on HTTPS connections generally fall into 3 categories:
- Compromising the quality of the HTTPS connection, through cryptanalysis or other protocol weaknesses.
- Compromising the client computer, such as by installing a malicious root certificate into the system or browser trust store.
- Obtaining a “rogue” certificate trusted by major browsers, generally by manipulating or compromising a certificate authority.
These are all possible, but for most attackers they are very difficult and require significant expense. Importantly, they are all targeted attacks, and are not feasible to execute against any user connecting to any website.
By contrast, plain HTTP connections can be easily intercepted and modified by anyone involved in the network connection, and so attacks can be carried out at large scale and at low cost.
HTTPs and HTTP/2
While HTTP/2 does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections.
This means that in practice, the major performance benefits of HTTP/2 first require the use of HTTPS.