{{short description|Web encryption method similar to HTTPS}} {{Distinguish|HTTPS}} {{HTTP}} '''Secure Hypertext Transfer Protocol''' ('''S-HTTP''') is an obsolete alternative to the [[HTTPS]] protocol for [[encryption|encrypting]] [[World Wide Web|web]] communications carried over the Internet. It was developed by Eric Rescorla and Allan M. Schiffman at Enterprise Integration Technologies in 1994<ref>{{cite IETF |title=The Secure HyperText Transfer Protocol |draft=draft-ietf-wts-shttp-01.txt |website=ietf.org |publisher=IETF |access-date=8 February 2022}}</ref> and published in 1999 as {{IETF RFC|2660 |first1=Peter |title=Attention Shoppers: Internet Is Open |url=https://www.nytimes.com/1994/08/12/business/attention-shoppers-internet-is-open.html |access-date=8 February 2022 |work=New York Times |date=12 August 1994}}. [[Netscape]]'s dominance of the browser market led to HTTPS becoming the [[de facto standard|de facto]] method for securing web communications.
==Comparison to HTTP over TLS (HTTPS)== S-HTTP encrypts only the served page data and submitted data like 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 is 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 [[virtual hosting#Name-based|name-based virtual hosting]] "chicken and egg" issue with determining which [[Domain Name System|DNS]] name was intended for the request.
This means that HTTPS implementations without [[Server Name Indication]] (SNI) support require a separate [[IP address]] per DNS name, and all HTTPS implementations require a separate port (usually 443 vs. HTTP's standard 80)<ref name=":0">{{cite web | url=https://www.linktionary.com/s/shttp.html | title=S-HTTP (Secure Hypertext Transfer Protocol) | author=Tom Sheldon | date=2001 | accessdate=2016-01-01}}</ref> for unambiguous use of encryption (treated in most browsers as a separate [[URI scheme]], ''https://'').
As documented in {{IETF RFC|2817}}, HTTP can also be secured by implementing [[HTTP/1.1 Upgrade header]]s 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 left blank; another set of headers is present 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').<ref name=":0" />
==References== {{Reflist}}
==External links== *[https://tools.ietf.org/html/rfc2660 RFC 2660 The Secure HyperText Transfer Protocol]
[[Category:Hypertext Transfer Protocol]] [[Category:Cryptographic protocols]]