Mit den Tipps und Workshops im ADMIN-Magazin 03/2013 sichern Administratoren ihre Webserver und Netze gegen Angriffe ab: gegen Abhören sensibler Informationen, ... (mehr)

Passphrase zum Start

Abschließend muss man Apache einmal neu starten, unter Debian etwa mit »/etc/init.d/apache2 restart« . Apache fordert dabei die Passphrase für den privaten Schlüssel ein. Verhindern kann man das nur, indem man die Verschlüsselung wieder entfernt. Damit ist der private Schlüssel aber ungeschützt, was wiederum ein Sicherheitsrisiko darstellt. Kommen mehrere per SSL gesicherte virtuelle Hosts zum Einsatz, versucht Apache die eingetippte Passphrase auch auf alle übrigen privaten Schlüssel anzuwenden. Im Idealfall muss man so nur einmal eine Passphrase eintippen.

Sobald der User jetzt die verschlüsselte Seite ansteuert – in den bisherigen Beispielen »https://login.example.com« – warnt der Browser bei einem selbst erstellten Zertifikat vor mangelnder Sicherheit (Abbildung 3). Hier bleibt dem Anwender nur, das Zertifikat per Hand als vertrauenswürdig einzustufen. Anschließend läuft die Kommunikation verschlüsselt ab.

Abbildung 3: Selbst erstellte Zertifikate weisen die Browser mit einer entsprechenden Meldung zunächst zurück.

Qual der Wahl

Neben den drei SSL-Direktiven aus Listing 1 kennt Apache noch ein paar weitere. Besonders interessant ist »SSLCipherSuite« . Sie gibt an, welche Verschlüsselungsalgorithmen der Webserver für den SSL-Handshake akzeptiert. Der Direktive folgt dabei eine durch Doppelpunkte getrennte Liste mit den möglichen Algorithmen. Angeben muss man dabei jeweils mindestens einen Algorithmus für den Schlüsselaustausch, die Authentifizierung, die Verschlüsselung und die Integritätsprüfung. Ein Beispiel für eine solche Auswahl wäre:

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

Diese Liste sieht auf den ersten Blick ziemlich wüst aus, erklärt sich aber schnell: Jeder Algorithmus erhält ein Kürzel, »RC4« steht beispielsweise für den RC4-Algorithmus. Alle weiteren Kürzel stellt Tabelle 1 vor. Damit man sich nicht die Finger wund tippt, gibt es netterweise noch Abkürzungen beziehungsweise Alias-Namen. So steht »SSLv2« für alle vom SSL-2-Standard unterstützten Algorithmen, »ALL« für alle möglichen. Die übrigen Abkürzungen listet Tabelle 2 auf. »Exportfähig« bezieht sich dabei auf die Ausfuhrbeschränkungen der USA, nach denen besonders starke Verschlüsselungsverfahren nicht exportiert werden dürfen. »EXP« enthält somit nur Verfahren mit geringer Schlüssellänge.

Tabelle 2

Alias-Namen für SSLCipherSuite

Kürzel

Bedeutung

SSLv3

Alle von SSL 3.0 unterstützte Algorithmen

TLSv1

Alle von TLS 1.0 unterstützte Algorithmen

EXP

Alle exportfähigen Algorithmen

EXPORT40

Exportfähige Algorithmen mit 40 Bit

EXPORT56

Exportfähige Algorithmen mit 56 Bit

LOW

Schwache, aber nicht exportfähige Algorithmen (Single-DES)

MEDIUM

Alle Algorithmen mit 128 Bit

HIGH

Alle Algorithmen, die Triple-DES nutzen

RSA

Alle Algorithmen, die einen RSA-Schlüsselaustausch verwenden

DH

Alle Algorithmen, die einen Diffie-Hellman-Schlüsselaustausch verwenden

EDH

Alle Algorithmen, die einen Schlüsselaustausch mit Ephemeral-Diffie-Hellman verwenden

ECDH

Schlüsselaustausch mittels Elliptic Curve Diffie-Hellman

ADH

Alle Algorithmen, die einen Anonymous-Diffie-Hellman-Schlüsselaustausch verwenden

AECDH

Alle Algorithmen, die einen Schlüsselaustausch mit Elliptic Curve Diffie-Hellman verwenden

SRP

Alle Algorithmen, die einen Schlüsselaustausch mit Secure Remote Password (SRP) verwenden

DSS

Alle Algorithmen, die eine DSS-Authentifizierung verwenden

ECDSA

Alle Algorithmen, die eine ECDSA-Authentifizierung verwenden

aNULL

Alle Algorithmen, die keine Authentifizierung verwenden

Tabelle 1

Mögliche Algorithmen für SSLCipherSuite

Kürzel

Bedeutung

Algorithmen für den Schlüsselaustausch

kRSA

RSA

kDHr

Diffie-Hellman mit RSA-Schlüssel

kDHd

Diffie-Hellman mit DSA-Schlüssel

kEDH

Ephemeral-Diffie-Hellman (temporärer Schlüssel ohne Zertifikat)

kSRP

Schlüsselaustausch per Secure Remote Password (SRP)

Authentifizierungsalgorithmen

aNULL

Keine Authentifizierung

aRSA

RSA

aDSS

DSS

aDH

Diffie-Hellman

Verschlüsselungsalgorithmus

eNULL

Keine Verschlüsselung

NULL

Wie eNULL

AES

AES

DES

DES

3DES

Triple-DES

RC4

RC4

RC2

RC2

IDEA

IDEA

Algorithmen zur Integritätsprüfung (MAC-Digest-Algorithmus)

MD5

MD5

SHA1

SHA1

SHA

Wie SHA1

SHA256

SHA256

SHA384

SHA384

Schließlich darf man bestimmte Algorithmen noch bevorzugen oder ausschließen. Das zeigen die Sonderzeichen »+« , »-« und »!« an, die den Kürzeln vorangestellt werden. »!« verbietet einen Algorithmus, »!ADH« schließt im obigen Beispiel folglich alle Algorithmen aus, die Anonymous Diffie-Hellmann verwenden. Das Minuszeichen »-« entfernt ebenfalls einen Algorithmus, der sich aber später in der Kette wieder hinzufügen lässt. Mit dem Pluszeichen kann man einen Algorithmus explizit an die entsprechende Position der Liste setzen und so die Reihenfolge beeinflussen. Im obigen Beispiel würde der Webserver etwa die Algorithmen aus der »HIGH« -Gruppe denen der »MEDIUM« -Gruppe bevorzugen. Abschließend kann man auch noch mehrere vorgegebene Cipher-Suiten auswählen, indem man zwischen den Kürzeln ein »+« einfügt. Im obigen Beispiel wären mit »RC4+RSA« alle Cipher-Suiten möglich, die »RC4« und »RSA« enthalten. Das Beispiel ist übrigens gleichzeitig der Standardwert unter Apache 2.2. Apache 2.4 übernimmt hingegen die Standardeinstellungen von OpenSSL.

Welche Algorithmenkombinationen mit einer Einstellung möglich sind, verrät der Befehl »openssl ciphers -v« . Ihm hängt man einfach den zu untersuchenden Bandwurm an:

openssl ciphers -v 'ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP'

Das Ergebnis ist eine Tabelle wie die aus Abbildung 5. Die erste Spalte listet die Namen der Cipher-Suiten auf, die zweite nennt den SSL-Standard. Es folgen in den weiteren Spalten die Algorithmen für den Schlüsselaustausch, die Authentifizierung, die Verschlüsselung und die Integritätsprüfung.

Abbildung 5: Die möglichen Algorithmenkombinationen zeigt openssl an.

Die großen Browser bevorzugen normalerweise sichere Algorithmen, derzeit vor allem AES, die jedoch mehr Rechenzeit kosten. Administratoren, die stattdessen auf schnellere, einfachere Verfahren setzen, leben gefährlich: So geriet zuletzt RC4 in die Schlagzeilen. Mehr zu Problemen mit TLS verrät ein Artikel in der Security-Rubrik dieses Hefts.

Man sollte daher nicht mit einer eigenen »SSLCipherSuite« -Regel die vom Client vorgeschlagenen, sicheren Verfahren überstimmen. Beschleunigen kann man die Codierung, indem man OpenSSL eine eventuell vorhandene Kryptohardware nutzen lässt. Das setzt allerdings voraus, dass OpenSSL mit »Engine« -Unterstützung übersetzt wurde (Abbildung 6). Ab OpenSSL 0.9.7 ist dies standardmäßig der Fall. Welche Hardwarebeschleuniger dann zur Verfügung stehen, verrät:

openssl engine

Von diesen wählt man einen aus und setzt den Namen in die Klammern hinter die Direktive »SSLCryptoDevice« , wie etwa:

SSLCryptoDevice rsax

Zusätzlich lässt sich auch ein Cache für Session-Daten einrichten:

SSLSessionCache dbm:/tmp/cachedatei

In diesem Fall würde Apache die DBM-Datei »/tmp/cachedatei« verwenden.

Abbildung 6: Auf diesem Core i7 unter Open Suse 12.3 gibt es nur ein Crypto-Device für hardwarebeschleunigte Verschlüsselung.
comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019