Wie X.509-Zertifikate im Rahmen von SSL/TLS verwendet werden, erfahren Sie in dieser Folge. Den Anfang macht die Beschreibung der beim Handshake ausgetauschten Nachrichten. Mit der 'ClientHello'-Nachricht sendet der Client folgende Informationen an den Server:

• Version:
  Die höchste SSL/TLS-Version, die der Client versteht.
• Random:
  Ein vom Client gewählter Zufallswert, gebildet aus einem Zeitstempel und einer Zufallszahl. Er verhindert Replay-Angriffe während des Schlüsselaustauschs.
• SessionID:
  Eine Sitzungskennung, um verschiedene Verbindungen/Sitzungen zu unterscheiden.
• CipherSuite:
  Eine Liste der vom Client unterstützten Verschlüsselungsalgorithmen, sortiert nach abnehmender Bedeutung. Jeder Eintrag enthält eine Methode zum Schlüsselaustausch und die so genannte CipherSpec mit Angaben über Verschlüsselungs- und MAC-Algorithmen, über Strom- oder Blockchiffre und Informationen für die Verschlüsselung und MAC-Berechnung.
• Compression Method:
  Eine Liste der vom Client unterstützten Komprimierungsalgorithmen.

Die daraufhin vom Server gesendete 'ServerHello'-Nachricht enthält folgende Informationen:

• Version:
  Die höchste SSL/TLS-Version, die sowohl Client als auch Server verstehen.
• Random:
  Ein von Server gewählter Zufallswert, gebildet aus einem Zeitstempel und einer Zufallszahl. Der Wert ist unabhängig von dem vom Client gesendeten Random-Wert.
• SessionID:
  Beim Start einer neuen Sitzung die vom Server vergebene ID, sonst die vom Client gelieferte ID der bestehenden Sitzung.
• CipherSuite:
  Enthält den vom Server aus der Liste des Clients gewählten Verschlüsselungsalgorithmus. Dies kann je nach Präferenz z.B. der stärkste oder schnellste der möglichen Algorithmen sein.
• Compression Method:
  Enthält den vom Server aus der Liste des Clients gewählten Komprimierungsalgorithmus.

Der Server sendet nach der 'ServerHello'-Nachricht sein Zertifikat (oder ggf. auch mehrere) in einer Zertifizierungsnachricht an den Client und signalisiert danach durch eine 'ServerHelloDone'-Nachricht, dass er fertig ist. Danach beginnen die Serverauthentifizierung und der Schüsselaustausch.

Der Client muss nun das X.509-Zertifikat prüfen. X.509-Zertifikate sind immer an einen "Distinguished Name" oder "Alternative Name", z.B. eine E-Mail-Adresse oder einen DNS-Eintrag, gebunden. Die meisten Webbrowser bringen eine vorkonfigurierte Liste vertrauenswürdiger CAs mit, den davon ausgestellten Zertifikaten vertrauen die Browser dadurch automatisch. Kann der Browser das Zertifikat nicht selbst verifizieren, fragt er beim Benutzer nach. Dieser kann dem Zertifikat dann (zweckmäßigerweise nach einer gründlichen Prüfung) einmalig oder auf Dauer sein Vertrauen aussprechen oder die Verbindung abbrechen. Bei Bedarf kann ein vom Browser akzeptiertes Zertifikat auch zusätzlich vom Benutzer geprüft und dessen Fingerprint mit einem auf sicherem Weg erhaltenen Vergleichswert verglichen werden. Ggf. kann ab SSL-Version 3.0 der Server zusätzlich seinerseits vom Client ein Zertifikat anfordern. Da diese Möglichkeit sehr selten eingesetzt wird, soll hier nicht weiter darauf eingegangen werden.

Nachdem das Zertifikat erfolgreich geprüft wurde, beginnt der Austausch der Schlüssel für die symmetrische Verschlüsselung. Dies soll hier beispielsweise mit RSA geschehen. Dazu erzeugt der Client eine weitere sichere, d.h. nicht vorhersagbare, Zufallszahl, das so genannte Pre-Master-Secret, das mit dem öffentlichen Schlüssel des Servers aus dem Zertifikat verschlüsselt und an den Server gesendet wird. Dieser kann es als einziger mit seinem privaten Schlüssel entschlüsseln und beweist dadurch seine Authentizität. Sowohl Client als auch Server können dann aus dem Pre-Master-Secret und den beiden Random-Werten aus den 'ClientHello'- und 'ServerHello'-Nachrichten das so genannte Master-Secret berechnen. In diesem Punkt unterscheiden sich SSLv3 und TLS: Während SSL für die Berechnung des Master-Secrets auf die vorhandenen Hash-Funktionen MD5 und SHA zurückgreift, verwendet TLS dafür eine eigene Zufallszahlenfunktion PRF (Pseudorandom Function). Aus dem Master-Secret werden dann die Schlüssel für die symmetrische Verschlüsselung der Verbindung berechnet.

Grafische Darstellung des Handshake-Ablaufs.

Nutzung von SSL/TLS in eigenen Programmen

Da SSL/TLS zwischen Anwendungs- und Transportschicht sitzt, kann jedes Programm seine Dienste in Anspruch nehmen. Für Java gibt es z.B. die Java Secure Socket Extensions (JSSE), die SSL 2.0 und 3.0 sowie TLS 1.0 unterstützen. JSSE bietet eine vollständige Abstraktion von SSL, sodass sich der Entwickler nicht selbst um die verschiedenen Phasen des Handshake-Protokolls kümmern muss, sondern nach der Initialisierung direkt über entsprechende Sockets eine geschützte Verbindung aufbauen kann. PHP kann bei entsprechender Installation die Funktionen einer vorhandenen OpenSSL-Installation nutzen. Außerdem unterstützen die Socket-Funktionen fsockopen() und stream_socket_client() SSL und TLS.

In der nächsten Folge werden Aufbau und Nutzung einer Public-Key-Infrastruktur (PKI) beschrieben.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Kryptographie – Anwendungen"

• About Security #79: Kryptographie – Identitätsprüfung
• About Security #80: Kryptographie – Web of Trust
• About Security #81: Kryptographie – Hierarchische Zertifizierungssysteme
• About Security #82: Kryptographie – Zertifikate in SSL/TLS
• About Security #83: Public-Key-Infrastruktur (PKI) – Der Aufbau
• About Security #84: Public-Key-Infrastruktur (PKI) – Die CA
• About Security #85: Sichere E-Mails mit S/MIME
• About Security #86: Sicheres Einloggen mit Single Sign-On
• About Security #87: Sicherheit von Single Sign-On