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 a little-used alternative to the HTTPS URI scheme for encrypting web communications carried over HTTP. S-HTTP is defined in RFC 2660. It was developed by Eric Rescorla and Allan M. Schiffman.[1]
Web browsers typically use HTTP to communicate with web servers, sending and receiving information without encrypting it. For sensitive transactions, such as Internet e-commerce or online access to financial accounts, the browser and server must encrypt this information. HTTPS and S-HTTP were both defined in the mid-1990s to address this need. Netscape and Microsoft supported HTTPS rather than S-HTTP, leading to HTTPS becoming the de facto standard mechanism for securing web communications.
Differences with HTTPS
S-HTTP encrypted only the page data, and data such as POST fields, leaving the initiation of the protocol unchanged. Because of this, S-HTTP could be used concurrently with HTTP (unsecured) on the same port, as the unencrypted header would determine whether the rest of the transmission would be encrypted.
In contrast, HTTPS wraps the entire communication within SSL, so the encryption starts before any protocol data is sent. This also means that it requires a separate port (usually 443 vs. HTTP's standard 80)[2] and unambiguous usage (treated in most browsers as a separate URI protocol, https://).
In S-HTTP, the desired URL is not transmitted in the cleartext headers, but left blank; another set of headers is present inside the encrypted payload. In HTTPS, all headers are inside the encrypted payload.
See also
References
- ^ Link to authoritative technical reference (RFC 2660)
- ^ Overview of S-HTTP