Secure Hypertext Transfer Protocol

Secure Hypertext Transfer Protocol (S-HTTP) is an obsolete alternative to the HTTPS protocol for encrypting web communications carried over HTTP. It was developed by Eric Rescorla and Allan M. Schiffman, and published in 1999 as RFC 2660.

HTTP
Request methods
Header fields
Status codes
Security access control methods
Security vulnerabilities

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. S-HTTP was used by Spyglass's web server,[1] while Netscape and Microsoft supported HTTPS rather than S-HTTP, leading to HTTPS becoming the de facto standard mechanism for securing web communications.

Comparison to HTTP over TLS

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 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 per DNS name, and all HTTPS implementations require a separate port (usually 443 vs. HTTP's standard 80)[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 IPs, 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').

gollark: It would be sent somewhere else, and there's caching.
gollark: There isn't really, because if you're just dealing with random TCP streams I don't think they have a similar thing to the HTTP Host header, which tells you what domain ~~you~~ the client wants to access.
gollark: caddy is a newer and trendier one which does nice stuff like HTTPS without having to use an external program like certbot, but in my opinion v2 made configuring it quite annoying.
gollark: I'd recommend nginx for reverse-proxying, it has reasonably non-annoying configuration and is very fast.
gollark: Reverse proxies are mostly a HTTP thing. You can probably get away with just running the other stuff on multiple ports.

References
  1. Booker, Ellis (1995-03-27). "Web servers move in different directions". Computerworld.
  2. Tom Sheldon (2001). "S-HTTP (Secure Hypertext Transfer Protocol)". Retrieved 2016-01-01.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.