wg fuldastrasse.de

LDAP mit TLS: eine Übersicht zur Implementierung in unsicheren Netzwerken

Inhalt

  1. Übersicht
  2. Gefahren für LDAP-Verzeichnisse
  3. Vorteile von TLS gegenüber anderen Authentifizierungs- und Sicherheitsimplementationen
  4. Implementierung von TLS im LDAP-Server
  5. Funktionsweise von TLS
  6. Record Layer
  7. Handshake Protokoll
  8. Fazit

Übersicht

Dieses Dokument gibt eine Übersicht über LDAP in Verbindung mit TLS ( Transport Layer Security ).

Gefahren für LDAP-Verzeichnisse

Solange LDAP lokal authentifiziert, benötige ich keine besonderen Sicherheitsmaßnahmen. Sobald LDAP über ein Netzwerk abgefragt wird, sind Vorsichtsmaßnahmen zu treffen, die:

  1.     unauthorisierten Zugriff auf Daten
  2.     unauthorisierten Zugriff auf wiederverwendbare Clientinformationen ( Anmeldedaten )
  3.     unauthorisierten Zugriff auf Daten (durch Monitoring des Zugriffs auf Daten von Clients)
  4.     unauthorisiertes Ändern von Daten
  5.     unauthorisiertes Ändern von Konfiguration oder Anmeldedaten
  6.     unauthorisiertes Benutzen von Ressourcen ( Achtung: meistens denial of Service-Attacke )
  7.     spoofing des LDAP-Verzeichnisses ( Client wird vorgemacht, er redet mit dem Server, in Wirklichkeit spricht er aber mit Drittem )

verhindern ( siehe RFC 2829 'Authentication Methods for LDAP' ).

Vorteile von TLS gegenüber anderen Authentifizierungs- und Sicherheitsimplementationen

  •     einfach zu implementieren
  •     benutzt SSL ( Secure Socket Layer ) und Zertifikate mit Schlüsseln
  •     bestätigt ServerID und schützt Informationen während der Übertragung
  •     serverbasierte Authentifizierung

Implementierung von TLS im LDAP-Server

Um TLS zu benutzen, müssen ein Zertifikat und dazugehörige Schlüssel generiert werden. Dazu benötige ich OpenSSL. Auf dem LDAP-Server sind dazu folgende Kommandos auszuführen:

'openssl genrsa -out ldap.key 1024'

'openssl req -new -key ldap.key -out ldap.csr'

Die richtigen Informationen müssen bei dem CSR ( Certificate Signing Request ) eingetragen werden. Für das Common Name Feld sollte der Name benutzt werden, den die Clients benutzen, wenn Sie sich zum LDAP-Server verbinden, normalerweise ist das der FQDN.

Entweder benötigt man eine offizielle CA ( Certificate Authority ) um das CSR zu verifizieren, oder man hat seine eigene CA. Gesetzt den Fall, wir haben keine CA, lautet das Kommando um sich eine Eigene zu erstellen:

'openssl genrsa -des3 -out ca.key 2048'

'openssl req -new -x509 -days 365 -key ca.key -out ca.cert'

Wenn sie möchten, können Sie den Inhalt des gerade erzeugten Zertifkates überprüfen mit:

'openssl x509 -in ldap.cert -text -noout'

Weiter gehts mit der Erstellung eines Zertifikates:

'openssl x509 -req -in ldap.csr -out ldap.cert -CA ca.cert -CAkey ca.key -CAcreateserial -days 365'

Die hieraus resultierende Datei 'ldap.cert' ist das Zertifikat für den LDAP-Server.

Der LDAP-Server benötigt Zugriff auf eine Kopie seines Zertifikates und seiner Schlüssel, wie auch auf das CA-Zertifikat. Die Schlüsseldatei muss nur durch den LDAP-Server lesbar sein, es reicht ein 'chmod 0400', und das die Datei Eigentum des Benutzers ldap und der Gruppe ldap ist.

Nun muß dem Server mitgeteilt werden, wo er seine Zertifikate und Schlüssel findet, dazu wird die slapd.conf editiert. Folgende Einträge werden hinzugefügt:

'TLSCertifikateFile /etc/ssl/openldap/ldap.cert'

'TLSCertifikateKeyFile /etc/ssl/openldap/ldap.key'

'TLSCACertifikateFile /etc/ssl/openldap/ca.cert'

Jetzt fehlt nur noch, das wir TLS in der 'ldap.conf' einschalten, respektive SSL ausschalten. Dazu kommentiert man den vorhandenen Eintrag

'#ssl off'

aus, und trägt einen Neuen ein:

'ssl start_tls'.

Abschließend wird mit einem 'service slapd restart' der LDAP-Server neu gestartet.

Damit haben wir eine Transport-Level-Verschlüsselung für unseren LDAP-Verkehr geschaffen, die unsere Daten sicher über das Netzwerk verschicken kann.

Funktionsweise von TLS

TLS besteht aus zwei Bestandteilen, dem Handshake Protokoll ( verantwortlich für Sicherheit ) und dem Record Layer ( Transportschicht ).

  • Record Layer

Der TLS Record Layer erhält nicht interpretierte Informationen von höher gelegenen Schichten ( Daten ). Er fragmentiert Datenblocks in chunks von 2^14 bytes oder weniger.

  • Handshake Protokoll

Das Handshake Protokoll ist verantwortlich für die Selektion einer Chiffre-Spezifikaton und für das Generieren eines Master Secrets, welche zusammen die primären krypthografischen Parameter für eine sichere Session ausmachen. Das Handshake Protokoll kann optional Parteien, die von einer vertrauten Stelle ( CA ) Zertifikate bekommen haben, gegeneinander authentifizieren. Die kryptografischen Parameter einer Session werden vom Handshake Protokoll ausgehandelt, welches 'on top' des Record Layers operiert.

Wenn ein TLS Client und Server anfangen zu kommunizieren, einigen sie sich auf eine Protokollversion, selektieren kryptografische Algorithmen, authentifizieren sich optional gegeneinander, und benutzen öffentliche Schlüssel um gemeinsam genutzte Secrets zu generieren.

Der Client schickt eine 'Hello'-Nachricht auf die der Server mit einer 'Hello'-Nachricht antworten muss, andernfalls kommt es zu einem Fehler und die Verbindung schlägt fehl. Das Client-'Hello' und das Server-'Hello' werden genutzt um auszuhandeln, welche Sicherheitsparameter von beiden unterstützt werden. Das Server-'Hello' bzw. das Client-'Hello' etabliert die folgenden Attribute:

  • Protokoll-Version
  • Session ID
  • Chiffrier-Suite
  • Kompressionsmethode

Zusätzlich werden zwei zufällige Werte generiert und ausgetauscht:

  • ClientHello.random
  • ServerHello.random

Nach den 'Hello'-Nachrichten wird der Server nun sein Zertifikat senden, wenn es authentifiziert werden soll. Ist der Server authentifiziert, kann er vom Client ebenfalls ein Zertifikat verlangen.

Danach sendet der Server die 'hello-done'-Nachricht um anzuzeigen, das die 'Hello'-Phase des Handshake-Protokolls nun vorbei ist. Jetzt wartet der Server auf eine Nachricht vom Client, hat der Server zuvor ein Zertifikat angefordert, muss der Client nun die Zertifikat-Message senden. Andernfalls wird jetzt die Client Schlüsselaustausch-Nachricht gesendet, der Inhalt dieser Nachricht ist abhängig vom Öffentlichen Schlüssel des selektierten Algorithmus zwischen Client-'Hello' und Server-'Hello'.

An dieser Stelle wird vom Client eine 'Change-Cipher-Spec'-Nachricht ( 'wechsle Chiffrier Code' ) gesendet, und er kopiert den anstehenden Chiffrier-Code über den bestehenden Chiffrier-Code.

Sofort verschickt der Client die 'Fertig'-Nachricht unter den neuen Algorithmen, Schlüsseln und Secrets.

Als Antwort erhält er vom Server die 'Change-Cipher-Spec'-Nachricht, der Server kopiert ebenfalls den neue Chiffrier-Code über den alten, und sendet seine 'Fertig'-Nachricht unter den neuen Chiffrier-Algorithmen.

An diesem Punkt ist der Handshake beendet, Server und Client beginnen jetzt verschlüsselte Daten auszutauschen.

Für weitere Informationen konsultieren Sie bitte RFC's 2246, 2830, 2829, 2828.

Bild 1: Handshake TLS



Fazit

Damit TLS sichere Verbindungen herstellen kann, müssen Schlüssel und Applikationen auf Client- wie Serversystemen sicher sein. Ebenfalls muss die Implementierung frei von Sicherheitslöchern sein.

Das System ist nur so stark, wie das schwächste Glied in der Kette von Schlüsseln und Algorithmen, auch sollten nur vertrauenswürdige kryptografische Funktionen genutzt werden. Kurze öffentliche Schlüssel, wie 40 Bit Verschlüsselungs-Schlüssel, und Server mit anonymer Authentifizierung sollten mit größter Vorsicht genutzt werden.

Benutzer und Administratoren müssen vorsichtig abwägen, welche Zertifikate und CA's vertrauenswürdig sind; eine unehrliche CA kann enormen Schaden anrichten.

Inhalt

  1. Übersicht
  2. Gefahren für LDAP-Verzeichnisse
  3. Vorteile von TLS gegenüber anderen Authentifizierungs- und Sicherheitsimplementationen
  4. Implementierung von TLS im LDAP-Server
  5. Funktionsweise von TLS
  6. Record Layer
  7. Handshake Protokoll
  8. Fazit

Malte Eismann malte(_at_)fuldastrasse.de 2004-03-02