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:

Mrz 052016
 

YAKINDU statechart tools are a pretty nice tool to model statemachines. You can generate code for C/C++ and Java out of the model. Further you can validate and simulate your statemachine to verify the behaviour. If you want to integrate your statemachine into a Qt application the concept of signals and slots fits perfectly into the in and out events of the statechart definition language of the YAKINDU SCT. My new custom Qt generator links both concepts together. It generates a C++ class which links between the C++ class generated from the C++ generator of YAKINDU SCT and the custom implementation code which must be implemented for custom behaviour of your application.

The generated code implements the following methods of the statemachines base class:

  1. Initialisation of all SCT operation callbacks (so called OCB).
  2. A pure virtual method initializeValues() for custom value initialisation.
  3. In events as Qt slots.
  4. Out events as Qt signals.
  5. Respects internal events with an extra runCycle() call.
  6. Optional implementation of the TimerInterface.
  7. Implementation of all SCT operations.

There is a detailed documentation at the SourceForge project site. There is also a small example Qt application to show how the generator works: https://svn.code.sf.net/p/sctqtgen/code/trunk/de.morknet.sct.qt.example.calculator.


Advertisement:


Download

If you have a working YAKINDU SCT running you only need to add an update site to your Eclipse. You may choose between a snapshot build or the release build.

Have a lot of fun with the new generator and feel free to file bugs or add comments into the forum.

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:

Aug 312014
 

Um einen möglichst hohen Performance Gewinn unter MySQL zu erzielen, sollte die Größe der Buffer Pools mindestens die Größe der Datenmenge umfassen. So funktioniert MySQL wie eine in-Memory-Datenbank. Für die Default Storage Engine InnoDB ist dafür der Parameter innodb_buffer_pool_size verantwortlich. Mit dem Tool mysqltuner kann man noch Hinweise bekommen, wie man noch weitere Parameter anpassen sollte.

Ein Beispiel für eine solche Ausgabe mit mysqltuner sieht folgendermaßen aus:

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1d 0h 17m 42s (3M q [42.492 qps], 150K conn, TX: 12B, RX: 304M)
[--] Reads / Writes: 98% / 2%
[--] Total buffers: 1.5G global + 18.6M per thread (150 max threads)
[OK] Maximum possible memory usage: 4.3G (27% of installed RAM)
[OK] Slow queries: 0% (10K/3M)
[OK] Highest usage of available connections: 55% (83/150)
[OK] Key buffer size / total MyISAM indexes: 16.0M/97.0K
[OK] Key buffer hit rate: 99.1% (1K cached / 17 reads)
[!!] Query cache efficiency: 6.8% (30K cached / 443K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 13K sorts)
[OK] Temporary tables created on disk: 3% (14K on disk / 412K total)
[OK] Thread cache hit rate: 87% (19K created / 150K connections)
[OK] Table cache hit rate: 27% (584 open / 2K opened)
[OK] Open file limit used: 0% (71/41K)
[OK] Table locks acquired immediately: 100% (112K immediate / 112K locks)
[OK] InnoDB data size / buffer pool: 652.3M/1.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
Variables to adjust:
    query_cache_limit (> 256M, or use smaller result sets)

Anzeige:


In diesem Beispiel kann man sehen, dass die Datenmenge ohne Probleme in den Speicher passt. Ein maximaler Speicherverbrauch von 4,3 GB ist für heutige Verhältnisse schon als klein zu betrachten. Ich habe schon in meinem Artikel über die SSL-Connections beschrieben, dass man die Default-Konfiguration nicht ändern sollte und statt dessen im Verzeichnis /etc/mysql/conf.d eine weitere Konfigurationsdatei anlegen sollte. Hier können die angepassten Werte z.B. in die Datei /etc/mysql/conf.d/003-performance.cnf eingetragen werden.

Huge Pages

Einen weiteren Performance-Schub kann man erreichen, in dem der Buffer Pool Huge Pages benutzt. In meinem Artikel Huge Pages unter Linux für die JVM nutzen beschreibe ich, wie man grundlegend Huge Pages unter Linux aufsetzt. Sind die Huge Pages eingerichtet, muss der User mysql in die Gruppe eingetragen werden, die auf die Huge Pages zugreifen darf. In meinem Artikel ist das die Gruppe hugetlb. Das kann mit folgendem Befehl durchgeführt werden:

usermod -G hugetlb mysql

Damit MySQL die Huge Pages auch benutzt, muss in die Section mysqld der Parameter large-pages ergänzt werden. Danach muss MySQL nur noch neu gestartet werden:

service mysql restart

Referenz:

http://dev.mysql.com/doc/refman/5.5/en/large-page-support.html

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

Mrz 192014
 

Seit geraumer Zeit entwickele ich mit meinem Kollegen Dominik Pieper an einem JEE-Generator, mit dem es auf einfache Art und Weise möglich ist, eine CRUD-Webanwendung zu generieren. In einem kleinen Einführungsvideo stelle ich einen kleinen Einstieg in den Generator dar.

Der generierte Code ist eine JEE6-Applikation basierend auf JSF 2.0 und EJB 3.1. Alle Masken können vollständig generiert werden. Zusätzlich kann eigener Code zusätzlich hinzugefügt werden. Somit wird eine maximale Flexibilität gewährleistet. Weitere Features sind:

  • Rollenbaseierte Sicherheit mit JAAS
  • Lokalisierung
  • Vollständige Eclipse-Integration
  • Deployment in JBoss 7 und Glassfish 3
  • u.v.a

Anzeige: