Please note, that the Knowledge Base isn't translated to english completely at the moment. You will still find some german texts - we are translating permanently the outstanding parts! Thank you for understanding!

SSL - TLS

		INFO & KNOWLEGDE

TLS (Transport Layer Security) ist in den RFCs 2246 und 3546 der TLS Arbeitsgruppe der IETF als zweischichtiges Protokoll definiert. Auf der unteren Ebene ist das Record-Protokoll, welches die übergebenen Daten in Pakete zufälliger Größe fragmentiert, komprimiert und mit einem MAC (Message Authentification Code) versieht. Auf dem Record-Protokoll setzen das Handshake-, das Change-Cipher-Spec- und Alert-Protokoll auf.

Das Handshake-Protokoll legt den Ablauf der Authentifizierung von Server und Client fest. Das Change-Cipher-Spec-Protokoll regelt den Wechsel einer neu ausgehandelten Cipher-Suite und das Alert-Protokoll dient zum Austausch von Kontrollnachrichten. Die Cipher-Suite enthält den verwendeten symmetrischen Verschlüsselungsalgorithmus, den Schlüsselaustauschalgorithmus, sowie die Hash-Funktion.

Es wird zwischen Sessions und Verbindungen unterschieden, wobei jede Verbindung zu einer Session gehört, zu einer Session aber mehrere auch zeitgleiche Verbindungen geben kann. Zu einer Session werden folgende Daten, die durch das Handshake-Protokoll ausgehandelt wurden, gespeichert:

- die Session ID
- das Zertifikat des Kommunikationspartners
- der verwendete symmetrische Algorithmus
- die verwendete Hash-Funktion
- die verwendete Kompressionsmethode
- das Master-Secret: dient zur Berechnung der symmetrischen Schlüssel sowie Initialisierungsvektoren, falls der CBC Modus verwendet wird.
- is_resumable – Flag: zeigt an, ob die Parameter für eine neue Verbindung genutzt werden können.

Für neue Verbindungen können die Einstellungen einer bereits ausgehandelten Session verwendet werden, der Handshake verkürzt sich dadurch. Eine Verbindung enthält folgende Sicherheitsparameter:

- Client Challenge sowie Server Challenge (je 32 Byte Zufallszahl)
- MAC-Geheimnis des Clients und des Servers
- Symmetrischer Schlüssel des Clients und des Servers
- Initialisierungsvektoren von Client und Server
- Sequenznummern für versendete und empfangene Pakete

Handshake

Im Handshake-Protokoll authentifizieren sich die beiden Kommunikationspartner. Dabei werden auch die vom Record-Protokoll benötigten Sicherheitsparameter ausgehandelt. Bei SSL existieren nur drei 3 Authentifizierungsmodi, da ein anonymer Server keine Clientauthentifizierung verlangen kann.

- beidseitige Authentifizierung
- Serverauthentifizierung und anonymer Client
- keine Authentifizierung

Bei anonymen Sessions sind „Man-in-the-middle“-Angriffe möglich, da lediglich Vertraulichkeit und Integrität der versendeten Nachrichten garantiert wird - aber keine Authentizität.

Beginn einer SSL - Session

Die Authentifizierung erfolgt mit x.509v3 Zertifikaten, gemäß PKIX. Der Client generiert ein Pre-Mastersecret, das er mit dem öffentlichen Schlüssel des Servers verschlüsselt. Aus diesem Geheimnis wird das Master-Secret der Session berechnet, dass in die Generierung der symmetrischen Schlüssel, Initialisierungsvektoren und MAC-Geheimnisse einfließt. Hat der Server diese Werte richtig berechnet konnte er das Pre-Master-Secret erfolgreich entschlüsseln, somit ist die Authentizität des Servers implizit bewiesen worden. Der Client beweist den Besitz des privaten Schlüssels zum Zertifikat durch eine eigene Message während des Handshakes, wo die vorhergehenden Handshake-Messages mit dem privaten Schlüssel signiert sind.

Die Kommunikationspartner einigen sich auf eine Cipher-Suite für die Session, welche von den Sicherheitsansprüchen der Anwendung abhängt.

		PRACTICE

Cipher-Suites

In den RFCs sind die möglichen Cipher-Suites definiert. Jede Cipher-Suite definiert mögliche Kombinationen aus Schlüsselaustausch- und Authentifizierungsalgorithmus, Verschlüsselungsalgorithmus (inklusive Schlüssellänge) und einem MAC-Algorithmus (HMAC). Eine Liste der Cipher-Suites welche der jeweilige Kommunikationsteilnehmer kennt wird zwischen den beiden Kommunikationspartnern ausgetauscht.

MAC- Algorithmen sind: MD5 und SHA-1, wobei bei neueren Cipher-Suites MD5 nicht mehr verwendet wird.

Schlüsselaustausch: RSA, DH-RSA, DH-DSS, Kerberos5 mit RFC2712, ECDH-ECDSA und ECDH-RSA als Draft

Verschlüsselung: DES40-CBC, DES-CBC, 3DES-EDE-CBC, RC2-CBC-40, RC4-40, RC4-128, IDEA-CBC, AES-128-CBC und AES-256-CBC mit RFC 3268,

Server Gated Cryptography

SGC ist eine Erweiterung von SSL bzw. TLS und wurde entwickelt, um in den Zeiten der amerikanischen Exportbeschränkung von kryptographischen Systemen, Leistungen von Finanzeinrichtungen mit einer 128 Bit SSL Verschlüsselung zu schützen. Der Verbindungsaufbau läuft anfangs normal wie bei SSL ab, bei der Serverauthentifizierung schickt der Server ein "SGC-Zertifikat", welches seine Eigenschaft durch eine bestimmte OID in der Extended Key Usage - Zertifikatserweiterung anzeigt. Der Client erkennt dies und sendet eine Reset-Nachricht und beginnt ein neues Handshake mit neuen Cipher-Suites.

Um ein solches Zertifikat zu erlangen, musste der Finanzdienstleister über eine SGC-Lizenz verfügen, für die er seine Eigenschaft als Finanzdienstleister und seine Bonität beweisen musste. Nach dem Fall der Exportbeschränkung und dem hinfällig werden dieser Bestimmung wurden diese Zertifikate allen angeboten, von Marketing-Abteilungen als "Supercerts" angepriesen.

Certificate

PKI-Standards PKIX

Certificates

Web authentication

Symmetric