7

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.

Rob Olmos
  • 2,220
  • 1
  • 15
  • 25
  • 2
    An additional IP is no longer a requirement for https VirtualHosts. See: http://serverfault.com/questions/126072/ssl-certificate-selection-based-on-host-header-is-it-possible/126075#126075 – Warner Sep 14 '10 at 13:25
  • Good comment (although I'm not sure what the deployment status of SNI is w.r.t. various versions of clients and servers, but that's probably for another question). – Bruno Sep 14 '10 at 13:57
  • 1
    @Warner the biggest problem with SNI now and for at least a few more years is that it doesn't work on Windows XP. http://en.wikipedia.org/wiki/Server_Name_Indication#Browsers – ThatGraemeGuy Sep 14 '10 at 15:15
  • 2
    @Warner: Yes, Firefox 2.0 supports it on XP. Realistically that's completely irrelevant. There are sites where 80% of the traffic still comes from IE on Windows XP, making SNI completely useless. Sure, be aware that SNI exists, but also take into account what your users are running. For the majority of sites, XP is still going to be there for a while. – ThatGraemeGuy Sep 15 '10 at 08:10

4 Answers4

4

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-HTTP HTTP upgraded to TLS compared with HTTPS are that it could be possible to do a downgrade attack, by intercepting but not relaying the Upgrade message (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 as STARTTLS, much more similar to S-HTTP HTTP 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 Upgrade mechanism 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:

Community
  • 1
Bruno
  • 4,069
  • 1
  • 20
  • 37
  • That's a good point about the Upgrade MITM attack which I just learned that the HTTPS links (if the page is served via HTTP) can also be intercepted in the same way which is why HSTS is coming to light. Thanks. – Rob Olmos Nov 02 '10 at 05:25
3

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.

William
  • 31
  • 1
1

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.

Community
  • 1
Dave Holland
  • 1,898
  • 1
  • 13
  • 17
  • S-HTTP upgrades to SSL/TLS during the connection (after an HTTP `Upgrade` request), but it's still transport-level security, not message-level security. It has nothing to do with VPN either. For message-level HTTP security, look at http://httpsec.org/ , but this is completely different. – Bruno Sep 14 '10 at 10:43
  • http://tools.ietf.org/html/rfc2660 Read the RFC on S-HTTP. – Dave Holland Sep 14 '10 at 14:18
  • Of course, you're right. Apologies. – Bruno Sep 14 '10 at 14:55
  • Sorry, I can't cancel the downvote unless you edit. The VPN stuff is unrelated anyway. – Bruno Sep 14 '10 at 14:58
  • (I've edited my answer too, giving you credit) – Bruno Sep 14 '10 at 15:06
  • No worries man... and actually the VPN stuff isn't unrelated, as some VPN's use HTTPS protocols - but S-HTTP wouldn't function for that as it's message level. – Dave Holland Sep 14 '10 at 22:49
1

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".

gabbelduck
  • 329
  • 1
  • 3
  • http://en.wikipedia.org/wiki/Strict_Transport_Security This is something paypal started and it looks like a merge between HTTPS and SHTTP - something in the future we'll all be using. – Jeremy Hajek Sep 14 '10 at 04:56