Studie: 99 Prozent aller SSL-verschlüsselten Verbindungen nicht sicher

  • Nur wenige Seiten implementieren derzeit HSTS - noch dazu richtig, die die Page der Sicherheitskonferenz Defcon im Bild.
    screenshot: derstandard.at

    Nur wenige Seiten implementieren derzeit HSTS - noch dazu richtig, die die Page der Sicherheitskonferenz Defcon im Bild.

Lassen sich über Man in the Middle-Attacke austricksen - Problem liegt in unverschlüsselter Initialisierung

Nach dem Auftauchen von Tools wie "Firesheep", die zeigten, wie einfach es ist eine Verbindung zu Facebook, Twitter und Co. "abzufangen", hat sich in den letzten Jahren ein gewisser Trend zur SSL-Verschlüsselung der Kommunikation ergeben. Dass es mit der simplen Verwendung einer https-Verbindung oft aber noch nicht getan ist, zeigt nun eine neue Studie des Münchner Sicherheitsunternehmens SecureNet, wie heise.de berichtet.

Initialisierung

Darin zieht man eine beinahe schon vernichtende Bilanz: 99 Prozent aller verschlüsselten Verbindungen seien in Wirklichkeit gar nicht sicher, ließen sich über bekannte Angriffe ausspionieren. Das Problem sei, dass die anfängliche Kommunikation (die Initialisierung der Verbindung) zwischen Client und Server üblicherweise unverschlüsselt abläuft. Über eine konventionelle "Man in the Middle"-Attacke können AngreiferInnen an dieser Stelle ansetzen, und den https-Link, den der Server an den Client zurückliefert auf einen http-Link zwingen.

Trickreich

In Folge wird die (Rück-)Kommunikation also wieder unverschlüsselt durchgeführt. Das besonders Perfide dabei: Da die Kommunikation vom Client zum Server weiterhin per https läuft, bemerken die NutzerInnen - ohne Netzwerkanalyse - gar nicht, dass ihre vermeintlich sichere Verbindung in Wirklichkeit mitgelesen werden kann.

HSTS

Dieses Problem ist natürlich kein gänzlich Unbekanntes, entsprechend gibt es mit HTTP Strict Transport Security (HSTS) schon seit 2009 ein Protokoll, dass dafür sorgt, dass auch zur Initialisierung der Verbindung kein unverschlüsselter Datenverkehr mehr nötig ist. Das Problem dabei: HSTS wird derzeit nur von einem Bruchteil aller Server, die https verwenden genutzt. SecureNet spricht hier international von gerade einmal 0,5 Prozent, in Deutschland von gar nur 0,1 Prozent. Bei deutschen Banken wären etwa nur 6 von 423 Webseiten durch HSTS geschützt.

Implementation

Doch selbst bei der Implementation von HSTS gibt es immer wieder Probleme: Damit der Schutz effektiv sei, müsse die Gültigkeit es Headers - in dem die HSTS-Anweisung enthalten ist - mindestens 30 Tage betragen, so SecureNet. Dies treffe aber wiederum nicht einmal bei der Hälfte der gefundenen Seiten, die HSTS nutzen zu, so der Sicherheitsdienstleister. Teilweise laufe hier der Header schon innerhalb von wenigen Stunden ab.

Ratschläge

Zusammenfassend rät SecureNet Unternehmen dazu, ihre MitarbeiterInnen zum Einsatz von VPN-Verbindungen zu zwingen. Auch bei der Browserwahl gilt es vorsichtig zu sein, so unterstützt etwa der Internet Explorer selbst in der aktuellsten Version 10 noch kein HSTS. (red, derStandard.at, 05.11.12)

Share if you care
Posting 1 bis 25 von 39
1 2
Also ich sehe da viel grundlegendere Probleme bei HTTPS.

Sofern es irgendwie gelingt, sich dazwischenzuhängen, kann man mit einem beliebigen gültigen Zertifikat auch HTTPS Verkehr abfangen, indem man HTTPS-Server spielt. Somit kann man mit dem eigenen Zertifikat entschlüsseln und dann wieder per HTTPS an die Bank über das Zertifikat der Bank weiterschicken.
Der User müsste wirklich prüfen, ob das verwendete Zertifikat das von der Bank ist, ansonsten kommt dieser nicht drauf.
Aber wer macht das schon?

Wenn Sie beim Online-Banking eine Zertifikatswarnung wegklicken (die heutzutage durchaus auf die Gefahr hinweisen), ist das nicht die Schuld des HTTPS-Protokolls.

Wirklich gefährlich wird es erst, wenn der Angreifer an ein gültiges Zertifikat für die Website gelangt. Das ist jedoch trivial.

In Windows gibt es ein API, mit dem man selber

Zertifizierungsstelle spielen kann. Habe mir die zwar nur grob angesehen, aber was ist, wenn jemand selber ein Zertifikat generiert und über die eigene Webseite prüft?
Gibt es hier einen Mechanismus, der das verhindert?

Bei selbstsignierten Zertifikaten wird von den Browsern eine Zertifikatswarnung angezeigt (heutzutage empfehlen die gängigen Browser die Seite zu verlassen, in so einem Fall).

Die Browser vertrauen per default nur Zertifikaten die von großen, namhaften Zertifizierungstellen ausgestellt wurden (diese kann man sich z.B. im Firefox mit dem Zertifikatsmanager ansehen).

*nicht* trivial :)

Sorry, das ist Unsinn. Der Aussteller des Zertifikats prüft natürlich, wem er ein Zertifikat für eine bestimmte Site ausstellt. Bei EV-Zertifikaten wird noch strenger geprüft und der Firmenname permanent angezeigt, das ist bei Banken inzwischen Standard.

hmm...

nur - "wie kommt der Mann in die Mitte"?

im wlan ists klar aber ansonsten ist das risiko eher gering oder?

z.B

wenn man Zugang zu einem Internet-Provider hat oder sich verschafft, dann kann man leicht Man in the Middle spielen.

durch..

...ein default-passwort eines wlan-routers zb...

geht meines wissens nur im gleichen subnet, außer man schafft es einen router zu erobern. da bin ich aber nicht berufen.

so gut hsts auch gemeint is - wünsche viel spaß beim administrieren der eigenen fritzbox/wasauchimmerfüreinrouter....

Inwiefern?
Was hat HSTS mit dem Router zu tun? Nichts?

und weil ich grad noch weiter gestöbert habe

die größte errungenschaft von HSTS ist es, dass damit verhindert wird, dass der user invalide zertifikate ignoriert. sollte man also nur machen, wenn man weit verbreitete und gültige zertifikate verwendet!

Wie kommen Sie darauf?
HSTS teilt dem Browser mit in Zukunft (für die im Header konfigurierte Zeit) SSL für weitere Request zu verwenden.

Bitte um Info, wie ein Protokoll-Header verhindern soll, dass ein User Zertifikatswarnungen ignoriert.

Gegenfrage: kennen Sie Wikipedia?

Ah ja, Sie haben Recht HSTS verhindert auch (das hab ich vorhin übersehen, da ich mir nur den Protokoll-Header angesehen habe), dass invalide Zertifikate akzeptiert werden.
Das ist aber nur die halbe Wahrheit nicht? ;-)

"sollte man also nur machen, wenn man weit verbreitete und gültige zertifikate verwendet!"
Der Satz hat mich verwirrt, wodurch ich Ihren Kommentar falsch gedeutet habe ("man"= User dachte ich).
Es ist ja so, dass der Webserver die HSTS-Infos mitsendet. Dieser wird dann ja sowieso ein offizielles Zertifikat besitzen.

Wichtiger ist jedoch eher, dass dadurch SSL-stripping Attacken verhindert werden können (sofern bereits 1x die Seite besucht hat, was ja der Pferdefuß an der Lösung ist).

es ist eine frechheit, wie viel man für so ein zerifikat bezahen muss - deswegen machen viele das zertifikat selber. wenn der user diese eigenbau zertifikate nicht mehr akzeptieren kann, dann ist hsts uninteressant für jeden der keine komerzielle seite betreibt. wenn das web sicherer werden soll, sollte auch für kleine sites eine adequate möglichkeit bestehen die verbindungen sicher zu machen.

$99/jahr bei godaddy. ein bisserl was müssens für die bürokratie schon überlassen, die identität bzw. verfügungsberechtigung für die domain muss schon überprüft werden damit das irgendwas bringt.

assymetrische verschlüsselung braucht halt zertifikate. wenn sie darauf verzichten wollen (und damit tür&tor für MitM öffnen) ist HSTS nicht ihr problem (einfach nicht aktivieren), sondern den usern ernsthaft zu erklären dass sie jetzt 10 sicherheitswarnungen wegklicken müssen, aber eh alles OK ist.

blödsinn, $13/jahr wollt ich schreiben.

Oder gratis bei startssl (für "level 1" zertifikate)

die sind für öffentliche sites eher sinnlos, da sie keine identitätsprüfung beinhalten und daher auch nicht automatisch akzeptiert werden. bringen nur was wenn man sie selbst auf die clients ausrollen kann.

fortsetzung

- eine site, die nur HTTPS verwendet (und zwar von anfang an) hat kaum ein risiko im sinne des artikels. (außer gefakten links per email und unaufmerksamen usern, die bekommt man aber eh immer)
- die VPN-empfehlung kann ich nur sehr bedingt nachvollziehen (macht nur für intranet-sites sinn, und die kann man ja auch strikt auf HTTPS stellen). ich finde diese empfehlung auch nicht in der verlinkten studie.

da der IE HSTS nicht unterstützt halte ich die HSTS-Empfehlung alleine auch für fahrlässig. die empfehlung muss lauten, für kritische sites ausschließlich HTTPS zuzulassen, HSTS ist ein netter zusatz, nicht mehr.

wer diesen artikel liest und versteht, worum es geht, hat es vorher schon gewusst

es klingt, als würde eine HTTPS-verbindung zu beginn unverschlüsselt aufgebaut werden, und ein MitM könnte unbemerkt die verschlüsselung dauerhaft verhindern. das ist natürlich unsinn.
- eine website beginnt oft mit HTTP, erst wenn es zB ans bezahlen geht wird auf HTTPS geswitcht. wenn sich ein MitM vorher reinhängt, wird dieser switch verhindert und der user bleibt auf HTTP.
- das sieht man aber natürlich im browser. verschleiert wird das nicht etwa wie im artikel völlig unverständlich angedeutet durch irgendwelche Tricks mit (Rück-)Kommunikation, sondern durch ein page-icon das aussieht wie das HTTPS-icon des browsers.
- HSTS sagt dem browser, dass er für diese site auch in zukunft immer HTTPS verwenden MUSS (steht im artikel ganz falsch)

danke!

du hast in wenigen zeilen mehr erklärt worum es geht, als es der verfasser dieses artikel versucht.

Danke für die Aufklärung der Details

Posting 1 bis 25 von 39
1 2

Die Kommentare von Usern und Userinnen geben nicht notwendigerweise die Meinung der Redaktion wieder. Die Redaktion behält sich vor, Kommentare, welche straf- oder zivilrechtliche Normen verletzen, den guten Sitten widersprechen oder sonst dem Ansehen des Mediums zuwiderlaufen (siehe ausführliche Forenregeln), zu entfernen. Der/Die Benutzer/in kann diesfalls keine Ansprüche stellen. Weiters behält sich die derStandard.at GmbH vor, Schadenersatzansprüche geltend zu machen und strafrechtlich relevante Tatbestände zur Anzeige zu bringen.