8.4.5. SSL/TLS - Secure Sockets Layer/Transport Layer Security

Mit der zunehmenden Akzeptanz des WWW wuchs sehr schnell das Bedürfnis, die zwischen Browsern und Servern bestehenden HTTP-Verbindungen kryptographisch zu sichern, um ein Ablauschen von Informationen sowie deren Verfälschung zu verhindern und eine zuverlässige Authentifizierung der Partner zu ermöglichen.

Ein Vorschlag, dieses Ziel zu erreichen, ist S-HTTP, das Secure HyperText Transfer Protocol. Wie der Name schon vermuten läßt, geht es darum, neue Sicherheitsmechanismen in das HTTP-Protokoll zu integrieren. Es handelt sich also hierbei um eine anwendungsspezifische Lösung. Eine detaillierte Beschreibung ist als Internet-Draft verfügbar.

Die Netscape Communications Corporation ging einen anderen Weg. Sie entwarf mit SSL ein applikationsunabhängiges Sicherheitsprotokoll, das unterschiedlichen Client-Server-Anwendungen eine abhör- und fälschungssichere Kommunikation erlaubt. Es ist konzeptionell zwischen der Transport- und der Anwendungsschicht angesiedelt und prinzipiell von allen verbindungsorientierten Diensten (HTTP, FTP, Telnet, SMTP, ...) nutzbar.

Für die Protokolle der höheren Schichten ist die Verwendung von SSL transparent. Allerdings können die vorhandenen Applikationen in der Regel nicht automatisch von SSL profitieren. Dazu ist meist eine Modifikation der Quelltexte erforderlich, um sie an die jeweils verwendete SSL-API anzupassen.

Im Gegensatz dazu erfordert der kryptographische Schutz von Kommunikationsverbindungen durch die Secure Shell typischerweise keinerlei Anpassungen der verwendeten Software, da sich die Applikationen über lokale Mechanismen der Interprozeßkommunikation (z.B. Pipes oder Pseudo-Terminals) an den SSH-Klienten bzw. -Server wenden, der dann völlig selbständig das SSH-Protokoll im Auftrag der betreffenden Applikationen abwickelt.

In der Praxis begegnet man zwei unterschiedlichen SSL-Versionen: SSL 2.0 und SSL 3.0. Letztere wurde in einem Internet-Draft beschrieben, der allerdings bereits im Mai 1997 seine Gültigkeit verlor ("expired"). Ein RFC zu SSL existiert nicht. Unabhängig davon hat SSL (speziell Version 3.0) eine recht große praktische Bedeutung erlangt.

SSL 3.0 wird z.B. von Netscape ab 3.x, MS Internet Explorer ab 4.0 sowie verschiedenen WWW-Servern (Apache-SSL, Stronghold, ...) unterstützt. Außerdem stellt die Firma Netscape für nichtkommerzielle Zwecke eine kostenfreie, in ANSI C geschriebene Referenzimplementierung bereit, die allerdings auf Grund der US-amerikanischen Exportbestimmungen nicht legal aus den USA bzw. Kanada exportiert werden darf, da sie starke kryptographische Verfahren beinhaltet.

Die SSL-Spezifikation ist öffentlich und existierte ursprünglich als Internet-Draft. Sie kann von Netscapes WWW-Server über die Seite Security Documentation [http://developer.netscape.com/docs/manuals/security.html] bezogen werden. Der URL der Spezifikation von SSL 3.0 lautet http://home.netscape.com/eng/ssl3/ssl-toc.html.

Eine Weiterentwicklung von SSL erfolgt durch die Transport Layer Security Working Group [http://www.ietf.org/html.charters/tls-charter.html] der IETF. Ein Ergebnis ihrer Arbeit ist die im RFC 2246 veröffentlichte Spezifikation der Version 1.0 des TLS-Protokolls (TLS steht für Transport Layer Security), die als Nachfolger von SSL 3.0 angesehen werden kann (die interne Versionsnummer auf dem sog. Record Layer lautet 3.1). Es wird erwartet, daß TLS seinen Vorgänger SSL in nicht allzu ferner Zukunft ablösen wird.

TLS basiert sehr stark auf SSL 3.0. Die nicht allzu großen Unterschiede haben aber dennoch zur Folge, daß die Interoperabilität der beiden Protokolle nicht a priori gegeben ist. TLS muß speziell auf SSL 3.0 "zurückschalten".

TLS 1.0 unterscheidet sich von SSL 3.0 im wesentlichen durch folgende Merkmale:

Bezüglich der Architektur und der Protokoll-Details unterscheiden sich SSH 2.x und SSL/TLS recht deutlich voneinander. Hinsichtlich des Leistungsumfangs weisen sie allerdings eine ganze Reihe von Gemeinsamkeiten auf. Alle genannten Protokolle sind applikationsunabhängig und logisch zwischen der Transport- und der Anwendungsebene angesiedelt. Ihre Aufgabe besteht darin, den Protokollen höherer Schichten in transparenter Weise Kommunikationskanäle mit einem hohen Sicherheitsniveau anzubieten.

Es läßt sich momentan nicht solide abschätzen, welche Bedeutung der Bereich Transport Layer Security im allgemeinen und die Protokolle SSL/TLS sowie SSH im besonderen in etwas entfernterer Zukunft haben werden. Das muß die Praxis zeigen. Einige Experten gehen z.B. davon aus, daß künftig der Bereich der Application Layer Security stark an Bedeutung gewinnen wird, und sehen daher TLS eher als relativ kurzfristige Zwischenlösung.

Mitunter wird die Ansicht vertreten, daß TLS auf Grund der sehr weiten Verbreitung von SSL bzw. TLS künftig alle anderen Lösungen verdrängen wird. Dies darf allerdings bzgl. SSH wegen der recht großen Anzahl von Secure-Shell-Installationen zumindest für die nähere Zukunft stark bezweifelt werden. Vermutlich liegt die Wahrheit wie so oft in der Mitte, d.h., man kann in den nächsten Jahren mit hoher Wahrscheinlichkeit von einer Koexistenz von TLS/SSL, SSH und anwendungsspezifischen Sicherheitsprotokollen ausgehen, wobei deren Einsatz in Abhängigkeit vom jeweiligen Verwendungszweck erfolgt.

SSL-Implementierungen

Ausgehend von den öffentlich zugänglichen Spezifikationen hat der Australier Eric A. Young eine SSL-Implementierung in der Sprache C geschaffen, die den Namen SSLeay trägt. Sie ist auch außerhalb der USA und Kanada legal und kostenfrei nutzbar und hat weltweit eine relativ große Verbreitung erlangt.

So wurde SSLeay z.B. von der Mozilla Crypto Group [http://mozilla-crypto.ssleay.org/] in ihrem Produkt Cryptozilla verwendet. Das Ziel dieses Projektes besteht darin, starke Kryptographie in die freien Quellen von Netscapes WWW-Browser Mozilla zu reintegrieren. Eine derartige Reintegration ist notwendig bzw. sinnvoll, da die US-amerikanischen Mozilla-Entwickler den von ihnen genutzten kryptographischen Quell-Code nicht freigeben, weil sie dazu auf Grund export- und lizenzrechtlicher Bedingungen nicht berechtigt sind.

Die SSLeay selbst wird nicht mehr weiterentwickelt oder gepflegt. Der letzte Stand ist die Version SSLeay-0.9.0b. Die SSLeay bildet allerdings die Basis des am 23.12.1998 offiziell gestarteten Projektes OpenSSL, in dem mehrere Freiwillige weltweit über das Internet mit dem Ziel zusammenarbeiten, eine robuste und voll ausgebaute SSL- sowie TLS-Implementierung bereitzustellen, deren Quellen öffentlich zur Verfügung stehen und die unter Beachtung einiger weniger Bedingungen sowohl für kommerzielle als auch nichtkommerzielle Zwecke kostenfrei eingesetzt werden darf.

Die zum Zeitpunkt der letzten Aktualisierung dieses Abschnitts aktuelle OpenSSL-Implementierung OpenSSL 0.9.3a vom 29.5.1999 unterstützt SSL 2.0 und 3.0 sowie TLS 1.0. Weitere Informationen zu OpenSSL sowie die Software sind über die Homepage des OpenSSL-Projekts erhältlich: http://www.openssl.org/.

Anders als SSH ist SSL kein eigenständig nutzbares Produkt, sondern "lediglich" ein Protokoll, das in bestehende oder neue Applikationen integriert werden kann bzw. muß. Deshalb spielt es momentan auch hauptsächlich bei WWW eine Rolle, da die weit verbreiteten Browser Netscape und MSIE (Microsoft Internet Explorer) schon seit längerem eine komfortable Nutzung sicherer Verbindungen erlauben (Zugriffsmethode https im URL).

Von Tim Hudson, Christoph Martin, Ben Laurie, Ralf S. Engelschall u.a. wurden bereits verschiedene kostenfreie Applikationen aus dem Umfeld Telnet, FTP und WWW nachträglich SSL-fähig gemacht, wobei diese Entwicklungen alle die SSLeay bzw. teilweise auch schon OpenSSL nutzen. Die Software und zugehörige Informationen können über das Internet bezogen werden, z.B. über FTP-Server an der Uni Mainz bzw. der Uni Trier:

Im Zusammenhang mit Apache-SSL bzw. mod_ssl sei noch der Stronghold Secure Server erwähnt. Es handelt sich dabei um einen kommerziellen WWW-Server, der auf dem populären Apache (s. Kapitel 6B) sowie der SSLeay-Implementierung basiert. Stronghold bietet standardmäßig die Unterstützung von SSL und in neueren Versionen auch bereits von TLS 1.0 an. Der Server ist auf vielen UNIX-Plattformen sowie unter Windows NT lauffähig und relativ leicht zu installieren und zu administrieren. Informationen zu Stronghold finden Sie unter http://stronghold.ukweb.com/stronghold/.

Neben SSleay und OpenSSL gibt es auch noch andere SSL-Implementierungen. Als ein Beispiel sei die vom Institut für Angewandte Informationsverarbeitung und Kommunikationstechnologien (IAIK) der TU Graz geschaffene, in der Programmiersprache Java geschriebene Bibliothek iSaSilk genannt. Nähere Informationen dazu sowie zu anderer in Java implementierter kryptographischer Software des IAIK sind unter http://jcewww.iaik.tu-graz.ac.at/ erhältlich. Es handelt sich bei allen genannten Paketen um kommerzielle Produkte. Um den Quell-Code zu erhalten, benötigt man eine spezielle Source-Code License, die allerdings lediglich zur Inspektion der Quelltexte, nicht aber zu deren anderweitiger Verwendung berechtigt.

Hinweis:

Im Juli 1998 wurde eine von Daniel Bleichenbacher entdeckte Schwäche in der Version 1.5 des RSA-Standards PKCS #1 publiziert, die unter bestimmten Umständen bei einigen SSL-Implementierungen von einem Angreifer ausgenutzt werden kann, um mittels einer adaptiven chosen-ciphertext attack das sog. pre_master_secret einzelner mitgehörter SSL-Verbindungen zu ermitteln. Dadurch gelangt der Angreifer in den Besitz aller zum Schutz einer Verbindung verwendeten sitzungsspezifischen Schlüssel (da diese nach einer bekannten Vorschrift aus dem pre_master_secret abgeleitet werden) und kann daher z.B. aufgezeichnete Sitzungen im nachhinein dechiffrieren.

Bleichenbachers Attacke richtet sich immer gegen SSL-Server und niemals gegen SSL-Klienten. Es gibt verschiedene, größtenteils relativ leicht implementierbare Möglichkeiten, SSL-Implementierungen so zu gestalten, daß sie (zumindest in der Praxis) dem genannten Angriff mit sehr hoher Wahrscheinlichkeit widerstehen. Sie sollten daher beim Einsatz von SSL-Software darauf achten, daß die von Ihnen verwendete Version nicht gegen die erwähnte Attacke anfällig ist.

Nähere Informationen zu dieser Problematik bieten folgende Dokumente:

SSL 3.0

SSL 3.0 ist ein relativ komplexes Protokoll. Wir wollen uns nachfolgend auf einige ausgewählte Aspekte beschränken. Wer vorhat, SSL/TLS-basierte Software zu entwickeln, dem bleibt das detaillierte Studium der Protokoll-Spezifikation sowie der jeweils verwendeten API natürlich nicht erspart.

SSL 3.0 besteht aus 2 Schichten. Auf der unteren Schicht befindet sich das sog. Record Protocol, das unmittelbar oberhalb eines zuverlässigen Transportprotokolls (im Internet also TCP) angesiedelt ist und dem Transport von Dateneinheiten eines höheren Protokolls dient, wobei es diese nicht interpretiert. Zu den Aufgaben des Record-Protokolls gehören die Fragmentierung/Defragmentierung, Kompression/Dekompression, Integritätssicherung auf der Basis eines MAC sowie die Ver- bzw. Entschlüsselung der ihm übergebenen Daten.

Als Beispiel für ein höheres Protokoll sei das SSL Handshake Protocol genannt, das der gegenseitigen Authentifizierung von Klient und Server, der Aushandlung der zum Schutz der Verbindung genutzten Chiffre sowie der dafür benötigten Schlüssel und sonstigen Parameter dient.

SSL-Verbindungen zeichnen sich durch die folgenden drei grundlegenden Eigenschaften aus:

Anmerkungen:

Handshake-Protokoll

Das Handshake-Protokoll erzeugt die für eine Sitzung benötigten kryptographischen Parameter. Nach der Aufnahme einer neuen Verbindung einigen sich Klient und Server auf die Protokollversion, wählen die später verwendeten kryptographischen Algorithmen, authentifizieren sich gemäß einem der drei möglichen Modi und nutzen ein Public-Key-Verfahren, um gemeinsame Geheimnisse zu erzeugen.

In der Protokollspezifikation findet sich folgende Darstellung des Ablaufs:

Client                                       Server

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

* Indicates optional or situation-dependent messages
  that are not always sent.

Note: To help avoid pipeline stalls, ChangeCipherSpec is
      an independent SSL Protocol content type, and is not
      actually an SSL handshake message.
Wie aus der Abbildung zu entnehmen ist, beginnen die beiden Partner ihre Kommunikation mit dem Austausch von Hello-Nachrichten. Dadurch werden folgende Parameter festgelegt:

Bei der Protokollversion, der Cipher Suite und dem Kompressionsverfahren wählt der Server aus den in der ClientHello-Nachricht unterbreiteten Vorschlägen des Klienten aus und teilt diesem seine Entscheidung in der ServerHello-Nachricht mit. Die Zufallswerte sind natürlich von jedem Partner unabhängig vom anderen zu bestimmen.

Über den Sitzungs-Identifikator kann der Klient versuchen, beim Server eine Wiederaufnahme einer früher existierenden Verbindung mit allen ausgehandelten Parametern zu erreichen. Wenn dies möglich ist, steht es dem Server frei, darauf einzugehen oder nicht. Wir wollen hier nur den Fall betrachten, daß eine Verbindung erstmals aufgebaut wird. Damit ist die Wiederaufnahme von im Cache gehaltenen Verbindungen für uns nicht von Belang.

Nach dem Hello sendet der Server sein Zertifikat, sofern er über eines verfügt und eine Server-Authentifizierung erforderlich ist. Zusätzlich wird ggf. eine ServerKeyExchange-Nachricht übertragen, um den später folgenden, vom Klienten initiierten Schlüsselaustausch zu ermöglichen. Diese Nachricht ist z.B. dann notwendig, wenn

Im letzten Fall handeln Klient und Server einen kürzeren, temporären Key aus, der durch den längeren signiert wird und die eigentliche Datenverschlüsselung übernimmt.

Nachdem der Server authentifiziert wurde, kann er auch vom Klienten ein Zertifikat anfordern, sofern dies für die gewählte Cipher Suite möglich ist. Danach schließt er seinerseits die Hello-Phase durch eine ServerHelloDone-Nachricht ab und wartet jetzt auf die Antwort des Klienten.

Wenn der Server vom Klienten ein Zertifikat angefordert hat, so muß dies der Klient entweder liefern oder eine Alarmmeldung (no_certificate alert) senden.

Im Anschluß daran leitet der Klient den Schlüsselaustausch ein. Dessen Ziel besteht darin, unter Verwendung eines Public-Key-Verfahrens bei beiden Partnern ein gemeinsames Geheimnis (master_secret) zu generieren, das nur diesen beiden bekannt und eindeutig der aktuellen Sitzung zugeordnet ist. Der konkrete Inhalt der ClientKeyExchange-Nachricht hängt vom verwendeten asymmetrischen Verfahren ab.

Sofern der Klient ein zum Signieren nutzbares Zertifikat an den Server übergeben hat, sendet er jetzt eine digital unterschriebene CertificateVerify-Nachricht, um das Zertifikat explizit zu verifizieren.

An diesem Punkt des Protokolls verschickt der Klient eine Nachricht vom Typ ChangeCipherSpec. Dadurch wird ein Übergang auf eine andere Verschlüsselungsstrategie angezeigt (andere Verfahren oder Parameter). Konkret aktiviert der Klient (und nachfolgend auch der Server) die in der Hello-Phase festgelegte Cipher Suite sowie die nachfolgend aus dem master_secret erzeugten Schlüssel, IVs und die bei der MAC-Berechnung benötigten Geheimnisse.

Unmittelbar nachdem der Klient die neuen Algorithmen und Parameter aktiviert hat, sendet er eine Finished-Nachricht, die der Verifikation des erfolgreichen Verlaufs des Schlüsselaustauschs sowie der Authentifizierung dient. Dabei handelt es sich also um die ersten Daten, die bereits nach der neuen Strategie kryptographisch gesichert wurden.

Der Server antwortet darauf mit einer eigenen ChangeCipherSpec-Nachricht, geht anschließend auf die darin spezifizierte neue Strategie über und sendet dann auch eine Finished-Nachricht.

Finished-Nachrichten werden vom Partner nicht explizit beantwortet, sind aber durch den Empfänger stets zu verifizieren. Unmittelbar nach deren Versand dürfen die verschlüsselten Daten der Applikationen übertragen werden. Daraus folgt, daß an dieser Stelle des Protokolls der Handshake komplett ist und beide Partner mit dem Austausch von Nutzerdaten beginnen können.

Authentifizierung und Schlüsselaustausch

Das unmittelbare Ziel des Schlüsselaustauschs besteht darin, bei beiden Kommunikationspartnern ein gemeinsames Geheimnis (pre_master_secret genannt) zu generieren, von dem mögliche Angreifer allerdings keine Kenntnis haben. Aus diesem Geheimnis leitet jeder Partner dann das oben schon erwähnte master_secret ab, das seinerseits u.a. dazu benötigt wird, die Finished-Nachrichten zu erzeugen. Durch das Senden einer korrekten Finished-Nachricht weist jeder Partner nach, daß er das pre_master_secret tatsächlich kennt.

Das master_secret wird bei allen drei Schlüsselaustauschverfahren (RSA, DH und Fortezza KEA) unter Verwendung der beiden Einweg-Hashfunktionen MD5 und SHA-1 nach folgendem Algorithmus aus dem pre_master_secret abgeleitet:

master_secret =
  MD5(pre_master_secret + SHA('A' + pre_master_secret +
      ClientHello.random + ServerHello.random)) +
  MD5(pre_master_secret + SHA('BB' + pre_master_secret +
      ClientHello.random + ServerHello.random)) +
  MD5(pre_master_secret + SHA('CCC' + pre_master_secret +
      ClientHello.random + ServerHello.random));

Schauen wir uns jetzt als konkretes Beispiel den Ablauf bei der Nutzung von RSA an (für die anderen Verfahren sei auf die SSL-Spezifikation verwiesen). Dabei werden der Schlüsselaustausch und die Authentifizierung des Servers kombiniert. Dessen öffentlicher Schlüssel wird entweder dem Zertifikat des Servers oder der KeyExchange-Nachricht entnommen, wobei er im zweiten Fall einen temporären Charakter trägt. Einen temporären Key unterschreibt der Server durch ein RSA- oder DSS-Zertifikat (d.h. mittels eines Schlüssels, der in dem jeweils verwendeten Zertifikat enthalten ist). Die Signatur schließt den aktuellen Zufallswert des Klienten (ClientHello.random) ein, um das Wiedereinspielen alter Zertifikate und temporärer Schlüssel zu verhindern.

Server können einen bestimmten temporären RSA-Key für mehrere Schlüsselaustausch-Operationen verwenden. Wir hatten weiter oben schon darauf hingewiesen, daß temporäre Schlüssel dann sinnvoll sind, wenn ein Server Zertifikate für sichere, d.h. lange Keys benötigt, auf Grund rechtlicher Beschränkungen aber nur kürzere Schlüssel beim Schlüsselaustausch verwenden darf.

Nachdem der Klient das Zertifikat des Servers verifiziert hat, chiffriert er ein von ihm selbst zufällig erzeugtes pre_master_secret mit dem öffentlichen Server-Schlüssel. Durch die erfolgreiche Entschlüsselung dieses Geheimnisses und die Erzeugung einer korrekten Finished-Nachricht beweist der Server die Kenntnis des zu seinem Zertifikat gehörenden privaten Schlüssels und damit seine Identität. Er ist somit authentifiziert.

Alle RSA-Verschlüsselungen erfolgen gemäß PKCS #1 und sind daher unter bestimmten Umständen gegen die oben erwähnte Attacke von Daniel Bleichenbacher anfällig.

Ein Klient authentifiziert sich bei Bedarf durch eine CertificateVerify-Nachricht. Er unterschreibt einen aus dem master_secret und allen zuvor ausgetauschten Handshake-Nachrichten abgeleiteten Wert. Die Handshake-Daten umfassen u.a. das Zertifikat des Servers und den Zufallswert ServerHello.random, so daß die Signatur sowohl an den Server als auch an den aktuellen Handshake-Prozeß gebunden wird.

Schutz der SSL-Records durch symmetrische Kryptographie

Die konkret zur Verschlüsselung und Sicherung der Integrität von SSL-Records genutzen Verfahren werden durch die jeweils aktuelle Cipher Suite festgelegt. Als Beispiel sei die Cipher Suite SSL_RSA_WITH_IDEA_CBC_SHA genannt, die laut SSL-Spezifikation folgende Eigenschaften aufweist:

Aus dem nach der o.g. Vorschrift gebildeten master_secret wird durch die Anwendung von Einweg-Hashfuntionen eine Folge von sicheren Bytes berechnet, aus der dann die Schlüssel für die symmetrische Verschlüsselung, die dazu erforderlichen IVs sowie die bei der MAC-Berechnung benötigten Geheimnisse abgeleitet werden. Konkret werden folgende Größen in der angegebenen Reihenfolge generiert:

Bezeichnung Erläuterung
client write MAC secret Geheimnis, das für die MAC-Operationen über den vom Klienten versendeten Daten genutzt wird
server write MAC secret Geheimnis, das für die MAC-Operationen über den vom Server versendeten Daten genutzt wird
client write key Schlüssel für die (symmetrisch) durch den Klienten ver- und den Server entschlüsselten Daten
server write key Schlüssel für die (symmetrisch) durch den Server ver- und den Klienten entschlüsselten Daten
client write IV Anfangs-IV für die durch den Klienten verschlüsselten Daten
server write IV Anfangs-IV für die durch den Server verschlüsselten Daten

Für die Erzeugung der einzelnen Keys, IVs und MAC-Geheimnisse stehen drei Ausgangsdaten zur Verfügung:

Zunächst wird daraus nach folgender Vorschrift ein hinreichend langer key_block berechnet, wobei der Operator + die Verkettung der Operanden ausdrückt:

key_block =
  MD5(master_secret + SHA(`A' + master_secret +
                          ServerHello.random +
                          ClientHello.random)) +
  MD5(master_secret + SHA(`BB' + master_secret +
                          ServerHello.random +
                          ClientHello.random)) +
  MD5(master_secret + SHA(`CCC' + master_secret +
                          ServerHello.random +
                          ClientHello.random)) + [...];

Daraus werden anschließend die einzelnen Schlüssel, MAC-Geheimnisse und IVs entsprechend der in der obigen Tabelle angegebenen Reihenfolge entnommen. Die für die einzelnen Größen benötigte Byteanzahl hängt von der jeweils verwendeten Cipher Suite ab. Evtl. im key_block vorhandene überzählige Bytes werden verworfen.

Sofern exportierbare Chiffren zum Einsatz kommen, sind weitere Operationen nötig, um die tatsächlich genutzten Keys zu ermitteln:

final_client_write_key = MD5(client_write_key +
                             ClientHello.random +
                             ServerHello.random);
final_server_write_key = MD5(server_write_key +
                             ServerHello.random +
                             ClientHello.random);

Die IVs für exportierbare Chiffren werden nach folgender Vorschrift gebildet:

client_write_IV = MD5(ClientHello.random + ServerHello.random);
server_write_IV = MD5(ServerHello.random + ClientHello.random);

Die MD5-Resultate werden dabei durch Verwerfen der niedrigstwertigen Bytes auf die jeweils benötigte Länge reduziert.

SSL definiert eine eigene MAC-Konstruktion, die wie bereits erwähnt bei TLS 1.0 gegen den allgemein anerkannten HMAC ersetzt wurde:

MAC = hash(MAC_write_secret + pad_2 +
       hash(MAC_write_secret + pad_1 + seq_num +
            SSLCompressed.type + SSLCompressed.length +
            SSLCompressed.fragment));


pad_1     The character 0x36 repeated 48 times for MD5
          or 40 times for SHA.
pad_2     The character 0x5c repeated 48 times for MD5
          or 40 times for SHA.
seq_num   The sequence number for this message.
hash      Hashing algorithm derived from the cipher suite.

Die MAC-Berechnung erfolgt stets vor der Verschlüsselung, allerdings nach einer optionalen Daten-Kompression. Der MAC bezieht sich auf den gesamten optional komprimierten Record (d.h. auf alle Felder mit Ausnahme des MAC selbst) und wird stets zusammen mit den anderen Daten des Records symmetrisch verschlüsselt. SSLCompressed.type, SSLCompressed.length und SSLCompressed.fragment beschreiben den Typ, die Länge sowie den Inhalt der komprimierten Daten.

Für beide Kommunikationsrichtungen wird je eine Sequenznummer seq_num verwaltet, die in die MAC-Berechnung einfließt und so gestattet, fehlende, umgeordnete oder überzählige Nachrichten zu erkennen.


Vertiefung:


© Holger Trapp, 1.7.1999