Archiv für den Monat: März 2015

Kürzere Laufzeit für neu ausgestellte Serverzertifikate

Wie bereits seit 2012 in der Policy der DFN-PKI verankert, wird ab 31.03.2015 abends die maximale Gültigkeit von neu ausgestellten Serverzertifikaten in der DFN-PKI, Sicherheitsniveau „Global“, auf 39 Monate beschränkt.

Die vorher mögliche Laufzeit von 5 Jahren ist nach den „Baseline Requirements“ des CA/Browser-Forums, zu deren Einhaltung die DFN-PKI verpflichtet ist, nicht mehr erlaubt.

Referenzen:

Abschnitt 6.3.2 des CP der DFN-PKI „Global“
Abschnitt 9.4.1 der Baseline Requirements

(jbr, 31.03.2015)

FREAK-Attack: Konfiguration von TLS-Servern prüfen

Am 3. März 2015 wurde ein neuer Angriff auf verschiedene TLS-Implementierungen wie Safari und openssl bekannt, der wieder einmal deutlich macht, wie wichtig eine korrekte Konfiguration von TLS-Servern ist:

https://www.smacktls.com/#freak

http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html

Ein aktiver Man-In-The-Middle kann unter bestimmten Umständen einen Client dazu bringen, alte und vollkommen unsichere SSL-Algorithmen zu akzeptieren. Dadurch kann die Verbindung vom Angreifer sehr leicht entschlüsselt werden. Der Angriff kann nur durchgeführt werden, wenn die folgenden beiden Bedingungen zusammen erfüllt sind:

Der Client verwendet eine verwundbare TLS-Software
Der Server erlaubt veraltete Cipher Suites

Die FREAK-Attacke kann also, wie zahlreiche anderen Angriffe auf verschlüsselte Verbindungen in der letzten Zeit, von jedem Administrator eines TLS-Servers nur durch Konfigurationseinstellungen abgewehrt werden.

Wir empfehlen dringend, regelmäßig die Konfigurationseinstellungen Ihrer TLS-Server zu überprüfen und beispielsweise mit den Anleitungen von BetterCrypto.org abzugleichen. Externe Werkzeuge wie der Test von SSL Labs können diese Arbeit deutlich erleichtern.

Bitte beachten Sie bei der Nutzung von externen Diensten, dass Sie damit Daten über Ihre Server an Dritte weitergeben.

(jbr, 04.03.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.

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

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)