Why did HTTPS win? Does anyone know of any specific reasons why Netscape and Microsoft both choose HTTPS instead of S-HTTP (RFC 2660)?
It appears to me that S-HTTP is more flexible and does not require a separate IP or port to serve the correct certificate because S-HTTP is able to utilize the Host header. Was IP space a concern at that time?
I can see the argument that HTTPS encrypted more of the connection data than S-HTTP, but I don't see much of the point if you can just as easily tell which website the user accessed because there's only one site per IP (most of the time) and the certificate usually says what domain anyways.
My Answer: SSL created in 1993/1994 by Netscape and HTTPS was naturally added on to it around the same time in 1994. The original goal of HTTPS being to retrofit existing protocols into security without any changes. S-HTTP didn't come along until 1999 and required HTTP 1.1 so by then HTTPS was so entrenched there was little benefit to implement S-HTTP. Thanks everyone.
EDIT: I have seen RFC 2817 called "S-HTTP" in a few places, but this in wrong and has nothing to do with the question, which was about RFC 2660, as @Dave Holland pointed out in his answer. Some elements of my answer could also apply to RFC 2660 as well, and it might be useful for comparison as there are similarities, but I don't really deserve the up-vote here. Apologies for the confusion...
I think the general reproaches made to
S-HTTPHTTP upgraded to TLS compared with HTTPS are that it could be possible to do a downgrade attack, by intercepting but not relaying theUpgrademessage (although the server can do something about it) and that, from the browser's perspective, it's harder to identify whether the URI is meant to be secure or not (https://vs.http://prefix). (This is of course, the very opposite arguments used by protocols that use mechanisms such asSTARTTLS, much more similar toS-HTTPHTTP upgraded to TLS.) In both cases, the protocols have to be configured properly (right cipher suites, ...) and the user interface has to provide enough to the user to judge whether the connection is secure or not (good cert/bad cert, ...).More importantly, it probably has to do with the "market forces", which historically have implemented HTTPS but not S-HTTP and saw no reason to change (at the underlying SSL/TLS level, it was long enough to move from SSLv2, to SSLv3 and TLSv1 and above).
In addition, RFC 2817 was published in 2000 and by that time, HTTPS had already been around for some time. The
Upgrademechanism also relies on using HTTP 1.1, whereas HTTPS can be made to work over HTTP 1.0 too (and at the time, not everything supported HTTP 1.1).You may find these threads of interest:
SHTTP was invented and implemented in Mosaic and NCSA httpd in 1993. HTTPS won in the marketplace because Mosaic Communications Corporation/Netscape developed and embedded SSL in Netscape Navigator and Netscape Enterprise Server. Netscape refused to implement SHTTP. No one wanted to use Mosaic after Netscape was released.
I can tell you that S-HTTP encrypts individual messages, and HTTPS encrypts the entire communication channel, this may be part of the reason from a technical standpoint. Due to the fact that it only encrypts individual messages it can't be used as a protocol for things like VPN. I don't really claim to know otherwise. See https://www.rfc-editor.org/rfc/rfc2660 for more details on S-HTTP.
Some comments/threads from actual decisionmakers at the time would be interesting - I can say that back at the time, I don't recall hearing much about s-http, and https was there early on.
In hindsight - the s-http spec looks to be very open and flexible, which may be what killed it - https I believe specified the use of SSL and implied the use of a global PKI and how that would work - wherase s-http said "yeah we can do that, if you want... plus all this other stuff".