Schlagwort-Archive: OCSP

OCSP-Stapling in nginx

OCSP-Stapling kann in nginx ab Version 1.3.7 leicht angeschaltet werden. Die Basiskonfiguration ist simpel, allerdings gilt es vier Fallen zu umgehen:

Netzwerk

Der Webserver, auf dem OCSP-Stapling konfiguriert werden soll, muss ausgehende Anfragen an http://ocsp.pca.dfn.de stellen können. Sollte der Server durch eine Firewall an ausgehendem Traffic gehindert werden, muss für OCSP-Stapling eine Ausnahme gemacht werden.

Ist dies nicht erwünscht, müssen komplexere Setups genutzt werden, bei denen OCSP-Responses als Datei über mehrere  Etappen bis zum Webserver gelangen. Auf diese Szenarien wird hier aber nicht weiter eingegangen.

DNS

nginx nutzt per Default den DNS Server von Google, IP 8.8.8.8, um die Adresse des OCSP-Responders  (in der DFN-PKI ist dies ocsp.pca.dfn.de) aufzulösen. Die meisten Webserver sind sinnvollerweise so konfiguriert, dass sie keine Verbindung zu externen DNS-Servern aufnehmen können. Daher muss dem nginx die Adresse des lokalen DNS-Servers separat über den Konfigurationseintrag resolver mitgeteilt werden.

Zertifikatsketten

nginx benötigt die vollständige Zertifikatkette des Serverzertifikats inklusive der Wurzel zum Betrieb von OCSP Stapling. Der dafür vorgesehene Konfigurationsparameter ist ssl_trusted_certificate.

Dieser Parameter ist ein wenig problematisch, da die dort enthaltene Zertifikatkette auch im Rahmen des TLS-Handshakes an Endgeräte ausgeliefert wird, wenn in ssl_certificate keine Kette enthalten ist. Im TLS-Handshake soll das Wurzelzertifikat aber nicht mit enthalten sein.

Die Lösung: In ssl_trusted_certificates die vollständige Kette inklusive Wurzelzertifiakt konfigurieren, und in das Serverzertifikat in ssl_certificate die Kette ohne Wurzelzertifikat aufnehmen. Die Reihenfolge der Zertifikate in den Dateien muss „aufsteigend“ bis zur Wurzel sein. Es müssen die reinen PEM-Files ohne Zwischen-Kommentare angegeben werden:
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----

Mehrere virtuelle Hosts

Wenn mehrere virtuelle Hosts im nginx konfiguriert sind, so muss OCSP-Stapling mindestens für den als default_server konfigurierten Host aktiviert sein, damit das OCSP-Stapling dann auch auf den anderen virtuellen Hosts funktionieren kann.

Konfiguration

Konkret sollte der vom OCSP-Stapling betroffene Teil der SSL-Konfiguration eines nginx also folgendermaßen aussehen (die IP-Adressen sind natürlich, wie die Pfade, nur Platzhalter):

ssl_trusted_certificate /pfad/vollstaendige_kette_mit_root
ssl_certificate /pfad/serverzertifikat_inklusive_kette_ohne_root
ssl_stapling on;
ssl_stapling_verify on;
resolver 192.168.100.100 192.168.100.101 valid=300s;
resolver_timeout 10s

Testen

Getestet wird die OCSP-Stapling-Konfiguration auf dem nginx mittels (der Host-Name ist natürlich auch hier nur ein Platzhalter) :

openssl s_client -connect blog.example.org:443 -servername blog.example.org -status < /dev/null 2>&1 | grep -i "OCSP response"

Nach einem Neustart des nginx wird die einzubettende OCSP-Response erst beim ersten Abruf einer Web-Seite des Servers vom OCSP-Responder abgeholt und zwischengespeichert, so dass bei diesem ersten Abruf keine OCSP-Response eingebettet werden kann. Erst beim zweiten Abruf einer Web-Seite des Servers wird dann auch eine eingebettete OCSP-Response mitgeliefert, d.h. nach einem Neustart des nginx muss obiger openssl-Aufruf zweimal hintereinander ausgeführt werden, um ein aussagekräftiges Ergebnis zu liefern.

Dokumentation von nginx:  http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling

(jbr, 17.06.2015, ergänzt am 20.11.2015)

Lightweight-OCSP nach RFC 5019 und FreeRADIUS

Die OCSP-Responder der DFN-PKI arbeiteten lange Zeit gemäß RFC 2560. Dieser Betriebsmodus hat insbesondere in Hochlast-Umgebungen Nachteile; insbesondere wird ein Caching von OCSP-Antworten deutlich erschwert.

RFC 5019, „The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments“, spezifiziert eine OCSP-Variante, die die Caching-Probleme deutlich abmildert.

Seit Mitte Mai wurden die OCSP-Responder der DFN-PKI der Reihe nach auf eine neue Software-Version gebracht, die RFC 5019 verwendet. Damit werden Caching-Header gesetzt und sogenannte Nonces aus eingehenden Anfragen nicht mehr in die OCSP-Antwort kopiert. Viele OCSP-Responder, auch von sehr großen CAs, werden erfolgreich nach RFC 5019 betrieben.

Leider gibt es hierbei einen Nebeneffekt bei FreeRADIUS: Wenn man Nutzerzertifikate zur Authentifizierung verwendet, und zur Validierung der Nutzerzertifikate OCSP aktiviert hat, muss zwingend eine zusätzliche Konfigurationsoption in den OCSP-Abschnitt der eap/tls-Konfiguration gesetzt werden:

ocsp {
   ...
   use_nonce = no
   ...
}

Wird diese Option nicht verwendet, akzeptiert FreeRADIUS das Nutzerzertifikat nicht und schreibt, je nach Loglevel, die folgende Nachricht in das radius.log :

Error: OCSP response has wrong nonce value

(jbr, 05.06.2015)

Mehr Privacy für den Nutzer: OCSP-Stapling

[Update 20.5.2016: Fehlerhafter Hinweis auf SSLCACertificateFile für Apache entfernt.]

Zertifikate für Webserver enthalten die URL eines OCSP-Responders, der von der Zertifizierungsstelle betrieben wird. Viele Webbrowser wie z.B. Firefox oder Internet Explorer (aber nicht Google Chrome) führen beim Aufrufen einer https-Webseite mit dieser URL eine Prüfung durch, ob das Zertifikat gesperrt wurde. Hierzu stellen sie nach dem Verbindungsaufbau mit der Webseite eine weitere Anfrage an den OCSP-Responder, dessen URL im Serverzertifikat enthalten ist.

ocsp

Ablauf eines Webseitenaufrufs inklusive OCSP-Abfrage

Dieses Verhalten offenbart dem Betreiber des OCSP-Responders, von welcher IP-Adresse welcher Webserver aufgerufen wurden. Selbstverständlich werden auf den OCSP-Respondern der DFN-PKI keine IP-Adressen geloggt. Für Zertifikate aus anderen PKIs ist das Logging-Verhalten der zugehörigen OCSP-Responder aber nicht einfach zu klären.

Ein weiterer Nachteil ist die erhöhte Latenz durch den zusätzlichen Verbindungsaufbau zum OCSP-Responder.

Zur Lösung dieses Problems gibt es seit einiger Zeit ein Verfahren namens OCSP-Stapling, standardisiert in http://tools.ietf.org/html/rfc6066

ocsp_stapling_angewandt

Ablauf eines Webseitenaufrufs mit OCSP-Stapling

Beim OCSP-Stapling bezieht der Webserver regelmäßig (z.B. jede Stunde) vom OCSP-Responder eine OCSP-Antwort über sein eigenes Zertifikat, und schickt diese direkt im initialen TLS-Handshake zum Webbrowser des Nutzers. Damit muss der Webbrowser des Nutzers keine Verbindung zum OCSP-Responder aufnehmen.

Da die OCSP-Antwort immer vom OCSP-Responder signiert ist und diese Signatur vom Webbrowser verifiziert wird, ist die Sicherheit des Verfahrens gewährleistet.

OCSP-Stapling ist ein Feature, das die Software des Webservers unterstützen muss, und das teilweise separat konfiguriert werden muss. Es wird z.B. von folgender Software unterstützt:

  • Microsoft IIS ab Version 8.0
  • Apache ab 2.3.3
  • nginx ab 1.3.7

In Microsoft IIS ist OCSP-Stapling per Default aktiviert, es ist keine Konfiguration notwendig. In Apache lässt es sich sehr einfach einschalten:

SSLStaplingCache shmcb:/tmp/stapling_cache(102400)
SSLUseStapling on
SSLStaplingReturnResponderErrors off

Bedingungen für die Nutzung im Apache:

  • Das socache_shmcb-Modul muss geladen sein.
  • SSLStaplingCache muss außerhalb eines VirtualHost gesetzt werden.
  • Der Server muss den OCSP-Responder erreichen können (Ausgehende Verbindung in der Firewall, evtl. DNS).

Ob ein Server so konfiguriert ist, dass OCSP-Stapling genutzt wird, kann entweder mit den Test-Werkzeugen von SSL Labs geprüft werden, oder aber direkt mit openssl:

# openssl s_client -connect www.example.org:443 -status
CONNECTED(00000003)
depth=3 C = DE, O = Test, CN = Test Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
[...]

Es ist zu empfehlen, wo immer möglich OCSP-Stapling zu aktivieren, da es für alle Beteiligten nur Vorteile bietet.

(jbr, 04.03.2015)