Man-in-the-middle-Angriff

Dieser Beitrag behandelt Man-in-the-middle-Angriffe auf Internet-Verbindungen zwischen Server (Website) und Client (Browser).

Bei Man-in-the-middle-Angriffen steht der Angreifer zwischen dem Webserver, der eine Website zur Verfügung stellt und dem Browser, mit dem diese aufgerufen wird. Gelingt es dem Angreifer, beiden vorzutäuschen, dass er der echte Kommunikationspartner ist, kann er nach belieben Daten abgreifen oder manipulieren. Beispielsweise könnte er im Falle einer Verbindung vom Kunden mit seiner Bank den Betrag einer Überweisung und die begünstigte Kontonummer ändern. Oder er könnte, wenn er denn Geheimdienst ist, die Kommunikation abhören und falsche Informationen einstreuen. Der Man-in-the-middle-Angriff ist also sehr ernst zu nehmen.

Man-in-the-middle-Angriffe fallen besonders leicht innerhalb eines Wireless Local Arrea Networks (WLAN). Vor allem öffentliche WLANs, bspw. an Flughäfen, Bahnhöfen oder in Cafés werden dazu genutzt. Dabei wird dem Browser entweder ein falscher Access Point vorgetäuscht oder der Angreifer erlangt Kontrolle über den Router.

Eine weitere Methode des Man-in-the-middle-Angriffs ist das Domain Name Server (DNS) Cache Poisoning. Domains (zum Beispiel https://dirkwolf.de) werden im Internet nicht direkt aufgerufen, sondern müssen über DNS zu den tatsächlich benötigten Internet Protocol-Adressen (IP-Adressen, zum Beispiel 5.9.121.204 für den Server, auf dem https://dirkwolf.de gehostet wird) geleitet werden. Beim DNS Cache Poisoning leitet der Angreifer statt auf die echte IP-Adresse auf eine vom ihm kontrollierte.

Schutz vor Man-in-the-middle-Angriffen bietet grundsätzlich die Verschlüsselung via SSL/TLS. Dazu muss entweder der Nutzer explizit https://… eingeben oder – was definitiv besser ist – der Server leitet alle Anfragen, egal ob https:// oder http://… auf eine verschlüsselte Seite um. Ist das so passiert, vereinbaren der Server, auf dem die Website gehostet ist und der Browser, der die Website aufruft, die Kommunikation verschlüsselt aufzubauen und den gesamten Inhalt nur verschlüsselt zu übermitteln.

Selbstverständlich haben mögliche Angreifer nach Wegen gesucht, auch das zu umgehen. Darauf reagiert die Internetgemeinde mit einer relativ neuen Abwehrmethode, der HTTPS Strict Transport Security (HSTS). Dazu lesen Sie hier mehr.

Forward Secrecy

Dieser Beitrag handelt von Forward Secrecy, einer Methode, um verschlüsselte Kommunikation direkt nach Ende der Session unbrauchbar zu machen und damit vor späterer Entschlüsselung zu schützen.

Wenn über Sicherheit von Websites gesprochen wird, betrachten wir vor allem das Hier und Heute. Aber das ist nicht alles. Es wird befürchtet, dass in exorbitant großen Mengen verschlüsselte Kommunikation auf den Servern der Geheimdienste der Welt gespeichert wird. Diese kann zwar (hoffentlich) heute noch nicht entschlüsselt werden. Doch ganz sicher arbeiten diverse legale und, vor allem, illegale Organisationen daran, den heute vorhandenen Schutz durch Verschlüsselung zu knacken.

Der Weg dahin ist die Art, wie SSL/TLS-Verbindungen sich verschlüsseln. Jede Internet-SSL-Verbindung beginnt mit einem sogenannten handshake (Händedruck), bei dem beide Seiten – der Web-Browser des Nutzers und der Webserver der angewählten Website – Ihre Fähigkeit zur Verschlüsselung bekannt geben und, wenn das festgestellt ist, sich auf einen (kurzlebigen) Session-Schlüssel einigen . Dabei authentifiziert sich der Server gegenüber dem anfragenden Web-Browser. Neben der Authentifizierung dient der Schlüsseltausch auch zur Verschlüsselung der Kommunikation während der gesamten Session. Die Schlüssel werden anschließend gelöscht. Das Ziel der Schlüsselaustauschphase ist also, beiden Seiten zu ermöglichen, andere zu hindern, an der Session teilzunehmen, also mitzuhören oder ggf. auch zu manipulieren.

Sitzungsschlüssel: Generierung und Austausch

Es gibt mehrere Verfahren zum Schlüsseltausch. Das traditionell verwendete Verfahren nutzt den RSA-Schlüssel des Servers, um den Session-Schlüssel sicher vom Client zum Server zu übertragen. Das ist ein äußerst effizientes Verfahren.

Allerdings kann damit jeder, der eine Kopie des privaten Schlüssels des Servers besitzt, die Session-Schlüssel aufdecken und damit die Session entschlüsseln. Das ist durchaus für einige Sicherheits-Techniken wünschenswert, weil sie ohne das nicht arbeiten könnten.

Mögliche Angreifer verfügen vielleicht heute nicht über den privaten Schlüssel vieler Server. Aber vielleicht verfügen sie später über Techniken, an den privaten Schlüssel zu gelangen und damit im Nachhinein jede gespeicherte, verschlüsselte Kommunikation des Webservers mit allen Beteiligten zu entschlüsseln.

Der Diffie-Hellmann-Schlüsseltausch

Eine Alternative zu dem RSA-basierte Schlüsselaustausch besteht darin, den vergänglichen Diffie-Hellman-Algorithmus zu verwenden. Dieser erzeugt den Session-Schlüssel so, dass nur die an der Kommunikation Beteiligten ihn erhalten. Niemand, auch niemand, der den privaten Schlüssel des Servers besitzt, kann ihn bekommen. Nachdem sie Sitzung beendet ist, zerstören beide Seiten den Session-Schlüssel. Auf diese Weise kann die Session nur noch entschlüsselt werden, wenn der Session -Schlüssel bekannt ist. Diese Funktion wird Forward Secrecy genannt.

Einen Session-Schlüssel zu knacken ist eindeutig viel schwieriger als an den privaten Schlüssel eines Servers zu kommen. Darüber hinaus können Sie mit einem Sitzungsschlüssel nur die eine Session entschlüsseln, mit dem privaten Schlüssel des Servers aber alle Sessions, die auf dem Server laufen.

SSL und Forward Secrecy

SSL unterstützt Forward Secrecy mit zwei Algorithmen, die der Standard-Diffie-Hellman-Methode (DHE) und die angepasste Version zur Verwendung mit Elliptic Curve Cryptography (ECDHE).

Bild mit einem Ausschnitt von forward secrecy auf ssllabs. com
Forward Secrecy dargestellt auf ssllabs.com

DHE ist deutlich langsamer als RSA, weshalb Website-Betreiber dazu neigen, die DHE-Suiten zugunsten der Serverleistung zu deaktivieren. Außerdem unterstützen nicht alle Browser alle notwendigen Suiten.

ECDHE ist fast so schnell wie RSA und damit derzeit die Methode der Wahl.

In der Praxis kann man, um sicher zu sein, sämtliche Kommunikation durchführen zu können, die Server so konfigurieren, dass zunächst ein handshake nach ECDHE erfolgt, wenn das nicht funktioniert, einer nach DHE und wenn der Kommunikationspartner (die anfragende Website) das auch nicht beherrscht, RSA. Sicherheitsbewusste Webmaster verzichten allerdings darauf, auch RSA zu akzeptieren. Da nur veraltete Systeme weder DHE- noch ECDHE-Verfahren unterstützen, sollte hier Konsequenz walten.

HTTPS Public Key Pinning (HPKP)

Dieser Beitrag handelt von HPKP (HTTPS Public Key Pinning). HPKP verhindert wirksam „Man-in-the-middle“-Angriffe bei mit Zertifikaten geschützten Websites

Eigentlich schützt ein SSL/TLS-Zertifikat wirksam vor dem so genannten „Man-in-the-middle“-Angriff auf eine Website (bzw. auf einen Webserver). Schlecht nur, wenn das Zertifikat korrupt ist, was in den letzten Monaten leider häufiger vorgekommen ist. Da wurden von einigen CAs (Certification Authority; autorisierte Zertifizierungsstelle) Zertifikate ausgestellt für Domains, die dem Antragsteller gar nicht gehörten. Ein Zertifikat wird von einer CA ausgestellt, um dem eine Website aufrufenden Web-Browser zu bestätigen, dass die aufgerufene Domain tatsächlich die ist, die aufgerufen wurde. Niemand kann sich als https://dirkwolf.de ausgeben, außer die von einer CA zertifizierten Website https://dirkwolf.de. Das eine Website zertifiziert ist, erkennt man leicht daran, dass vor allen aufgerufenen Seiten https:// steht. Der Nutzer kann so sicher sein, dass er tatsächlich auf der Website https://dirkwolf.de ist, wenn er diese Domain aufruft. Außerdem werden Daten, die über diese Verbindung ausgetauscht werden, verschlüsselt. Das können bspw. Adressdaten sein, die eingegeben werden, um Infomaterial anzufordern oder die Kommentarfunktion unter diesem Beitrag.

Um dem Problem korrupter Zertifikate zu begegnen, ist nun eben jener neue Standard HPKP eingeführt worden. Ruft ein Nutzer eine Website, die mit HPKP geschützt ist erstmalig auf, wird dem aufrufenden Browser ein so genannter Pin übergeben, in dem zwei Schlüssel abgelegt sind und eine zeitlich Vorgabe. Der erste Schlüssel wird genutzt, um beim nächsten Aufruf zu prüfen, ob es sich tatsächlich um die richtige Website handelt. Hat ein anderer ein Zertifikat für die Domain erworben, nützt das nichts, weil er nicht den richtigen Schlüssel mitliefert, den der aufrufende Browser bei sich gespeichert hat. Der zweite Schlüssel dient als Backup, für den Fall, dass der erste Schlüssel kompromittiert wird. In diesem Fall würde der aufrufende Browser ansonsten die Website nicht mehr anzeigen. Die zeitliche Vorgabe (meist 60 Tage) dient dazu, dem Browser anzuweisen, 60 Tage lang den Schlüssel zu verlangen. Ruft der Nutzer die Website bspw. nach einer Woche erneut auf, beginnen die 60 Tage von vorn. Das sorgt dafür, dass nach einem Wechsel des Zertifikats, bspw. wenn das alte Zertifikat ausläuft, ein reibungsloser Übergang zum neuen Zertifikat gewährleistet wird. In diesem Fall wird einfach der alte Backup-Schlüssel als neuer erster Schlüssel definiert und ein neuer Backup-Schlüssel hinterlegt. Das erfordert jedoch eine saubere Hosting-Leistung, denn wird das beim Einbinden eines neuen Zertifikats vergessen, können alle regelmäßigen Besucher die Website nicht mehr sehen.

Der HPKP-Standard sieht außerdem vor, dass eine URL angegeben werden kann, an die eine Meldung abgesetzt wird, wenn ein Web-Browser den Aufruf einer Website abgelehnt hat, weil ein falscher Schlüssel verwendet wurde. So kann der Website-Betreiber feststellen, dass ein korruptes Zertifikat existiert.

Das Bild zeigt den HPKP-Eintrag von ssllabs.com
HPKP, dargestellt im Test von ssllabs.com

HPKP ist besonders sinnvoll im Zusammenhang mit (HSTS) Strict Transport Security. Darüber können Sie hier einen anderen Beitrag lesen.

Die Sicherheit der eigenen Website testen: ssllabs.com

Dieser Beitrag handelt von  ssllabs.com, einer Website zur Überprüfung der Qualität von SSL/TLS-Servern.

Es gibt eine sehr einfache Methode, die Sicherheit der eigenen Website zu testen. Das US-Amerikanische Unternehmen QUALYS stellt ein Forum zur Verfügung, das sich in IT-Sicherheitskreisen hohes Ansehen erarbeitet hat.

ssllabs.com versteht sich als ein nicht-kommerzielles Forum, das die Sicherheit von Websites allgemein verbessern will. Es handelt sich um eine „Sammlung von Dokumenten, Tools und Gedanken zu SSL“ (Text von ssllabs.com). ssllabs.com wird betrieben und unterstützt von dem US-Amerikanischen Unternehmen QUALYS, das professionell Unternehmen zu sicheren Websites verhilft.

Wie hilft ssllabs.com mir?

Was müssen Sie tun, um Ihre Website auf die Sicherheit zu überprüfen? Ganz einfach: gehen Sie auf die Seite https://www.ssllabs.com/ssltest/, geben die URL Ihrer Website (www.meineseite.de) in das Eingabefeld ein und klicken auf „Submit“. Jetzt müssen Sie sich noch ein paar Minuten gedulden, dann erscheint das Ergebnis. Ist es kein A gibt es Handlungsbedarf. ssllabs.com liefert Ihnen die konkreten Gründe, warum Ihre Website nicht so sicher ist, wie sie sein sollte.

Sollten Sie kein SSL/TLS-Zertifikat für Ihre Website eingebunden haben, können Sie sich den Test sparen. Ihre Website ist dann eh nicht sicher.

Wenn alles in bester Ordnung ist, sieht das Ergebnis des Tests auf ssllabs.com so aus:

Screenshot vom Ergebnis des Sicherheits-Tests auf ssllabs.com für dirkwolf.de: A+
So sieht ein gutes Ergebnis auf ssllabs. com aus: A+ für dirkwolf.de

 

 

 

 

 

 

 

 

 

Wenn nicht so gut gearbeitet wurde, kann es aber auch so aussehen:

Das Bild zeigt das Ergebnis des Sicherheits-Tests der Website controlcenter.o2online.de: die schlechteste Note F
So sieht es aus, wenn sich um die Sicherheit der Website nicht gekümmert wird

 

 

 

 

 

 

 

 

 

 

 

Die Noten orientieren sich am amerikanischen Schulnoten-System von A (sehr gut) als Bestnote bis F (ungenügend) als Höchststrafe. Es kommt aber noch viel schlimmer. Denn die Browser-Hersteller bestrafen solch ein Verhalten inzwischen teils völlig zu Recht gnadenlos:

DFas Bild zeigt, dass eine Website, die nicht sicher ist, im Browser Chrome von Google klar als nicht sicher gekennzeichnet wird
Googles Browser Chrome sagt klar: hier ist nichts sicher!

 

Das Bild zeigt den Browser Firefox. Er öffnet eine nicht sichere Seite erst gar nicht.
Der Firefox ist noch rigoroser. Er öffnet die Seite gar nicht.

 

 

 

 

 

 

 

 

Das Bild zeigt, dass der Internet Explorer keine Reaktion zeigt, wenn eine nicht sichere Website geöffnet wird.
Dem Internet Explorer hingegen scheint es egal zu sein.