Secure Hypertext Transfer Protocol
| HTTP |
|---|
 |
| Request methods |
| Header fields |
| Response status codes |
| Security access control methods |
| Security vulnerabilities |
Secure Hypertext Transfer Protocol (S-HTTP) is an obsolete alternative to HTTPS for encrypting web communications over the Internet. It was developed by Eric Rescorla and Allan M. Schiffman at Enterprise Integration Technologies in 1994[1] and published in 1999 as RFC 2660. Netscape's dominance of the browser market led to HTTPS becoming the de facto method for securing web communications.
Comparison to HTTP over TLS (HTTPS)
[edit]S-HTTP encrypts only the served page data and submitted data, such as POST fields, while leaving the protocol initiation unchanged. Because of this, S-HTTP could be used concurrently with unsecured HTTP on the same port, with the unencrypted header determining whether the rest of the transmission was encrypted.
In contrast, HTTP over TLS wraps the entire communication within Transport Layer Security (TLS; formerly SSL), so the encryption starts before any protocol data is sent. This creates a name-based virtual hosting "chicken and egg" issue with determining which DNS name was intended for the request.
This means that HTTPS implementations without Server Name Indication (SNI) support require a separate IP address for each DNS name, while HTTPS uses a separate port (usually 443 rather than HTTP's standard 80) and a separate URI scheme (https://).[2] for unambiguous use of encryption (treated in most browsers as a separate URI scheme, https://).
As documented in RFC 2817, HTTP can also be secured by implementing HTTP/1.1 Upgrade headers and upgrading to TLS. Running HTTP over TLS negotiated in this way does not have the implications of HTTPS with regards to name-based virtual hosting (no extra IP addresses, ports, or URI space). However, few implementations support this method.
In S-HTTP, the desired URL is not transmitted in the cleartext headers but is left blank; another set of headers is included inside the encrypted payload. In HTTP over TLS, all headers are inside the encrypted payload and the server application does not generally have the opportunity to gracefully recover from TLS fatal errors (including 'client certificate is untrusted' and 'client certificate is expired').[2]
References
[edit]- ↑ "The Secure HyperText Transfer Protocol". ietf.org. IETF. I-D draft-ietf-wts-shttp-01.txt. Retrieved 8 February 2022.
- 1 2 Tom Sheldon (2001). "S-HTTP (Secure Hypertext Transfer Protocol)". Retrieved 2016-01-01.