Allgemeines

SSL (und sein Nachfolger TLS ) ist ein Protokoll, das arbeitet direkt über TCP (obwohl es auch Implementierungen für datagrammbasierte Protokolle wie UDP gibt). Auf diese Weise können Protokolle auf höheren Schichten (wie HTTP) unverändert bleiben, während s bis zur Bereitstellung einer sicheren Verbindung. Unter der SSL-Schicht ist HTTP mit HTTPS identisch.

Bei korrekter Verwendung von SSL / TLS kann ein Angreifer auf dem Kabel nur sehen, mit welcher IP-Adresse und welchem Port Sie verbunden sind, ungefähr wie viele Daten Sie senden und welche Verschlüsselung und Komprimierung verwendet werden. Er kann die Verbindung auch beenden, aber beide Seiten wissen, dass die Verbindung von einem Dritten unterbrochen wurde.

In der Regel kann der Angreifer auch herausfinden, zu welchem Hostnamen Sie eine Verbindung herstellen (aber nicht der Rest der URL): Obwohl HTTPS selbst den Hostnamen nicht verfügbar macht, muss Ihr Browser normalerweise zuerst eine DNS-Anfrage stellen, um herauszufinden, an welche IP-Adresse die Anfrage gesendet werden soll.

Hoch Beschreibung des Protokolls auf Ebenenebene

Nach dem Aufbau einer TCP-Verbindung wird der SSL-Handshake vom Client gestartet. Der Client (der ein Browser sowie jedes andere Programm wie Windows Update oder PuTTY sein kann) sendet eine Reihe von Spezifikationen:

• welche Version von SSL / TLS ausgeführt wird,
• was ciphersuites verwendet werden soll und
• was Komprimierungsmethoden , die verwendet werden sollen.

Der Server identifiziert die höchste von ihm und dem Client unterstützte SSL / TLS-Version, wählt eine Chiffrensuite aus einer der Optionen des Clients aus (sofern er eine unterstützt) und wählt optional eine Komprimierungsmethode aus.

Danach ist die Grundeinstellung abgeschlossen, und der Server sendet sein Zertifikat. Dieses Zertifikat muss entweder vom Client selbst oder von einer Partei, der der Client vertraut, als vertrauenswürdig eingestuft werden. Wenn der Client beispielsweise GeoTrust vertraut, kann er dem Zertifikat von Google.com vertrauen, da GeoTrust kryptografisch signiert das Zertifikat von Google.

Nachdem das Zertifikat überprüft wurde und sichergestellt ist, dass dieser Server wirklich der ist, für den er sich ausgibt (und kein Mann in der Mitte), wird ein Schlüssel ausgetauscht. Dies kann ein öffentlicher Schlüssel sein, ein “ PreMasterSecret “ oder einfach nichts, abhängig von der ausgewählten Chiffrensuite. Sowohl der Server als auch der Client können jetzt den Schlüssel für symmetrische Verschlüsselung ^{whynot PKE?} . Der Client teilt dem Server mit, dass von nun an die gesamte Kommunikation verschlüsselt wird. und sendet eine verschlüsselte und authentifizierte Nachricht an den Server.

Der Server überprüft, ob der MAC (der zur Authentifizierung verwendet wird) korrekt ist und ob die Nachricht korrekt entschlüsselt werden kann. Anschließend gibt er eine Nachricht zurück, die der Client überprüft wie Nun.

Der Handshake ist nun beendet und die beiden Hosts können sicher kommunizieren. Weitere Informationen finden Sie unter technet.microsoft.com/en-us/library/cc785811 und en.wikipedia .org / wiki / Secure_Sockets_Layer .

Um die Verbindung zu schließen, wird ein close_notify „alert“ verwendet. Wenn ein Angreifer versucht, die Verbindung durch Beenden der TCP-Verbindung (Einspeisen eines FIN-Pakets) zu beenden, wissen beide Seiten, dass die Verbindung nicht ordnungsgemäß beendet wurde. Die Verbindung kann dadurch jedoch nicht beeinträchtigt, sondern nur unterbrochen werden.

Weitere Details

Warum können Sie Google.com vertrauen, indem Sie GeoTrust vertrauen?

Eine Website möchte sicher mit Ihnen kommunizieren. Um seine Identität zu beweisen und sicherzustellen, dass es sich nicht um einen Angreifer handelt, müssen Sie den öffentlichen Schlüssel des Servers haben. Sie können jedoch kaum alle Schlüssel speichern Von allen Websites auf der Erde wäre die Datenbank riesig und Updates müssten stündlich ausgeführt werden!

Die Lösung hierfür ist Certificate Authorities, kurz CA.Bei der Installation Ihres Betriebssystems oder Browsers wurde wahrscheinlich eine Liste vertrauenswürdiger Zertifizierungsstellen mitgeliefert. Diese Liste kann nach Belieben geändert werden. Sie können entfernen, wem Sie nicht vertrauen, andere hinzufügen oder sogar Ihre eigene Zertifizierungsstelle erstellen (obwohl Sie die einzige sind, die dieser Zertifizierungsstelle vertraut, ist sie für öffentliche Websites nicht sehr nützlich). In dieser CA-Liste wird auch der öffentliche Schlüssel der CA gespeichert.

Wenn der Server von Google Ihnen das Zertifikat sendet, wird auch erwähnt, dass es von GeoTrust signiert ist. Wenn Sie GeoTrust vertrauen, können Sie (mithilfe des öffentlichen Schlüssels von GeoTrust) überprüfen, ob GeoTrust das Serverzertifikat wirklich signiert hat. Um selbst ein Zertifikat zu signieren, benötigen Sie den privaten Schlüssel, der nur GeoTrust bekannt ist. Auf diese Weise kann ein Angreifer selbst kein Zertifikat signieren und fälschlicherweise behaupten, Google.com zu sein. Wenn das Zertifikat nur um ein Bit geändert wurde, ist das Vorzeichen falsch und der Client lehnt es ab.

Wenn ich den öffentlichen Schlüssel kenne, kann der Server dies seine Identität beweisen?

Ja. In der Regel werden der öffentliche Schlüssel und der private Schlüssel entschlüsselt. Verschlüsseln Sie eine Nachricht mit dem öffentlichen Schlüssel des Servers, senden Sie sie, und wenn der Server die ursprüngliche Nachricht wiederholen kann, hat er nur bewiesen, dass er den privaten Schlüssel erhalten hat, ohne den Schlüssel preiszugeben.

Aus diesem Grund ist so wichtig, um dem öffentlichen Schlüssel vertrauen zu können: Jeder kann ein privates / öffentliches Schlüsselpaar generieren, auch ein Angreifer. Sie möchten nicht den öffentlichen Schlüssel eines Angreifers verwenden!

Wenn Eine der Zertifizierungsstellen, denen Sie vertrauen, ist gefährdet. Ein Angreifer kann den gestohlenen privaten Schlüssel verwenden, um ein Zertifikat für eine beliebige Website zu signieren. Wenn der Angreifer ein gefälschtes Zertifikat an Ihren Client senden kann, das von ihm selbst mit dem privaten Schlüssel einer vertrauenswürdigen Zertifizierungsstelle signiert wurde, weiß Ihr Client nicht, dass es sich bei dem öffentlichen Schlüssel um einen gefälschten handelt, der mit einem gestohlenen privaten Schlüssel signiert ist.

Aber eine Zertifizierungsstelle kann mich dazu bringen, jedem gewünschten Server zu vertrauen!

Ja, und hier kommt das Vertrauen Wenn Organisationen wie Microsoft, Apple und Mozilla einer Zertifizierungsstelle vertrauen, muss die Zertifizierungsstelle Audits durchführen. Eine andere Organisation überprüft sie regelmäßig, um sicherzustellen, dass noch alles ordnungsgemäß ausgeführt wird

Die Ausstellung eines Zertifikats erfolgt nur dann, wenn der Registrant nachweisen kann, dass er die Domain besitzt, für die das Zertifikat ausgestellt wurde.

Was ist dieser MAC für die Nachrichtenauthentifizierung?

Jede Nachricht ist mit einem sogenannten Nachrichtenauthentifizierungscode signiert oder MAC kurz. Wenn wir uns auf einen Schlüssel und eine Hashing-Chiffre einigen, können Sie überprüfen, ob meine Nachricht von mir stammt, und ich kann überprüfen, ob Ihre Nachricht von Ihnen stammt.

Zum Beispiel mit dem Schlüssel “ richtige Heftklammer für Pferdebatterien “ und die Meldung “ Beispiel „, Ich kann den MAC “ 58393 “ berechnen. Wenn ich diese Nachricht mit dem MAC an Sie sende (Sie kennen den Schlüssel bereits), können Sie dieselbe Berechnung durchführen und den berechneten MAC mit dem von mir gesendeten MAC abgleichen.

Ein Angreifer kann die Nachricht ändern kennt aber den Schlüssel nicht. Er kann den korrekten MAC nicht berechnen, und Sie wissen, dass die Nachricht nicht authentisch ist.

Durch die Angabe einer Sequenznummer bei der Berechnung des MAC können Sie die -Wiedergabe eliminieren Angriffe . SSL führt dies aus.

Sie sagten, der Client sendet einen Schlüssel, der dann zum Einrichten verwendet wird symmetrische Verschlüsselung. Was hindert einen Angreifer daran, es zu verwenden?

Der öffentliche Schlüssel des Servers funktioniert. Da wir überprüft haben, dass der öffentliche Schlüssel wirklich zum Server gehört und niemand anderes, wir kann den Schlüssel mit dem öffentlichen Schlüssel verschlüsseln. Wenn der Server diesen empfängt, kann er ihn mit dem privaten Schlüssel entschlüsseln. Wenn andere ihn empfangen, kann er ihn nicht entschlüsseln.

Aus diesem Grund ist auch die Schlüsselgröße wichtig: Je größer der öffentliche und der private Schlüssel sind, desto schwieriger ist es, den vom Client an den Server gesendeten Schlüssel zu knacken.

So knacken Sie SSL

Zusammenfassend :

• Versuchen Sie, wenn der Benutzer Zertifikatswarnungen ignoriert;
• Die Anwendung lädt möglicherweise Daten von Ein unverschlüsselter Kanal (z. B. HTTP), der manipuliert werden kann.
• Eine ungeschützte Anmeldeseite, die an HTTPS gesendet wird, kann so geändert werden, dass sie an HTTP gesendet wird.
• Nicht gepatchte Anwendungen anfällig für Exploits wie BEAST und CRIME;
• Rückgriff auf andere Methoden erfolgreich h als physischer Angriff;
• Exploit Seitenkanäle wie Nachrichtenlänge und Zeit zur Bildung der Nachricht verwendet;
• Warten Sie auf Quantenangriffe .

Siehe auch: Ein Schema mit vielen Angriffsvektoren gegen SSL von Ivan Ristic ^(png)

Im Detail:

Es gibt kein einfaches und direktes Weg; SSL ist sicher, wenn es richtig gemacht wird. Ein Angreifer kann versuchen, wenn der Benutzer Zertifikatswarnungen ignoriert, was die Sicherheit sofort beeinträchtigen würde. Wenn ein Benutzer dies tut, benötigt der Angreifer keinen privaten Schlüssel von einer Zertifizierungsstelle, um ein Zertifikat zu fälschen. Er muss lediglich ein eigenes Zertifikat senden.

Ein anderer Weg wäre ein Fehler in der Anwendung (Server- oder Client-Seite). Ein einfaches Beispiel sind Websites: Wenn eine der von der Website verwendeten Ressourcen (z. B. ein Bild oder ein Skript) über HTTP geladen wird, kann die Vertraulichkeit nicht mehr garantiert werden. Auch wenn Browser Senden Sie den HTTP-Referer-Header nicht, wenn Sie nicht sichere Ressourcen von einer sicheren Seite ( source ) anfordern. Es ist dennoch möglich, dass jemand, der den Datenverkehr abhört, errät, wo Sie sich befinden „wieder zu Besuch von; Wenn sie beispielsweise wissen, dass die Bilder X, Y und Z auf einer Seite verwendet werden, können sie davon ausgehen, dass Sie diese Seite besuchen, wenn Ihr Browser diese drei Bilder gleichzeitig anfordert. Darüber hinaus kann beim Laden von Javascript die gesamte Seite gefährdet sein. Ein Angreifer kann jedes Skript auf der Seite ausführen und beispielsweise ändern, an wen die Banküberweisung geht.

In diesem Fall (eine Ressource wird über HTTP geladen) gibt der Browser eine Warnung mit gemischtem Inhalt aus: Chrome , Firefox , Internet Explorer 9

Ein weiterer Trick für HTTP besteht darin, dass die Anmeldeseite nicht gesichert ist und an eine https-Seite gesendet wird. “ Großartig, “ Der Entwickler dachte wahrscheinlich, “ Jetzt speichere ich die Serverlast und die Das Passwort wird weiterhin verschlüsselt gesendet! “ Das Problem ist sslstrip , ein Tool, das die unsichere Anmeldeseite so ändert, dass es Wird irgendwo eingereicht, damit der Angreifer es lesen kann.

In den letzten Jahren gab es auch verschiedene Angriffe, z. B. die Sicherheitsanfälligkeit TLS-Neuverhandlung , sslsniff , BEAST und vor kurzem KRIMINALITÄT . Alle gängigen Browser sind jedoch vor all diesen Angriffen geschützt, sodass diese Sicherheitsanfälligkeiten kein Risiko darstellen, wenn Sie einen aktuellen Browser verwenden.

Zu guter Letzt können Sie auf andere Methoden zurückgreifen, um diese zu erhalten die Informationen, die SSL Ihnen verweigert. Wenn Sie die Verbindung des Benutzers bereits sehen und manipulieren können, ist es möglicherweise nicht so schwierig, einen seiner EXE-Downloads durch einen Keylogger zu ersetzen oder diese Person einfach physisch anzugreifen. Die Kryptografie ist möglicherweise ziemlich sicher, aber Menschen und menschliches Versagen ist immer noch ein schwacher Faktor. Laut dieses Dokuments von Verizon betrafen 10% der Datenverletzungen physische Angriffe (siehe Seite 3). Es ist sicherlich etwas zu beachten.

Kommentare

• Ich würde mich für eine etwas ausführlichere Erklärung für “ Ein Schlüssel wird “ gegen den symmetrischen Schlüssel ausgetauscht. Wie kommt es, dass jemand mit einem Paket-Sniffer nicht darauf zugreifen kann?
• @Yehosef Gute Frage! Ich habe vergessen, das in meiner Antwort zu erklären. Wenn man sich umschaut, stellt sich heraus, dass es tatsächlich eine Frage gibt, die diesem Thema gewidmet ist: security.stackexchange.com/q/6290/10863
• @ Iwazaru Alle CAs tun dies seit dem ersten Tag. Der Zweck eines Zertifikats besteht darin, den öffentlichen Schlüssel für eine bestimmte Domain bereitzustellen und ihn zu signieren, um zu beweisen, dass er wirklich der richtige Schlüssel für die Domain ist. Lassen Sie ‚ s Encrypt genau das tun, was es tun sollte: Überprüfen Sie, ob Sie Eigentümer der Domain sind, und signieren Sie Ihr Zertifikat (mit Ihrem Schlüssel), wenn Sie dies nachweisen können. Jetzt vertraut jeder, der vertraut, Let ‚ s Encrypt, das praktisch jeder Browser ist, diesem Zertifikat.
• Äh, nein. TLS wird in der Tat nur über TCP implementiert.
• Fand diesen grafischen SSL-Handshake-Prozess sehr klar.

Da das allgemeine Konzept von SSL bereits in einigen anderen Fragen behandelt wurde (z. B. this und that ), diesmal werde ich auf Details eingehen. Details sind wichtig. Diese Antwort wird etwas ausführlich sein.

Verlauf

SSL ist ein Protokoll mit einer langen Geschichte und mehreren Versionen.Erste Prototypen stammten von Netscape, als sie die ersten Versionen ihres Flaggschiff-Browsers Netscape Navigator entwickelten (dieser Browser hat Mosaic in den frühen Zeiten der Browserkriege, die immer noch toben, wenn auch mit neuen Konkurrenten). Version 1 wurde noch nie veröffentlicht, daher wissen wir nicht, wie es aussah. SSL Version 2 wird in einem Entwurf beschrieben, der dort gelesen werden kann. Es weist eine Reihe von Schwachstellen auf, von denen einige ziemlich schwerwiegend sind. Daher ist es veraltet und neuere SSL / TLS-Implementierungen unterstützen es nicht (während ältere standardmäßig deaktiviert sind). Ich werde nicht weiter von SSL Version 2 sprechen, außer als gelegentliche Referenz.

SSL Version 3 (die ich „SSLv3“ nennen werde) war ein erweitertes Protokoll, das noch heute funktioniert und weitgehend unterstützt wird. Obwohl das Protokoll immer noch Eigentum von Netscape Communications ist (oder wer es heutzutage besitzt), wurde es als „historischer RFC“ veröffentlicht ( RFC 6101 ). In der Zwischenzeit wurde das Protokoll mit einem neuen Namen standardisiert, um rechtliche Probleme zu vermeiden. Der neue Name lautet TLS .

Bisher wurden drei Versionen von TLS mit jeweils eigenen Versionen erstellt dedizierter RFC: TLS 1.0 , TLS 1.1 und TLS 1.2 . Sie sind sich untereinander und mit SSLv3 intern sehr ähnlich, sodass eine Implementierung SSLv3 und alle drei TLS-Versionen problemlos unterstützen kann, wobei mindestens 95% des Codes gemeinsam sind. Intern sind alle Versionen jedoch durch eine Versionsnummer im Format major.minor gekennzeichnet. SSLv3 ist dann 3.0, während die TLS-Versionen 3.1, 3.2 und 3.3 sind. Daher ist es kein Wunder, dass TLS 1.0 manchmal als SSL 3.1 bezeichnet wird (und es ist auch nicht falsch). SSL 3.0 und TLS 1.0 unterscheiden sich nur durch einige winzige Details. TLS 1.1 und 1.2 werden noch nicht allgemein unterstützt, obwohl es aufgrund möglicher Schwächen einen Anstoß dafür gibt (siehe unten für den „BEAST-Angriff“). SSLv3 und TLS 1.0 werden „überall“ unterstützt (selbst IE 6.0 kennt sie).

Kontext

SSL zielt darauf ab, einen sicheren bidirektionalen Tunnel für beliebige Daten bereitzustellen. Betrachten Sie TCP , das bekannte Protokoll zum Senden von Daten über das Internet. TCP arbeitet über die IP- „Pakete“ und stellt einen bidirektionalen Tunnel für Bytes bereit. Es funktioniert für jeden Bytewert und sendet sie in zwei Streams, die gleichzeitig arbeiten können. TCP erledigt die harte Arbeit, die Daten in Pakete aufzuteilen, zu bestätigen, wieder in die richtige Reihenfolge zu bringen, Duplikate zu entfernen und verlorene Pakete erneut zu senden. Aus Sicht der Anwendung, die TCP verwendet, gibt es nur zwei Streams, und die Pakete sind unsichtbar. Insbesondere werden die Streams nicht in „Nachrichten“ aufgeteilt (es liegt an der Anwendung, ihre eigenen Codierungsregeln zu verwenden, wenn sie Nachrichten haben möchte, und genau das ist HTTP tut dies.

TCP ist zuverlässig bei „Unfällen“, dh Übertragungsfehlern aufgrund von flockiger Hardware, Netzwerküberlastung und Personen mit Smartphones, die die Reichweite einer bestimmten Basisstation verlassen und andere nicht böswillige Ereignisse. Eine Person mit böser Absicht (der „Angreifer“) mit einem gewissen Zugriff auf das Transportmedium könnte jedoch alle übertragenen Daten lesen und / oder absichtlich ändern, und TCP schützt nicht davor SSL.

SSL setzt voraus, dass es über ein TCP-ähnliches Protokoll funktioniert, das einen zuverlässigen Stream bereitstellt. SSL implementiert keine Neuemission verlorener Pakete und dergleichen. Der Angreifer ist soll an der Macht sein, um die Kommunikation auf unvermeidbare Weise vollständig zu stören (zum Beispiel kann er die Kabel abschneiden), also ist es die Aufgabe von SSL:

• Änderungen erkennen (der Angreifer darf die Daten nicht stillschweigend ändern können)
• Gewährleistung der Vertraulichkeit von Daten (the Der Angreifer darf keine Kenntnis von den ausgetauschten Daten erlangen.

SSL erfüllt diese Ziele weitgehend (aber nicht absolut).

Datensätze

SSL ist geschichtet und die unterste Schicht ist das Aufzeichnungsprotokoll . Alle Daten, die in einem SSL-Tunnel gesendet werden, werden in Datensätze aufgeteilt. Über das Kabel (den zugrunde liegenden TCP-Socket oder das TCP-ähnliche Medium) sieht ein Datensatz folgendermaßen aus:

HH V1:V2 L1:L2 data

Dabei gilt Folgendes:

• HH ist ein einzelnes Byte, das den Datentyp im Datensatz angibt.Es sind vier Typen definiert: change_cipher_spec (20), alert (21), handshake (22) und application_data ( 23).
• V1: V2 ist die Protokollversion über zwei Bytes. Für alle derzeit definierten Versionen hat V1 den Wert 0x03, während V2 den Wert 0x00 für SSLv3, 0x01 für TLS 1.0 und 0x02 für TLS 1.1 hat und 0x03 für TLS 1.2.
• L1: L2 ist die Länge von data in Bytes (Big-Endian-Konvention ist verwendet: die Länge beträgt 256 * L1 + L2). Die Gesamtlänge von data darf 18432 Byte nicht überschreiten, in der Praxis kann sie diesen Wert jedoch nicht erreichen.

Ein Datensatz hat also eine Fünf- Byte-Header, gefolgt von höchstens 18 kB Daten. In der data werden symmetrische Verschlüsselungs- und Integritätsprüfungen angewendet. Wenn ein Datensatz ausgegeben wird, sollen sowohl Sender als auch Empfänger vereinbaren, welche kryptografischen Algorithmen derzeit angewendet werden und mit welchen Schlüsseln. Diese Übereinstimmung wird durch das im nächsten Abschnitt beschriebene Handshake-Protokoll erzielt. Zu diesem Zeitpunkt wird auch eine eventuelle Komprimierung angewendet.

Im Detail funktioniert das Erstellen eines Datensatzes folgendermaßen:

• Zunächst müssen einige Bytes übertragen werden ;; Dies sind Anwendungsdaten oder eine andere Art von Bytes. Diese Nutzlast besteht aus höchstens 16384 Bytes, möglicherweise jedoch aus weniger (eine Nutzlast der Länge 0 ist zulässig, aber es stellt sich heraus, dass Internet Explorer 6.0 diese überhaupt nicht mag ).
• Die Nutzdaten werden dann mit dem derzeit vereinbarten Komprimierungsalgorithmus komprimiert. Die Komprimierung ist zustandsbehaftet und kann daher vom Inhalt früherer Datensätze abhängen. In der Praxis ist die Komprimierung entweder „null“ (überhaupt keine Komprimierung) oder „Deflate“ ( RFC 3749 ), wobei letzterer derzeit höflich, aber fest der Ausgang angezeigt wird Tür im Webkontext aufgrund des jüngsten CRIME-Angriffs . Die Komprimierung zielt darauf ab, Daten zu verkürzen, muss sie jedoch in einigen ungünstigen Situationen unbedingt geringfügig erweitern (aufgrund des -Pigeonhole-Prinzips ). SSL ermöglicht eine Erweiterung von höchstens 1024 Bytes. Natürlich wird die Nullkomprimierung niemals erweitert (aber auch nie verkürzt). Deflate wird bei einer guten Implementierung um höchstens 10 Byte erweitert.
• Die komprimierte Nutzlast wird dann vor Änderungen geschützt und verschlüsselt. Wenn die aktuellen Verschlüsselungs- und Integritätsalgorithmen „null“ sind, ist dieser Schritt keine Operation. Andernfalls wird ein MAC angehängt, dann wird etwas aufgefüllt (abhängig vom Verschlüsselungsalgorithmus) und das Ergebnis wird verschlüsselt. Diese Schritte führen erneut zu einer Erweiterung, die der SSL-Standard auf 1024 zusätzliche Bytes begrenzt (zusammen mit der maximalen Erweiterung aus dem Komprimierungsschritt gelangen wir zu den 18432 Bytes, zu denen wir den 5-Byte-Header hinzufügen müssen).

Der MAC ist normalerweise HMAC mit einer der üblichen Hash-Funktionen (meistens MD5, SHA-1 oder SHA-256). (Mit SSLv3 ist dies nicht der „wahre“ HMAC, sondern etwas sehr Ähnliches und nach unserem besten Wissen so sicher wie HMAC). Bei der Verschlüsselung wird entweder eine Blockverschlüsselung im CBC-Modus oder die Stream-Verschlüsselung RC4 verwendet. Es ist zu beachten, dass theoretisch andere Arten von Modi oder Algorithmen verwendet werden könnten, beispielsweise einer dieser raffinierten Modi, die Verschlüsselungs- und Integritätsprüfungen kombinieren; Es gibt sogar einige RFC dafür . In der Praxis kennen die implementierten Implementierungen diese jedoch noch nicht, daher HMAC und CBC. Entscheidend ist, dass der MAC zuerst berechnet und an die Daten angehängt wird und das Ergebnis verschlüsselt wird. Dies ist MAC-dann-verschlüsseln und es ist eigentlich keine sehr gute Idee . Der MAC wird über die Verkettung der (komprimierten) Nutzdaten und einer Sequenznummer berechnet, sodass ein fleißiger Angreifer möglicherweise keine Datensätze austauschen kann.

Handshake

Der Handshake ist ein Protokoll, das innerhalb des Aufzeichnungsprotokolls abgespielt wird. Ziel ist es, die Algorithmen und Schlüssel festzulegen, die für die Datensätze verwendet werden sollen. Es besteht aus Nachrichten . Jede Handshake-Nachricht beginnt mit einem 4-Byte-Header, einem Byte, das den Nachrichtentyp beschreibt, und drei Bytes für die Nachrichtenlänge (Big-Endian-Konvention). Die aufeinanderfolgenden Handshake-Nachrichten werden dann mit Datensätzen gesendet, die mit dem Typ „Handshake“ gekennzeichnet sind (das erste Byte des Headers jedes Datensatzes hat den Wert 22).

Beachten Sie die Ebenen: Die Handshake-Nachrichten, komplett mit vier – Byte-Header werden dann als Datensätze gesendet, und jeder Datensatz auch hat einen eigenen Header. Darüber hinaus können mehrere Handshake-Nachrichten innerhalb desselben Datensatzes gesendet werden, und eine bestimmte Handshake-Nachricht kann auf mehrere Datensätze aufgeteilt werden.Aus der Sicht des Moduls, das die Handshake-Nachrichten erstellt, sind die „Datensätze“ nur ein Stream, auf dem Bytes gesendet werden können. Die tatsächliche Aufteilung dieses Streams in Datensätze ist nicht bekannt.

Vollständiger Handshake

Zunächst „vereinbaren“ Client und Server eine Nullverschlüsselung ohne MAC und Nullkomprimierung. Dies bedeutet, dass der Datensatz, den sie zuerst senden, als Klartext und ungeschützt gesendet wird.

Die erste Nachricht eines Handshakes ist eine ClientHello. Dies ist die Nachricht, mit der der Client seine Absicht erklärt, SSL auszuführen. Beachten Sie, dass „Client“ eine symbolische Rolle ist. es bedeutet „die Partei, die zuerst spricht“. Es kommt vor, dass im HTTPS-Kontext, bei dem es sich um HTTP innerhalb von SSL innerhalb von TCP handelt, alle drei Schichten den Begriff „Client“ und „Server“ haben und alle übereinstimmen (der TCP-Client ist auch der SSL-Client und der HTTP-Client), aber das ist eine Art Zufall.

Die Nachricht ClientHello enthält:

• das maximale Protokoll Version, die der Client unterstützen möchte;
• der „Client-Zufall“ (32 Bytes, von denen 28 mit einem kryptografisch starken Zahlengenerator generiert werden sollen);
• der “ Sitzungs-ID „(falls der Client eine Sitzung mit einem abgekürzten Handshake fortsetzen möchte, siehe unten);
• die Liste der“ Cipher Suites „, die dem Client bekannt sind, sortiert nach Client-Präferenzen;
• die Liste der Komprimierungsalgorithmen, die dem Client bekannt sind, sortiert nach Clientpräferenzen;
• einige optionale Erweiterungen.

A Verschlüsselungssuite ist eine symbolische 16-Bit-Kennung für eine Reihe von Kryptografien c Algorithmen. Beispielsweise hat die Verschlüsselungssuite TLS_RSA_WITH_AES_128_CBC_SHA den Wert 0x002F und bedeutet, dass Datensätze die HMAC / SHA-1- und AES-Verschlüsselung mit einem 128-Bit-Schlüssel verwenden und der Schlüsselaustausch durch Verschlüsselung erfolgt ein zufälliger Schlüssel mit dem öffentlichen RSA-Schlüssel des Servers.

Der Server antwortet auf die ClientHello mit einer ServerHello welches enthält:

• die Protokollversion, die der Client und der Server verwenden werden
• den „Server zufällig“ (32 Bytes, mit 28 zufällige Bytes);
• die Sitzungs-ID für diese Verbindung;
• die Verschlüsselungssuite, die verwendet wird;
• der Komprimierungsalgorithmus, der verwendet wird;
• optional einige Erweiterungen.

Der vollständige Handshake sieht folgendermaßen aus:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(Dieses Schema wurde schamlos aus dem RFC kopiert.)

Wir sehen die ClientHello und ServerHello. Dann sendet der Server einige andere Nachrichten, die von der Cipher Suite und einigen anderen Parametern abhängen rs:

• Zertifikat: das Zertifikat des Servers, das seinen öffentlichen Schlüssel enthält. Mehr dazu weiter unten. Diese Nachricht wird fast immer gesendet, außer wenn die Cipher Suite einen Handshake ohne Zertifikat vorschreibt.
• ServerKeyExchange: einige zusätzliche Werte für den Schlüsselaustausch, wenn das, was im Zertifikat enthalten ist, nicht ausreicht. Insbesondere verwenden die „DHE“ -Cipher-Suites einen kurzlebigen Diffie-Hellman -Schlüsselaustausch, für den diese Nachricht erforderlich ist.
• CertificateRequest: eine Nachricht, in der der Client auch mit einem eigenen Zertifikat identifiziert wird. Diese Nachricht enthält die Liste der Namen von Vertrauensankern (auch als „Stammzertifikate“ bezeichnet), mit denen der Server das Clientzertifikat überprüft.
• ServerHelloDone: eine Markierungsnachricht (mit der Länge Null), die besagt, dass der Server fertig ist und der Client jetzt sprechen sollte.

Der Client muss dann antworten mit:

• Zertifikat: das Client-Zertifikat, if Der Server hat einen angefordert. Es gibt geringfügige Unterschiede zwischen den Versionen (bei SSLv3 muss der Client diese Nachricht weglassen, wenn er kein Zertifikat hat; bei TLS 1.0+ muss er in derselben Situation eine Certificate senden Nachricht mit einer leeren Liste von Zertifikaten).
• ClientKeyExchange: der Client-Teil des eigentlichen Schlüsselaustauschs (z. B. ein mit dem Server-RSA-Schlüssel verschlüsselter Zufallswert).
• CertificateVerify: a Digitale Signatur , die vom Client über alle vorherigen Handshake-Nachrichten berechnet wurde. Diese Nachricht wird gesendet, wenn der Server ein Client-Zertifikat angefordert hat und der Client die Anforderungen erfüllt hat. Auf diese Weise beweist der Client dem Server, dass er den öffentlichen Schlüssel, der in dem von ihm gesendeten Zertifikat codiert ist, wirklich „besitzt“.

Dann sendet der Client eine ChangeCipherSpec Nachricht, bei der es sich nicht um eine Handshake-Nachricht handelt: Sie hat einen eigenen Datensatztyp und wird daher in einem eigenen Datensatz gesendet.Sein Inhalt ist rein symbolisch (ein einzelnes Byte mit dem Wert 1). Diese Nachricht markiert den Punkt, an dem der Client zur neu ausgehandelten Verschlüsselungssuite und zu den Schlüsseln wechselt. Die nachfolgenden Datensätze vom Client werden dann verschlüsselt.

Die Nachricht Fertig ist eine kryptografische Prüfsumme, die berechnet wird über alle vorherigen Handshake-Nachrichten (sowohl vom Client als auch vom Server). Da es nach ChangeCipherSpec ausgegeben wird, wird es auch von der Integritätsprüfung und der Verschlüsselung abgedeckt. Wenn der Server diese Nachricht empfängt und ihren Inhalt überprüft, erhält er einen Beweis dafür, dass er tatsächlich die ganze Zeit mit demselben Client gesprochen hat. Diese Nachricht schützt den Handshake vor Änderungen (der Angreifer kann die Handshake-Nachrichten nicht ändern und erhält trotzdem die Finished -Nachricht richtig).

Der Server antwortet schließlich mit seinem eigenen ChangeCipherSpec dann Finished. Zu diesem Zeitpunkt ist der Handshake beendet und der Client und der Server können Anwendungsdaten austauschen (in verschlüsselten Datensätzen, die als solche gekennzeichnet sind).

Beachten Sie Folgendes: der Client schlägt vor, aber der Server wählt . Die Cipher Suite befindet sich in den Händen des Servers. Höfliche Server sollten (wenn möglich) den Vorlieben des Clients folgen, können dies jedoch anders und einige tatsächlich (z. B. als Teil des Schutzes vor BEAST).

Abgekürzter Handshake

Beim vollständigen Handshake sendet der Server eine „Sitzungs-ID“ (dh eine Gruppe von bis zu 32 Byte) an den Client. Später kann der Client zurückkommen und dieselbe Sitzungs-ID als Teil seiner ClientHello senden. Dies bedeutet, dass sich der Client weiterhin die Verschlüsselungssuite und die Schlüssel aus dem vorherigen Handshake merkt und diese Parameter wiederverwenden möchte. Wenn sich der Server auch an die Verschlüsselungssuite und die Schlüssel erinnert, kopiert er diese bestimmte Sitzungs-ID in seine ServerHello und folgt dann der abgekürzter Handshake :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

Der abgekürzte Handshake ist kürzer: weniger Nachrichten, nein Geschäft mit asymmetrischer Kryptographie und vor allem reduzierte Latenz . Webbrowser und Server machen das oft. Ein typischer Webbrowser öffnet eine SSL-Verbindung mit einem vollständigen Handshake und führt dann abgekürzte Handshakes für alle anderen Verbindungen zu demselben Server durch: die anderen Verbindungen, die parallel geöffnet werden, sowie die nachfolgenden Verbindungen zu demselben Server. In der Tat werden typische Webserver Verbindungen nach 15 Sekunden Inaktivität schließen, aber sie werden sich Sitzungen (die Verschlüsselungssuite und die Schlüssel) viel länger (möglicherweise für Stunden oder sogar Tage) merken.

Schlüsselaustausch

Es gibt mehrere Schlüsselaustauschalgorithmen, die SSL verwenden kann. Dies wird von der Cipher Suite angegeben. Jeder Schlüsselaustauschalgorithmus funktioniert mit einigen Arten von öffentlichen Serverschlüsseln. Die gebräuchlichsten Schlüsselaustauschalgorithmen sind:

• RSA: Der Schlüssel des Servers ist vom Typ RSA. Der Client generiert einen zufälligen Wert (den “ Pre-Master-Geheimnis „von 48 Bytes, von denen 46 zufällig sind) und verschlüsselt es mit dem öffentlichen Schlüssel des Servers. Es gibt kein ServerKeyExchange.
• DHE_RSA: Der Schlüssel des Servers ist vom Typ RSA, wird jedoch nur für verwendet Signatur. Der eigentliche Schlüsselaustausch verwendet Diffie-Hellman. Der Server sendet eine ServerKeyExchange -Nachricht, die die DH-Parameter (Modul, Generator) und einen neu generierten öffentlichen DH-Schlüssel sowie den Server enthält signiert diese Nachricht. Der Client antwortet mit einer ClientKeyExchange -Nachricht, die auch einen neu generierten öffentlichen DH-Schlüssel enthält. Der DH gibt das „Pre-Master-Geheimnis“ aus „.
• DHE_DSS: wie DHE_RSA, aber der Server verfügt über einen DSS-Schlüssel (“ DSS „ist ebenfalls bekannt als „DSA“ ). DSS ist ein Nur-Signatur-Algorithmus.

Weniger häufig verwendete Schlüsselaustauschalgorithmen umfassen:

• DH: Der Schlüssel des Servers ist vom Typ Diffie-Hellman (es handelt sich um ein Zertifikat , das a enthält DH-Taste). Dies war früher auf administrative Weise „populär“ (die US-Bundesregierung hat seine Verwendung vorgeschrieben), als das RSA-Patent noch aktiv war (dies war im vorigen Jahrhundert). Trotz des bürokratischen Vorstoßes war es nie so weit verbreitet wie RSA.
• DH_anon: Wie die DHE -Suiten, aber ohne die Signatur vom Server. Dies ist eine zertifikatlose Verschlüsselungssuite. Aufgrund seiner Konstruktion ist es anfällig für Man-in-the-Middle-Angriffe und wird daher nur sehr selten aktiviert.
• PSK: Pre-Shared Key Cipher Suites. Der nur symmetrische Schlüsselaustausch, der auf einem zuvor festgelegten gemeinsamen Geheimnis aufbaut.
• SRP: Die Anwendung des SRP-Protokolls , das ein Protokoll zum Austausch authentifizierter Schlüsselschlüssel . Client und Server authentifizieren sich gegenseitig in Bezug auf ein gemeinsames Geheimnis, bei dem es sich um ein Kennwort mit niedriger Entropie handeln kann (während PSK ein gemeinsames Geheimnis mit hoher Entropie erfordert). Sehr geschickt. Noch nicht weit verbreitet.
• Ein kurzlebiger RSA-Schlüssel: wie DHE, jedoch mit einem neu generierten RSA-Schlüsselpaar. Da das Generieren von RSA-Schlüsseln teuer ist, ist dies keine beliebte Option und wurde nur als Teil von „Export“ -Cipher-Suites angegeben, die den US-Exportbestimmungen für Kryptografie vor 2000 (d. H. RSA-Schlüssel mit höchstens 512 Bit) entsprachen. Das macht heutzutage niemand mehr.
• Varianten der DH* -Algorithmen mit elliptischen Kurven . Sehr modisch. Sollte in Zukunft üblich werden.

Zertifikate und Authentifizierung

Digitale Zertifikate sind Gefäße für asymmetrische Schlüssel. Sie sollen die Schlüsselverteilung lösen. Der Client möchte nämlich den öffentlichen Schlüssel des Servers verwenden. Der Angreifer versucht, den Client dazu zu bringen, den öffentlichen Schlüssel des Angreifers zu verwenden. Der Client muss also eine Möglichkeit haben, um sicherzustellen, dass er den richtigen Schlüssel verwendet.

SSL soll X.509 verwenden. Dies ist ein Standard für Zertifikate. Jedes Zertifikat wird von einer Zertifizierungsstelle signiert . Die Idee ist, dass der Client die öffentlichen Schlüssel einer Handvoll Zertifizierungsstellen von Natur aus kennt (dies sind die „Vertrauensanker“ oder „Stammzertifikate“). Mit diesen Schlüsseln kann der Client die von einer Zertifizierungsstelle berechnete Signatur über ein an den Server ausgestelltes Zertifikat überprüfen . Dieser Prozess kann rekursiv erweitert werden: Eine Zertifizierungsstelle kann ein Zertifikat für eine andere Zertifizierungsstelle ausstellen (d. H. Die Zertifikatstruktur, die den anderen Namen und Schlüssel der Zertifizierungsstelle enthält, signieren ). Eine Kette von Zertifikaten, die mit einer Stammzertifizierungsstelle beginnt und mit dem Zertifikat des Servers endet, mit dazwischen liegenden Zwischenzertifizierungsstellenzertifikaten, wobei jedes Zertifikat relativ zu dem öffentlichen Schlüssel signiert ist, der im vorherigen Zertifikat codiert ist, wird einfallslos als Zertifikatskette .

Der Client muss also Folgendes tun:

• Ruft eine Zertifikatkette ab, die mit dem Zertifikat des Servers endet. Die Nachricht Certificate vom Server soll genau eine solche Kette enthalten.
• Validieren Sie die Kette, dh überprüfen Sie alle Signaturen und Namen sowie die verschiedenen X.509-Bits. Außerdem sollte der Client den Widerrufsstatus aller Zertifikate in der Kette überprüfen, der komplex und schwer ist (Webbrowser tun dies jetzt mehr oder weniger, aber es ist eine neuere Entwicklung).
• Stellen Sie sicher, dass der beabsichtigte Servername tatsächlich im Zertifikat des Servers geschrieben ist. Da der Client nicht nur einen validierten öffentlichen Schlüssel verwenden möchte, Es möchte auch den öffentlichen Schlüssel eines bestimmten Servers verwenden. Weitere Informationen dazu finden Sie unter RFC 2818 in einem HTTPS-Kontext

Das Zertifizierungsmodell mit X.509-Zertifikaten wurde oft kritisiert, nicht wirklich aus technischen Gründen, sondern aus politisch-wirtschaftlichen Gründen. Es konzentriert die Validierungskraft auf die Hände einiger weniger Spieler , die nicht unbedingt gut gemeint oder zumindest nicht immer kompetent sind. Hin und wieder werden Vorschläge für andere Systeme veröffentlicht (z. B. Konvergenz oder

Nachher Die langwierige Darstellung von SSL in der vorherigen Antwort lässt uns mit den lustigen Dingen beginnen, nämlich:

Angriffe auf SSL

Es gab viele Angriffe auf SSL, einige bauten auf Implementierungsfehlern auf, andere auf echte Protokollschwächen.

Man muss bedenken, dass SSL zwar eines der am meisten angegriffenen Protokolle ist (da es sehr bekannt ist: Eine erfolgreiche Anwendung auf SSL sieht in der Zusammenfassung eines Forschungsartikels sehr gut aus). SSL ist auch eines der am häufigsten reparierten Protokolle.Es ist gerade deshalb als robust anzusehen, weil alle bekannten Methoden zum Angriff auf Transportprotokolle unter SSL ausprobiert und SSL gegebenenfalls gepatcht wurden.

Versions-Rollback

In den frühen Tagen von SSLv3 war SSLv2 noch weit verbreitet, und daher sendeten Clients häufig SSLv2-kompatibel ClientHello -Nachrichten, die lediglich darauf hinweisen, dass auch SSLv3 unterstützt wird; Der Server würde dann den Hinweis nehmen und in SSLv3 + -Dialekt antworten (Einzelheiten finden Sie in Anhang E von RFC 2246 ). Da SSLv2 Schwächen aufwies, war es im besten Interesse des Angreifers, dafür zu sorgen, dass ein Client und ein Server, die beide SSLv3 kennen, dennoch über SSLv2 miteinander kommunizieren. Dies wird als Versions-Rollback-Angriff bezeichnet. Das Konzept erstreckt sich formal auch auf spätere Versionen.

Kludges wurden hinzugefügt, um Rollback-Versuche zu erkennen. Für die Back-to-SSLv2-Rollbacks sollte ein Client, der SSLv3 + kennt, ein spezielles Padding für den RSA-Verschlüsselungsschritt verwenden (SSLv2 unterstützt nur den RSA-basierten Schlüsselaustausch): in PKCS # 1 sollen die zu verschlüsselnden Daten mit einer Anzahl von zufälligen Bytes aufgefüllt werden; Ein SSLv3-fähiger Client soll dann jedes der letzten acht Füllbytes auf den festen Wert 0x03 setzen. Der Server überprüft dann diese Bytes. Wenn die acht 0x03 gefunden werden, wird höchstwahrscheinlich ein Rollback versucht, und der Server lehnt den Versuch ab (ein Nur-SSLv2-Client hat nur eine Wahrscheinlichkeit von 255 ^-8 , solche Auffüllbytes aus purem Mangel an zu verwenden Glück, so dass falsch positive Ergebnisse mit einer vernachlässigbaren Rate auftreten.

Für Rollbacks auf eine alte Version von SSL / TLS, die jedoch nicht älter als SSLv3 ist, wurde ein weiterer Kludge hinzugefügt: im Pre-Master-Geheimnis von 48 Bytes, die der Client mit dem RSA-Schlüssel des Servers verschlüsselt, sind die ersten beiden Bytes nicht zufällig, sondern sollten der „maximal unterstützten Protokollversion“ entsprechen, die der Client zuerst in seine -Nachricht. Leider haben einige Clients etwas falsch gemacht, und dieser Kludge funktioniert nur mit einem RSA-basierten Schlüsselaustausch, sodass der Schutz gegen Rollback dort sehr begrenzt ist. Glücklicherweise hat SSLv3 + einen weiteren, viel leistungsstärkeren Schutz gegen Rollbacks, dh die Handshake-Nachrichten werden zusammen gehasht, wenn die Finished -Nachrichten erstellt werden. Dieser Pro wirkt sich gegen Rollbacks aus, es sei denn, die „alte Version“ wäre so durch und durch schwach, dass der Angreifer die gesamte Verschlüsselung vor dem Ende des Handshakes selbst vollständig aufheben könnte. Dies ist noch nicht geschehen (SSLv3 ist immer noch recht robust).

Schwache Cipher Suites

Einige der Standard-Chiffresuiten sind absichtlich schwach. Es gibt:

• einige Cipher Suites ohne Verschlüsselung, nur Integritätsprüfung, z. TLS_RSA_WITH_NULL_SHA;
• einige Cipher Suites mit 40-Bit-Verschlüsselung, wie z. B. TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (Cipher Suites, die den Anforderungen entsprechen sollen die strengen US-Exportregeln des letzten Jahrhunderts (diese Vorschriften wurden größtenteils am Ende der Bill Clinton-Ära aufgehoben);
• einige Chiffresuiten mit 56-Bit-Verschlüsselung, wie TLS_RSA_WITH_DES_CBC_SHA. 56-Bit-DES ist mit der vorhandenen Technologie zerbrechlich, aber für einen Amateur (selbst einen gelangweilten Studenten mit Zugang zu einigen hundert Universitätsmaschinen) ist das immer noch ein bisschen schwierig ), daher neige ich dazu, 56-Bit-DES als „mittlere Stärke“ zu qualifizieren.

Dies eröffnet den Weg zu einer Variante von Versions-Rollback-Angriffen, bei denen der Angreifer Client und Server zur Übereinstimmung zwingt Bei einer schwachen Verschlüsselungssuite besteht die Idee darin, dass der Angreifer die Liste der vom Client angekündigten Verschlüsselungssuiten ändert. Dies ist für den Angreifer möglich, wenn die ausgewählte Verschlüsselungssuite so schwach ist, dass er sie beschädigen kann, um eine scheinbar korrekte Finished Nachricht. Tatsächlich ist der in SSLv3 + verwendete MAC (auch wenn er auf MD5 basiert) robust genug, um dies zu verhindern. Also keine wirkliche Sorge hier. Außerdem ist meine Meinung, dass hier eine echte Schwäche vorliegt Dies ist der Fall, wenn ein Client oder ein Server akzeptiert, überhaupt eine schwache Verschlüsselungssuite zu verwenden.

Moderne Webbrowser erlauben standardmäßig nicht die Verwendung solcher schwachen Verschlüsselungssuiten.

Diebstahl privater Schlüssel

Wenn eine SSL-Verbindung den RSA-Schlüsselaustausch verwendet, Ein Angreifer bewahrt eine Kopie der Datensätze auf und erhält später (möglicherweise Monate später, möglicherweise durch Überprüfen aller Sicherungen auf weggeworfenen Festplatten oder Bändern) eine Kopie des privaten Schlüssels. Anschließend kann er diese entwirren Beim Handshake und beim Entschlüsseln der Daten.

Bei Perfect Forward Secrecy geht es darum, „später“ dem entgegenzuwirken. Sie erhalten es mithilfe der DHE Chiffresuiten. Bei einer DHE-Verschlüsselungssuite ist der tatsächliche private Schlüssel, der zum Entschlüsseln des Handshakes verwendet werden kann, der kurzlebige Diffie-Hellman-Schlüssel, nicht der private RSA- (oder DSS-) Schlüssel des Servers.Da es kurzlebig war, existierte es nur im RAM und wurde nie auf die Festplatte geschrieben. Daher sollte es viel widerstandsfähiger gegen Hintergedanken sein.

Die Lektion lautet also: Versuchen Sie in der Regel, wenn möglich, eine DHE-Verschlüsselungssuite zu verwenden. Sie sollten sich immer noch um Ihre Backups kümmern und nicht zulassen, dass Ihr privater Schlüssel ausläuft, aber zumindest machen die DHE-Suiten einen solchen Verlust etwas weniger problematisch, insbesondere wenn er nach dem Ende der Lebensdauer des Schlüssels auftritt (dh das entsprechende Zertifikat ist nein länger gültig).

Zertifikat leidet

Das gesamte Zertifikatgeschäft ist a Wunde Stelle in SSL.

Technisch gesehen ist SSL ziemlich unabhängig von X.509. Die Zertifikatsketten werden als undurchsichtige Blobs ausgetauscht. Irgendwann muss der Client den öffentlichen Schlüssel des Servers verwenden, aber der Client kann diesen Schlüssel nach eigenem Ermessen „kennen“. In bestimmten Szenarien, in denen SSL verwendet werden kann, kennt der Client den Server bereits „s öffentlicher Schlüssel (im Code fest codiert) und ignoriert nur das vom Server gesendete Zertifikat. Im allgemeinen Fall von HTTPS führt der Client jedoch eine Validierung der Zertifikatkette des Servers durch, wie in X.509 ( Lesen Sie es auf Kosten Ihrer geistigen Gesundheit (Sie wurden gewarnt).

Dies ergibt eine Reihe von Angriffsvektoren, zum Beispiel:

• Bei der Validierung muss dies überprüft werden Die Zertifikate sind zum aktuellen Datum noch gültig. Woher kennt der Client-Computer das aktuelle Datum? Mit seiner internen Uhr und möglicherweise durch Gespräche mit NTP-Servern (in ein ziemlich ungeschützter Weg!). Der Client könnte um einige Minuten, Stunden, Tage, sogar Jahre (ich habe es gesehen) ausgeschaltet sein, und bis zu einem gewissen Grad könnte ein mächtiger Angreifer dies erzwingen, indem er mit NTP-Nachrichten herumfummelt. Dies würde es ermöglichen Der Angreifer verwendet veraltete Zertifikate, die vor Jahren widerrufen wurden. Beachten Sie eine lustige Tatsache: Die SSL „Client Random“ und „Server Random“ sollten 28 zufällige Bytes und das lokale Datum und die lokale Uhrzeit (über 4) enthalten Bytes). Diese Aufnahme of time sollte Teil einer Problemumgehung gegen zeitbasierte Angriffe sein. Mir ist keine Implementierung bekannt, die dies wirklich überprüft.

• Bis ca. 2003 hat die Implementierung der Zertifikatsüberprüfung in Internet Explorer / Windows die Erweiterung „Basic Constraints“ nicht verarbeitet richtig. Der Nettoeffekt war, dass jeder mit einem 100 € -Zertifikat als Zertifizierungsstelle fungieren und „Zertifikate“ mit willkürlich ausgewählten Namen und Schlüsseln ausstellen konnte.

• X. .509 enthält eine Schadensbegrenzungsfunktion namens Widerruf : Hier geht es darum, eine Liste verbannter Zertifikate zu veröffentlichen, die kryptografisch gut aussehen, aber nicht vertrauenswürdig sind (z. B. wenn ihr privater Schlüssel gestohlen wurde oder sie enthalten) ein falscher Name). Der Widerruf funktioniert nur, soweit die beteiligten Parteien (d. H. Browser) das Herunterladen von Mammut-Widerrufslisten (die mehrere Megabyte lang sein können!) Akzeptieren oder OCSP-Server kontaktieren. Moderne Browser tun dies jetzt, aber etwas widerstrebend, und viele akzeptieren es trotzdem, eine Verbindung herzustellen, wenn sie die Informationen zum Widerrufsstatus nicht rechtzeitig erhalten können (weil der menschliche Benutzer nicht geduldig ist). Die Gesamtsituation verbessert sich im Laufe der Jahre, jedoch recht langsam.

• Einige Stammzertifizierungsstellen haben in der Vergangenheit einige Fehler begangen (z. B. Comodo und DigiNotar). Dies führte zur Ausstellung gefälschter Zertifikate (der Name lautet www.microsoft.com, aber der private Schlüssel befindet sich überhaupt nicht in der Hand von Microsoft …). Diese Fehler wurden entdeckt und die Zertifikate widerrufen, aber es wirft immer noch einige unangenehme Fragen auf (z. B. gibt es andere Zertifizierungsstellen, die solche Probleme hatten, sie aber nicht enthüllten oder, noch schlimmer, sie nie bemerkten?).

X.509 ist eine sehr komplexe Zusammenstellung von Algorithmen, Technologien, Spezifikationen und Komitees, und es ist sehr schwierig, sie richtig zu machen. Der Versuch, X.509-Zertifikate „von Hand“ in einer ungeschützten Programmiersprache wie C zu dekodieren, ist eine einfache Möglichkeit, Pufferüberläufe zu erhalten.

Bleichenbacher Attacks

Daniel Bleichenbacher fand 1998 einen schönen Angriff gegen RSA. Wenn Sie ein Datenelement mit RSA verschlüsseln (wie dies für die Nachricht ClientKeyExchange in SSL der Fall ist), müssen die zu verschlüsselnden Daten der Reihe nach aufgefüllt sein um eine Byte-Sequenz mit der gleichen Länge wie der RSA-Modul zu erstellen. Das Auffüllen besteht hauptsächlich aus zufälligen Bytes, aber es gibt ein wenig Struktur (insbesondere müssen die ersten beiden Bytes nach dem Auffüllen 0x00 0x02 sein).

Bei der Entschlüsselung (dann auf dem Server) muss das Auffüllen erfolgen gefunden und entfernt werden. Es kommt vor, dass zu diesem Zeitpunkt, als der Server entschlüsselt, aber eine ungültige Auffüllung erhalten hat (die 0x00 0x02-Bytes waren nicht vorhanden), diese mit einer Warnmeldung (gemäß der SSL-Spezifikation) gemeldet wurde, während eine gültige Auffüllung dazu führte Der Server verwendet den scheinbar entschlüsselten Wert und macht mit dem Handshake weiter.

Diese Art von Dingen wird als Padding Orakel bezeichnet. Es ermöglicht einem Angreifer, eine beliebige Folge von Bytes zu senden, als wäre es ein verschlüsseltes Pre-Master-Geheimnis, und zu wissen, ob die Entschlüsselung dieser Folge eine gültige Auffüllung ergeben würde oder nicht. Dies ist nur eine 1-Bit-Information, aber es reicht aus, den privaten Schlüssel mit ein paar Millionen Anfragen (mit geschickt gestalteten „verschlüsselten“ Zeichenfolgen) wiederherzustellen.

Problemumgehung: Wenn die Entschlüsselung zu einer Ungültigkeit führt Beim Auffüllen verwendet der Server weiterhin ein zufälliges Pre-Master-Geheimnis. Der Handshake schlägt später mit den Nachrichten Finished fehl. Alle aktuellen Implementierungen von SSL tun dies.

Das Padding-Orakel schlägt zurück

Ein weiterer Bereich, in dem ein Padding-Orakel gefunden wurde, befindet sich im Berücksichtigen Sie CBC-Verschlüsselung und HMAC. Die zu verschlüsselnden Daten werden zuerst MAC-fähig und dann das Ergebnis verschlüsselt. Bei der CBC-Verschlüsselung müssen die zu verschlüsselnden Daten eine Länge haben, die ein Vielfaches der Blockgröße beträgt (8 Byte für 3DES, 16 Bytes für AES). Daher wird ein gewisses Auffüllen mit einer gewissen Struktur angewendet.

Zu diesem Zeitpunkt (der Angriff wurde von Vaudenay im Jahr 2002 herausgefunden), als eine SSL-Implementierung einen Empfang verarbeitete d record gab unterschiedliche Warnmeldungen für diese beiden Bedingungen zurück:

• Bei der Entschlüsselung wurde keine gültige Auffüllstruktur gefunden.
• Bei der Entschlüsselung Es wurde eine gültige Auffüllung gefunden, aber dann wurde der MAC überprüft und stimmte nicht überein.

Dies ist ein Auffüllungs-Orakel, mit dem einige verschlüsselte Daten wiederhergestellt werden können. Es erfordert einen aktiven Angreifer, aber es ist nicht so schwer. Vaudenay hat es implementiert und es wurde auf den Fall erweitert, dass eine modifizierte SSL-Implementierung in beiden Fällen dieselbe Warnmeldung zurückgab, die Rückkehr im zweiten Fall jedoch länger dauerte, da die Zeit für die Neuberechnung des MAC benötigt wird (eine nette Demonstration von ein Timing-Angriff ).

Da die Leute nie erfahren, war die in ASP.NET verwendete Microsoft-Implementierung von SSL noch nicht gepatcht ab 2010 (acht Jahre später!), als Rizzo und Duong den Vaudenay-Angriff erneut implementierten und eine Demonstration erstellten, in der HTTP-Cookies wiederhergestellt wurden.

Siehe diese Seite für einige Hinweise. Man muss beachten, dass, wenn SSL encrypt-then-MAC verwendet hätte, solche Probleme vermieden worden wären (die fehlerhaften Datensätze wären zuvor auf MAC-Ebene zurückgewiesen worden auch unter Berücksichtigung der Entschlüsselung).

BEAST

Der BEAST-Angriff ist wieder von Duong und Rizzo, und es ist wieder ein Remake eines älteren Angriffs (von Philip Rogaway im Jahr 2002). Betrachten Sie CBC , um auf die Idee zu kommen. In dieser Betriebsart wird jeder Datenblock zuerst mit dem Ergebnis der Verschlüsselung des vorherigen Blocks XOR-verknüpft. und das ist das Ergebnis des XOR, das verschlüsselt ist. Dies geschieht, um die Blöcke zu „randomisieren“ und die Lecks zu vermeiden, die im EZB-Modus gefunden werden. Da der erste Block nicht hat Bei einem „vorherigen“ Block muss ein Initialisierungsvektor (IV) vorhanden sein, der die Rolle des vorherigen Blocks für den ersten Block spielt.

Es stellt sich heraus, dass ein Angreifer, wenn er einen Teil der zu verschlüsselnden Daten steuern und auch die IV vorhersagen kann, die verwendet werden soll, die Verschlüsselungsmaschine in eine weitere Entschlüsselung umwandeln kann Orakel und verwenden Sie es, um einige andere verschlüsselte Daten wiederherzustellen (die der Angreifer nicht auswählt). In SSLv3 und TLS 1.0 kann der Angreifer jedoch die IV für einen Datensatz vorhersagen: Dies ist der letzte Block von Der Angreifer muss also in der Lage sein, einige Daten im Stream zu senden, um die Zieldaten an einem Punkt zu „pushen“, an dem die Implementierung den vorherigen Datensatz erstellt und gesendet hat (normalerweise bei einem Wert von 16 kB) von Daten wurden akkumuliert), aber es wurde nicht mit dem Erstellen der nächsten begonnen.

TLS 1.1+ ist dagegen geschützt, da in TLS 1.1 (und nachfolgenden Versionen) eine zufällige IV pro Datensatz verwendet wird. Für SSLv3 und TLS 1.0 besteht eine Problemumgehung darin, Datensätze mit der Länge Null zu senden, dh Datensätze mit einer Nutzlast der Länge Null, jedoch mit einem MAC und Auffüllen und Verschlüsselung, und der MAC wird aus einem geheimen Schlüssel und über die Sequenz berechnet Dies spielt also die Rolle eines Zufallszahlengenerators. Leider drosselt IE 6.0 bei Datensätzen mit der Länge Null. Andere Strategien beinhalten eine 1 / n-1-Aufteilung (ein n Byte-Datensatz wird als zwei Datensätze gesendet, einer mit einem einzelnen Byte Nutzlast, der andere mit dem verbleibenden n-1 ).

Eine andere Problemumgehung besteht darin, die Verwendung einer Nicht-CBC-Verschlüsselungssuite zu erzwingen, wenn dies möglich ist. Der Server wählt eine RC4-basierte Verschlüsselungssuite aus, falls eine in der Liste der von der Client, selbst wenn der Client eine CBC-basierte Verschlüsselungssuite bevorzugt hätte. Mit diesem Tool können Sie feststellen, ob sich ein bestimmter Server anscheinend so verhält.(Hinweis: BEAST ist ein Angriff auf den Client . Durch Auswahl einer RC4-Verschlüsselungssuite kann der Server jedoch einen unachtsamen Client schützen.)

Siehe diese Seite für einige Hinweise. Während TLS 1.1 aus dem Jahr 2006 stammt, kann der BEAST-Angriff die Browser-Anbieter zu einem endgültigen Upgrade zwingen.

CRIME

Wie bei jedem Hollywood-Franchise haben Duong und Rizzo 2012 die Fortsetzung der Fortsetzung veröffentlicht. CRIME nutzt eine Leckage aus, die vor Jahren theoretisiert wurde, aber nur in der kürzlich veröffentlichten Demonstration anschaulich demonstriert wurde. CRIME nutzt die Komprimierung im selben Setup wie der BEAST-Angriff (der Angreifer kann einige eigene Daten in einer SSL-Verbindung senden, wobei auch interessante Zieldaten wie ein Cookie gesendet werden). Grob gesagt gibt der Angreifer in seinen Daten einen potenziellen Wert für die Zielzeichenfolge ein. Wenn dies übereinstimmt, werden die resultierenden Datensätze durch Komprimierung kürzer. Siehe diese Frage für eine (vorkognitive) Analyse.

CRIME wird vermieden, indem überhaupt keine Komprimierung auf TLS-Ebene verwendet wird Was Browser jetzt tun. Internet Explorer und IIS haben die Komprimierung auf TLS-Ebene nie implementiert (ausnahmsweise hat Schlamperei den Tag gerettet). Firefox und Chrome haben es implementiert und diesen Sommer deaktiviert (sie wurden von Duong und Rizzo, die für ihre Aktivitäten verantwortlich sind, vorgewarnt).

CRIME zeigt, warum ich am Anfang meines SSL-Erklärungen :

SSL erfüllt diese Ziele weitgehend (aber nicht absolut). P. >

In der Tat verliert die Verschlüsselung die Länge der verschlüsselten Daten. Es ist keine gute Lösung dafür bekannt. Und die Länge allein kann viele Dinge offenbaren. Wenn Sie beispielsweise mit einem Netzwerkmonitor eine SSL-Verbindung beobachten, können Sie die „zusätzlichen Handshakes“ im Stream erkennen (da das erste Byte jedes Datensatzes den Datentyp im Datensatz identifiziert und nicht verschlüsselt ist). Mit den Längen der Datensätze ist es ziemlich einfach zu erkennen, ob der Client ein Zertifikat bereitgestellt hat oder nicht.

Pudel

( edit: Dieser Abschnitt wurde hinzugefügt am 15.10.2014)

Der „Pudel“ -Angriff nutzt einen Fehler aus, der für SSL 3.0 mit CBC-basierten Cipher Suites spezifisch ist. Es basiert auf einer häufig übersehenen Funktion von SSL 3.0: Die meisten Füllbytes werden ignoriert. In TLS 1.0 ist das Auffüllen (Bytes, die in einem Datensatz hinzugefügt wurden, um die Länge mit der CBC-Verschlüsselung kompatibel zu machen, die nur vollständige Blöcke verarbeitet) vollständig angegeben. Alle Bytes müssen einen bestimmten Wert haben und der Empfänger überprüft dies. In SSL 3.0 werden Padding-Byte-Inhalte ignoriert, sodass ein Angreifer Änderungen vornehmen kann, die größtenteils unbemerkt bleiben. Die Änderung wirkt sich nur auf nicht anwendbare Daten aus, kann jedoch in ähnlicher Weise wie BEAST als Entschlüsselungsorakel verwendet werden.

Weitere Details finden Sie unter Antwort .

Die Zukunft

Menschen lernen nie. Es besteht ein großer Druck, SSL aus vielen Gründen um raffinierte Erweiterungen zu erweitern, die am Anfang immer gut aussehen, aber zusätzliche Probleme verursachen können.

Betrachten Sie beispielsweise SSL FalseStart . Hier geht es hauptsächlich darum, dass der Client seine Anwendungsdaten direkt nach dem Senden seiner Finished -Nachricht (in einem vollständigen Handshake) sendet, ohne auf die Finished Nachricht vom Server. Dies reduziert die Latenz, was gut und gut gemeint ist. Dies ändert jedoch die Sicherheitslage: Bevor die Nachricht Finished vom Server empfangen wurde, wird dieser nur implizit authentifiziert (der Client hat noch keinen Beweis dafür, dass der beabsichtigte Server tatsächlich beteiligt war alles; es weiß nur, dass alles, was es sendet, nur vom vorgesehenen Server gelesen werden kann). Dies kann Auswirkungen haben; Beispielsweise könnte ein Angreifer den Server bis zu diesem Punkt emulieren nd z. B. den Client zwingen, eine CBC-basierte Verschlüsselungssuite oder TLS-Komprimierung zu verwenden. Wenn ein Client FalseStart implementiert, verringert dies die Wirksamkeit von Schutzmaßnahmen gegen BEAST und CRIME, wie dies sonst vom Server erzwungen werden könnte.

(Google deaktiviert FalseStart in diesem Frühjahr, anscheinend aufgrund von Kompatibilitätsproblemen mit einigen Servern. Wie auch immer, die „Reduzierung der Latenz um 30%“ sah seltsam aus, da FalseStart nur einen Einfluss auf vollständige Handshakes haben würde, nicht auf abgekürzte Handshakes. Ich glaube nicht an diese angeblichen Vorteile, zumindest nicht in dieser Größenordnung.)

Kommentare

• Der Aufwand, mit dem Sie gute Informationen bereitstellen Diese Seite ist wirklich verrückt und äußerst bewundernswert. Sehr geschätzt.
• Siehe auch tools.ietf.org / html / rfc7457