Warum wurde HTTPS anstelle von S-HTTP zur Standardmethode?

Warum hat HTTPS gewonnen? Kennt jemand bestimmte Gründe, warum sowohl Netscape als auch Microsoft HTTPS anstelle von S-HTTP (RFC 2660) wählen ?

Es scheint mir, dass S-HTTP flexibler ist und keine separate IP oder einen separaten Port benötigt, um das richtige Zertifikat bereitzustellen, da S-HTTP den Host-Header verwenden kann. War IP-Raum zu dieser Zeit ein Problem?

Ich kann das Argument sehen, dass HTTPS mehr Verbindungsdaten als S-HTTP verschlüsselt hat, aber ich sehe nicht viel davon, wenn Sie genauso leicht erkennen können, auf welche Website der Benutzer zugegriffen hat, da es nur eine Site pro IP gibt (die meisten davon) die Zeit) und das Zertifikat sagt normalerweise, welche Domain sowieso.

Meine Antwort: SSL, das 1993/1994 von Netscape und HTTPS erstellt wurde, wurde natürlich ungefähr zur gleichen Zeit im Jahr 1994 hinzugefügt. Das ursprüngliche Ziel von HTTPS bestand darin, vorhandene Protokolle ohne Änderungen in die Sicherheit nachzurüsten. S-HTTP kam erst 1999 auf den Markt und erforderte HTTP 1.1. Bis dahin war HTTPS so fest verankert, dass die Implementierung von S-HTTP nur einen geringen Nutzen brachte. Vielen Dank an alle.

EDIT: Ich habe RFC 2817 mit dem Namen "S-HTTP" an einigen Stellen gesehen, aber dies ist falsch und hat nichts mit der Frage zu tun, die sich auf RFC 2660 bezog, wie @ Dave Holland in seiner Antwort hervorhob . Einige Elemente meiner Antwort könnten auch für RFC 2660 gelten, und es könnte zum Vergleich nützlich sein, da es Ähnlichkeiten gibt, aber ich verdiene die Aufwertung hier nicht wirklich. Entschuldigung für die Verwirrung ...

Ich denke, die allgemeinen Vorwürfe gegen S-HTTP HTTP, das im Vergleich zu HTTPS auf TLS aktualisiert wurde, bestehen darin, dass es möglich sein könnte, einen Downgrade-Angriff durchzuführen, indem die UpgradeNachricht abgefangen, aber nicht weitergeleitet wird (obwohl der Server etwas dagegen tun kann) Aus Sicht des Browsers ist es schwieriger zu erkennen, ob der URI sicher sein soll oder nicht (im https://Vergleich zum http://Präfix). (Dies sind natürlich die STARTTLSgenau entgegengesetzten Argumente, die von Protokollen verwendet werden, die Mechanismen verwenden, wie z. B. S-HTTP HTTP, das auf TLS aktualisiert wurde.) In beiden Fällen müssen die Protokolle ordnungsgemäß konfiguriert werden (Right Cipher Suites, .. .) und die Benutzeroberfläche muss dem Benutzer genügend bieten, um beurteilen zu können, ob die Verbindung sicher ist oder nicht (gutes Zertifikat / schlechtes Zertifikat, ...).

Noch wichtiger ist, dass es wahrscheinlich mit den "Marktkräften" zu tun hat, die in der Vergangenheit HTTPS, aber nicht S-HTTP implementiert haben und keinen Grund zur Änderung sahen (auf der zugrunde liegenden SSL / TLS-Ebene war es lang genug, um von SSLv2 zu wechseln SSLv3 und TLSv1 und höher).

Darüber hinaus wurde RFC 2817 im Jahr 2000 veröffentlicht, und zu diesem Zeitpunkt gab es HTTPS bereits seit einiger Zeit. Der UpgradeMechanismus basiert auch auf der Verwendung von HTTP 1.1, während HTTPS auch über HTTP 1.0 funktionieren kann (und zu diesem Zeitpunkt nicht alles HTTP 1.1 unterstützt).

Möglicherweise finden Sie folgende interessante Themen:

• IETF TLS-Mailingliste: RFC 2817 vorgeschlagener Widerruf des Standardstatus?
• http://jis.mit.edu/pipermail/saag/2001q4/000253.html

SHTTP wurde 1993 in Mosaic und NCSA httpd erfunden und implementiert. HTTPS gewann auf dem Markt, weil Mosaic Communications Corporation / Netscape SSL in Netscape Navigator und Netscape Enterprise Server entwickelt und eingebettet hat. Netscape weigerte sich, SHTTP zu implementieren. Nach der Veröffentlichung von Netscape wollte niemand Mosaic verwenden.

Einige Kommentare / Threads von tatsächlichen Entscheidungsträgern zu dieser Zeit wären interessant - ich kann sagen, dass ich mich damals nicht daran erinnere, viel über s-http gehört zu haben, und https war schon früh da.

Im Nachhinein - die s-http-Spezifikation scheint sehr offen und flexibel zu sein, was sie möglicherweise getötet hat - https hat meiner Meinung nach die Verwendung von SSL spezifiziert und die Verwendung einer globalen PKI impliziert und wie dies funktionieren würde - wobei s-http sagte "Ja, das können wir, wenn du willst ... und all das andere Zeug".

Ich kann Ihnen sagen, dass S-HTTP einzelne Nachrichten verschlüsselt und HTTPS den gesamten Kommunikationskanal verschlüsselt. Dies kann aus technischer Sicht ein Teil des Grundes sein. Aufgrund der Tatsache, dass nur einzelne Nachrichten verschlüsselt werden, kann es nicht als Protokoll für Dinge wie VPN verwendet werden. Ich behaupte nicht wirklich, etwas anderes zu wissen. Weitere Informationen zu S-HTTP finden Sie unter http://tools.ietf.org/html/rfc2660 .