Archiv für den Monat: Oktober 2014

Skript zum Testen der Zertifikatkette und SSLv3-Fähigkeit eines Servers

Es kann mühsam sein zu prüfen, welche Zertifikatkette ein HTTPS-Server ausliefert. Die Ansicht im Webbrowser ist unzuverlässig, da der Browser unter Umständen eigene Zertifikatketten bei der Anzeige verwendet.

Ein direkter Test ist daher sinnvoll. Wir haben ein kleines Testprogramm entwickelt, das als Bash-Skript unter Linux, MacOS X und Cygwin (Windows, mit installiertem openssl und curl) läuft.

Es ist verfügbar unter: https://info.pca.dfn.de/doc/testserver.sh

Das Skript stellt eine Verbindung zu einem zu testenden Server her, und untersucht die Zertifikate, die beim Verbindungsaufbau vom Server übermittelt werden. Gegebenenfalls werden Handlungsempfehlungen ausgegeben.

Zusätzlich testet das Skript, ob auf dem Server das unsichere SSL 3.0 aktiviert ist.

Das Skript wird mit dem Namen des zu testenden Servers aufgerufen, optional mit dem Port. Als Beispiel (verkürzte Ausgabe):

$ ./testserver.sh www.dfn-cert.de 443

================================================
Informationen:
--------------
Server: www.dfn-cert.de
        www.dfn-cert.de has address 193.174.13.92
        www.dfn-cert.de has IPv6 address 2001:638:714:2801:2::
Port: 443
SSLv3 ist abgeschaltet (gut!)
Serverzertifikat:
  SubjectDN:    C=DE, ST=Hamburg, L=Hamburg, O=DFN-CERT Services GmbH, CN=www.dfn-cert.de
  Seriennummer: 6586080966759854 (0x176601787c55ae)
[...]
================================================
Ergebnisse:

Kette OK: www.dfn-cert.de:443 hat eine korrekte SHA-2 Konfiguration von Serverzertifikat und Zertifikatkette. Es ist nichts weiter zu tun.

SSLv3 ist abgeschaltet (gut!)

(jbr, 17.10.2014)

Firefox 33 und die Web-RA-Oberfläche der DFN-PKI

Mit dem Erscheinen der neuesten Version 33 von Mozilla Firefox ergeben sich leider deutliche Veränderungen bei der Benutzung der Web-RA-Oberfläche der DFN-PKI durch Teilnehmerservice Mitarbeiter:

Mit der Web-RA-Oberfläche konnten in der Vergangenheit Zertifikat- und Sperranträge genehmigt werden.

Leider hat Mozilla die zugrunde liegende Funktionalität aus Firefox 33 entfernt, so dass in der Web-RA-Oberfläche keine Zertifikat- und Sperranträge mehr genehmigt werden können. Seamonkey 2.30 ist ebenfalls betroffen.

Wichtig:

  • Die Beantragung von Zertifikaten und Sperrungen durch Nutzer und alle weiteren Features der Web-Oberfläche funktionieren nach wie vor ohne Einschränkungen.
  • Es ist ausschließlich das Genehmigen von Zertifikat- und Sperranträgen in der Web-Oberfläche betroffen.

Sie haben jetzt die folgenden Alternativen, um Zertifikat- und Sperranträge zu genehmigen:

(jbr, 16.10.2014)

SSL 3.0 abschalten

[Update: Hinweise zur Konfiguration von Windows Server/IIS]
[Update 2: Test mit openssl ergänzt]

Aus Rückwärtskompatibilitätsgründen werden viele HTTPS-Server noch mit Unterstützung von SSL 3.0 zusätzlich zum moderneren TLS 1.0, 1.1 und 1.2 betrieben.

SSL 3.0 wird seit langem als deutlich unsicherer als TLS bewertet. Am 14.10.2014 wurde ein weiterer Angriff auf SSL 3.0 veröffentlicht:

http://googleonlinesecurity.blogspot.de/2014/10/this-poodle-bites-exploiting-ssl-30.html

Für Serverbetreiber sollte dieser neue Angriff Anlass sein, SSL 3.0 endgültig abzuschalten.

Uns ist aktuell nur eine Software bekannt, die auf SSL 3.0 angewiesen ist: Der alt-ehrwürdige Internet Explorer 6, für dessen Einsatz es keinerlei Rechtfertigung mehr gibt.

SSL 3.0 kann folgendermaßen abgeschaltet werden:

Apache httpd
SSLProtocol all -SSLv2 -SSLv3
nginx
ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
Windows Server

(Getestet mit Windows Server 2012R2)

Folgendes PowerShell-Skript ausführen, danach das System neu starten (nur IIS neu starten reichte in unseren Tests nicht aus):

md 'HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server' -Force
New-ItemProperty -path 'HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server' -name Enabled -value 0 -PropertyType 'DWord' -Force

Entnommen von folgender Seite mit weiteren sehr nützlichen TLS-Konfigurationshinweisen für Windows Server: http://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12

Test

Ob ein Server SSL 3.0 anbietet oder nicht, lässt sich mit folgender openssl-Zeile ermitteln:

openssl s_client -connect <FQDN>:443 -ssl3

Bei abgeschaltetem SSL 3.0 erscheint folgende Ausgabe:

CONNECTED(00000003)
140185900164752:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL alert number 40
140185900164752:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
[...]
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
[...]
    Verify return code: 0 (ok)

 

(jbr, 15.10.2014)

freeradius und eine Falle bei der Zertifikaterneuerung

Vor kurzem lief ein Anwender in eine unangenehme Falle bei der Konfiguration von freeradius: Das Serverzertifikat vom Radius-Server wird in einer Datei abgelegt, die als „certificate_file“ in der eap.conf im Abschnitt tls konfiguriert wird.

eap {
[...]
     tls {
[...]
         certificate_file = ${certdir}/server.pem

In diese Datei kann optional zusätzlich die Zertifizierungskette vom Serverzertifikat mit aufgenommen werden, d.h., in der Datei stehen mehrere Zertifikate hintereinander:

-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----

Bei der Zertifikaterneuerung wurde dies übersehen, und in dem certificate_file nur das neue Serverzertifikat ohne Zertifizierungskette abgelegt. Daraufhin konnten sich diverse eduroam-Clients nicht mehr verbinden, und im freeradius-Log erschienen die folgenden Fehlermeldungen:


Tue Sep 30 13:28:01 2014 : Error: TLS Alert read:fatal:unknown CA
Tue Sep 30 13:28:01 2014 : Error: rlm_eap: SSL error error:14094418:SSL
routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

Abhilfe: Vor der Zertifikaterneuerung prüfen, ob die verwendete freeradius-Konfiguration die Zertifizierungskette im certificate_file erfordert, und gegebenenfalls vor der Installation des neuen Zertifikats ergänzen.

(jbr, 01.10.2014)