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:

Puppet: Virtuelle Ressourcen fuer Benutzer und SSH-Keys

Puppet kann Ressourcen nur einfach definieren. Hat man eine Klasse einmal eingebunden, kann man dieses an einer zweiten Stelle nicht erneut tun. Folgendes Beispiel:

Ich deploye eine selbst entwickelte Software und moechte sie unter einem bestimmten Nutzeraccount laufen lassen. Mit Puppet stelle ich sicher, dass der Nutzeraccount existiert. Spaeter moechte ich auf dem gleichen Server eine zweite Software deployen die ebenfalls unter diesem Benutzeraccount laeuft. Ich erzeuge dafuer ein weiteres Modul das die Abhaengigkeiten abbildet. Laesst sich wunderbar alles konfigurieren, aber spaetestens auf dem Server gibt es dann einen Fehler:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate declaration: Class[FOO] is already declared; cannot redeclare at /etc/puppet/manifests/site.pp:20 on node node01.example.org

Die Loesung fuer das Problem sind virtuelle Ressourcen. Im folgenden Beispiel moechte ich aufzeigen, wie man Benutzeraccounts als virtuelle Ressourcen definiert und auf den Nodes einbindet. Die Loesung die ich hier aufzeige habe ich mir nicht selbst ausgedacht, sondern bei meinem Kollegen abgeguckt.

Eigentlich kommt man bei mehreren Benutzeraccounts auf mehreren Servern nicht um einen LDAP Server herum. Bei kleineren Setups kann man es aber auch noch auf die klassische Art- und Weise mit lokalen Konten machen.

Viele Anleitungen die man im Internet liesst zeigen Wege, bei denen man die Benutzerinformationen als Parameter an die Klasse uebergibt. Ich habe mich bewusst dagegen entschieden und alle Infos in dem Modul. Spaeter werde ich mich wohl noch mal mit Hiera beschaeftigen, dann werde ich die Informationen dort ablegen.

Die Verzeichnisstruktur meines Moduls „users“ sieht wie folgt aus:

└── manifests
    ├── init.pp
    ├── mmuster.pp
    └── virtual.pp

Die init.pp ist sehr simpel:

class users () {
  include users::virtual
}

Spannender wird es dann, wenn man die virtual.pp anschaut:

class users::virtual {
 
  @user { 'mmuster':
    ensure      => 'present',
    comment     => 'Max Mustermann,,,',
    shell       => '/bin/bash',
    managehome  => true,
    groups      => ['sudo', 'wheel' ],
    }
 
  @ssh_authorized_key { 'mmuster-privat':
    ensure      => 'present',
    type        => 'ssh-rsa',
    user        => 'mmuster',
    key         => 'AAA [...] ZZZ='
  }
}

Virtuelle Ressourcen definiert man mit einem vorgestellten @. In dem Beispiel werden zwei virtuelle Ressourcen definiert:

  1. Den Nutzeraccount mmuster
  2. Den oeffentlichen SSH-Key mmuster-privat

Die Parameter fuer den Nutzeraccount mmuster bedeuten folgendes:

  • ensure => ‚present‘: Stellt sicher, dass der Benutzeraccount existiert. Wenn nicht wird er angelegt.
  • comment => ‚Max Mustermann,,,‘: Kommentar zum Benutzeraccountt in der /etc/passwd
  • shell => ‚/bin/bash‘: Die Shell die der Benutzeraccount haben soll.
  • managehome => true: Stellt sicher das das Homeverzeichnis existiert.
  • groups => [’sudo‘, ‚wheel‘ ]: Stellt sicher, dass der Benutzeraccount Mitglied in den Gruppen sudo und wheel ist. Die Gruppen muessen im System existieren. Sie werden nicht automatisch angelegt!

Die Einstellungen fuer den SSH-Key mmuster-privat bedeuten folgendes:

  • ensure => ‚present‘: Stellt sicher, dass der SSH-Key existiert
  • type => ’ssh-rsa‘: Definiert den Verschluesselungsalgorithmus
  • user => ‚mmuster‘: Der Benutzeraccount zu dem dieser oeffentliche SSH Schlussel gehoert
  • key => ‚AAA […] ZZZ=‘:Der eigentliche public key

Fertig ist die Definition der virtuellen Ressourcen. Damit diese spaeter auch auf dem Node ausgefuehrt werden, muessen sie mit der realize Funktion markiert werden. Das passiert in der dritten Datei: mmuster.pp

class users::mmuster inherits users::virtual {
 
  realize(
    User['mmuster'],
    Ssh_authorized_key['mmuster-privat']
  )
}

Das schoene an dieser Loesung ist, dass der Nutzer nun mit einer einzigen Zeile zu dem Node hinzugefuegt werden kann:

include users::mmuster

Zum Schluss: Das Passwort wird nicht gesetzt. Man kann den Hash bei dem Nutzer mit dem Parameter password => “ mitgeben. Das finde ich aber nicht gut, weil die Nutzer dann die Passwoerter nicht selbst aendern koennen. Man findet im Netz auch Infos zu Kruecken mit denen man das Passwort nur beim Nutzer anlegen setzen kann, sollte man an diesem Punkt angelangt sein ist definitiv wieder der Zeitpunkt erreicht sich erneut Gedanken ueber einen LDAP Server zur Benutzerverwaltung zu machen 8-)

HowTo: SkyGo unter Ubuntu Linux 14.04 mit Firefox schauen

SkyGo laeuft bekanntermassen nur mit Silverlight und das gibt es mit dem ganzen DRM nur unter Windows. Dachte ich auch bis vor einigen Tagen mich ein Arbeitskollege auf das Pipelight Projekt aufmerksam gemacht hat. Lange Rede kurzer Sinn, SO laeuft SkyGo nun bei mir auch unter Linux:

sudo add-apt-repository ppa:pipelight/stable
sudo apt-get update
sudo apt-get install --install-recommends pipelight-multi
sudo pipelight-plugin --update
sudo pipelight-plugin --disable silverlight
sudo pipelight-plugin --enable silverlight5.0

Anschliessend Firefox neu starten und warten bis alles heruntergeladen und aktiviert wurde. Weiter musste ich fuer die Seite www.skygo.sky.de die Plugins AdBlock Plus, DoNotTrackMe und Disconnect deaktivieren sowie mit  User Agent Overrider den Agent auf Windows / Firefox 26 aendern.

SkyGo mit Pipelight in Firefox unter Linux