HTTPS vs HTTP: Warum das sicherere Protokoll nicht zum Standard wird
HTTPS auch bei den Großen noch kein Standard
Seine sensiblen Kontodaten in ein HTTP Formular einzugeben, ist in etwa so, als würde man Benutzernamen und Kennwort auf eine Postkarte schreiben und in die Welt hinausschicken, versinnbildlicht Scott Gilbertson den Sicherheitsmangel von HTTP auf arstechnica.com. Nicht erst seit das Netzwerk Sniffing Tool FireSheep sein Unwesen in den WLAN Hotspots dieser Welt treibt, weiß man eigentlich, wie unsicher HTTP Verbindungen gegen das Auslesen von Eingabedaten ist. Trotzdem verwenden selbst die großen Websites, man erinnere nur an Twitters mobile Site, nicht standardmäßig HTTPS.
HTTPS – der Kostenaspekt
Tatsache ist, das sei vorangestellt, das Web könnte komplett über HTTPS Verbindungen funktionieren. Mehrere kleinere Problemstellen verhindern aber, dass HTTPS im großen Stil umgesetzt wird. Zum einen und das trifft insbesondere die zahlreichen kleinen Websites, hindern hohe Kosten für Sicherheitszertifikate HTTPS an der Ausbreitung. Seiten wie Facebook, Google oder Twitter mögen damit aus finanzieller Hinsicht keine Probleme haben, für die kleineren Webangebote hingegen bedeutet es schmerzliche Zusatzkosten. Zudem wachsen bei steigendem Traffic auch die Kosten für HTTPS mit und das mehr als bei purem HTTP.
Caching vs. HTTPS
Ein weiterer Grund, der uns vom HTTPS geschützten Web trennt, ist der Verlust der Möglichkeit Inhalte im Cache abzulegen. Mit der weltweit stetig zunehmenden Bandbreite, die jeder Internetnutzer zur Verfügung hat, sollte dieses Problem allerdings marginal sein. Vielmehr trauen sich die großen Anbieter von Webinhalten wohl nicht an HTTPS heran, weil sie damit Performanceeinbußen hinnehmen müssten. Tatsächlich verlängern sich die Latenzzeiten durch die Hinzunahme der SSL-Verschlüsselung ein wenig, aber auch das dürfte, abgewogen mit dem Sicherheitsaspekt eigentlich keine Rolle spielen. Außerdem strebt auch dieser Ausrede der technologische Fortschritt in Form von steigenden Bandbreiten entgegen.
Virtuelle Hosts funtionieren nicht mit HTTPS
Scott Gilbertson vermutet in seinem Artikel „HTTPS is more secure, so why isn’t the Web using it?“ die Problematik zwischen HTTPS und virtuellen Hosts als Hauptgrund für die nicht flächendeckende Nutzung von HTTPS. Das Problem ist, dass zahlreiche kleine Webseiten auf der Basis virtueller Hosts, angeboten von einem der vielen Web Hosting Providern, entstehen. Problematisch deshalb, weil dadurch tausende Websites mit der gleichen IP auf dem gleichen physikalischen Server liegen. Das funktioniere mit HTTP, mit HTTPS hingegen überhaupt nicht, erklärt Gilbertson. Zwar gebe es mit dem TLS Extensions Protokoll einen Weg beides zu vereinen, doch sei TLS nur teilweise implementiert und könne daher von kleinen virtuell gehosteten Websites nicht genutzt werden.
HTTPS – Eine Frage der Priorisierung: Performance contra Sicherheit
In Zukunft wird man sich immer eindringlicher die Frage stellen müssen, wie man zwischen den beiden kritischen Größen Geschwindigkeit und Sicherheit die Prioritäten setzten möchte. Offensichtlich wäre ein Web, basierend auf purem HTTPS, möglich. Es darf eigentlich nicht mehr lange dauern, bis auch die letzten kleinen Hindernisse aus dem Weg geräumt sind.
Bildnachweis für die Newsübersicht: Foto: Mirko Macari, Flickr.com. Lizenz: CC BY 2.0
HTTPS sollte bei allen Seiten gang und Gebe sein die wirklich mit Benutzerdaten was zu tun haben. Was bei kleinen Blogs wirklich egal ist, die brauchen einfach kein HTTPS aber bei Seiten wie Twitter und Facebook und vielleicht sogar Foren mit paar Hundert Usern sollte es mittlerweile dazu gehören.
Aber so ein SSL Zertifikat ist doch nicht so teuer, oder?
gibt es für deutlich unter 39,–/Jahr, z. t. auch kostenlos.
das grösste problem ist wirklich das ip-adressen bzw. portgebundene aushandeln der verbindung. techniken wie server name indication (SNI) sind leider noch nicht standard.
Das kommt auf die Art des Zertifikats an. (Premium, Wildcard, EV,…)
Wenn Microsoft und das olle Windows XP nicht mehr wären und Leute unter diesem auch noch den Internet Explorer meiden würden, dann wäre SNI kein Problem mehr. Habe kürzlich dazu einen Blogartikel verfasst: http://blog.klose-it.de/leider-immer-noch-kein-sni-mit-windows-xp-und
Wer in letzter Zeit mal einen Blick auf die hier genannten Seiten wie Facebook und Twitter geworfen hat, wird sicherlich festgestellt haben, dass https dort mittlerweile existiert, bei beiden aber noch optional. Google Mail setzt https voraus, um eine Verbindung herzustellen. Einige deutsche Provider bieten das Protokoll weiterhin nur als optional an, wieso auch immer.
Dies ist schon der zweite Artikel in dieser Richtung den ich lese, in dem behauptet wird, dass Twitter und Facebook kein https können, was schlicht und ergreifend falsch ist. Bei Facebook geht es seit geschätzt einem halben Jahr, bei Twitter seit einigen Wochen.
Bei StartSSL (www.startssl.com) kann man sich im Übrigen kostenfrei ein Zertifikat für eine Domain samt passender Subdomain ausstellen lassen. Die meisten Browser akzeptieren dieses dann auch ohne zu murren. Nach wie vor ist leider die Voraussetzung dafür, dass man seinen eigenen (virtuellen) Server hat, da die meisten Shared-Hosting-Provider die Installation von SSL-Zertifikaten nicht zulassen. Bei den teureren Paketen mag dies mittlerweile gehen, man korrigiere mich an dieser Stelle, falls dem so ist.
Kann eigentlich eine Site, die grundsätzlich mit HTTPS läuft, auch HTTP Elemente (Grafiken, Text-Content, CSS, …) problemlos einbinden? Müsste ja nicht alles HTTPS sein, oder?
@Michael: Ja, das ist natürlich möglich. Nur zeigen die Browser dann eine entsprechende Warnmeldung, weil die sichere Verbindung dadurch „aufgeweicht“ wird.
Zum Kostenaspekt: Bei http://www.startssl.com/ gibt es seriöse Zertifikate kostenlos, diese werden von allen großen Browsern akzeptiert. Somit wird kein Endandwender durch irgendwelche Sicherheitshinweise seines Browsers genervt.
Es wird einfach an der VirtualHost-Problematik liegen, wie oben dargestellt. Es wäre schön, wenn sich die technischen Lösungen dafür bald mal in die Browser verbreiten. Wenn z.B. Google das promoten würde, dann würde sich die Verbreitung wohl stark verbessern und man könnte als Serverbetreiber diese Techniken einsetzen.
@Ulf: grad mal deinen Artikel gelesen, sieht ja so aus, als wäre SNI schon hinreichend gut verbreitet. Fehlt nur noch WinXP…
@Florian: Nein, nicht mal Windows XP fehlt, wenn man auf den Internet Explorer verzichtet ;-). Alle anderen Browser können SNI auch unter XP. Und für so was hasse ich Microsoft, vollkommen unverständlich, wieso so was nicht einfach nachgerüstet wird. Vista und 7 können es doch auch. Ich kann mir einfach nicht vorstellen, dass es so schwierig ist, einen Patch dafür zu implementieren.
@Ulf
Und weil es schlicht falsch ist, behauptet der Artikel auch nicht, Twitter und FB könnten gar kein https:
„Trotzdem verwenden selbst die großen Websites, man erinnere nur an Twitters mobile Site, nicht standardmäßig HTTPS.“
@Ulf: tja, wer weiss wie tief die zuständige Lib in WinXP steckt und welche Zertifizierungen sie nach der Ergänzung von SNI erneuern müssten…
Man muss es eben pro SNI-Website abwägen, ob man die WinXP/IE Nutzer außen vor lassen kann.
„Ich kann mir einfach nicht vorstellen, dass es so schwierig ist, einen Patch dafür zu implementieren.“
@Ulf: XP ist ein altes System! Warum einen Patch dafür entwickeln? Sollen die User doch bitte auf Win7 umsteigen… Darum ja auch nix mehr IE6… etc.
Ein so altes System wie XP gehört einfach nicht mehr unterstützt!!
Danke euch für den Tipp zu SNI. Genau das was ich suche!
Möchte nicht mehr wie die Admin-Bereiche von diversen Projekten auf einem Server mit nur einer IP jeweils per HTTPS erreichen können. Da reicht das für mich.
Warum soll ich denn für ein SSL-Zertifikat bezahlen? In den unteren Preisklassen ist das doch eh nur heisse Luft! Ich bin dafür, das CACert endlich auch in den Betriebssystemen aus Redmond standardmäßig eingetragen ist.
@ DeinWeb – Ein Web für alle!
Natürlich hast du recht! In diesem fachlichen Artikel ist die Gleichsetzung im Sprachgebrauch von Internet und Web nicht angebracht. Ich habe es geändert.
Im Artikel wird korrekterweise gesagt, dass HTTPS die sichere Form des Browsens im Web ist. Motiviert wird das mehrfach durch Usernamen und Passwörter, die man einfach nicht ungesichert durch das Netz schicken sollte. Das ist auch sinnvoll und richtig so.
Aber: Was habe ich konkret davon, wenn ich den Blog einer „kleinen Seite“ lese und dies dann über HTTPS tue? Was schütze ich da? Der Blog ist eh öffentlich – wenn da jemand „mitliest“, wen interessiert das?
Wir haben in der Vergangenheit gesehen, dass auch Banken, die typischerweise die wichtigen Bereiche nur über HTTPS anbieten, ebenfalls Opfer von Phishing und Cross-Site Scripting Attacken werden können.
HTTPS per „Gieskanne“ alleine nützt gar nix – im Gegenteil: Es kann zu „wir haben jetzt HTTPS, also kann ich das Hirn ausschalten“ führen.
Das mit den virtuellen Hosts ist blödsinn. Die TLS-Erweiterung wird heutzutage flächendeckend unterstützt, und ist kein Grund mehr, auf HTTPs zu verzichten.
t
Fakt ist, dass man eine IP Adresse pro Domain braucht, die per HTTPS erreichbar sein soll. Genau das ist aber mit den „kleinen“ virtual Hosts üblicherweise nicht zu leisten.
Der technische Hintergrund ist der, dass bereits die initiale Anfrage verschlüsselt wird – also ein SSL Zertifikat erwrtet, aber der Server gar nicht entscheiden kann welcher Host (aka Domänenname) angesprochen werden soll, bzw.welches Domänen-spezifisches Zertifikat geliefert werden sol.
Es gibt nun eine tolle Erfindung names SNI (welches technisch eine Erweiterung zu TLS ist) , die dieses Problem mit der initialen Anfrage lösen soll – allerdings hapert es noch mit dem Browser Support. Zumindest auf Windows XP (immer noch massiv im Einsatz) und Android sieht es da dann ganz dunkel aus. Auf der Windows-Serverseite braucht es wenigstens IIS8 – von Flächendeckung zu sprechen ist da doch recht ambitioniert.
@Olaf Monien: Nein, mit SNI braucht man eben nicht mehr eine IP pro Domain, und das finde ich auch sinnvoll. Jeder Rechner sollte in jedem Netzwerk genau eine IP haben. Dafür sind sie da.
Dass Microsoft mal wieder im letzten Jahrhundert lebt, wundert mich gar nicht. Bloß, wenn man auf Microsoft wartet, können wir jeden technischen Fortschritt gleich absagen. Aber die verschlüsselung funktioniert ja trotzdem, und sicher ist die Übertragung selbst ja auch. Einzig die Zertifikate sind falsch. Dann fügt man einen Hinweis ein, der Nutzer soll gefälligst einen vernünftigen Browser verwenden. Problem gelöst.