Schloss_Dateien

KRITISCHE SSL-LÜCKE

Posted on

HTTP Strict Transport Security (HSTS)

Einige Webseiten sind mittlerweile ausschließlich über HTTPS zu erreichen – warum auch nicht. solange der Browser allerdings noch versehentlich ungesicherte HTTP-Verbindungen zum Server aufbauen kann, besteht die Möglichkeit, dass sensible Daten über ein unverschlüsseltes POST-Kommando zum Server gelangen, oder das Angreifer durch eine Man in the Middle-Attacke die HTTP-Verbindung verschleppen.
HTTP Strict Transport Security steuert gegen.
Die Idee ist simple: Webseiten, die ausschließlich per HTTPS angesprochen werden wollen, fügen in ihre Server-Antworten einen HSTS-Header mit ein. Ähnlich wie bei einem Cookie merkt sich der Browser in der eigenen Datenbank, von welchen Servern er HSTS-Header bekommen hat und weigert sich ab sofort diesen per HTTP anzusprechen.

HTTP Strict Transport Security ist ein Sicherheitsmechanismus für HTTPS-Verbindungen. Dieser soll vor der Aushebung der Verbindungsverschlüsselung durch eine downgrade Attacke schützen.
Dazu kann ein Server mit Hilfe des HTTP response header Strict Transport Security einem Client mitteilen, in Zukunft für eine definierte Zeit (max. age) ausschließlich verschlüsselte Verbindungen für diese Domain zu nutzen. Dieses lässt sich optional über den Parameter includeSubDomains ausweiten.
Durch eine von Google Chrome betreute und anderen großen Webbrowsern genutzte HSTS preload list werden die Limitierungen des trust on fire use-Prinzip für eine definierte Liste von Domains umgangen.
Die Eintragung zusätzlicher Domains ist kostenlos möglich. Die Speicherung der HSTS-Informationen durch den Client lässt sich für ein Tracking von Benutzern ausnutzen.
Sehr kritisch wurde in diesem Zusammenhang diskutiert, dass Google Chrome die HSTS-Informationen auch in den für besonderen Datenschutz ausgelegten Incognitus-Modus übernimmt.
Der Standard wurde 2012 von der Internet Engineering Task Force (IETF) als RFC 6797 veröffentlicht und wird unter anderem von den jüngsten Versionen der gängigen Webbrowser unterstützt.
Anlass für eine solche Entwicklung waren von Moxie Marlinspike 2009 demonstrierte Attacken auf verschlüsselte Verbindungen durch Man in the Middle-Attacken, die sich vor zustande kommen einer verschlüsselten Verbindung dazwischen schalten.

Secure Socket Layer (SSL)

SSL ist ein Protokoll, das der Authentifizierung und Verschlüsselung von Internetverbindungen dient. SSL schiebt sich zwischen die Anwendungsprotokolle und den Transportprotokollen. Ein typisches Beispiel für den Einsatz von SSL ist der gesicherte Abruf von vertraulichen Daten über HTTP und die gesicherte Übermittlung von vertraulichen Daten an den HTTP-Server. In der Regel geht es darum, die Echtheit des kontaktierten Servers durch ein Zertifikat zu garantieren und die Verbindung zwischen Client und Server zu verschlüsseln. SSL ist äußerst beliebt und das Standard-Protokoll bzw. die Erweiterung für Anwendungsprotokolle, die keine Verschlüsselung für sichere Verbindungen mitbringen.
Allerdings birgt dieses Protokoll auch einige Schwachstellen.
Die Schwachstellen im SSL-Protokoll lassen sich Berichten zufolge von Angreifern ausnutzen, um in geschützte Verbindungen eigene Inhalte einzuschleusen. Betroffen wären neben HTTPS auch alle anderen Protokolle wie IMAP, die zur Transportsicherung SSL einsetzen.
Sobald ein Besucher eine SSL-verschlüsselte Seite besucht, tauschen Client und Server über das SSL TSL Protokoll im Hintergrund Kryptographieschlüssel aus, die anschließend für die Verschlüsselung der Kommunikation verwendet werden.

Da seine Sitzung allerdings eine lange Zeit dauern kann, wurde im Frühjahr 2012 eine Funktion eingeführt, die sich Heartbeat nennt. Diese ist dafür zuständig, die Erreichbarkeit der Gegenstelle zu prüfen. Dazu schickt der Client dem Server ein kleines Datenpaket, das der Server kopiert und seinerseits zurück an den Client schickt.
An dieser Stelle greift nun die Lücke, die dafür sorgt, dass der Server die Länge der Nachricht nicht überprüft und dem Client eine Nachricht in der von ihm angegebenen Größe zurückschickt. Wenn nun der Client beispielsweise eine leere, 1 Byte große Nachricht an den Server schickt, sie aber als 64KByte groß erklärt, kopiert der Server sie in den Speicher und schickt seinerseits dann eine 64KByte große Nachricht zurück. Es kommt vor, dass sich zu diesem Zeitpunkt auf dem Server sensible Daten im Speicher befinden und die zurückgeschickt werden.
Normalerweise befinden sich nicht nur Benutzernamen und Passwörter im Speicher, mitunter ist es sogar möglich, dass sich auch private Schlüssel darin befinden. Sollte es einem Angreifer gelingen, einen solchen Schlüssel zu ergattern, dann kann er eine zuvor aufgenommene Kommunikation zwischen zwei Parteien, die mit diesem Schlüssel verschlüsselt wurden, ohne Probleme nachträglich entschlüsseln.
Spätestens jetzt offenbart sich die Tragweite dieses Bugs: Da dieser Angriff kaum Spuren auf dem Server hinterlässt, kann im Nachhinein nicht mit Sicherheit festgestellt werden, welche Daten der Server übermittelt hat. Nun stellt sich die Frage, welche Schritte eingeleitet werden sollen und welche konkrete Auswirkungen dies mit sich führt.

Falls Sie bei diesem Thema Hilfe benötigen sollten, wenden Sie sich gerne an 5 Sterne Marketing!