HTTP Public Key Pinning / HPKP -> Erklärung und Einrichtung

Ein Problem „by-Design“ ist, dass jede CA für jeden Webserver Zertifikate ausstellen kann. Kaufe ich mir bei der CA foo für die Domain www.example.org ein Zertifikat, bin ich nicht davor geschützt, dass die CA bar kein Zertifikat für die gleiche Domain ausstellt. Alles schon vorgekommen… Da Webbrowser von Haus aus hunderten Zertifizierungsstellen vertrauen ist das auch kein Problem theoretischer Natur mehr, und mit Superfish oder Privdog sogar brandaktuell.

Es gibt keine 100%tige Lösung für das Problem mit den CAs, aber eine, die einen deutlichen Gewinn an Sicherheit bringt, und das für jede HTTPS Verbindung. Das ganze heißt HTTP Public Key Pinning und ist einfach erklärt: Der Webserver sendet bei seiner Antwort in einem HTTP Header mindestens zwei Informationen: a) Pins von zwei Schlüsseln und b) die Information wie lange diese gültig sein sollen. Der Webbrowser merkt sich diese Informationen und verweigert die Kontaktaufname, wenn die Pin des gesendeten Zertifikates nicht mit einer Pin aus dem HTTP Header übereinstimmt. Eine Pin ist übrigens der base64 encodete SHA256-Hash Fingerprint eines public Keys eines Zertifikats [Update: Danke Puhh für die Korrektur].
Die empfohlene Gültigkeit der Informationen liegt bei 60 Tagen, Das erklärt auch warum es zwei Pins sein müssen. Verliert man nämlich einen Key, oder dieser wird wegen einer Sicherheitslücke unsicher (Gruß an Heartbleed), schließt man potentielle Leser im schlimmsten Fall 60 Tage lang von seiner Webseite aus. Um hier das Risiko zu verringern müssen immer zwei Pins angegeben werden wovon eine die eines Backup Keys ist.

In der Praxis sieht das wie folgt aus:

  • Zwei Keys generieren:
    openssl genrsa -out www.example.org.hpkp1.key 4096
    openssl genrsa -out www.example.org.hpkp2.key 4096
  • Mit dem ersten Key einen CSR erstellen:
    openssl req -new -sha256 -key www.example.org.hpkp1.key -out www.example.org.csr
  • Zertifikat mit dem CSR besorgen
  • Zertifikat im Apache vhost einbinden
  • HPKP Header generieren. Dafür kann zum Beispiel das Skript hpkp-gen genommen werden.
  • HPKP Header in Apache einrichten. Dafür muss zuerst das Modul Headers aktiviert sein:
    a2enmod headers

    und danach der generierte HPKP Header in den vhost eingetragen werden:

      ## Header rules
      ## as per http://httpd.apache.org/docs/2.2/mod/mod_headers.html#header
      Header always set Public-Key-Pins: 'max-age=5184000; pin-sha256="+sCGKoPvhK0bw4OcPAnWL7QYsM5wMe/mn1t8VYqY9mM="; pin-sha256="bumevWtKeyHRNs7ZXbyqVVVcbifEL8iDjAzPyQ60tBE="'
  • Monitoring anpassen. Dieses sollte meckern sobald das Zertifikat in weniger als 60 Tagen abläuft. Dann sollte man mit dem Backup Key einen neuen CSR erzeugen, ein neues Zertifikat hinterlegen, einen neuen Backup-Key erstellen und auch den HPKP Header in Apache anpassen und die Pins entsprechend durchrotieren.
  • SSLLabs Test machen. Dort sollte ganz unten im letzten Kasten und darin im vorletzten Abschnitt „Public Key Pinning (HPKP)“ in grün und mit yes stehen. HSTS+HPKP

HPKP bringt darüber hinaus noch etwas spannendes mit. Wenn der Webbrowser eine Verbindung ablehnt, weil der Pin des vom Webserver gesendeten Zertifikates nicht mit einer im HTTP Header angegebenen oder im Webbrowser gespeicherten Pin übereinstimmt, kann dieser eine bestimmte Stelle informieren. Diese Stelle kann im HPKP Header optional mit angegeben werden. Dafür wird dort noch eine report-uri=“http://www.example.org/hpkpReportUrl“ hinzugefügt. Der Header sieht dann zum Beispiel so aus:

Public-Key-Pins: 'max-age=5184000; pin-sha256="+sCGKoPvhK0bw4OcPAnWL7QYsM5wMe/mn1t8VYqY9mM="; pin-sha256="bumevWtKeyHRNs7ZXbyqVVVcbifEL8iDjAzPyQ60tBE="; report-uri="http://www.pregos.info/hpkp.php"'

Die Info wird im JSON Format übertragen und als POST gesendet.

Update
Hier das hpkp.php Skript:

<?php
 
/* script that can be used as a report-uri for HPKP.
   Will just send a mail to $hpkp_to with some info and json data
   Written by Hanno Böck, https://hboeck.de/
   License: CC0 / Public Domain
*/
 
$hpkp_to = "[insert email]";
$hpkp_log = "../hpkp.log";
 
$hpkp_info = "Host: ".$_SERVER['HTTP_HOST']."n";
$hpkp_info .= "Request URI: ".$_SERVER['REQUEST_URI']."n";
if ( array_key_exists('HTTP_REFERER', $_SERVER) ) {
$hpkp_info .= "Referrer: ".$_SERVER['HTTP_REFERER']."n";
}
$hpkp_info .= "Remote IP: ".$_SERVER['REMOTE_ADDR']."n";
$hpkp_info .= "User agent: ".$_SERVER['HTTP_USER_AGENT']."n";
$hpkp_info .= "CSP JSON POST data:nn";
$hpkp_info .= str_replace( ",", ",n", file_get_contents('php://input') );
$hpkp_info .= "nServer Info:nn";
$hpkp_info .= print_r($_SERVER, true);
 
 
mail($hpkp_to, "HPKP Warning from ".$_SERVER['HTTP_HOST'], $hpkp_info);
echo "ok";
 
if ($hpkp_log != "") {
	$f = fopen($hpkp_log, "a");
	fwrite($f, $hpkp_info);
	fclose($f);
}

Puppet: SSL Zertifikate neu erzeugen für Master, Agent und PuppetDB

Wenn man „ausversehen“ mal auf dem Puppetmaster Server ein

puppet cert clean --all

ausgeführt hat und dann versucht das ganze Schlamassel wieder auszubaden sind folgende Informationen gut zu wissen:

  • Neue Zertifikate auf den Nodes erzeugt man, in dem man das Verzeichnis /var/lib/puppet/ssl einfach umbenennt und den Agent neu laufen lässt:
    $ mv /var/lib/puppet/ssl /var/lib/puppet/ssl_old
    $ puppet agent --test --server puppet.example.org
  • Wenn man auf dem Puppetmaster ebenfalls ein neues Zertifikat erzeugt und es dann Fehlermeldungen auf den Nodes gibt nach dem Motto „hostname was not match with the server certificate“ helfen folgende Schritte:
    1. Auf dem Puppetmaster Server den Certificate Hostname anzeigen:
      $ puppet master --configprint certname
    2. Puppetmaster ausstellen und altes Zertifikat löschen:
      $ service puppetmaster stop
      $ find $(puppet master --configprint ssldir) -name "$(puppet master --configprint certname).pem" -delete
    3. Den Zertifikatsnamen und die Alternativen DNS-Namen in der /etc/puppet/puppet.conf eintragen mit den folgenden Optionen:
      [master]
      certname=puppet.example.org
      certdnsname=puppet.example.org
      dns_alt_names=puppetmaster.example.org
    4. Puppetmaster Server im Vordergrund starten und zusehen wie die neuen Zertifikate generiert werden, wenn die Meldung „notice: Starting Puppet master version…“ dort steht mit Strg+c beenden:
      $ puppet master --no-daemonize --verbose
      Strg+c
      $ service puppetmaster start
  • Wenn es dann von PuppetDB eine Fehlermeldung gibt nach dem Motto „‚replace facts‘ to PuppetDB: certificate verify failed“ hilft folgendes:
    $ service puppetdb stop
    $ mv /etc/puppetdb/ssl /etc/puppetdb/ssl_old
    $ /usr/sbin/puppetdb-ssl-setup -f
    $ service puppetdb start

Infos von hier und da.

Mehr Sicherheit fuer die eigenen Daten – Zertifikate

Dieses ist der dritte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann. Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann. Der dritte Teil hier bezieht sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.

Oft probiere ich eine Software aus, erstelle mir fix eine Subdomain, richte einen vHost ein, und entweder das was ich ausprobiere ist gut und es geht in meinen digitalen Alltag ueber, oder eben nicht. Zurueck bleiben verwaiste Subdomains, deaktivierte vHosts und dann natuerlich Applikationen die ich taeglich nutze, und zu denen ich eine unverschluesselte Verbindung aufbaue, obwohl ich es selbst in der Hand habe die Verschluesselung einzustellen.

Ich habe mich an dieser Stelle bewusst gegen eine eigene CA entschieden. Das ist hinten raus sicherlich praktisch, haette meine Einstiegshuerde aber wieder zu hoch gelegt und ich bin mit frueheren Versuchen daran bisher immer an mir selbst und fehlender Kontinuitaet gescheitert. Schlichte einfache selbst signierte Zertifikate sind fuer mich immer noch am einfachsten.

Was ich jedoch gemacht habe, ist, das ich alle Zertifikate bei CAcert signieren lassen habe. Das hat fuer mich den Vorteil, dass ich ueber alle Zertifikate einen Ueberblick habe, und wenn ich will, kann ich mir auch das CAcert Rootzertifikat importieren und einfach denen vertrauen. Gemacht wie folgt:

  1. Key erzeugen:
    openssl genrsa -out example.org.key 4096
  2. CSR erzeugen:
    openssl req -new -key example.org.key -out example.org.csr

    Bei den Fragen ist nur wichtig, dass der „Common Name“ der Name der Domain oder Subdomain ist, die man sichern moechte. Ein Passwort ist nicht einzugeben.

Bei CACert dann den Inhalt der example.org.csr Datei eingeben und das Zertifikat was man angezeigt und per Email zugesendet bekommt unter example.org.crt abspeichern.

Ein einfacher Apache vHost mit SSL sieht wie folgt aus:

<VirtualHost *:443>
ServerAdmin webmaster@example.org
ServerName example.org
DocumentRoot /var/www/example.org
 
SSLEngine on
SSLCertificateFile /path/to/example.org.crt
SSLCertificateKeyFile /path/to/example.org.key
 
CustomLog /var/log/apache2/example.org-access.log combined
</VirtualHost>

Wenn man auf den Dienst nur ueber https zugreifen moechte und eine einfache Weiterleitung von  HTTP auf HTTPS einrichten moechte, kann man das zum Beispiel mit einem kleinen vHost und einer entsprechenden rewrite Regel machen:

<VirtualHost *:80>
ServerAdmin webmaster@example.org
ServerName example.org
DocumentRoot /var/www/example.org
 
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
 
CustomLog /var/log/apache2/example.org-access.log combined
</VirtualHost>

Wenn man Zugriff auf ein Nagios hat, dann ergibt es Sinn das Ablaufdatum des SSL Zertifikates mit zu Ueberwachen, damit man da nicht irgendwann in Probleme rennt. Das folgende Kommando und der folgende Check warnen einen sobald das Zertifikat nur noch 30 Tage gueltig ist.

Command Definition:

define command{
        command_name    check_ssl_certexpire
        command_line    $USER1$/check_http -H $HOSTNAME$ -p $ARG1$  -C 30
        }

Check:

define service{
        use                             my-service
        host_name                       example.org
        service_description             SSL-Cert root
        check_command                   check_ssl_certexpire!443
        }