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:


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:

O&K-Radlader L25 als Modell

 Eingebettete Systeme, Modellbau  Kommentare deaktiviert für O&K-Radlader L25 als Modell
Feb 232011
 

Vor ein paar Tagen war ich bei meinem Freund Tobias Braeker. Er hat sich als Dipl. Ing. (Maschinenbau) einen Kindheitstraum verwirklicht und einen Radlader im Maßstab 1:12 nachgebaut. Der O&K L25 ist aus Edelstahl gefertigt, wiegt stattliche 12 kg und kann bis zu 9 kg heben. Das Modell ist sehr detailliert gearbeitet. Jedes Rad wird durch einen eigenen Glockenankermotor (Faulhaber) angetrieben, die Schaufel wird hydraulisch betätigt. Ein Soundmodul sorgt für Hörgenuss, denn das Motorengeräusch passt zu den gesteuerten Fahrkommandos. Natürlich ist das Modell auch vorbildlich mit Leuchten (Blinker, Rückfahrscheinwerfer, etc.) ausgestattet. Übrigens kann die Schaufel hydraulisch durch ein anderes Anbaugerät ausgewechselt werden.

Radlader

Die Steuerung ist ein waschechtes Embedded System. Sie beinhaltet den Empfänger, die Motorensteuerung, die Sound- und Lichtsteuerung. Der linke Steuerhebel bedient das Fahrzeug selbst, der rechte Steuerhebel bedient die Schaufel. Die Bedienung braucht natürlich Übung, denn meistens ist man es gewöhnt, mit links die Geschwindigkeit und mit rechts die Lenkung zu bedienen. Es macht aber in jedem Fall viel Spaß, Sand und Steine durch das Gelände zu transportieren.

Tobias verkauft das Modell als Bausatz oder als Fertigmodell. Die Preise können über seine Homepage erfragt werden. Auf YouTube können weitere interessante Filme mit dem L25 betrachtet werden. Für die Zukunft plant er die Konstruktion eines Kippers. Ich bin mal gespannt 🙂

Feb 092011
 

Linux bietet auf x86-Architekturen die Möglichkeit, statt der normalerweise 4K großen Memory Pages auch 2M große Pages zu nutzen. Der Vorteil hierbei ist, dass die MMU der CPU deutlich seltener ein Address Mapping von virtuellem Speicher auf die physikalische Adresse durchführen muss. Dieser Vorgang wird auch Table Walk genannt. Er hat den Nachteil, dass der Zugriff auf diese Mapping-Tabellen am Cache vorbei durchgeführt werden muss und somit sehr langsam ist. Das Ergebnis des Table Walks landet seinerseits in einem speziellem Cache, dem sog. TLB. Es bietet sich unter Linux an, Software mit hohem Speicherverbrauch diese Huge Pages oder Huge Tables nutzen zu lassen. Gerade Server-Prozesse wie JBoss fallen da schnell ins Auge.

Will man unter Java diese sog. Huge Pages verwenden, reicht da die JVM-Option -XX:+UseLargePages. Allerdings ist das nicht die gesamte Arbeit. Dazu muss man den Linux-Kernel anweisen, Huge Tables zur Verfügung zu stellen. Dazu muss man sich erst klar werden, dass Huge Tables dem allgemeinen Memory Pool entzogen wird und nicht mal dem Linux Caching mehr zur Verfügung steht. Es ist also Speicher, der dem Java-Prozess dediziert zur Verfügung steht. Es empfiehlt sich, 512M mehr als Huge Tables bereitzustellen, als man mit -Xmx der virtuellen Maschine zur Verfügung stellt. Hat man 8G RAM, und will man 3,5G dem Java bereit stellen. Müssen wir 4G an Huge Tables bereitstellen. Das geschieht in der Datei /etc/sysctl.d/hugetlb.conf. Dort müssen drei Einträge gemacht werden:

  1. kernel.shmmax=<max-shared-memory-in-bytes>
    Da Huge Tables als Shared Memory allokiert werden, muss die Maximalzahl hier auf die verwendete Speichergröße hochgesetzt werden.
  2. vm.nr_hugepages=<amount>
    Die Zahl der Huge Tables selbst. Will man 4G an Huge Tables haben, muss hier eine 2048 eingetragen werden, weil 2048 * 2M = 4G ist.
  3. vm.hugetlb_shm_group=<gid>
    Hier muss die Usergroup eingetragen werden, die Huge Tables benutzen darf.

Sind die Werte eingetragen, muss man ein sysctl -p -f /etc/sysctl.d/hugetlb.conf ausführen, um die Werte dem Kernel mitzuteilen. Hat der Server schon eine relativ lange Uptime, muss er vielleicht durchgestartet werden. Grund ist, dass die Huge Tables im Stück im Speicher liegen müssen. Da es auch beim Hauptspeicher eine Fragmentierung geben kann, kann evtl. die Zuteilung der Huge Tables nur teilweise gelingen. Kontrollieren kann man das, indem man cat /proc/meminfo ausführt. Das ergibt dann so eine Ausgabe wie:

HugePages_Total:     512
HugePages_Free:      512
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       47040 kB
DirectMap2M:     4147200 kB

Hier sind 512 (= 1G) Huge Tables zugewiesen worden. Als Nächstes muss dem entsprechenden Benutzer, der die Huge Tables benutzen möchte, die Erlaubnis geben, diesen Speicher fest im Speicher zu halten, so dass er nicht im Swap landen kann. Das erfolgt in der Datei /etc/security/limits.conf. Hier wird die Größe des Wertes kernel.shmmax aus der Datei /etc/sysctl.d/hugetlb.conf übernommen. Die Einträge lauten:

<username> soft memlock <locked-memory-in-kbytes>
<username> hard memlock <locked-memory-in-kbytes>

Benutzt man für den Usernamen „*“, gilt diese Einstellung für alle Benutzer, ausgenommen root. Für ihn muss man explizit einen Eintrag machen, wenn gewünscht. Üblicherweise läuft JBoss nicht als root, sondern hat einen dedizierten Benutzer, den man dann auch hier eintragen sollte. Hierbei muss man darauf achten, das PAM so konfiguriert ist, dass die Limits auch als Benutzer entsprechend konfiguriert werden. Hat man als Shell die bash, kann man mit ulimit -a überprüfen, ob der Wert max locked memory korrekt gesetzt wurde. Ein Reboot ist hierfür nicht erforderlich!

jboss@master:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 3145728
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65536
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Sind die Huge Tables verfügbar und die Limits gesetzt, kann man jede JVM mit der Option -XX:+UseLargePages starten und Java benutzt Huge Tables.

Kann Java keine Huge Tables allokieren, kommt es zu folgender Fehlermeldung:

Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory (errno = 22).

In diesem Falle allokiert Java „normalen“ Speicher. Wenn zu viele Huge Tables belegt wurden, kann es dann zu einem Engpass an normalen Speicher kommen. Die Wahl der Option -Xmx ist daher wichtig!

Unter JBoss sollte diese Option in die Datei $JBOSS_HOME/bin/run.conf übernommen werden.

oAW-Tools jetzt Open Source

 Eclipse, MDSD, Software  Kommentare deaktiviert für oAW-Tools jetzt Open Source
Jul 092010
 

Die oAW-Tools sind ab sofort auf SourceForge als Open Source verfügbar. Die oAW-Tools beinhalten eine Reihe kleiner Komponenten und Beautifier. Die Startseite ist unter http://sourceforge.net/apps/trac/oaw/ erreichbar. Der Quellcode kann aus dem Subversion-Repository heruntergeladen werden. Ferner gibt es noch eine Update-Site, die direkt aus dem Eclipse benutzt werden kann.

Viel Spaß!