it-swarm.com.de

Welcher Teil eines Datenpakets ist in SSL / TLS verschlüsselt und authentifiziert?

Ich versuche, mich mit dem Anwendungsdatensatz zu befassen, der gesicherten Datenverkehr enthält. Ich verstehe, dass TLS/SSL ein "Authentifizieren-dann-Verschlüsseln" -Protokoll ist, was bedeutet, dass ein HMAC über den Nur-Text berechnet wird und der resultierende Digest an die Nachricht angehängt wird. Schließlich wird das gesamte Paket unter Verwendung der ausgehandelten Verschlüsselung verschlüsselt.

Ich weiß auch, dass die ersten drei Felder eines "Anwendungsdaten" -Datensatzes sind:

  • Inhaltstyp (0x17 zur Angabe der Anwendungsdaten)
  • Protokollversion (0x0301 für TLS1.0 et al.)
  • Datensatzlänge (Länge des verschlüsselten Inhalts in Byte)

Angesichts der folgenden (vereinfachten) "Daten"

GET /index.html HTTP/1.1
Host: helpme.com

Wie würde das resultierende verschlüsselte Paket aussehen und welche Teile würden verschlüsselt und welcher Teil würde gehackt?

Bitte verwenden Sie die folgende (erneut vereinfachte) Abbildung, um die Beantwortung zu vereinfachen:

01   |  ContentType  |  ProtocolVersion  |  RecordLength  |
02    GET /index.html HTTP/1.1
03    Host: helpme.com
04   |  HMAC  |  Padding  |

Mein bester Gast beim Durchlesen RFC 5246 :

Die Zeilen 01-03 sind in HMAC enthalten
Die Zeilen 02-04 sind in der Verschlüsselung enthalten

Jede Hilfe wird geschätzt.

12
Eddie

KURZE ANTWORT

Im Fall von HTTPS werden alle Daten, die gesendet worden wären, wenn die Verbindung nicht sicher gewesen wäre, als verschlüsselte Anwendungsdaten gesendet. Aus historischen Gründen werden außerdem MAC und Padding verschlüsselt. In SSL 3.0 und TLS 1.0 bedeutet dies, dass das Layout wie folgt lautet:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02 (encrypted)    GET /index.html HTTP/1.1
03 (encrypted)    Host: helpme.com
04 (encrypted)    |  MAC  |  Padding  |

Beachten Sie, dass der MAC streng genommen nur ein HMAC in TLS 1.0 und höher ist. In SSL 3.0 war dies ein spezieller Modus, der nur in diesem Protokoll verwendet wurde.

etwas längere Antwort

Ab TLS 1.1 wird am Anfang der verschlüsselten Daten eine explizite IV eingefügt, wenn eine Blockverschlüsselung im CBC-Modus ausgehandelt wurde:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02                IV
03 (encrypted)    GET /index.html HTTP/1.1
04 (encrypted)    Host: helpme.com
05 (encrypted)    |  HMAC  |  Padding  |

Die IV dient dazu, den Chiffretext unvorhersehbar und weniger anfällig für bestimmte kryptografische Angriffe zu machen. Implementierungen können es sowohl bei der Verschlüsselung als auch bei der Entschlüsselung unterschiedlich behandeln. Einige Implementierungen generieren es möglicherweise zufällig, während andere es als Chiffretext des letzten Blocks des vorherigen XOR-Fragments mit einem konstanten Wert generieren. Umgekehrt können Implementierungen es bei der Entschlüsselung entweder als unabhängiges Feld oder als ersten Block von Chiffretext behandeln (und den entsprechenden entschlüsselten Block verwerfen, bevor das entschlüsselte Klartextfragment ausgegeben wird, genau wie HMAC und Padding verworfen werden).

Ab TLS 1.2 wird möglicherweise eine AEAD-Verschlüsselung ausgehandelt, was bedeutet, dass der MAC-Mechanismus in den Verschlüsselungsmodus integriert ist und kein HMAC erforderlich ist. In diesem Fall sieht das Layout wie folgt aus:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02 (plain)        Nonce 
03 (encrypted)    GET /index.html HTTP/1.1
04 (encrypted)    Host: helpme.com

Beachten Sie, dass die Länge des Chiffretextes, der den Feldern 03 und 04 entspricht, länger ist als die Länge des entsprechenden Klartextes. Das genaue Layout hängt von den Details des AEAD-Verschlüsselungsmodus ab. Normalerweise endet es nur mit einem MAC.

Um die Sache noch weiter zu verkomplizieren, wird der MAC in allen Protokollversionen und Verschlüsselungsmodi über Daten berechnet, die sich sowohl vom Klartextfragment (optional komprimiert) als auch vom verschlüsselten Fragment unterscheiden. Insbesondere hat das RecordLength-Feld den Nur-Text-/komprimierten Wert (nicht den verschlüsselten Wert) und eine Sequenznummer wird eingefügt, um Wiederholungsangriffe zu verhindern. Der MAC selbst ist offensichtlich nicht in den Daten enthalten, über die der MAC berechnet wird, und das Auffüllen auch nicht. Der letzte Teil, bei dem der MAC nicht über das Auffüllen berechnet wird, ist der Grund, warum einige der Angriffe gegen SSL/TLS möglich sind.

IMPLICIT SSL/EXPLICIT TLS

HTTPS ist eine Instanz von Implizites SSL, was ungefähr bedeutet, dass SSL/TLS die äußerste Protokollschicht der Verbindung ist. Das erste, was über die Verbindung gesendet wird, ist ein SSL/TLS-Handshake, und alle Anwendungsdaten werden verschlüsselt gesendet. HTTPS ist immer implizites SSL.

Im Gegensatz dazu bedeutet Explizites TLS, dass SSL/TLS explizit als Teil des zugrunde liegenden Anwendungsprotokolls ausgehandelt wird. Dies ist üblich, z. im Fall von Anwendungsprotokollen wie SMTP, POP3 und FTP. Wenn explizites TLS verwendet wird, sind die ersten Daten, die über die Verbindung gesendet werden, die Eröffnungsprotokollnachrichten des Anwendungsprotokolls.

Beachten Sie, dass der Teil "SSL" und "TLS" von implizitem SSL und explizitem TLS eine Fehlbezeichnung ist, da es für einen Client und einen Server durchaus möglich ist, TLS 1.0 oder höher über eine implizite SSL-Verbindung auszuhandeln und umgekehrt zu verhandeln SSL 3.0 über eine explizite TLS-Verbindung.

KÖNNEN KUNDENAUTHENTIFIZIERUNG UND SESSIONSAUFNAHME VERTRAUEN?

Um die Sache noch komplizierter zu machen, sollte beachtet werden, dass das Verschlüsseln von etwas für jemanden nicht garantiert, dass die Entität die einzige ist, die die verschlüsselten Daten liest, da es niemals möglich ist, den Empfänger daran zu hindern, den entschlüsselten Klartext einfach an einen Dritten weiterzuleiten Party. Dies ist insbesondere bei SSL/TLS wichtig, da die Authentifizierung normalerweise nur in eine Richtung erfolgt (der Server authentifiziert sich beim Client) und ein spezieller Handshake erforderlich ist, um den Client beim Server zu authentifizieren.

Dieser Angriff zeigt, wie diese Tatsache mit aktuellen Protokollen und einigen kryptografischen Grundelementen ausgenutzt werden kann. Es gibt jedoch einige Dinge, die getan werden können, um dies zu verhindern. Die folgenden Regeln verhindern beispielsweise den Angriff, können jedoch die Kompatibilität mit vorhandenen Implementierungen beeinträchtigen:

  1. Wenn der Server eine Clientauthentifizierung erfordert, gilt Folgendes: a. Senden Sie als erstes nach Abschluss des ersten Handshakes eine hello_request und fordern Sie die Clientauthentifizierung für diesen zweiten Handshake an, oder b. Implementieren Sie das Anwendungsprotokoll (oder die Anwendung, die das Anwendungsprotokoll verwendet) so, dass keine vor der Clientauthentifizierung gesendeten Daten als vom Client authentifiziert behandelt werden, z. indem Sie intern eine völlig neue Anwendungssitzung starten und den Client alles erneut senden lassen, was er vor dem authentifizierten Handshake gesendet hat.
  2. Wenn eine Verbindung mit einer Wiederaufnahme (abgekürzter Handshake) hergestellt wurde, behandeln Sie alle hello_request- oder client_hello-Nachrichten über diese Verbindung als Fehler.
9