Apache: OCSP Stapling aktivieren

Ab Apache Version 2.4 (in Debian Jessie enthalten) wird OCSP Stapling unterstützt. OCSP steht für Online Certificate Status Protocol. Damit kann die Gültigkeit eines Zertifikates abgefragt werden. Das ganze sieht in der Praxis dann so aus, dass wenn ein Nutzer eine Webseite über HTTPS aufruft, der Webbrowser dann eine im Zertifikat enthaltene OCSP Responder Adresse abfragt um festzustellen, ob das Zertifikat noch gültig ist. Das ist natürlich für die Sicherheit gut, hat aber zwei Nachteile:

  • Die OCSP Responder Server werden beim Verbindungsaufbau zusätzlich abgefragt, das führt je nach Auslastung und Verfügbarkeit des Responders zu einer Verzögerung
  • Der OCSP Responder Server bekommt mit, welche Webseite von welcher IP-Adresse aufgerufen wird

Ob die OCSP Responder letzteres nun loggen oder nicht ist nicht immer eindeutig zu klären, deswegen gehe ich davon aus, dass das im Zweifel so ist.

Abhilfe bringt OCSP Stapling. Dabei fragt der Webserver selbst regelmäßig den OCSP Responder für seine Zertifikate ab und behält diese Information in einem Zwischenspeicher. Beim Verbindungsaufbau sendet er dann die OCSP Antwort gleich mit. Da es sich hierbei um eine komplett signierte Kommunikation handelt, vom OCSP Responder über den Webserver bis hin zum Browser und der Browser die Signatur überprüft ist die Antwort verifiziert und der Browser muss keine Verbindung mehr zum OCSP Responder aufnehmen.

In Apache ist das ganze recht einfach eingerichtet. Ich habe einfach unter /etc/apache2/conf.d/ eine Datei OCSP_Stapling.conf angelegt mit dem folgenden Inhalt:

SSLUseStapling on
SSLStaplingCache 'shmcb:/tmp/stapling-cache(102400)'
SSLStaplingReturnResponderErrors off

Dabei ist wichtig, dass der SSLStaplingCache außerhalb eines vhosts definiert wird. Prüfen kann man das ganze dann bei dem von mir gern genommenen SSL Server Test von Qualys. Da sieht das dann bei Erfolg so aus:

screenshot-www ssllabs com 2015-08-30 14-35-20

Weitere Informationen zu dem Thema:

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.

Ein Versuch #Heartbleed fuer nicht-Techniker verstaendlich zu machen

heartbleed

Eigentlich sollte ich keine Zeit haben zu schreiben, aber das ist die mit Abstand krasseste Sicherheitsluecke die es seit langem gegeben hat. Das Ausmass kann man nur erahnen, im Prinzip muessen alle persoenlichen Daten auf einem System das den Fehler hatte als unsicher erachtet werden. Es reicht nicht die gepatchte Version von OpenSSL einzuspielen und die betroffenen Prozesse wie Apache, Postfix, Dovecot oder OpenVPN neu zu starten. Es muessen private Schluessel und Zertifikate erneuert werden und wer den Konsequenzen der Luecke klar ins Gesicht schaut wird auch ueberall Passwoerter neu setzen muessen.

Heute beim Kaffee und Kuchen fragte unsere Nachbarin wie man sich das vorstellen koennte und ich habe versucht es wie folgt zu erklaeren:

Stell Dir vor auf dieser Welt gibt es einen Hersteller fuer Haustuerschloesser. Dieser Hersteller baut sehr sichere Schloesser und man kann sich darauf verlassen, dass wenn man seine Haustuer mit einem Schloss dieser Marke schuetzt, dass dort nicht eingebrochen werden kann. Das Schloss ist in diesen Fall OpenSSL, und das Haus der Server selbst.

Vor ein paar Jahren gab es dann den Trend zu sogenannter Perfect Forward Secrecy. Im uebertragenen Sinne kann man sich das so vorstellen, dass das Schloss kontinuierlich neue Schluessel generiert die jedes mal anders sind. Gelangt also mal ein Haustuerschluessel in die falschen Haende, dann kann man damit trotzdem nichts mehr anfangen, weil das Schloss sich geaendert hat.

Die Sicherheitsluecke in OpenSSL erlaubt es, das man von extern, ohne, dass man auf den Server einbrechen muss, an sehr sehr private Daten gelangen kann. Das koennen Zugangsdaten sein oder auch der private Key, mit dem man sich dann fuer den Server ausgeben kann ohne eben dieser zu sein.

Wenn man das wieder auf den Schlosshersteller und das Haus zurueckbringt, dann stelle man sich vor, das man zu jedem Haus mit einem Schloss von diesem Schlosshersteller hingehen kann, und ohne einzubrechen bekommt man die Information wie das Schloss jetzt Schluessel generiert. Man muss nichts stehlen, man muss nichts kaputt machen, man geht einfach hin und fragt und das Schloss sagt es einem.

Auch wenn in dem Beispiel viele Dinge vielleicht als Vergleich hinken, es zeigt ziemlich einfach welche Tragweite die Sicherheitsluecke hat. Man kann ja von aussen nicht sehen „ob jemand vorbeigekommen ist und gefragt hat wie sich das Schloss aendert oder nicht“. Aus diesem Grund muss man alle Server auf denen OpenSSL in der betroffenen Version eingesetzt wurde als unsicher betrachten. Der Fehler existiert seit dem 14. Maerz 2012 und man muss also davon ausgehen, dass es Menschen / Organisationen gibt, die seit zwei Jahren in alles rein gucken konnten was man irgendwie sichern wollte.

Fuer Sysadmins ist das der Supergau…

Eine ganz gute Zusammenfassung zu dem Thema gibt es bei Golem:

Weitere Infos:

Wer seine eigene Infrastruktur testen moechte (Router, NAS, Drucket etc) kann mit dem heartbleeder lokale IP Adressen probieren und findet dann auf einschlaegigen Seiten wie Packetstormsecurity die entsprechenden Exploits…