German translation SS_HowTo

[Jobst Giesecke]

Title: Starke SSL/TLS-Verschlüsselung: Anleitungen

SSL/TLS

Die Lösung dieses Problems ist trivial und bleibt dem Leser als Übung überlassen.

-- Ein Standardzitat

Wie bestimmte Sicherheitsanforderungen für SSL-fähige Webserver erfüllt werden, ist wegen der Kohärenzen zwischen SSL, HTTP und dem Apache bei der Verarbeitung von Anfragen nicht immer offensichtlich. Dieses Kapitel enthält Anleitungen zur Lösung typischer Problemsituationen. Sie sind als erster Schritt auf dem Weg zur endgültigen Lösung gedacht, bevor Sie die Hinweise aufgreifen, sollten Sie jedoch sicher sein, dass Sie die Zusammenhänge verstanden haben. Nichts ist schlimmer, als die Umsetzung einer Lösung zur Beseitigung von Sicherheitsproblemen, ohne sich über die damit verbundenen Einschränkungen und Konsequenzen im Klaren zu sein.

• Ausschließliche SSLv2-Server
• Server mit ausschließlich starker Verschlüsselung
• SGC (Server Gated Cryptography)
• Strengere Anforderungen auf Verzeichnisebene

Mit folgenden Zeilen können Sie einen SSL-Server einrichten, der nur mit dem SSLv2-Protokoll und den entsprechenden Algorithmen arbeitet:

SSLProtocol -all +SSLv2
SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP

Mit den folgenden Zeilen werden nur die stärksten Algorithmen aktiviert:

SSLProtocol all
SSLCipherSuite HIGH:MEDIUM

Dies kann mit Hilfe der Server Gated Cryptography (SGC) geschehen. Details hierzu finden Sie in der Datei README.GlobalID, die Bestandteil der mod_ssl-Distribution ist. Kurz zusammengefasst: Der Server besitzt ein Global ID-Serverzertifikat, das von einem speziellen CA-Zertifikat der Firma Verisign signiert ist. Dieses Zertifikat aktiviert die starke Verschlüsselung für Exportbrowser. Das funktioniert folgendermaßen: Der Browser stellt eine Verbindung mit einem Exportalgorithmus her. Daraufhin sendet der Server sein GlobalID-Zertifikat, welches der Browser verifiziert. Anschließend aktualisiert er seine Verschlüsselungsalgorithmen, bevor die HTTP-Kommunikation stattfindet. Dabei stellt sich die Frage, wie dieses Upgrade der Verschlüsselungsalgorithmen bei gleichzeitig erzwungener starker Verschlüsselung möglich ist. Oder anders ausgedrückt: Browser müssen entweder zu Beginn eine Verbindung mit starker Verschlüsselung herstellen oder sie müssen eine Upgrade für starke Verschlüsselung durchführen, sie dürfen die Exportalgorithmen aber nicht übernehmen. Hierfür wird ein Trick angewendet:

# Alle Algorithmen für das anfängliche Handshake zulassen,
# damit Exportbrowser über SGC ein Upgrade durch führen können.
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Directory /usr/local/apache2/htdocs>
# Abschließend alle Browser ablehnen, die kein Upgrade durchgeführt haben.
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
</Directory>

Das geht sicherlich nicht mit einer serverweiten SSLCipherSuite-Anweisung, die die Algorithmen auf die starken Varianten einschränkt. Das Modul mod_ssl erlaubt aber eine Neukonfiguration der Verschlüsselungsalgorithmen auf Verzeichnisebene und erzwingt automatisch eine Neuverhandlung der SSL-Parameter für diese neue Konfiguration. Die Lösung sieht so aus:

# Generell keine Einschränkungen
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Location /strong/area>
# Aber für https://hostname/strong/area/ und darunter liegende
# Ressourcen sind starke Algorithmen erforderlich:
SSLCipherSuite HIGH:MEDIUM
</Location>

• Einfache Client-Authentifizierung mit Zertifikat
• Selektive Client-Authentifizierung mit Zertifikat
• Spezielle Client-Authentifizierung mit Zertifikat
• Intranet versus Internet-Authentifizierung

Wenn die Benutzer Ihres Servers eine geschlossene Gruppe bilden, wie dies zum Beispiel in einem Intranet der Fall ist, können Sie eine einfache Zertifikat-Authentifizierung durchführen. Hierfür müssen Sie Client-Zertifikate ausstellen, die von einem eigenen CA-Zertifikat signiert werden (in ca.crt) und anschließend die Clients anhand dieses Zertifikats überprüfen.

# Ein Client-Zertifikat vorschreiben, das direkt vom
# eigenen CA-Zertifikat (in ca.crt) signiert ist.
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile conf/ssl.crt/ca.crt

Auch hierfür wird eine Neukonfiguration auf Verzeichnisebene mit dem Modul mod_ssl durchgeführt:

SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt

<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>

Hierfür müssen verschiedene Elemente des Client-Zertifikats überprüft werden. Normalerweise muss der vollständige Distinguished Name (DN) des Subjekts oder Teile davon überprüft werden. Das kann auf zwei Arten geschehen: mit der mod_auth_basic-Variante oder der SSLRequire-Variante. Die erste Variante eignet sich, wenn es sich um Clients völlig unterschiedlichen Typs handelt, d.h. wenn die DNs keine gemeinsamen Felder besitzen (normalerweise ist die Organisation o.ä. gleich). In diesem Fall müssen Sie eine Passwortdatenbank mit allen Clients einrichten. Die zweite Variante wird empfohlen, wenn die Clients alle zu einer allgemeinen Hierarchie gehören, die im DN kodiert ist, weil sie dann leichter zu erfassen sind.

Die erste Variante:

SSLVerifyClient      none
<Directory /usr/local/apache2/htdocs/secure/area>

SSLVerifyClient      require
SSLVerifyDepth       5
SSLCACertificateFile conf/ssl.crt/ca.crt
SSLCACertificatePath conf/ssl.crt
SSLOptions           +FakeBasicAuth
SSLRequireSSL
AuthName             "Snake Oil Authentication"
AuthType             Basic
AuthBasicProvider    file
AuthUserFile         /usr/local/apache2/conf/httpd.passwd
require              valid-user
</Directory>

/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA

Die zweite Variante:

SSLVerifyClient      none
<Directory /usr/local/apache2/htdocs/secure/area>

  SSLVerifyClient      require
  SSLVerifyDepth       5
  SSLCACertificateFile conf/ssl.crt/ca.crt
  SSLCACertificatePath conf/ssl.crt
  SSLOptions           +FakeBasicAuth
  SSLRequireSSL
  SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." \
               und %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
</Directory>

Wenn das Intranet über das IP-Netzwerk 192.160.1.0/24 identifiziert werden kann und der Unterbereich auf der Intranet-Website die URL /subarea besitzt, dann legen Sie außerhalb des virtuellen HTTPS-Abschnitts folgende Konfiguration fest (damit sie für HTTPS und HTTP gilt):

SSLCACertificateFile conf/ssl.crt/company-ca.crt

<Directory /usr/local/apache2/htdocs>
#   Außerhalb des Unterbereichs nur Zugriff aus dem Intranet
Order                deny,allow
Deny                 from all
Allow                from 192.168.1.0/24
</Directory>

<Directory /usr/local/apache2/htdocs/subarea>
#   Innerhalb des Unterbereich Zugriff aus dem Intranet, aus dem Internet
#   aber nur für HTTPS + Starker Algorithmus + Passwort
#   oder alternative HTTPS + Starker Algorithmus + Client-Zertifikat

#   Wird HTTPS benutzt, muss ein starker Algorithmus benutzt werden.
#   Außerdem werden Client-Zertifikate als Alternative
#   zur Basic-Authentifizierung zugelassen.
SSLVerifyClient      optional
SSLVerifyDepth       1
SSLOptions           +FakeBasicAuth +StrictRequire
SSLRequire           %{SSL_CIPHER_USEKEYSIZE} >= 128

#   Clients aus dem Internet müssen HTTPS verwenden
RewriteEngine        on
RewriteCond          %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
RewriteCond          %{HTTPS} !=on
RewriteRule          .* - [F]

#   Netzwerkzugriff und/oder Basic-Authentifizierung zulassen
Satisfy              any

#   Netzwerkzugriffskontrolle
Order                deny,allow
Deny                 from all
Allow                192.168.1.0/24

#   HTTP-Basic-Authentifizierung
AuthType             basic
AuthName             "Protected Intranet Area"
AuthBasicProvider    file
AuthUserFile         conf/protected.passwd
Require              valid-user
</Directory>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]