it-swarm-eu.dev

Warum ist HTTPS nicht das Standardprotokoll?

Warum wird HTTP immer noch häufig verwendet, was ich für viel sichereres HTTPS halte?

75
blunders

SSL/TLS hat einen leichten Overhead. Als Google Google Mail auf HTTPS umstellte (von einer optionalen Funktion auf die Standardeinstellung), stellten sie fest, dass der CPU-Overhead etwa + 1% und der Netzwerk-Overhead + 2% betrug. siehe dieser Text für Details. Dies gilt jedoch für Google Mail, das aus privaten, dynamischen, nicht gemeinsam genutzten Daten besteht und auf Google-Systemen gehostet wird, auf die von überall mit sehr geringer Latenz zugegriffen werden kann. Die Haupteffekte von HTTPS im Vergleich zu HTTP sind:

  • Die Verbindungsinitiierung erfordert einige zusätzliche Netzwerk-Roundtrips. Da solche Verbindungen "am Leben erhalten" und nach Möglichkeit wiederverwendet werden, ist diese zusätzliche Latenz vernachlässigbar, wenn eine bestimmte Site mit wiederholten Interaktionen verwendet wird (wie es für Google Mail typisch ist). Systeme, die hauptsächlich statische Inhalte bereitstellen, können den Netzwerk-Overhead als nicht vernachlässigbar empfinden.

  • Proxyserver können mit HTTPS bereitgestellte Seiten nicht zwischenspeichern (da sie diese Seiten nicht einmal sehen). Auch hier gibt es nichts Statisches, das mit Google Mail zwischengespeichert werden kann, aber dies ist ein sehr spezifischer Kontext. ISPs lieben das Caching sehr, da die Netzwerkbandbreite ihre Lebenskraft ist.

  • HTTPS ist HTTP innerhalb von SSL/TLS. Während des TLS-Handshakes zeigt der Server sein Zertifikat an, das den beabsichtigten Servernamen angeben muss - und dies geschieht , bevor die HTTP-Anforderung selbst an die gesendet wird Server. Dies verhindert virtuelles Hosting, es sei denn, eine TLS-Erweiterung namens Servername Indication wird verwendet. Dies erfordert die Unterstützung des Kunden. Insbesondere unterstützt Internet Explorer nicht die Servernamenanzeige unter Windows XP (IE 7.0 und höher), aber nur unter Vista und Win7). Angesichts des aktuellen Marktanteils von Desktop-Systemen, die WinXP verwenden, kann nicht davon ausgegangen werden, dass "jeder" die Angabe des Servernamens unterstützt. Stattdessen müssen HTTPS-Server eine IP pro Servernamen verwenden, den aktuellen Status der IPv6-Bereitstellung und IPv4 Adressmangel machen dies zu einem Problem.

  • HTTPS ist im folgenden Sinne "sicherer" als HTTP: Die Daten werden als von einem benannten Server stammend authentifiziert, und die Übertragung ist vertraulich in Bezug auf jeden, der die Leitung belauschen darf. Dies ist ein Sicherheitsmodell, das in vielen Situationen nicht sinnvoll ist: Wenn Sie sich beispielsweise ein Video von Youtube ansehen, ist es Ihnen egal, ob das Video wirklich von youtube.com oder von einem Hacker stammt, der (höflich) sendet Sie das Video, das Sie sehen möchten; und dieses Video ist sowieso öffentliche Daten, daher ist die Vertraulichkeit hier von geringer Relevanz. Außerdem erfolgt die Authentifizierung nur relativ zum Serverzertifikat, das von einer Zertifizierungsstelle stammt, die dem Clientbrowser bekannt ist. Zertifikate sind nicht kostenlos, da der Sinn von Zertifikaten darin besteht, dass sie die physische Identifizierung des Zertifikatsinhabers durch die Zertifizierungsstelle beinhalten (ich sage nicht, dass die kommerzielle Zertifizierungsstelle ihre Zertifikate fair bewertet, aber selbst die fairste Zertifizierungsstelle, die vom Buddha selbst betrieben wird, würde dies tun müssen noch eine Gebühr für ein Zertifikat erheben). Kommerzielle Zertifizierungsstelle würde nur HTTPS als "Standard" lieben. Darüber hinaus ist nicht klar, ob das von den X.509-Zertifikaten verkörperte PKI-Modell tatsächlich "standardmäßig" für das Internet insgesamt benötigt wird (insbesondere wenn es um Beziehungen zwischen Zertifikaten und dem DNS geht - einige argumentieren, dass a Das Serverzertifikat sollte vom Registrar ausgestellt werden, wenn die Domain erstellt wird.

  • In vielen Unternehmensnetzwerken bedeutet HTTPS, dass die Daten von Lauschern nicht gesehen werden können und diese Kategorie alle Arten von Inhaltsfiltern und Antivirensoftware umfasst. Wenn Sie HTTPS als Standard festlegen, sind viele Systemadministratoren sehr unglücklich.

All dies sind Gründe, warum HTTPS als Standardprotokoll für das Web nicht unbedingt eine gute Idee ist. Sie sind jedoch nicht der Grund, warum HTTPS derzeit nicht das Standardprotokoll für das Web ist. HTTPS ist nicht die Standardeinstellung, nur weil HTTP zuerst vorhanden war.

68
Thomas Pornin

Obwohl es bereits gute Antworten gibt, glaube ich, dass ein Aspekt bisher übersehen wird.

Hier ist es: Normales HTTP ist das Standardprotokoll für das Web, da die meisten Informationen im Web keine Sicherheit benötigen.

Ich möchte weder die Frage noch die Sicherheitsbedenken einiger Websites/Anwendungen herabsetzen. Aber wir können manchmal vergessen, wie viel Web-Verkehr:

  • enthält nur vollständig öffentliche Informationen
  • oder hat wenig oder keinen Wert
  • oder wenn mehr Besucher den Wert der Website erhöhen (Nachrichtenmedien, Netzwerkeffekt Websites)

Ein paar kurze Beispiele, ich bin sicher, Sie können schnell mehr in Ihrem Kopf machen:

  • Fast alle Unternehmenswebsites, manchmal auch als "Broschüren-Websites" bezeichnet, enthalten öffentliche Informationen zu einem Unternehmen.
  • Fast alle Nachrichtenmedien, Blogs, Fernsehsender usw., die Werbeunterstützung als primäre Monetarisierungsstrategie gewählt haben.
  • Dienste, die anbieten Logins und zusätzliche Personalisierung, aber auch ihre Inhalte kostenlos an alle weitergeben, die anonym surfen (YouTube fx).
31
Jesper M
  • Dies führt zu einer erheblich höheren CPU-Auslastung des Servers, insbesondere bei statischen Inhalten.
  • Es ist schwieriger, mit Paketerfassungen zu debuggen
  • Es werden keine namensbasierten virtuellen Server unterstützt
5
Mike Scott

HTTP war immer die Standardeinstellung. Anfangs wurde https für nichts benötigt, es war so ziemlich eine Ergänzung, da sich herausstellte, dass unter bestimmten Umständen Sicherheit erforderlich war.

Selbst jetzt gibt es so viele Websites, die kein https benötigen, dass es immer noch kein überzeugendes Argument ist, http vollständig zu ersetzen.

Mit immer effektiveren Mechanismen zum Ausführen von TLS-gesicherten Verbindungen wird der CPU-Overhead immer weniger zum Problem.

5
Rory Alsop

Niemand hat auf ein klares Problem hingewiesen, das sich aus der Verwendung von http als Standard anstelle von https ergibt.

Kaum jemand stört sich daran, die vollständige URL zu schreiben, wenn er eine Ressource anfordert, die für verschiedene Zwecke verschlüsselt und/oder signiert werden muss.

Nehmen Sie als Beispiel Google Mail, wenn Benutzer gmail.com besuchen, besuchen sie tatsächlich das Standardprotokoll von http und nicht https. Zu diesem Zeitpunkt ist die Sicherheit in Szenarien fehlgeschlagen, in denen der Gegner den Datenverkehr abfängt. Warum? Weil es möglich ist, HTML von der https-Anfrage zu entfernen und sie auf http zu verweisen.

Wenn https tatsächlich das Standardprotokoll gewesen wäre, wären Ihre Sitzungen zu Websites geschützt worden.

Für die Frage, warum http anstelle von https ausgewählt wird, gelten die verschiedenen obigen Antworten. Die Welt ist einfach noch nicht bereit für die weit verbreitete Verwendung von Verschlüsselung.

5

Zusätzlich zu den Gründen, die andere bereits angegeben haben:

  • Zusätzliche Arbeit zum Einrichten von HTTPS auf dem Server erforderlich

    Der Serveradministrator muss Zertifikate für jede Domäne konfigurieren. Dies beinhaltet die Interaktion mit einer Zertifizierungsstelle, um zu beweisen, dass Sie der echte Eigentümer der Domain sind, und um Zertifikatserneuerungen zu erhalten. Dies kann bedeuten, dass Sie Zertifikatsignierungsanforderungen manuell generieren und Erneuerungen erwerben oder einen automatisierten Prozess dafür einrichten (z. B. certbot mit Let's Encrypt). In beiden Fällen ist es mehr Arbeit als HTTPS nicht zu verwenden.

  • Zusätzliche IP-Adressen erforderlich

    Dies ist kein wirkliches Problem, da die Unterstützung von SNI (Server Name Identification) in Browsern und SSL-Client-Bibliotheken weit verbreitet ist.

    Traditionell war es jedoch erforderlich, für jeden Standort eine andere IP-Adresse zu verwenden, wobei SSL auf einem bestimmten Server und Port verwendet wurde. Dies wurde durch die Möglichkeit des namenbasierten Hostings (virtuelles Hosting) beeinträchtigt - eine weit verbreitete Methode, mit der viele verschiedene Domänen von derselben IP-Adresse gehostet werden können. Mit HTTPS funktioniert reguläres namenbasiertes Hosting nicht, da der Server wissen muss, was Hostname in der SSL/TLS-Validierungsschicht vorher das HTTP darstellt Anfrage, die den Hostnamen enthält, kann entschlüsselt werden.

    Die Server Name Identification (SNI), die das namenbasierte Hosting auf der SSL/TLS-Ebene effektiv implementiert, hebt diese Einschränkung auf.

  • langsame Veränderung

    HTTPS war eine Modifikation eines bestehenden Protokolls, HTTP, das bereits sehr tief verwurzelt war, bevor viele Leute anfingen, über Sicherheit nachzudenken. Sobald sich eine Technologie etabliert hat und so allgegenwärtig ist wie HTTP, kann es sehr lange dauern, bis die Welt zu ihrem Nachfolger wechselt, selbst wenn die Gründe für die Änderung zwingend sind.

3
thomasrutter

Thomas hat bereits eine ausgezeichnete Antwort geschrieben, aber ich dachte, ich würde noch ein paar Gründe nennen, warum HTTPS nicht weiter verbreitet ist ...

  • Nicht erforderlich. Wie Jespers Antwort aufschlussreich zeigt, "benötigt die Mehrheit der Informationen im Web keine Sicherheit". Allerdings, wobei Suchmaschinen, Werbefirmen, Internetfilter auf Länderebene und andere "Big Brother" -Programme (z. B. NSA) immer häufiger nachverfolgen; es erhöht die Notwendigkeit größerer Datenschutzmaßnahmen.

  • Geschwindigkeit. Es fühlt sich oft an langsam wegen der zusätzlichen Hin- und Rückfahrten und zusätzlichen Anfragen nach Zertifikatsperrlisten ( OCSP usw.). Zum Glück SPDY (von Google erstellt und jetzt in allen gängigen Browsern unterstützt) und einige interessante Arbeit von CloudFlare helfen dabei, dies zu ändern .

  • Preis von Zertifikaten. Die meisten Zertifizierungsstellen berechnen für ein Zertifikat exorbitante Geldbeträge (Hunderte von Dollar). Zum Glück es gibt kostenlose Optionen , aber diese erhalten nicht so viel Werbung (nicht sicher warum?).

  • Preis für IP-Adressen. Bis sich IPv6 verbreitet, werden Websites mit der zunehmenden Knappheit (und damit den Kosten) von IPv4-Adressen konfrontiert sein. SNI ermöglicht die Verwendung mehrerer Zertifikate für eine einzelne IP-Adresse, jedoch ohne SNI-Unterstützung in Windows XP oder IE 6, die meisten Sites benötigen noch eine dedizierte IP-Adresse, um SSL bereitzustellen.

  • Erhöhung der Server-CPU-Auslastung.  Dies ist eine verbreitete Überzeugung, aber laut Google " SSL/TLS ist nicht mehr rechenintensiv ".

2
Simon East

Die einfachste und vernünftigste Erklärung, die ich unter meinen Kollegen gefunden habe, ist, dass es immer mit HTTP gemacht wurde. Warum sollte ich es jetzt ändern?.

Wenn es nicht kaputt ist, reparieren Sie es nicht.

1
blfoleyus

Die eigentliche Antwort ist, dass SSL-Zertifikate in ihrer aktuellen Form komisch schwer zu verwenden sind. Sie sind so unbrauchbar, dass sie die Sicherheit von Zertifikaten gefährden, da Benutzer Verknüpfungen verwenden, um nur Aufgaben zu erledigen. Ich sage dies als jemand, der sich routinemäßig mit 2-Wege-SSL (PKI-Zertifikaten), den TLS-Stack-Inkompatibilitäten, die durch die Komplexität der Spezifikation entstehen, und der verrückten Anzahl von Konfigurationskombinationen (Verschlüsselungsgrenzen, Optionen, sprachspezifische Bibliotheksfehler) befasst usw.), die als "TLS" bezeichnet werden.

Sehen Sie den Aufstieg von LetsEncrypt als Beweis dafür, dass dies wahr ist.

Caddy ist ein Reverse-Proxy-Projekt, das LetsEncrypt verwendet. Es kann Zertifikate erneuern, während der Server ausgeführt wird, und die Benutzer verwenden sehr kurze Ablaufzeiten, da die Erneuerungen automatisiert werden.

1
Rob