t3n News Entwicklung

HTTPS vs HTTP: Warum das sicherere Protokoll nicht zum Standard wird

HTTPS vs HTTP: Warum das sicherere Protokoll nicht zum Standard wird

Warum wird HTTPS eigentlich nicht zum alleinigen Standard? Die Frage drängt sich auf, zieht man in Betracht, dass es HTTP und HTTPS schon seit den Anfängen des Web gibt. HTTPS ist die sichere Variante der beiden Protokolle. Alle Websites, auf denen wir Geldgeschäfte tätigen, verwenden die HTTPS Verbindung – seien es Bankgeschäfte, Einkäufe oder andere Online Bestellungen. Trotzdem ist immer noch weitestgehend HTTP der Standard. Warum das so ist und warum nicht das gesamte Web über HTTPS realisiert wird, erfahrt ihr hier.

HTTPS vs HTTP: Warum das sicherere Protokoll nicht zum Standard wird
Foto: Mirko Macari, Flickr.com. Lizenz: CC BY 2.0

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.

Über eine HTTPS Verbindung wird Hackern das Ausspähen von Kontodaten erheblich erschwert.(Foto: CBS_Fan / flickr.com, Lizenz: CC-BY-SA)

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.

Virtuelle Server stellen ein Problem dar. Die großen Webseiten wie Facebook, Twitter und Co. könnten jedoch mit ihren Serverfarmen pures HTTPS leisten – alles eine Frage der Priorisierung.(Foto: MysteryBee / flickr.com, Lizenz: CC-BY-SA)

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.

Weiterführende Links:

Bildnachweis für die Newsübersicht: Foto: Mirko Macari, Flickr.com. Lizenz: CC BY 2.0

Vorheriger Artikel Zurück zur Startseite Nächster Artikel
21 Antworten
  1. von Dennis am 22.03.2011 (11:32 Uhr)

    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.

    Antworten Teilen
  2. von Michael am 22.03.2011 (11:40 Uhr)

    Aber so ein SSL Zertifikat ist doch nicht so teuer, oder?

    Antworten Teilen
  3. von tron am 22.03.2011 (11:53 Uhr)

    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.

    Antworten Teilen
  4. von Patryk am 22.03.2011 (11:59 Uhr)

    Das kommt auf die Art des Zertifikats an. (Premium, Wildcard, EV,...)

    Antworten Teilen
  5. von Ulf am 22.03.2011 (12:01 Uhr)

    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.

    Antworten Teilen
  6. von Michael am 22.03.2011 (12:03 Uhr)

    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?

    Antworten Teilen
  7. von Ulf am 22.03.2011 (12:04 Uhr)

    @Michael: Ja, das ist natürlich möglich. Nur zeigen die Browser dann eine entsprechende Warnmeldung, weil die sichere Verbindung dadurch „aufgeweicht“ wird.

    Antworten Teilen
  8. von Florian Heyer am 22.03.2011 (12:09 Uhr)

    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.

    Antworten Teilen
  9. von Florian Heyer am 22.03.2011 (12:13 Uhr)

    @Ulf: grad mal deinen Artikel gelesen, sieht ja so aus, als wäre SNI schon hinreichend gut verbreitet. Fehlt nur noch WinXP...

    Antworten Teilen
  10. von Ulf am 22.03.2011 (12:16 Uhr)

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

    Antworten Teilen
  11. von Jan Borns am 22.03.2011 (13:09 Uhr)

    @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.“

    Antworten Teilen
  12. von Florian Heyer am 22.03.2011 (13:12 Uhr)

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

    Antworten Teilen
  13. von Nerd am 22.03.2011 (14:12 Uhr)

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

    Antworten Teilen
  14. von Jeffrey am 22.03.2011 (19:32 Uhr)

    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.

    Antworten Teilen
  15. von virtualmachine am 22.03.2011 (19:55 Uhr)

    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.

    Antworten Teilen
  16. von Marcel Seer am 23.03.2011 (09:53 Uhr)

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

    Antworten Teilen
  17. von Olaf Monien am 30.03.2011 (13:36 Uhr)

    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.

    Antworten Teilen
  18. von Bachsau am 17.02.2012 (03:09 Uhr)

    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.

    Antworten Teilen
  19. von Bachsau am 17.02.2012 (03:09 Uhr)

    t

    Antworten Teilen
  20. von Olaf Monien am 17.02.2012 (03:51 Uhr)

    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.

    Antworten Teilen
  21. von Bachsau am 17.02.2012 (15:41 Uhr)

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

    Antworten Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Mehr zum Thema Amazon
WordPress auf HTTPS: So stellst du deine Seite komplett um
WordPress auf HTTPS: So stellst du deine Seite komplett um

Eigentlich sollte es nicht schwer sein, eine CMS-Website von http auf HTTPS umzustellen – bei WordPress ist das aktuell aber noch mit ein bisschen Aufwand verbunden. Wie ihr eure WordPress-Website … » weiterlesen

Drown attackiert HTTPS-Server: Datenklau trotz verschlüsselter Verbindungen
Drown attackiert HTTPS-Server: Datenklau trotz verschlüsselter Verbindungen

Vergesst Heartbleed, die neue Bedrohung für Daten im Netz heißt „Drown“. Forschern zufolge ist fast jeder dritte HTTPS-Server weltweit betroffen. Server-Betreiber sollten schnell reagieren. » weiterlesen

HTTPS: Google markiert bald alle Websites ohne SSL-Verschlüsselung
HTTPS: Google markiert bald alle Websites ohne SSL-Verschlüsselung

Google will das Internet sicherer machen und HTTPS standardisieren – kein leichtes Unterfangen. Um Website-Betreiber in diese Richtung zu lotsen, will Google Seiten ohne Verschlüsselung bald … » weiterlesen

Alle Hefte Jetzt abonnieren – für nur 35 €

Kennst Du schon unser t3n Magazin?