Mai 172016
 

OpenJDK 7 kam ohne Probleme mit 4 KBit breiten Diffie-Hellman-Schlüsselaustausch klar. Aus unbekannten Gründen ist das in OpenJDK 8 nicht mehr der Fall. Da Apache 2.4 die DH-Schlüsselbreite aus der Schlüsselbreite des SSL-Zertifikats übernimmt, kann man mit OpenJDK 8 keinen Kontakt mit Webservern aufnehmen, die eine entsprechend hohe SSL-Sicherheit bieten.

Installation von OpenJDK 8 unter Ubuntu 14.04 LTS

Unter Ubuntu 14.04 ist OpenJDK 8 noch nicht in der Distribution enthalten. Um hier ein OpenJDK 8 zu installieren, muss ein PPA-Repository in der Datei /etc/apt/sources.list ergänzt werden.

deb http://ppa.launchpad.net/openjdk-r/ppa/ubuntu trusty main

Das OpenJDK 8 wird durch folgende Befehlsfolge installiert:

sudo gpg --recv-keys EB9B1D8886F44E2A
sudo gpg --export EB9B1D8886F44E2A|apt-key add -
sudo apt-get update
sudo apt-get install openjdk-8-jdk

Die erste Befehlsfolge installiert den Repository Key lokal, um dem PPA-Repository vertrauen zu können.


Anzeige:


Installation von Bouncy Castle

Bouncy Castle eine Sammlung kryptografischer Algorithmen und enthält einen sog. Security Provider, welcher diese Algorithmen für das JRE bereitstellt. Glücklicherweise stellt Ubuntu 14.04 Bouncy Castle schon in der Distribution bereit und muss somit nur noch installiert werden:

sudo apt-get install libbcprov-java

Jetzt muss die Library aus dem Paket im OpenJDK sichtbar gemacht werden. Das erfolgt sinnvollerweise über einen symbolischen Link:

cd /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext
sudo ln -s /usr/share/java/bcprov.jar .

Als abschließenden Schritt muss der Security Provider konfiguriert werden. Mit dem Lieblingseditor – z.B. vi – wird die Datei /etc/java-8-openjdk/security/java.security geöffnet:

sudo vi /etc/java-8-openjdk/security/java.security

Relativ am Anfang der Datei befinden sich mehrere Zeilen, die mit security.provider.X beginnen. Es sind die möglichen Security Provider, die priorisiert bei der Instanziierung abgearbeitet werden. An zweiter Stelle wird folgende Zeile eingefügt:

security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider

Alle nachfolgenden Zeilen müssen entsprechend umnummeriert werden.

Wichtig!
Die Zeile darf nicht an erster Stelle konfiguriert werden, weil intern im OpenJDK Abhängigkeiten nicht mehr aufgelöst werden können!

Nach diesen Schritten sollte es möglich sein, mit OpenJDK 8 eine sichere SSL-Verbindung aufbauen zu können.

Referenzen:

Jan 152015
 

Nach neuesten Erkenntnissen [2] und [3] ist die NSA nicht nur an HTTPS-Verkehr, sondern auch an SSH interessiert. Es ist aber nicht so, dass SSH grundsätzlich geknackt ist, sondern dass SSH-Verkehr nur unter gewissen Umständen entziffert werden kann. Werden entsprechend gute Cipher verwendet, ist auch für die NSA eine Entschlüsselung derzeit nicht möglich. Wie bei HTTPS sollten bei SSH nur die Cipher eingestellt werden, die derzeit als sicher gelten. Das ist auch nötig, da selbst in aktuellen Betriebssystemversionen (z.B. Ubuntu 12.04 LTS und 14.04 LTS) unter anderem auch RC4 möglich ist, was inzwischen als hinreichend unsicher gilt.

Bei OpenSSH werden die Ciphers nicht mit einem Kommando festgelegt. Es werden der Schlüsselaustausch, das symmetrische Kryptoverfahren und die Authenzität mit drei getrennten Kommandos eingestellt. Diese Werte können für den Server (/etc/ssh/sshd_config) und für den Client (/etc/ssh/ssh_config) auf demselben Weg konfiguriert werden. SSH beherrscht unter neueren Linux-Versionen mehr Cipher. Welche unterstützt werden, sind in der Man Page unter den entsprechenden Schlüsselwörtern einsehbar.


Anzeige:




Key Exchange

Die Schlüsselaustausch-Algorithmen für den symmetrischen Verschlüsselungsalgorithmus wird mit dem Schlüsselwort KexAlgorithms konfiguriert. Grundsätzlich sollte hier Perfect Forward Secracy verwendet werden. Das hat den Vorteil, dass selbst für mitgeschnittenen Traffic der Schlüssel nur durch Brute Force ermittelt werden muss. Hier sind je nach Version folgende Algorithmen in ihrer Reihenfolge sinnvoll:

  • curve25519-sha256@libssh.org
  • diffie-hellman-group-exchange-sha256
  • diffie-hellman-group-exchange-sha1
  • diffie-hellman-group14-sha1
  • diffie-hellman-group1-sha1

Clientseitig kann noch folgende Option ergänzt werden, damit nach 64 MByte Traffic ein neuer symmetrischer Schlüssel ausgehandelt wird. Das erschwert zusätzlich noch das Knacken der Daten.

RekeyLimit 64M

Symmetrische Verschlüsselung

Die symmetrische Verschlüsselung wird mit dem Schlüsselwort Ciphers konfiguriert. Auch hier eine Liste der entsprechenden Ciphers:

  • chacha20-poly1305@openssh.com
  • aes256-gcm@openssh.com
  • aes256-ctr
  • aes256-cbc
  • aes128-ctr
  • aes128-cbc


Anzeige:


Message authentication codes

Hierfür wird das Schlüsselwort MACs verwendet. Grundsätzlich sollte kein MD5 oder SHA1 verwendet werden, da sie inzwischen als weich gelten. Leider können einige SSH-Varianten keine besseren MACs als SHA1, sodass man hierauf leider noch nicht vollständig verzichten kann. Auch sollten mindestens 128 Bit verwendet werden. In den neuesten SSH-Varianten gibt es noch die Encrypt-then-Mac-Varianten, die als noch sicherer gelten. Hier die Liste der möglichen MACs:

  • hmac-sha2-512-etm@openssh.com
  • hmac-sha2-256-etm@openssh.com
  • hmac-sha2-512
  • hmac-sha2-256
  • hmac-sha1

Für ein Ubuntu 12.04 LTS sähe eine entsprechende Konfiguration folgendermaßen aus:

sshd_config

Ciphers       aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
MACs          hmac-sha2-512,hmac-sha1

Außer den Ciphers gibt es noch weitere Einstellungen, auf die Wert gelegt werden sollte. So sollte grundsätzlich Public Key Authentication eingesetzt werden und die Passwort-Authentifizierung abgeschaltet werden:

PubkeyAuthentication yes
PasswordAuthentication no

Welche Algorithmen ein Client verwenden darf, kann zentral in der Datei /etc/ssh/ssh_config eingestellt werden. Es gibt aber noch zusätzlich die Möglichkeit, in der Datei $HOME/.ssh/config Ausnahmen zu konfigurieren, da meist ältere Hosts nicht ganz so sichere Algorithmen benutzen können. So muss man nicht die Algorithmen auf den kleinsten gemeinsamen Nenner bringen, sondern kann die besten Algorithmen als Default einsetzen.

Will man sich auf einem anderen Host einloggen, können die ausgehandelten Algorithmen und Werte mit ssh -vv eingesehen werden:

...
debug1: kex: server->client chacha20-poly1305@openssh.com  none
debug1: kex: client->server chacha20-poly1305@openssh.com  none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 4052/8192
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
...
debug1: Host 'trusty' is known and matches the ECDSA host key.
...
debug2: bits set: 4089/8192
debug1: ssh_ecdsa_verify: signature correct
...

Abschließende Bemerkungen

Wie bei allen asymmetrischen Verfahren ist es auch bei SSH wichtig, dass der Private Key nicht verloren geht und mit einer ausreichend harten Passphrase gesichert ist. Aus den Snowden-Dokumenten geht hervor, dass die NSA stark an den Private Keys interessiert ist und unter Umständen mit allen Mitteln versucht, an diese zu kommen. Gerade wenn keine Perfect Forward Secrecy eingesetzt wird ist das ein Problem, weil damit rückwirkend aufgezeichneter Traffic im Nachhinein entschlüsselt werden kann.

Referenzen:

  1. https://stribika.github.io/2015/01/04/secure-secure-shell.html
  2. http://www.spiegel.de/netzwelt/netzpolitik/snowden-dokument-so-unterminiert-die-nsa-die-sicherheit-des-internets-a-1010588.html
  3. http://www.heise.de/security/artikel/SSH-SSL-IPsec-alles-kaputt-kann-das-weg-2514013.html
  4. http://www.openssh.com/
Sep 182014
 

Der SSL-Server-Test bei den Qualys SSL Labs hat sich als de facto Standard zum Testen der SSL-Verschlüsselung entwickelt. Es werden vier prozentuale Ratings ermittelt und eine abschließende Qualitätsstufe. Die vier Ratings lauten:

  1. Güte des Zertifikats
  2. Protokoll-Support, je neuer desto besser und je weniger alte Protokolle, desto besser.
  3. Art des Schlüsselaustauschs
  4. Güte der Verschlüsselung

In Zusammenarbeit mit meinem Kollegen Dominik Kupschke haben wir erarbeitet, wie man einen Apache 2.4 so konfiguriert, dass man ein „A+“-Rating mit 100%/95%/100%/100% erhält.

A+ Rating


Anzeige:




Durch dieses Rating bedingt können sich Oracle Java Clients und Windows XP-Clients nicht mehr verbinden. Für normales Web Browsing reicht das typischerweise aus. Wenn es nötig ist, dass sich auch diese Clients verbinden, sind kleinere Änderungen nötig, die weiter unten beschrieben werden.

Hinweis!
Ein Apache 2.2 unter Ubuntu kann kein „A+“-Rating erreichen, weil er kein Elliptic Curve Diffe-Hellman unterstützt und einige Windows-Varianten kein Ephemeral Diffie-Hellman unterstützen.

Das Zertifikat

Ein gutes Zertifikat sollte folgende Kriterien erfüllen:

  1. Der Common Name (CN) sollte zum Hostname passen.
  2. Der Zeitbereich sollte passen, also nicht abgelaufen sein.
  3. Es sollte durch eine offizielle CA signiert worden sein.
  4. Der Schlüssel sollte mindestens 2048 Bit breit sein. Spielt Performance keine Rolle, sind 4096 Bit besser.
  5. Das Zertifikat muss mindestens mit SHA256 signiert worden sein. Neuerdings meldet SSL-Labs Intermediate CAs als „weak“, wenn sie selbst mit SHA1 signiert wurden.
  6. Das Zertifikat sollte nicht widerrufen worden sein und die CA sollte OCSP und CRL unterstützen.

Sind Intermediate Zertifikate im Spiel, sollten diese mit dem Apache-Befehl SSLCertificateChainFile ausgewiesen werden. Da der Befehl typischerweise in der Virtual Host-Umgebung benutzt wird, sollten auch nur die benötigten Intermediate CAs hier angegeben werden, was den SSL-Handshake beim Aufbau der Verbindung beschleunigt.

Der Protokoll-Support

Moderne Browser unterstützen mindestens TLSv1, was der Nachfolger von SSL3 ist. Da TLSv1.1 nur wenig Bedeutung findet, reicht die Aktivierung von TLSv1.0 und TLSv1.2 im globalen Server Context des Apache. In der Datei /etc/apache2/conf-enabled/ssl.conf wird daher das Protokoll global konfiguriert.

SSLProtocol  all -SSLv3 -TLSv1.1

Hier kann man nur ein Rating von 95% erreichen. Für 100% müsste man auch TLSv1.0 ausschalten, was aber unter heutigen Bedingungen nicht praktikabel ist, denn es sind noch viele Browser im Feld, die kein TLSv1.2 unterstützen.

Key Exchange und Cipher Strength

Diese beiden Ratings werden im Apache im selben Kommando konfiguriert. Wir bevorzugen Ephemeral Diffie-Hellman vor Elliptic Curve Diffie-Hellman. Beides sind Perfect Forward Secrecy-Verfahren und gelten als besonders sicher. Braucht man Java und Windows XP nicht, muss Apache 2.4 tatsächlich nur vier Ciphers unterstützen. Damit der Client einen Cipher aus der Prioritätenliste des Apache benutzt, ist noch das Kommando SSLHonorCipherOrder On nötig.

Hier bietet es sich an, gleich OCSP-Stapling mit zu konfigurieren. OCSP-Stapling hat den Vorteil, dass der Apache ermittelt, ob das Zertifikat noch gültig ist und diese Information dem Client mitteilt. Dazu muss allerdings die CA OCSP unterstützen. Die CA schreibt in das Zertifikat die URL des OCSP-Responders hinein. Diese kann ganz einfach mit folgendem Kommando ermittelt werden:

openssl x509 -in <CERTIFICATE_PATH> -noout -ocsp_uri

Wird keine OCSP-URL ausgegeben, sollte man OCSP-Stapling sicherheitshalber abschalten (das ist Default im Apache 2.4).

Die gesamte Datei /etc/apache2/conf-enabled/ssl.conf enthält daher nur fünf Kommandos:

SSLProtocol           all -SSLv3 -TLSv1.1
SSLHonorCipherOrder   On
SSLCipherSuite        DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA
SSLUseStapling        On
SSLStaplingCache      "shmcb:${APACHE_RUN_DIR}/stapling_cache(128000)"

Anzeige:


Unterstützung für Oracle Java

Leider unterstützt Oracle Java im Gegensatz zu OpenJDK keine AES-256-Bit-Verschlüsselung. Soll Java auch unterstützt werden, senkt sich leider für die Cipher Strength das Rating auf 90%. Das gesamte „A+“-Rating bleibt jedoch erhalten. Hierfür muss nur das Kommando SSLCipherSuite durch weitere Cipher ergänzt (nicht ersetzt) werden:

  1. Oracle Java 8:
    SSLCipherSuite ...:ECDHE-RSA-AES128-GCM-SHA256
  2. Oracle Java 8 und 7:
    SSLCipherSuite ...:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA
  3. Oracle Java 8, 7 und 6:
    SSLCipherSuite ...:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA:AES128-SHA

Falls die Kontrolle über alle Oracle Java Installationen gegeben ist, kann durch die Installation der Java Cryptography Extension (JCE) die Unterstützung für 256-Bit Verschlüsselungen nachgerüstet werden. Die beiden .jar Files aus diesem Zip müssen einfach in den Ordner $JAVA_HOME/lib/security/ verschoben werden. Diese Maßnahme läuft allerdings client-seitig ab und ändert nichts an den server-seitigen Einstellungen für die Java-Unterstützung.

Hinweis!
Java 6 unterstützt kein Perfect Forward Secrecy!

Unterstützung für Windows XP

Obwohl Microsoft Windows XP abgekündigt hat, setzen gerade viele größere Unternehmen Windows XP mit einer erweiterten Support Lizenz ein. Sollen auch Windows XP-Clients auf die Website zugreifen können, müssen zwei Varianten unterschieden werden:

  1. Windows XP mit Internet Explorer 8
    Für Windows XP muss der Cipher DES-CBC3-SHA ergänzt werden.
  2. Windows XP mit Internet Explorer 6
    Diese Variante sollte nicht mehr in Betracht kommen, wird hier aber der Vollständigkeit halber mit ausfgelistet. Hierfür muss zusätzlich noch SSLv3 aktiviert werden, was auch das Protokoll-Rating von 95% auf 90% herunterzieht.

Hinweis!
Windows XP unterstützt kein Perfect Forward Secrecy!

Hinweis!
Wird Windows XP benötigt, Java allerdings nicht, kann Java sich trotzdem mit dem für Windows XP benötigtem Cipher DES-CBC3-SHA verbinden. Das ist an dieser Stelle kein wirkliches Sicherheitsproblem, allerdings empfiehlt es sich, trotzdem die Cipher für Oracle Java 6-8 mit zu übernehmen.

Strict Transport Security

Mit Strict Transport Security wird durch einen HTTP-Header-Eintrag dem Browser mitgeteilt, dass er für die konfigurierte Dauer diese Website ausschließlich verschlüsselt aufzurufen hat. Eine unverschlüsselte Verbindung ist für den Browser dann nicht mehr möglich. Diese Erweiterung ist schon seit ein paar Jahren in allen gängigen Browsern implementiert. Wir empfehlen eine Verwendung von einem Jahr. Die Konfiguration sollte im Virtual Host Context gesetzt sein. Das Modul mod_headers muss für die Funktion aktiviert sein.

<VirtualHost ...:443>
...
        Header always set Strict-Transport-Security "max-age=31556926"
...
</VirtualHost>

In der Online-Literatur wird fast immer ergänzend der Wert includeSubDomains erwähnt. Werden mehrere Hosts unter derselben Domain verwendet, werden dadurch zu allen anderen Servern verschlüsselte Verbindungen eingefordert. Dies ist aber typischerweise nicht erwünscht und so sollte jeder Virtual Host einzel konfiguriert werden.

Hinweis!
Erst HSTS sorgt bei den SSL-Labs dafür, dass aus einem „A“-Rating ein „A+“-Rating wird.

Server Name Indication

Auf Grund des Mangels an IP-Adressen, wird häufig sog. Name Based Virtual Hosting verwendet. Dabei teilen sich eine IP-Adresse mehrere Hostnames. Das führt zu Problemen bei SSL-Verbindungen, da in der Virual Host-Umgebung das richtige Zertifikat ermittelt werden muss. Da die Verbindung erstmal nur über die IP-Adresse zustande kommt, musste der SSL-Handshake um die Server Name Indication (SNI) ergänzt werden. Hier ist nur zu erwähnen, dass Windows XP und Java 6 die SNI nicht beherrschen.

An dieser Stelle sei auch erwähnt, dass die gemachten Cipher Einstellungen auch im Virtual Host Context funktionieren. Somit können in einer Apache-Instanz mehrere Virtual Hosts konfiguriert werden, in denen unterschiedlichen Anforderungen an das SSL gestellt werden.

Abschließend sei natürlich noch bemerkt, dass die Software aktuell gehalten werden muss! Nur so lassen sich Sicherheitslücken wie POODLE oder BEAST vermeiden!

Referenzen:

Sep 132014
 

Es kommt häufig vor, dass man beim Apache nicht gegen eine htpasswd-Datei authentifizieren möchte, sondern das gegen eine MySQL-Datenbank erledigen möchte. Unter Ubuntu muss zu diesem Zweck das Paket libaprutil1-dbd-mysql installiert werden:

sudo apt-get install libaprutil1-dbd-mysql

Danach müssen die passenden Module aktiviert werden. Der Restart kann erfolgen, wenn die Konfiguration angepasst wurde:

sudo a2enmod authn_dbd

Für die Datenbank sollte ein eigener DB-User eingerichtet werden, der nur Lesezugriff auf die Tabelle mit den Passwörtern hat. In unserem Beispiel heißt die Tabelle User und hat mindestens zwei Spalten names login und password. Die Spalte password sollte das verschlüsselte (Warnung) Passwort enthalten. Für den Apache ergeben sich für die Basic Authentication folgende Bedingungen für den Inhalt der password-Spalte:

  1. Plain Text Passwort (sehr unsicher (!))
    Hier steht das Passwort im Klartext in der Spalte. Davon ist dringend (!) abzuraten!
  2. SHA1 Passwort (SHA1 gilt inzwischen als weich (!))
    Dabei wird das SHA1-gehashte Passwort als Base64 enkodiert und „{SHA}“ vorangestellt. Also z.B.: {SHA}YusNsXhRioN2sjZ2wmOesnMsC+g=
  3. MD5 Passwort (unsicher (!))
    Dabei wird das MD5-gehashte Passwort als Base64 enkodiert und „$apr1“ vorangestellt. Also z.B.: $apr1$KJJD/S8O$rY.oEVoZ.wovVwDnu1qUK1
  4. crypt
    Diese Methode greift unter Linux auf die crypt()-Funktion der libcrypt zu. Hiermit lassen sich MD5, blowfish, SHA1, SHA-256 uns SHA-512 realisieren.

Anzeige:


Welche Methode Apache benutzt hängt also von dem einzelnen Passwort ab, so wie es in der Datenbank steht. Es lassen sich also die Passwort-Formate mischen. Mit der crypt-Variante kann man auf SHA-512 zurückgreifen. Das in der Datenbank hinterlegte Format lautet:

$6$<salt>$<40-byte-hash>

Ich will hier zwei Methoden vorstellen, wie man einen SHA-512 mit crypt-Format für die Datenbank erzeugen kann: erstens mit C und zweitens mit Java.

SHA-512 mit C

Unter Linux lässt sich unter Verwendung der crypt()-Methode, die auch Apache verwendet, ein Text mit SHA-512 hashen. Die Methode nimmt ein Passwort und ein Salt. Dem Salt wird die Hashing-Methode in "$"-Zeichen vorangestellt. Für SHA-256 ist das $5$ und für SHA-512 $6$ vorangestellt. Das folgende Code-Beispiel erzeugt einen gehashten Text aus dem Passwort „test“ und dem Salt „1234„, den der Apache verarbeiten kann:

#define _XOPEN_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
 
int main(int argc, char *argv[])
{
    const char *salt = "$6$1234$";
    const char *pass = "test";
    char *result = crypt(pass, salt);
 
    printf("%s\n", result);
    return EXIT_SUCCESS;
}

Das Programm muss noch kompiliert und ausgeführt werden:

gcc crypt.c -o crypt -lcrypt
./crypt

Als Ausgabe erfolgt:

$6$1234$RtjH4vyYsWBTNKMNb.n8pesSjKQm4e/mTwC8kGIX4G29pNGyRUWvUETb/z1emQuQ8R6h6kou8eriOKZ0j2IAi0

SHA-512 mit Java

Für Java benötigt man die Apache Commons Codec. In ihr ist eine zu Linux kompatible crypt()-Methode in der Klasse org.apache.commons.codec.digest.Crypt enthalten. Der Aufruf ist zu der mit C kompatibel und sieht im Vergleich so aus:

import org.apache.commons.codec.digest.Crypt;
...
    public static String encrypt()
    {
        return Crypt.crypt("test", "$6$1234$");
    }
...

Anzeige:


Konfiguration im Apache

Die Konfiguration besteht aus zwei Teilen

  1. Die Kontaktdaten zur Datenbank
  2. Die Konfiguration der Basic Authentication

Die Kontaktdaten zur Datenbank müssen zwingend außerhalb der Location– bzw. Directory-Tags stehen. Die Konfiguration der Basic Authentication selbst ist einfach. Neben der üblichen Kommandos AuthType, AuthName und Require muss nur der AuthBasicProvider und die DB-Query mittels AuthDBUserPWQuery angegeben werden. Der User wird über das %s in der Query ersetzt. Das Passwort wird mit dem ersten Ergebnis der ersten Spalte verglichen. Apache wandelt das Passwort automatisch in das Format um, wie das Passwort in der Datenbank hinterlegt ist. So können sogar gemischte Werte in der Tabelle hinterlegt werden.

...
<IfModule mod_dbd.c>
        DBDriver mysql
        DBDParams "host=<DB-Host> dbname=<DB-Name> user=<DB-User> pass=<password>"
</IfModule>
...
<Location ...> oder <Directory ...>
        AuthType Basic
        AuthName "Authentifizierter Bereich"
        AuthUserFile /dev/null
                 
        <IfModule mod_authn_dbd.c>
                AuthBasicProvider dbd
                AuthDBDUserPWQuery "SELECT u.password FROM User u WHERE user.login = %s"
                Require valid-user
        </IfModule>
</Location> oder </Directory>
...

Die Werte DB-Host, DB-Name, DB-User und password müssen den eigenen Gegebenheiten angepasst werden. Nachdem die Module aktiviert und der Apache konfiguriert wurde, muss er neu gestartet werden:

sudo service apache2 restart

Authentifizierung über Rollen

Das Modul mod_authn_dbd ermöglicht auch das Login über Rollen. Dazu muss statt einem Require valid-user ein Require dbd-group konfiguriert werden. Zusätzlich muss eine Query zum Ermitteln der Rolle eines Users konfiguriert werden. Dabei handelt es sich um eine Mapping-Tabelle, die vom User auf eine Gruppe zielt:

...
<Location ...> oder <Directory ...>
        ...
        Require dbd-group 
        AuthzDBDQuery "SELECT ur.group FROM UserRole ur WHERE ur.user = %s"
        ...
</Location> oder </Directory>
...

Alternative: mod_auth_mysql

Alternativ kann man auch das Modul mod_auth_mysql benutzen. Leider wird es nur bis Apache 2.2 unterstützt, so dass ich hier nicht näher auf die Konfiguration eingehe.

Referenzen:

Aug 242014
 

MySQL lässt den verschlüsselten Zugriff mit SSL zu. Dazu sollte das passende Zertifikat im Ordner /etc/ssl hinterlegt werden.

Konfiguration

Unter Ubuntu oder Debian empfiehlt es sich, die vom Paketverwalter mitgelieferte Datei /etc/mysql/my.cnf unangetastet zu lassen. Stattdessen können im Verzeichnis /etc/mysql/conf.d beliebig viele Dateien mit Endung .cnf ergänzt werden. Für die verschlüsselte Connection legen wir daher folgende Datei in /etc/mysql/conf.d/001-ssl.cnf an:

[client]
ssl-ca      = /etc/ssl/certs/ca-certificates.crt
 
[mysqld]
ssl
ssl-ca      = /etc/ssl/certs/ca-certificates.crt
ssl-cert    = /etc/ssl/localhost-cert.pem
ssl-key     = /etc/ssl/localhost-key.pem
ssl-cipher  = DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA

Anzeige:


Das Zertifikat für Client und Server darf nicht mit SHA256 signiert werden, ansonsten erscheint folgende Fehlermeldung, wenn man sich mit dem mysql-Client verbinden will:

mysql -p
Enter password:
ERROR 2026 (HY000): SSL connection error: ASN: bad other signature confirmation

Es gibt auch einen vermeintlichen Bug unter Ubuntu 12.04 LTS. Ein dort generierter SSL-Private Key kann nicht von MySQL eingelesen werden. Mit der Anweisung kann der Schlüssel jedoch umgewandelt werden:

openssl rsa -in /etc/ssl/localhost-key.pem  -out /etc/ssl/localhost-key.pem 

Neustart

Die Datei des Private Key darf nur für Root und der Gruppe ssl-cert lesbar sein. Daher muss der MySQL-User mysql auch in die Gruppe ssl-cert eingetragen werden. Nach diesen Eintragungen muss MySQL mit

usermod -G ssl-cert mysql
service mysql restart

neu gestartet werden.


Anzeige:


Testen der verschlüsselten Verbindung

Jetzt kann überprüft werden, ob sich ein Client mit SSL verbindet. Dazu benutzt man einfach das Terminal-Programm mysql und verbindet sich mit beliebigen Benutzerdaten mit einer beliebigen Datenbank. Als nächstes gibt man nur:

status

ein und erhält folgende Ausgabe:

mysql> status
--------------
mysql  Ver 14.14 Distrib 5.5.38, for debian-linux-gnu (x86_64) using readline 6.2

Connection id:          5000
Current database:
Current user:           root@localhost
SSL:                    Cipher in use is DHE-RSA-AES256-SHA
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         5.5.38-0ubuntu0.12.04.1 (Ubuntu)
Protocol version:       10
Connection:             Localhost via UNIX socket
Server characterset:    utf8
Db     characterset:    utf8
Client characterset:    latin1
Conn.  characterset:    latin1
UNIX socket:            /run/mysqld/mysqld.sock
Uptime:                 7 days 5 hours 48 min 30 sec

Threads: 21  Questions: 321745  Slow queries: 0  Opens: 1197  Flush tables: 1  Open tables: 413  Queries per second avg: 0.514

Die Zeile mit „SSL“ deutet auf den verwendeten Verschlüsselungsalgorithmus hin.

Verschlüsselte JDBC-Verbindung

Damit die typischen Application Server auch eine verschlüsselte Verbindung zu MySQL aufbauen, ist nur ein weiterer Connection Parameter notwendig: useSSL=true. Ein kompletter Connection String könnte also so aussehen:

jdbc:mysql://localhost:3306/database?autoReconnect=true&characterEncoding=utf8&useSSL=true

Referenz:

http://dev.mysql.com/doc/refman/5.5/en/ssl-connections.html

Dez 262013
 

Die neuesten Nachrichten aus den USA über das Mitlauschen der NSA des nahezu gesamten Internet-Verkehrs hat gezeigt, dass es heißt mit Daten sehr sensibel umzugehen. Es hat sich aber auch gezeigt, dass die bloße Verschlüsselung z.B. über HTTPS alleine nicht ausreicht, da häufig Verschlüsselungsalgorithmen (z.B. RC4) eingesetzt werden, von denen man vermutet, dass die erzeugten verschlüsselten Daten von der NSA in Echtzeit mitgelesen werden können. Insbesondere Sparkassen und Banken in Deutschland bevorzugen leider immer noch RC4. Hier kann man sich z.B. bei Benutzung des Firefox dagegen schützen, indem man hier RC4 ausschaltet. Die Banken bieten häufig genug andere, bessere Verschlüsselungsalgorithmen an, sodass die Seiten weiterhin uneingeschränkt benutzt werden können. Bei itemis habe ich mit meinem Kollegen Dominik Kupschke sämtliche verschlüsselten Dienste auf sichere Algorithmen gehärtet, sodass sie z.B. gar nicht erst RC4 anbieten. Dieser Artikel soll eine Zusammenfassung dieser Ergebnisse liefern und Aufschluss über gute Verschlüsselungsverfahren bieten. Es soll hier nicht auf deren Funktionsweise eingegangen werden, hierfür gibt es genug Quellen im Internet.

Für eine gute SSL-Verschlüsselung sind vier Punkte wesentlich:

  1. Das Zertifikat
  2. Der Schlüsselaustausch für die synchrone Verschlüsselung
  3. Die synchrone Verschlüsselung
  4. Die Prüfung der Authenzität

Die verwendeten Algorithmen werden in ihrer Kombination Cipher genannt. Diese können bei den meisten Diensten konfiguriert werden.


Anzeige:


Das Zertifikat

Das Zertifikat ist ein Public Key, der von einer Zertifizierungsstelle (CA) signiert wurde, bei einem Verbindungsaufbau gegen diese Zertifizierungsstelle verifiziert werden. kann. Die entscheidende Kenngröße ist die Breite des Schlüssels. Für die typischerweise verwendeten RSA-Schlüssel sollten mindestens 2048 Bits verwendet werden. Für wirklich sensible Daten sollten mindestens 4096 Bits verwendet werden.

Der Schlüsselaustausch

Mit dem asynchronen Verschlüsselungsverfahren wird das Verteilungsproblem des Schlüssels gelöst. Mit dem Public Key kann nur verschlüsselt werden und mit dem Private Key kann entschlüsselt werden. Wie die Namen schon andeuten, darf der Public Key in fremde Hände geraten. Der Private Key verbleibt auf dem Server und muss entsprechend gegen unberechtigten Zugriff geschützt werden. Diese Verschlüsselungsart ist gegenüber der synchronen Verschlüsselungsart sehr langsam. Es gibt Verfahren, die mit asynchroner Verschlüsselung einen zufälligen synchronen Schlüssel aushandeln, der dann für den weiteren Verbindungsverlauf verwendet wird. Hier gibt es zwei herausragende Verfahren:

  1. Diffie-Hellman
  2. Elliptic Curves

Beide Verfahren behandeln sog. Perfect Forward Secrecy. Damit werden auch im Laufe der Verbindung die synchronen Schlüssel ausgetauscht. Das erhöht die Sicherheit, da mit immensen Aufwand nur ein Teil der Verbindung geknackt werden könnte. Bei den Perfect Forward Secrecy Verfahren lassen sich aufgezeichnete Verbindungen nicht mit dem Privaten Schlüssel des Servers entschlüsseln, hier spricht von man Folgenlosigkeit.  Das Verfahren, das die Elliptic Curves benutzt wurde von dem amerikanischen Normungsinstitut spezifiziert. An diesem Verfahren hat die NSA mitgewirkt und daher steht dieses Verfahren im Verdacht, eine Backdoor der NSA zu haben. Das Diffie-Hellman-Verfahren kann mit unterschiedlichen Schlüsselbreiten arbeiten. Natürlich sollte auch hier ein möglichst breiter Schlüssel verwendet werden.

Zusammenfassung:

Auch wenn Elliptic Curves performanter sind, sollte auf dieses Verfahren verzichtet werden! Das empfohlene Schlüsselaustauschverfahren lautet DH Group 15.


Anzeige:


Die synchron verschlüsselte Verbindung

Aus Gründen der Performance wird für den Datentransport synchrone Verschlüsselung verwendet. Hierbei wird zum Ver- und Entschlüsseln derselbe Schlüssel verwendet. Folgende Verfahren werden typischerweise angeboten:

  • RC4
  • DES
  • 3DES
  • AES
  • CAMELLIA

Man geht davon aus, dass RC4 von der NSA in Echtzeit mitgelesen werden kann. Daher sollte dieser Algorithmus dringend vermieden werden! Leider bevorzugen gerade viele Banken und Sparkassen diese Verschlüsselung. Im Firefox kann man die Verwendung dieser Verschlüsselung abschalten. Dazu ruft man die URL about:config auf. Im Suchfeld sucht man nach „rc4“. Die sechs angezeigten Werte werden mittels Doppelklick auf „false“ gesetzt.

RC4

DES benutzt eine Schlüsselbreite von nur 56 Bits und ist somit ebenfalls zu schwach. 3DES ist ein dreifach hintereinander durchgeführter DES. Derzeit gilt dieser Algorithmuss noch als sicher. AES ist der bevorzugte Algorithmus. Er kann mit 128, 192 und 256 Bits Schlüsselbreite verwendet werden. AES ist über einen Wettbewerb ausgeschrieben worden, der unter Anderem die Implementierung in Soft- und Hardware erleichtern soll. AES mit 256 Bits ist daher der bevorzugte Algorithmus. Java kann in der handelsüblichen Form nur AES mit 128 Bits. Diese Verschlüsselung ist dem 3DES vorzuziehen. CAMELLIA ist ein weiterer Algorithmus, der nicht selten auftaucht und ebenfalls als sicher gilt.

Zusammenfassung:

AES256 ist optimal. 3DES ist zwar noch sicher, aber AES128 ist 3DES vorzuziehen.

Die Prüfung der Authenzität

Um beim Schlüsselaustausch sog. Man in the middle-Attacken zu vermeiden, gibt es sog. HMAC-Verfahren. Hier werden Hashing-Algorithmen eingesetzt. Häufig wird SHA eingesetzt. Lässt sich SHA 256 oder SHA2 einsetzen, sollte dieser benutzt werden. Auf MD5 sollte dringend verzichtet werden.

Gesellschaftliche Aspekte

Verschlüsselung und das Abschöpfen des Internet-Verkehrs ist für IT-Laien ein undurchschaubares Thema. Im Zusammenhang mit der NSA-Affäre taucht sehr häufig das Argument auf: „Ich habe nichts zu verbergen!“. Vielleicht veranschaulicht die Tatsache, dass wir nicht nackt rumlaufen, weil wir was zu verbergen haben, diesen Unterschied. Hier muss zwischen Unschuld und Scham unterschieden werden. Man hat sich nichts zu Schulden kommen lassen und es wird durch das Abschöpfen der Internet-Daten mit gutem Gewissen nichts ans Licht kommen. Allerdings ist im Grundgesetz das Recht auf Privatsphäre festgeschrieben. Wir hängen unsere Kontoauszüge auch nicht an den nächsten Baum und hier greift das Argument: „Wenn es den Nachbarn nicht zu interesssieren hat, dann hat es die NSA auch nicht zu interessieren!“.

Die NSA schöpft ohne zu fragen die Daten ganzer Völker ab und stellt damit ganze Völker unter Generalverdacht. Das ist der Anfang eines Überwachungsstaates und untergräbt bestehende rechtsstaatliche Demokratien.

Mehr zu diesem Thema: