Beim sogenannten Certificate pinning werden Zertifikate, welche für die Verschlüsselung von Webseiten und anderen Diensten genutzt werden, lokal gespeichert. Dies hat den Vorteil, das dass Zertifikat nicht einfach unbemerkt durch ein anderes Zertifikat ausgetauscht werden kann und erschwert damit das abhören von SSL/TLS-Verbindungen.
Leider ist diese Funktionalität in den gängigen Browsern nicht vorhanden. Mit dem Firefox-AddOn Certificate Patrol kann man ein solches Certificate pinning im Browser nachrüsten. Zertifikate müssen dabei einmalig akzeptiert werden – anschließend wird man informiert, wenn sich das Zertifikat ändert. Damit ist es für einen Angreifer wesentlich schwieriger geworden, dem Nutzer falsche Zertifikate unterzuschieben.
Wer seine Domains mit Zertifikaten für SSL bzw. TLS ausgerüstet, um den Aufruf per HTTPS zu ermöglichen, fragt sich am Ende wie sinnvoll das ganze konfiguriert ist.
Eine Auswertung für heise.de
Mit dem SSL-Test von Qualys kann man das unter ssllabs.com/ssltest/ herausfinden. Nach dem Test erfolgt eine Auswertung, welche mit einer Gesamtnote bewertet wird. Anschließend finden sich in tabellarischer Form die Einzelergebnisse.
Einen Server auf seine SSL-Fähigkeiten zu überprüfen ist für den Laien nicht ohne weiteres möglich. Durch das Bash-Skript testssl.sh sieht dies nun anders aus.
testssl.sh in Aktion
Das freie, unter der GPL2 lizenzierte Skript, dient dazu die Sicherheit der SSL-Implementation eines entfernten Servers zu testen. Die Syntax für den Test ist dabei einfach gehalten:
./testssl.sh example.com
Daneben verfügt „testssl.sh“ über weitere Optionen, wie man der Dokumentation entnehmen kann. Dem Autor des Skriptes kann auf Twitter gefolgt werden.
Wenn man mit nicht von einer Certificate Authority signierten Zertifikaten arbeitet, so wird man früher oder später folgende Fehlermeldung unter .NET zu sehen bekommen.
Das Remotezertifikat ist laut Validierungsverfahren ungültig.
SSL ist zwar aktiviert, aber das Zertifikat kann in diesem Fall nicht validiert werden. Eine Methode um die Validierung abzuschalten ist dabei folgenden Einzeiler über diese Zeilen zu schreiben:
Für verschlüsselte HTTP Verbindungen benötigt man ein Zertifikat. Dieses kann man sich von einer Zertifizierungsstelle (Certificate Authority, CA) ausstellen lassen. Der Haken an der Sache ist das dies Geld kostet (CACert und StartCom mal außen vor gelassen). Eine Alternative hierzu wäre es das Zertifikat selbst zu erstellen. Bei Diensten die man nur für einen kleinen Nutzerkreis z.B. für die Familie hostet, ist es auch vertretbar die Zertifikatswarnung im Browser über sich ergehen zu lassen. Für die Zertifikate wird ein Ordner erstellt und in diesen gewechselt:
Bei der Erstellung des Certificate Signing Request müssen einige Daten angegeben werden:
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Mecklenburg-Vorpommern
Locality Name (eg, city) []:Neubrandenburg
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example Inc
Organizational Unit Name (eg, section) []:Skunk works
Common Name (e.g. server FQDN or YOUR name) []:example.org
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Nun muss das Zertifikat noch signiert werden, bevor wir es verwenden können:
In diesem Fall ist das Zertifikat 730 Tage, also zwei Jahre gültig. Da die Signierung nun abgeschlossen ist, kann das Zertifikat in Nginx eingebunden werden. Dazu öffnen wir die Datei „/etc/nginx/sites-available/example“, wobei „example“ hier natürlich für die entsprechende Konfigurationsdatei steht. Dort sollte die SSL Konfiguration vorgenommen werden:
server {
listen 443 ssl;
root /var/www/example/root;
index index.html index.htm;
server_name .example.org;
ssl_certificate /etc/nginx/ssl/example.crt;
ssl_certificate_key /etc/nginx/ssl/example.key;
}
Nach dem Aktualisieren der Konfiguration mittels:
service nginx restart
ist die verschlüsselte Verbindung für die eingerichtete Seite aktiv und kann genutzt werden.
