TLS: Eine kleine Übersicht

Der durschnittliche Internetbenutzer benutzt TLS (Transport Layer Security) mittlerweile auf fast allen größeren Websiten – ohne, dass sich dieser darüber bewusst wäre, in den allermeisten Fällen. Auch in meiner Ausbildung bei NETWAYS darf ich mich nun intensiv mit TLS beschäftigen. Doch was ist TLS? Dieser Text soll einen groben Umriss um die zugrunde liegenden Prinzipien und Techniken hinter TLS legen.

Warum brauchen wir TLS?

TLS wird benötigt, um drei Probleme zu lösen. Unsere Kommunikationen sollen verschlüsselt sein – wir wollen nicht, dass Pakete oder Informationen, die wir übertragen, abgehört werden. Außerdem wollen wir sicher gehen, dass der andere Teilnehmer dieser Kommunikation auch derjenige ist, mit dem wir diesen Austausch an Informationen vollziehen wollen. Darüber hinaus wäre es auch gut, sich darauf verlassen zu können, dass das, was von der einen Seite losgeschickt wurde, auch das ist, was der andere erhält. Um diese drei Probleme kümmert sich TLS. Doch wie macht es das?

Eine Beispielverbindung:

1. ClientHello

Ein Client verbindet sich mit einem Server und verlangt eine gesichertete Verbindung. Dazu wird die Version von TLS übertragen, und eine Chiffrensammlung, aus denen sich der Server die Verschlüsselungsmethode aussuchen kann.

2. ServerHello & Certificate & ServerKeyExchange

Der Server antwortet, welches Chiffre verwendet werden soll, und einem Zertifikat, welches den Server authentifizieren soll und einen öffentlichen Schlüssel enthält.

3. ClientKeyExchange

Dieses Zertifikat wird von dem Client verifiziert, und der öffentliche Schlüssel des Servers wird vom Client benutzt, um ein pre-master secret zu erstellen, welcher dann wieder an den Server geschickt wird.

Der Server entschlüsselt das pre-master secret, und beide Parteien nutzen es, um einen geheimen, geteilten Schlüssel zu erstellen, welcher als shared secret bezeichnet wird.

4. ChangeCipherSpec

Der Client versendet die erste, mit dem shared secret verschlüsselte Nachricht, welche der Server entschlüsseln soll, damit geprüft werden kann, ob die Verschlüsselung richtig initialisiert wurde. Wenn diese Verifizierung erfolgreich abgelaufen ist, kommunizieren dann der Client und der Server verschlüsselt untereinander. Dieser ganze Prozess wird als TLS-Handshake bezeichnet.



Geschichte: TLS wurde unter dem Vorläufernamen SSL (Secure Sockets Layer) in 1994 von Netscape für den damals sehr populären Browser Mosaic vorgestellt. Version 2.0 und 3.0 folgten jeweils ein Jahr später. 1999 wurde SSL 3.1 bei der Aufnahme als Standart von der Internet Engineering Task Force in TLS 1.0 umbenannt. 2006 folgte Version 1.1, 2008 1.2 und 2018 die heutige Version 1.3.


Asymmetrische & Symmetrische Verschlüsselung: TLS ist zunächst asymmetrisch, dann symmetrisch verschlüsselt. Was bedeutet das? Nun, hier kommen die Schlüsselpaare ins Spiel. TLS benötigt einen öffentlichen und einen privaten Schlüssel. Der öffentliche Schlüssel wird benutzt, damit der Gegenpart einen Vorschlüssel erstellen kann, welcher dann von dem privaten Schlüssel wieder decodiert wird. Das ist eine asymmetrische Verschlüsselung – welche allerdings deutlich kostenintensiver und aufwändiger ist, und sich dementsprechend nicht für die zahlreichen Anwendungsmöglichkeiten für eine TLS-Verbindung eignet. Dank’ dem Vorschlüssel können allerdings beide Seiten des Austausches einen gemeinsamen, geheimen Schlüssel berechnen, mit Hilfe dessen die verschlüsselten Nachrichten auf jeweils beiden Seiten entschlüsselt werden können. Somit ist der Kern von TLS eine symmetrische Verschlüsselung; der Austausch der tatsächlichen Information passiert über diesen Kanal. Um aber an diesen Punkt zu kommen, sind asymmetrische Verschlüsselungsprinzipien im Einsatz.


Zertifikate: Wie in dem TLS-Handshake betrachtet, sind Zertifkate elementar zur Ausweisung und Identifikation von Server und Client – und wohl der kritischste Punkt in dem ganzen TLS-Ablauf. Damit ein Kommunikationspartner identifiziert werden kann, muss er sein Zertifikat ausweisen, welches seine Identiät beweist. Ausgestellt wird ein Zertifikat von einer certificate authority, einem vertrauenswürdigen Aussteller dieser Zertifikate, was verschiedenste Dinge bedeuten kann: Viele multinationale Konzerne stellen kommerziell Zertifikate aus, darunter fallen Firmen wie IdenTrust, Sectigo und DigiCert Group. Es existieren allerdings auch einige non-profit organisations, wie CAcert und Let’s Encrypt, die als Zertifizierungsstelle auftreten. Darüber hinaus gibt es natürlich auch jede Menge Zertifikatsaussteller innerhalb von Netzen, welche in der Hand von einem vertrauenswürdigen Admin liegen.


Chiffrensammlung: Eine Chiffrensammlung ist eine Auflistung aus den Verschlüsselungsmethoden, die bei einer TLS-Verbindung eingesetzt werden können. Beispiele dafür wären RSA, MD5, SHA. Bei einer TLC-Verbindung wird in ClientHello und ServerHello unter den beiden beteiligten Parteien kommuniziert, welche dieser Methoden zur Verfügung für den Aufbau der Verbindung stehen.


https: Doch was hat es nun mit https auf sich? Ganz einfach: https (HyperText Transfer Protocol Secure) ist eine Extension von http, bei der http über eine verschlüsselte TLS-Verbindung versendet wird, was sie im Gegensatz zu Klartext-http vor unerwünschten Abschnorchelungen und sonstigen Attacken schützt.


Verbreitung: Laut der regelmäßig auf einen neuen Stand gebrachten Auswertung von SSL Labs von rund 140.000 Webpages bieten gerade mal 67.2% eine adequate TLS-Ausstattung. Das mag im ersten Moment etwas niedrig erscheinen, man darf aber auch nicht vergessen, dass diese Lage vor nicht allzu langer Zeit noch deutlich, deutlich schlimmer war, und durch Maßnahmen wie einer automatischen Warnung von Chrome verbessert wurde. So hat sich auch laut Firefox Telemetry die Anzahl der per https aufgerufenen Websiten sich von 25% auf 75% erhöht. Ebenso bemerkenswert: Einem Jahr nach Einführung von TLS 1.3 unterstützen gerade mal 15% den aktuellen Standart, der absolut überwiegende Teil bietet noch hauptsächlich TLS 1.2 an. Man darf gespannt sein, wie lange es dauert, bis der Großteil den Wechsel vollzogen hat. Auf der anderen Seite bieten 7.5% der Webpages noch Unterstüztung für SSL 3.0 an, einem Standart, der mittlerweile fast so alt ist wie ich selbst, und als nicht sicher gilt.

 

 

 

Henrik Triem
Henrik Triem
Junior Developer

Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.

Verschlüsselten File-Container mittels cryptsetup und LUKS erstellen


Datenschutz wird im Jahr 2018 so groß geschrieben wie nie zuvor. Verschiedene Anforderungen an die Absicherung der Daten zwingen Admins, sich elegante und sichere Setups einfallen zu lassen. Ich nehme das zum Anlass, eine neue Serie zur Dateiverschlüsselung zu eröffnen, bei der es um die verschiedensten Möglichkeiten geht, die gespeicherten Daten gegen den Zugriff Unbefugter abzusichern.
Oftmals ist eine Verschlüsselung der Daten aufgrund bestehender Infrastrukturen oder mangels Rechten (z. B. bei extern angemieteten Storages) nicht so einfach möglich. Früher war hier ECryptFS im Linux-Umfeld und TrueCrypt bei Windows State of the Art. Heute haben sich die Anforderungen geändert und ECryptFS ist wegen einer zu restriktiven Beschränkungen der Dateinamen nicht mehr alltagstauglich. Daher stelle ich hier eine moderne Alternative mit cryptsetup in Ergänzung mit LUKS vor.

Vorbereitung

Installation von cryptsetup (Beispiel Debian-Derivate)

sudo apt-get install cryptsetup

Laden des Kernel-Moduls (nur bei initialer Einrichtung)

sudo modprobe dm-crypt

File-Container erstellen

Zunächst wird mittels dd ein File-Container mit 1GB Größe erstellt, der Wert kann natürlich je nach Anforderung angepasst werden

dd if=/dev/zero of=/storage/my_container bs=1M count=1024

File-Container mittels cryptsetup initialisieren

 cryptsetup -y luksFormat /storage/my_container

Nun die gewünschte Passphrase eingeben. Aber Achtung, ohne ein gut gewähltes Passwort nutzt die stärkste Verschlüsselung nichts!
Verschlüsselten Container öffnen und Dateisystem erstellen

cryptsetup luksOpen /storage/my_container my_mount

hier wird das Kennwort abgefragt, dies sollte man sich natürlich zuvor gut merken. Der Container ist nun unter /dev/mapper/my_mount eingebunden.  Anschließend wird ein ext4-Dateisystem in dem Container erzeugt.

mkfs.ext4 -j /dev/mapper/my_mount

File-Container am Wunschort mounten

Ordner zum mounten erstellen

mkdir /my_data
mount /dev/mapper/my_mount /my_data

Fertig – alle Daten die nun in /my_data erzeugt werden, landen am Ende verschlüsselt im Container, wie in meinem Beispiel unter /storage/my_container

Mount aushängen und File-Container schließen

Damit die Daten während der Nichtnutzung auch wirklich sicher sind, empfehle ich, den Container wieder abzuschließen.

umount /my_data
cryptsetup luksClose my_mount

Protip

Ich habe auf diese Art der Verschlüsselung bei meiner Nextcloud zurückgegriffen, da mir die Bordmittel von Nextcloud nicht gefallen, oder zu langsam sind. Im nächsten Artikel werde ich auch erklären, wie man den Container entsprechend vergrößern kann. Alle mit my_ verwendeten Variablen, können natürlich auf die jeweiligen Bedürfnisse angepasst werden.

Haben wollen?

Wir bieten natürlich bei uns im Managed-Hosting individuelle Lösungen an. Falls unsere (potentiellen) Kunden ein solches Setup wünschen, so sind wir natürlich für jeden Spaß zu haben.

Disclaimer

LUKS verwaltet die Verschlüsselungsdaten im Header. Ohne den Header (oder im Falle einer Beschädigung), ist ein Zugriff auf die Daten nicht mehr möglich. Es gibt verschiedene Tools, wie beispielsweise zuluCrypt, mit denen die Schlüssel und Header verwaltet und gesichert werden können, doch dazu in einem späteren Artikel mehr. Die Anleitung wurde nach bestem Wissen und Gewissen erstellt, testet bitte jedoch selbst ausreichend, bevor diese Lösung in die Produktion geht, damit das ihr die Funktionsweise versteht und Datenverlust vermeidet.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

SSL leicht gemacht – forcierte Weiterleitung von HTTP auf HTTPS einrichten

This entry is part 3 of 5 in the series SSL leicht gemacht


In den vorherigen Teilen der Serie wurde bereits die Erstellung und Einbindung der Zertifikate beschrieben. Eines Tages wünscht sich der Admin jedoch die sichere Verbindung aller Seitenbesucher, ohne dass diese manuell ein https voranstellen müssen. Gerade bei einer Migration einer bestehenden Seite wird der
Parallelbetrieb erst nach eingehenden Tests eingestellt und das SSL jeweils forciert, um Seitenbesucher nicht mit ungültigen Zertifikaten oder Mixed Content zu verunsichern.
Die eigentliche Umsetzung ist dann relativ einfach und wird in unserem Beispiel direkt in der Vhost-Definition des Apache vorgenommen. Übrigens, die verfügbaren Vhosts sind zu finden unter: /etc/apache2/sites-available. Hier wird nun der HTTP-Vhost (Port 80) um den unten aufgezeigten Block mit den Rewrites erweitert.

<VirtualHost *:80>
  ServerAdmin webmaster@netways.de
  ServerName www.netways.de
  DocumentRoot /var/www/html/netways.de/
  <Directory /var/www/html/netways.de/>
   Options FollowSymLinks
   AllowOverride All
  </Directory>
  ErrorLog /var/log/apache2/error.log
  LogLevel warn
  CustomLog /var/log/apache2/access.log combined
  RewriteEngine on
  RewriteCond %{SERVER_NAME} =www.netways.de [OR]
  RewriteCond %{SERVER_NAME} =netways.de
  RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
 </VirtualHost>

Damit das Ganze nun auch funktioniert, muss natürlich der SSL-Vhost unter Port 443 erreichbar sein. Wie dieser initial erstellt wird, ist im Artikel SSL-Zertifikat einbinden beschrieben.
Übrigens: wer Let’s Encrypt verwendet, wird im Wizard gleich gefragt, ob SSL forciert werden soll. Der Wizard übernimmt dann die oben gezeigten Schritte. Wie man Let’s Encrypt einsetzt, haben wir natürlich auch schon einmal beschrieben. Damit später keine Seitenbesucher verloren gehen, sollte der HTTP-Vhost, der auf Port 80 läuft, nicht abgeschaltet werden. Die Verbindung ist mit dieser Maßnahme sicher und alle Besucher werden auf https umgeleitet.
Wer damit gar nichts zu tun haben will, und trotzdem stets auf der sicheren Seite sein will, der kann natürlich seine Seite auch bei NETWAYS im Managed Hosting betreuen lassen. Hier kümmern wir uns darum.
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Postfix – TLS / SSL Verschlüsselung aktivieren

In aller Munde ist es stets, dass man verschlüsselte Verbindungen nutzen soll. Auch beim Versand von E-Mails sollte man auf Verschlüsselung setzen, damit die Kommunikation entsprechend sicher abgewickelt wird. Auch Postfix bietet diese Möglichkeit.

Verschlüsselung der Verbindung zwischen Client und Server

Bei Ubuntu werden standardmäßig einige selbstsignierte Zertifikate mitgeliefert, welche per Default auch schon im Postfix hinterlegt sind.

smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

Benutzt man diese, kommen bei allen gängigen E-Mail Clients jedoch Hinweise, dass die Verbindung eventuell nicht sicher sei. Beseitzt man kein gültiges Zertifikat, kann man hier auch ein Zertifikat von LetsEncrypt verwenden. Mehr dazu kann man auch im Artikel “kostenfreie TLS-Zertifikate mit Let’s Encrypt” lesen. Wie man ein konstenpflichtiges Zertifkat erwerben kann, wird zudem im Artikel “SSL leicht gemacht – CSR und Keyfile erstellen und Zertifikat ordern” beschrieben. Alternativ kann hierzu auch unser Support kontaktiert werden.
Anschließend ist die Option smtpd_tls_security_level zu befüllen – per Default ist diese nicht gesetzt.

smtpd_tls_security_level = may

Durch “may” wird besagt, dass TLS Verschlüsselte Clients unterstützt werden, es aber nicht zwingend notwendig ist. Wer TLS Verschlüsselte Kommunikation forcieren möchte, kann hier entsprechend “enforce” setzen, damit es erzwungen wird und Clients immer verschlüsselt mit dem Server Kommunizieren. Damit wäre es grundlegend getan, man sollte jedoch noch darauf achten gewisse SSL Versionen, sowie Cipher zu verbieten, da diese schon etwas älter sind und daher nicht mehr als sicher gelten. Anbei eine Beispielkonfiguration, diese muss je nach Endgerät ggf. auch angepasst werden.

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = ECDHE-RSA-RC4-SHA
smtpd_tls_mandatory_exclude_ciphers = ECDHE-RSA-RC4-SHA

Möchte man zudem die TLS Informationen auch im Header sehen, kann man noch folgende Option setzen:

smtpd_tls_received_header = yes

Verschlüsselung der Verbindung zwischen Servern

Damit wäre die Client <-> Server Kommunikation soweit verschlüsselt und viele denken sich sicher, das wäre es. Zwischen Mailservern findet aber natürlich ebenfalls Kommunikation statt, welche verschlüsselt werden soll. Dies wird entsprechend wie folgt aktiviert:

smtp_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtp_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtp_tls_security_level=may

Ähnlich wie bei der Client-Server-Kommunikation wird auch hier durch “may” besagt, dass Verschlüsselung genutzt wird insofern es möglich ist. Im Header kann man dies nun auch nachvollziehen, indem man nach ähnlichen Daten sucht:
Ohne Verschlüsselung (smtp_tls_security_level=none):
Received: from mail.domain1.tld (mail.domain1.tld [1.2.3.4]) by mail.domain2.tld (Postfix) with ESMTP id 1234567890
Mit Verschlüsselung (smtp_tls_security_level=may):
Received: from mail.domain1.tld (mail.domain1.tld [1.2.3.4]) by mail.domain2.tld (Postfix) with ESMTPS id 1234567890

Verschlüsselung der IMAP Verbindung

Damit wären wir fertig mit Postfix. Anbei noch einige Informationen für jene, die Dovecot nutzen um E-Mails von Ihrem Server per IMAP abzurufen, denn diese Verbindungen wollen ja auch noch verschlüsselt werden. Dies funktioniert sehr simpel – die Konfigurationen dafür finden wir normalerweise unterhalb von “/etc/dovecot/conf.d/“, meist handelt es sich dabei um die Datei “10-ssl.conf“.
Dort editieren, bzw. erweitern wir unsere entsprechenden Konfigurationen um folgende Zeilen:

ssl = yes
ssl_cert = </etc/ssl/certs/ssl-cert-snakeoil.pem
ssl_key = </etc/ssl/private/ssl-cert-snakeoil.key

Zudem nehmen wir noch einige Feinjustierungen vor, wie bereits zuvor bei Postfix. Beachten sollten wir aber, dass sich die Cipher-Liste je nach Endgerät auch ändern kann und man diese etwas anpassen muss. Diese dient hier nur als Beispiel.

ssl_protocols = !SSLv3 !SSLv2
ssl_cipher_list = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4
ssl_dh_parameters_length = 2048

Auch hier gilt: Hat man bereits ein gültiges Zertifikat, kann man dieses hier gerne verwenden um Fehler im E-Mail Client zu verhindern. Nun ist noch in der “10-auth.conf” die folgende Einstellung wichtig:

disable_plaintext_auth = no

Damit wird ein ähnlicher Effekt erzielt, wie bereits bei Postfix wenn wir “may” als Option gesetzt haben. Wir können nun TLS nutzen, müssen es aber nicht zwingend. Wer hier auf absolute Nummer sicher gehen möchte, kann natürlich auch hier “yes” setzen.
Mit “dovecot -n” können wir die aktiven Einstellungen überprüfen.

Fabian Rothlauf
Fabian Rothlauf
Senior Systems Engineer

Fabian kehrte nach seinem fünfjährigen Ausflug nach Weimar zurück in seine Geburtsstadt Nürnberg und hat im September 2016 bei NETWAYS als Systems Engineer im Hosting Support angefangen. Der Mopsliebhaber, der schon seit seinem 16. Lebensjahr ein Faible für Adminaufgaben hat, liebt außerdem Grillen, Metal und Computerspiele. An seinem Beruf reizt ihn vor allem die Abwechslung, gute Weiterentwicklungsmöglichketen und dass es selten mal einen Stillstand gibt. Nachdem er die Berufsschulzeit bereits mit Eric und Georg genießen...

SSL leicht gemacht – Zertifikat einbinden (Apache2)

This entry is part 1 of 5 in the series SSL leicht gemacht

In meinem letzten Blogpost habe ich über die Erstellung eines Keyfiles und eines CSR geschrieben. Im zweiten Teil meiner Serie SSL leicht gemacht zeige ich den nächsten Schritt und beschreibe die Einrichtung des Zertifikates mittels der Webserversoftware Apache.
Bestandsaufnahme:
nun sollten folgende Dateien vorhanden sein

  • selbst erstellt
    • CSR (in unserem Beispiel netways.de.csr)
    • Privatekey (netways.de.key)
  • von Zertifizierungsstelle erstellt und übermittelt
    • cert.cabundle
    • certificate.crt

Diese Zertifikatsdateien können jetzt auf dem Webserver eingerichtet werden.
Als nächstes werden die Zertifikatsdateien im korrekten Verzeichnis abgelegt. Hierzu eignet sich zum Beispiel /etc/apache2/ssl/netways.de/. Hier sollte die Zusammengehörigkeit der einzelnen Dateien noch einmal überprüft werden. Der CSR wird übrigens nicht mehr benötigt und kann gelöscht werden.
Apache kann im Moment noch nichts mit den Zertifikatsdateien anfangen und noch lernen “SSL zu sprechen”. Dazu wird ein SSL-VHost eingerichtet. Als Basis hierfür kann der abzusichernde VHost vorerst kopiert werden.

cp /etc/apache2/sites-available/001-netways.de.conf /etc/apache2/sites-available/001-netways.de-ssl.conf

Diese neue SSL-Config wird nun angepasst, damit der Apache nun weiß, was er zu tun hat.
Innerhalb der nun betreffenden VHost-Definition werden nun noch ein paar Paramater für SSL angegeben

SSLEngine on
 SSLCertificateKeyFile /etc/apache2/ssl/netways.de/netways.de.key
 SSLCertificateFile /etc/apache2/ssl/netways.de/certificate.crt
 SSLCertificateChainFile /etc/apache2/ssl/netways.de/cert.cabundle

Übrigens in der Einleitung der VHost-Definition (i. d. R. ganz oben in der neuen Datei) sollte der angegebene Port 80 auf 443 geändert werden.

<VirtualHost 123.456.789.012:80> auf <VirtualHost 123.456.789.012:443>

Abschließend wird der Apache noch um ein paar Funktionalitäten erweitert (SSL und der neue VHost wird aktiviert):

a2enmod ssl
a2ensite 001-netways.de-ssl.conf
service apache2 restart

Der VHost ist nun zusätzlich mit SSL abgesichert und in unserem Beispiel via https://netways.de und http://netways.de erreichbar. Ob alles geklappt hat, sieht man nun am erfolgreichen Verbindungsaufbau via HTTPS oder kann es zum Beispiel bei SSL Labs ausführlich prüfen lassen.
Die Namensgebung der Zertifikate unterscheidet sich von Zertifizierungsstelle zu Zertifizierungsstelle und kann auch mal mit .pem bezeichnet sein usw. Dies kann “ignoriert” werden und beliebig selbst in der Config auf die neuen Endungen angepasst werden. Auch eine Umbenennung der Dateien auf das eigene Schema ist ein möglicher Lösungsansatz.
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

SSL leicht gemacht – CSR und Keyfile erstellen und Zertifikat ordern

This entry is part 2 of 5 in the series SSL leicht gemacht

Oftmals kommt trotz der breiten Verfügbarkeit von Letsencrypt der Wunsch nach kostenpflichtigen Zertifikaten auf. Die Gründe sind vielfältig: längere Gültigkeit, Wildcard-, Multidomain- oder Extended-Validation (Grüne-Leiste) Zertifikate – all das bietet Letsencrypt leider nicht und deshalb ist der Bedarf nach solchen Zertifikaten noch immer vorhanden. In den nächsten Wochen werden wir immer wieder Blogposts zum Thema SSL erstellen, alle zu finden in unserer Serie “SSL leicht gemacht”
Zu aller Anfang wird ein CSR (Certificate Signing Request) und ein Keyfile (privater Schlüssel) benötigt. Aus Sicherheitsgründen empfehlen wir prinzipiell die Erstellung gleich auf dem Zielsystem des Zertifikates vorzunehmen, so müssen die Daten nicht umgezogen werden und bleiben nicht “zufällig” irgendwo liegen.
Los geht’s mit dem Kommando

openssl req -new -nodes -keyout netways.de.key -out netways.de.csr -newkey rsa:4096

Dadurch wird im aktuellen Verzeichnis ein Privatekey mit einer Schlüssellänge von 4096 Bit (default 2048) angelegt. Der folgende Wizard sammelt nun noch die Daten für das CSR ein.
Hier wird nach dem Land, dem Staat, der Stadt, der Firma, der Abteilung, der zu sichernden Domain und der Kontaktmailadresse gefragt. Eingaben können auch leergelassen werden und mit der Eingabetaste übersprungen werden (ACHTUNG: Defaultwerte (sofern vorhanden) aus den eckigen Klammern werden übernommen).
Zur Kontrolle kann das CSR noch mit dem Kommando

openssl req -in netways.de.csr -noout -text

überprüft werden. Übrigens gibt es bei Umlauten (wie so oft) Probleme. Wir vermeiden diese gern durch die Verwendung englischer Städtenamen wie im aktuellen Beispiel zu sehen.
Abschließend kontrollieren wir das Keyfile noch (zumindest, ob es so in der Art aussieht).

Fertig, nun geht man zur Bestellung des Zertifikates über. Hierzu kann man auf jeden beliebigen Zertifikatshändler zurückgreifen. Wegen anhaltender “Unstimmigkeiten” bei Google und Symantec empfehle ich persönlich (bei der Neubestellung) auf Produkte von Comodo zurückzugreifen. Die Comodo-Zertifikate sind preislich im Mittelfeld und die Akzeptanz der Zertifikate ist hoch. Für die Bestellung wird nur der CSR benötigt. Das Keyfile sollte keinesfalls an irgendjemanden weitergegeben werden und auf dem Server verbleiben.
Bei der Bestellung werden nochmal alle möglichen Daten, gewünschte Laufzeit usw. abgefragt. Unter anderem auch die Mailadresse. Die Auswahlmöglichkeiten dieser ist oftmals beschränkt. Die ausgewählte Mailadresse muss zwingend verfügbar sein, um die Validierung via Mail abzuschließen und ein Zertifikat zu erhalten. Sofern alles geklappt hat, bekommt man später in der Regel per Mail das Zertifikat und ggf. das CA-Bundle zugeschickt.
Wie das alles nun zusammen eingerichtet wird, schreibe ich im Artikel Zertifikat einbinden (Apache2).
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

kostenfreie TLS-Zertifikate mit Let's Encrypt

Let’s Encrypt hat seit gut einem Jahr die Testphase verlassen und verteilt fleißig Zertifikate – kostenfrei versteht sich. Wo anfangs in der Testphase “nur” wenige Millionen Zertifikate ausgegeben wurden, ist diese Zahl inzwischen kräftig gewachsen – Tendenz steigend. WordPress und andere Dienste setzen Let’s Encrypt in breitem Maße ein um das Internet ein bisschen besser (sicherer) zu machen.
Neben der reinen Absicherung der Verbindung hilft ein Zertifikat noch beim Ranking und dem lästigen Wegklicken von Sicherheitswarnungen bei selbstsignierten Zertifikaten, beispielsweise bei Testumgebungen. Chrome bemängelt seit der Version 39 auch die Sicherheit von normalen HTTP-Verbindungen und kennzeichnet diese als “nicht sicher”.
Die Zertifikate von Let’s Encrypt sind nicht besser oder schlechter als andere Zertifikate – nur kosten sie nichts und sind nicht so lange gültig – durch Automatismen zur Erneuerung eher ein Vorteil als ein Nachteil. Bei Let’s Encrypt gibt es keine Wildcard- oder EV-Zertifikate, wenn der Wunsch nach diesen besteht, greift man lieber zu kommerziellen Produkten. Auch wenn die Validierung mehr Sicherheiten bringen soll, als eine Domain-Validierung (hier wird ein Hash in einem vhost hinterlegt und von Let’s Encrypt geprüft), wird einem ein kommerzielles Produkt nahe gelegt.
Also eignen sich die Zertifikate für folgende Anwendungsfälle: Basisabsicherung von Diensten, wo sonst keine Verschlüsselung unbedingt notwendig wäre (z. B. WordPress-Blog), Absicherung von Staging-Systemen, Absicherung als kostenfreie Zugabe des Hosters, Absicherung von internen Diensten und zur Absicherung von privaten Websiten.
Aber wie kommt man nun zu den Zertifikaten?
Hier gibt es verschiedene Wege, allerdings gehe ich nur kurz auf die Command-Line basierte Beantragung ein. Dafür wird von Let’s Encrypt selbst der Certbot empfohlen, der bringt alles mit.
Nach dem Download / der Installation des Certbots (hier kommt es auf die Distribution an) kann dieser mittels dem einfachen Aufrufs

./certbot-auto

starten. Jetzt werden die weiteren Abhängigkeiten noch aus dem jeweiligen Paketmanager nachinstalliert. Ein Wizard startet und fragt welche Domains abgesichert werden sollen und ob ein automatischer (sicherer) redirect von HTTP auf HTTPS erfolgen soll (Hierzu werden Rewrite-Rules in der VHost-Config angelegt). Der Rest geht von alleine, eine CSR wird erstellt, ein vhost für die Domain-Validierung wird angelegt, es wird von extern gecheckt, ob der String im vhost erreichbar ist, Zertifikat wird ausgeteilt und gleich eingerichtet.
Achtung, nachdem der Wizard angestoßen wurde, wird mehrfach der Webserver neugestartet und Configfiles verändert. Für eine alternative Beantragung mit mehr Eigenverantwortung bitte die Hinweise zu certonly und webroot lesen.
Zertifikat nur 90 Tage gültig – was tun?
Die TLS-Zertifikate von Let’s Encrypt sind nur 90 Tage gültig. Die Beweggründe hierfür sind unterschiedlich. Aber aus meiner Sicht ist dies ein wesentlicher Sicherheitsvorteil. Damit es zu keinen Zertifikatsfehlern kommt, heißt es hier im richtigen Moment die Erneuerung der Zertifikate anzustoßen. Denn ein neues Zertifikat bekommt man erst kurz vor Ablauf des alten Zertifikates. An dieser Stelle komme ich an die vormals angesprochenen Automatismen zurück. So reicht es eigentlich täglich 1-2x einen Cron laufen zu lassen:

./certbot-auto renew

Durch dieses Kommando schaut der Certbot beim jeweiligen Lauf des Crons, ob das Zertifikat in Kürze abläuft. Wenn ja, wird ein neues Zertifikat beantragt und hinterlegt, wenn nicht meldet sich der Certbot nur mit einer kurzen Meldung im Log:

INFO:certbot.renewal:Cert not yet due for renewal

Auch hier sicherheitshalber nochmal der Hinweis, dass alle Abhängigkeiten beim renew aktualisiert werden (zu vermeiden mit dem –no-self-upgrade Flag). Desweiteren wird auch wieder ein vhost angelegt und der Webserver-Dienst durchgestartet.
Auch unsere Kunden mit komplexen Setups hinter Loadbalancern und HA-Clustern können von Let’s Encrypt profitieren – wir bauen hierzu die passende Lösung.
Freuen wir uns auf die nächsten Jahre, der wichtigste Schritt wurde bereits gemacht. Wer bei uns Kunde ist, kann schon heute von diesem tollen Service profitieren.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

TrueCrypt Disaster Recovery

Ich stand vor Kurzem privat vor der Aufgabe die Daten einer mit TrueCrypt verschlüsselten Festplatte, die versehentlich mittels fdisk partitioniert und anschließend formatiert wurde, wiederherzustellen. Unmöglich? Dachte ich auch zuerst…
Bevor ich irgendwelche Wiederherstellungsvesuche unternommen habe, wurde das komplette Abbild der Festplatte aber erstmal mittels dd gesichert. Unter Linux geht das ganz einfach, z.B. so:

# dd if=/QUELL/PLATTE of=/SPEICHER/ZIEL

Mein erster Ansatz war ein mir altbekanntes Tool: TestDisk. Allerdings stösst das bei per TrueCrypt verschlüsselten Platten schnell an seine Grenzen. Nach einer kurzen Recherche fand ich dann schließlich TestCrypt. TestCrypt ist speziell für die Wiederherstellung von TrueCrypt-Verschlüsselungen entwickelt worden, funkioniert aber erst ab TrueCrypt Version 5.1a. Voraussetzung ist natürlich das man noch im Besitz des TrueCrypt Passwortes oder des Keyfiles ist.
testcryptDie größte Schwierigkeit bei TestCrypt war bei mir das es nur unter Windows funktioniert, also musste ich kurzerhand eine alte Windows XP Installation aktivieren um die Software installieren zu können. Sobald die Software gestartet und das entsprechende Volume ausgewählt wurde, sucht TestCrypt nach dem Backup Volume Header. Sobald dieser gefunden wurde lässt sich das Volume als zusätzlicher Datenträger einhängen und erhält so Zugriff auf die schon verloren geglaubten Daten.
Nach Sicherung der Daten auf eine andere Platte, habe ich die Gelegenheit genutzt und den Datenträger gleich neu mit VeraCrypt verschlüsselt. VeraCrypt ist sozusagen der Nachfolger von TrueCrypt, da dieses seit Mitte 2014 nicht mehr weiterentwickelt und somit als potenziell unsicher eingestuft wird.
Um solchen “Horror”-Szenarien vorbeugen bzw. besser begegnen zu können empfiehlt es sich beispielweise im Vorfeld den entsprechenden Volume Header zu sichern oder aber gleich eine bewährte Backup- bzw. Recoverylösung wie Bareos zu verwenden. Nicht zuletzt möchte ich mich bei den Entwicklern von TestCrypt bedanken, mir haben sie in diesem Fall sehr viel Ärger erspart!

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Warum SSL nicht funktioniert

Zugegeben, der Titel ist sehr provokativ formuliert. Es soll hier auch gar nicht darum gehen, irgendwelche Sicherheitslücken direkt im SSL-Protokoll (bzw. TLS) oder einer der vielzähligen Implementierungen aufzuzeigen. Vielmehr möchte ich zeigen, dass Verschlüsselung, wie sie heutzutage an vielen Stellen eingesetzt wird, oft nicht mehr tut, als den Benutzer in Sicherheit zu wiegen.
Viele Webseiten unterstützen inzwischen Verschlüsselung – nicht zuletzt, da beispielsweise Google dies seit einigen Monaten in die Bewertung des Rankings einfließen lässt.
Seine Ziele erreicht SSL hier allerdings leider nur bedingt. Es wird zwar sichergestellt, dass die Webseite wie auch Benutzereingaben auf dem Transportweg z.B. durch transparente Proxies nicht verändert werden.
Trotz Verschlüsselung lassen sich von einem Angreifer, der die Netzwerkverbindung passiv abhören kann, dennoch viele Informationen ableiten:
1. Üblicherweise unterstützen Webseiten Redirects, die von HTTP auf HTTPS umleiten. Dabei wird allerdings die erste HTTP-Anfrage ohne Verschlüsselung abgesendet, aus der sich beispielsweise die vollständige URL erfahren lässt.
Zwar gibt es für dieses Problem die HTTP-Erweiterung HSTS, aber zum einen wird sie nur von den wenigstens Webseiten unterstützt und zum anderen greift sie nicht beim ersten Request.
2. Webseiten integrieren prinzipbedingt oftmals Bilder oder JavaScript-Dateien von anderen Webseiten. Selbst wenn diese auch über HTTPS-URLs eingebettet wurden, lässt sich zumindest feststellen, welchen Organisationen diese externen Webseiten gehören.
Beim Aufrufen eines WordPress-Blogs wäre es so beispielsweise nicht verwunderlich, IP-Adressen von Facebook, Google, Twitter und WordPress zu sehen, was z.B. darauf hindeuten würde, dass der Blog über Plugins für Social Buttons verfügt.
3. Anhand der in Punkt 2 ermittelten Daten lässt sich bereits ein recht guter Fingerabdruck erstellen. Noch eindeutiger wird dieser, wenn man die Download-Größe der Webseiten-Requests beobachtet. Viele Webseiten inkludieren beispielsweise eine unterschiedliche Anzahl an Bildern, die dazu beitragen, dass sich die Download-Größe von Seite zu Seite signifikant unterscheidet. Der technische Begriff dafür ist Traffic Analysis.
Um mit diesen Informationen Rückschlüsse auf die aufgerufene URL zu ziehen, müsste der Angreifer über einen Index aller aufrufbaren Seiten verfügen, um deren Download-Größe mit der tatsächlich aufgerufenen Seite zu vergleichen. Bei öffentlich zugänglichen Seiten ließe sich dieser Index mit Hilfe eines Web-Crawlers mit moderatem Aufwand erstellen.
Die beschriebenen Probleme gibt es natürlich nicht nur bei Webseiten. Wenn ich beispielsweise einen Blick in mein E-Mail-Postfach werfe, finde ich gerade einmal eine Handvoll signierter E-Mails und eine einzige verschlüsselte E-Mail. Alle anderen E-Mails liegen unverschlüsselt auf dem E-Mailserver meines Providers (Google).
Fragen Sie einfach einmal einen Ihrer Bekannten, ob deren E-Mails verschlüsselt sind: Dank großflächiger Werbemaßnahmen wie “E-Mail made in Germany” und De-Mail wird Ihnen dieser die Frage sicher bejahen. Dumm nur, dass dabei nur die Verbindung zum E-Mailserver der Provider verschlüsselt ist, dieser aber dann die Mails im Klartext einsehen kann.

GnuPG / GPG Best Practices

Dieser Artikel richtet sich an User, die bereits etwas Erfahrung mit GnuPG / GPG / OpenPGP haben. GnuPG liefert bereits sehr brauchbare Standardeinstellungen mit und es kann ohne Probleme ohne grossen Zusatzaufwand verwendet werden. Wer aber etwas tiefer eintauchen, höhere Sicherheit und mehr Komfort möchte, findet im Folgenden einige Vorschläge.
Die Konfiguration
Normalerweise konfiguriert man GnuPG durch ein Konfigfile, meist ~/.gnupg/gpg.conf. Einige graphische Frontends sollten einige dieser Optionen auch anbieten und sie gegebenenfalls in eine Konfigurationsdatei schreiben.
Bei mir sieht das so aus:

default-key 91B8ECDC6265BAE6
default-recipient-self
keyserver hkp://keys.gnupg.net
keyserver-options auto-key-retrieve
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
personal-cipher-preferences AES256 AES192 AES
personal-compress-preferences SHA512 SHA384 SHA256 SHA224
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
use-agent
verify-options show-uid-validity

Nicht alle Optionen sind für die Verwendung des Schlüssels für sichere E-Mail wichtig, sondern werden mehr beim Verschlüsseln und Signieren von Dateien auf der Kommandozeile verwendet. Die Optionen können auch beim Aufruf von gpg auf der Kommandozeile angegeben werde. Eine Liste findet sich auf der GnuPG Homepage.
Der default-key gibt einfach an, welcher Schlüssel als eigener Schlüssel für Signaturen oder Verschlüsselung an sich selbst verwendet wird. Dabei wird eine längere Fassung der ID verwendet, da es bei der 8 stelligen Kurzfassung, die man oft sieht, zu leicht zu Kollisionen kommen kann. Wer meinen Schlüssel betrachtet, wird sehen, dass ich auch noch nicht alle dieser Ratschläge mit diesem Key umgesetzt habe. Ein neuer Schlüssel ist generiert, hat aber noch zu wenig Signaturen, um ihn sinnvoll zu verwenden. Es ist also nur mehr eine Frage der Zeit, bis ich mich an meine eigenen Empfehlungen halte. 🙂
Die Option default-recipient-self gibt an, dass man beim Verschlüsseln auf der Kommandozeile keinen Empfänger angeben muss, sondern immer mit dem eigenen Key verschlüsselt wird, wenn keine ID angegeben wird.
Mit keyserver wird der Standardkeyserver angegeben, der genutzt wird, wenn kein anderer Schlüsselserver auf der Kommandozeile genannt wird. Dabei wird immer wieder davor gewarnt, pgp.mit.edu als Keyserver zu verwenden, da dieser berüchtigt dafür ist, Daten nicht sauber mit anderen Servern zu synchronisieren. Welcher andere Keyserver genannt wird, ist meist nebensächlich, da sich eigentlich alle Keyserver miteinander abgleichen sollen.
Durch keyserver-options auto-key-retrieve werden Schlüssel, die im Keyring fehlen, aber zum Verifizieren von Signaturen benötigt werden, automatisch geholt.
Die personal-digest-preferences, personal-cipher-preferences und personal-compress-preferences Listen geben an, welche dieser Algorithmen man bevorzugt, in absteigender Reihenfolge. Beim Versand einer Nachricht wird damit jeweils von links an nach dem ersten Algorithmus gesucht, den alle Empfänger unterstützen. So ist sichergestellt, dass möglichst starke Standards verwendet werden, aber auch an ältere oder suboptimal konfigurierte Clients versandt werden kann. Gibt man z.B. keinen Digest (Hashing) Algorithmus aus der SHA-2 Familie an, nutzt GnuPG Standardmässig SHA-1 für Hashing, was nicht mehr empfohlen werden kann. Es sollte unbedingt ein Algorithmus aus der SHA-2 Familie vor SHA-1 und MD5 in der Liste stehen. Welche Algorithmen in der eigenen Installation zur Verfügung stehen, sieht man übrigens bei einem Aufruf von gpg --version. Bei diesen Optionen eine Liste anzugeben, verhindert den Versand nicht, da immer ein Algorithmus gewählt wird, den alle Empfänger verstehen. Das bedeutet aber auch, dass unter Umständen dennoch unsichere Algorithmen verwendet werden.
Die Option cert-digest-algo ist etwas tückisch. Sie gibt an, welcher Hash Algorithmus beim Signieren von fremden Schlüsseln verwendet wird. Wird der nicht von anderen Usern unterstützt, können Signaturen nicht überprüft werden. Gilt das auch für die Selbstsignatur eines Schlüssels, kann er gar nicht vom Kommunikationspartner verwendet werden. Standard ist eigentlich MD5 für PGP2 Schlüssel und SHA-1 für alle anderen Schlüssel. Da diese aber nicht mehr verwendet werden sollten, steht man vor der Wahl: Unsicherer Algorithmus oder unter Umständen Inkompatibilität zu anderen Usern. Ich habe mich bei neuen Schlüsseln für die mögliche Inkompatibilität entschieden. Vielleicht kann ich damit ja auch den einen oder anderen User zum Upgrade auf eine sichere Version bewegen. Da Signaturen normalerweise nur einmal erstellt werden, sollte man diese Option unbedingt setzen, bevor man einen neuen Schlüssel erstellt. Aus den genannten Gründen führen auch manche Seiten diese Option als “esoteric option” auf. 🙂
Mit default-preference-list gibt man an, welche Algorithmen man selbst unterstützen möchte. Diese Liste wird beim Erstellen eines neuen Schlüssels verwendet, sie sollte also unbedingt gesetzt werden, bevor man einen Schlüssel erstellt. Diese Liste wird auch im Schlüssel verankert und daraus und aus den oben genannten personal-...-preferences wird dann die beste bevorzugte Version ausgesucht, die von allen Beteiligten unterstützt wird. Diese Einstellung kann auch nachträglich am Schlüssel geändert werden. Allerdings muss dann der Absender wieder den aktuellen Schlüssel haben, um die aktuelle Liste zu verwenden. Also auch gleich lieber vor Erstellung eines neuen Schlüssels richtig setzen.
use-agent gibt lediglich an, dass der GnuPG Agent verwendet wird, sofern verfügbar. Damit wird eine eingegebene Passphrase für einige Zeit gespeichert und man muss sie nicht gleich erneut eingeben.
Zu guter letzt sorgt verify-options show-uid-validity dafür, dass beim Anzeigen von UIDs auch gleich deren Gültigkeit angezeigt wird.
Beim Erstellen neuer Schlüssel zu beachten
Wie erwähnt, macht es Sinn, die Optionen in der Konfigurationsdatei zu setzen, bevor man einen Schlüssel erstellt.
Mit gpg --gen-key wird die Erstellung eines neuen Schlüssels gestartet. Ausnahmsweise sei es auch erlaubt, eine GUI dafür zu verwenden. 😉 Dieser Artikel richtet sich an Fortgeschrittene, weshalb auf die Erstellung an sich nicht weiter eingegangen wird.
Als Schlüsselpaar wird bei aktuelleren GnuPG Installationen bereits RSA/RSA vorgeschlagen, was auch übernommen werden sollte.
Dann kommt das leidige Thema der Schlüssellänge. Hier gilt fast noch mehr, als bei den Algorithmen, dass davon die Kompatibilität zu Kommunikationspartnern abhängt. Die meisten sollten inzwischen 4096bit unterstützen. Weniger sollte man alleine schon deshalb nicht mehr wählen, weil man den Schlüssel ja einige Zeit behalten möchte und 4096bit noch länger aktuell bleiben wird, als kürzere Schlüssel. Längere Schlüssel werden noch immer von zu wenig Clients unterstützt. Wobei man bedenken sollte, dass viele Clients zwar keine Erstellung von Schlüsseln über einer bestimmten Länge anbieten, aber sehr wohl mit solchen umgehen können. Es gibt noch weitere Gründe, warum es nicht unbedingt sinnvoll ist, längere Schlüssel als 4096bit zu erstellen, aber dazu vielleicht später mehr.
Es gibt einige Artikel, die darauf eingehen, ob es Sinn macht, ein Kommentar zum Schlüssel hinzuzufügen. Wobei die meisten entweder sehr dafür oder sehr dagegen sind. Ich selbst füge nur mehr Kommentare hinzu, wenn es für mich Sinn macht. Ein Beispiel wäre “package signing key” für Schlüssel, über die ich eigentlich nicht kommunizieren möchte. Kommentare, die nur Informationen enthalten, die man auch aus der zu der uid gehörigen E-Mail Adresse entnehmen kann, kann man getrost weglassen.
Wichtig ist, ein Ablaufdatum festzulegen. Einige Seiten empfehlen, es nicht weiter als 5 Jahre in die Zukunft zu setzen. Es kann jederzeit, auch nach Ablauf des Schlüssels, verändert werden. Nach einer Änderung sollte der Schlüssel wieder auf einen Keyserver hochgeladen werden. Auch wenn man noch so darauf achtet, kann es passieren, dass man den privaten Teil des Schlüssels verliert oder die Passphrase vergisst. Dann sollte der Schlüssel nicht ewig über die Keyserver geistern, sondern irgendwann entfernt werden. Dabei geht es weniger darum, dass Ressourcen gespart werden, sondern mehr darum, dass ein Kommunikationspartner auch wirklich nur Schlüssel von den Keyservern holt, die auch noch zum Entschlüsseln genutzt werden können. Ähnliches gilt, wenn der Besitzer des Schlüssels ihn aus anderen Gründen nicht mehr nutzen kann (z.B. weil er verstorben ist)
Nach dem Erstellen des Schlüssels
Als erstes sollte ein Revocation Certificate erstellt werden. gpg --output revoke.asc --gen-revoke [keyid] Dieses sollte an einem sicheren Platz (USB Stick in einem Tresor, Truecrypt Container, oder vergleichbares) abgespeichert und evtl. sogar ausgedruckt (dazu beim Erstellen die Option --armor verwenden, um das Zertifikat als ASCII zu erhalten) werden, um sie im schlimmsten Fall abzutippen. Mit diesem Zertifikat kann der Schlüssel ungültig gemacht werden, ohne, dass man den privaten Teil oder die Passphrase braucht. Das ist einerseits gut, wenn man einen oder beide dieser Teile verloren hat, aber andererseits sehr gefährlich, weil jeder damit den Schlüssel ungültig machen kann. Um es zu verwenden, importiert man es einfach in seinen Schlüsselbund und lädt den Schlüssel auf einen Keyserver hoch. Ab da scheint er bei jedem als ungültig auf, der die aktuelle Version des Schlüssels hat.
Dann können weitere IDs zu dem Schlüssel hinzugefügt werden. Eine für jede E-Mail Adresse, mit der man den Schlüssel verwenden will. Einige Anleitungen empfehlen auch, eine ID ohne E-Mail Adresse hinzuzufügen, da sich der Name seltener ändert als E-Mail Adressen. Ich bin ein Freund davon, sich zumindest eine Adresse mit einer eigenen Domain zuzulegen, die sich möglichst nie ändert, was diesen Grund wieder relativiert. Ausserdem signieren manche automatisierte Tools nur “aktive” IDs, also solche, von deren E-Mail Adressen man auch Nachrichten empfangen kann, was hier ebenfalls nicht funktionieren würde. Es spricht aber auch nicht wirklich etwas gegen das Erstellen einer solchen ID.
Eine Photo ID finde ich persönlich sinnvoll, vor allem wenn man Schlüssel nur bei persönlichem Kontakt signiert. Legt man sich selbst eine Signatur Policy zurecht, die auch Signaturen ohne persönliches Treffen erlauben, kann es sinnvoll sein, auf die Signatur einer Photo ID zu verzichten. Man kann ja auch einzelne IDs signieren.
Mit gpg --send-key [keyid] schickt man den Schlüssel dann an den konfigurierten Keyserver. An sich reicht es, ihn an einen Server zu senden, da sich die Keyserver untereinander synchronisieren. In der Praxis funktioniert das nicht immer reibungslos, aber im Allgemeinen findet jeder Schlüssel früher oder später den Weg zu den einzelnen Servern.
Regelmässige Wartung
Da, anders als bei S/MIME, aktualisierte Schlüssel nicht beim Versand von E-Mails übertragen werden, sondern immer wieder vom Keyserver geladen werden müssen, ist es sehr wichtig, die Schlüssel regelmässig von einem Keyserver zu aktualisieren. Dazu habe ich folgenden Eintrag in meiner crontab: 40 5 * * 4 /usr/bin/gpg --refresh-keys --keyserver-options no-honor-keyserver-url ; /usr/bin/gpg --refresh-keys --keyserver-options honor-keyserver-url . Das funktioniert, weil ich das Gerät regelmässig für Wartungsaufgaben über Nacht laufen lasse. Wer das anders hält, muss eben die Zeit des cronjobs anpassen. Dabei führe ich --refresh-keys zwei mal aus. Einmal hole ich die Schlüssel von dem Keyserver, den ich mir als Standard konfiguriert habe und einmal von dem Keyserver, den die Schlüsselbesitzer evtl. in ihren Schlüsseln hinterlegt haben. Damit respektiere ich einerseits, falls jemand seinen Schlüssel an einem bestimmten Server pflegt, der sich unter Umständen gar nicht mit anderen Schlüsselservern synchronisiert und bin andererseits dafür gewappnet, dass jemand evtl. einen Server angegeben hat, der gar nicht mehr existiert. Wer keinen hkps fähigen Keyserver verwendet, überträgt damit regelmässig eine Liste der Schlüssel im eigenen Keyring und damit wahrscheinlich eine Liste der regelmässigen Kommunikationspartner. Es gibt Tools, die helfen, das zu Verschleiern, ohne auf hkps umsteigen zu müssen, da aber keine weitere Information enthalten ist, hebe ich Anleitungen dafür für etwaige spätere Artikel auf.
Mit dem Befehl gpg --update-trustdb kann man die Trust-DB ausfüllen. Damit gibt man für alle Schlüssel, für die man das noch nicht getan hat, an, wie sehr man dem Besitzer zutraut, Schlüssel anderer Personen nur nach ordentlicher Überprüfung der Identität zu vertrauen. Diese Information hat durchaus mit der persönlichen Meinung über die Besitzer zu tun und sollte deshalb sehr vertraulich behandelt werden. Sie wird auch nicht mit einem Schlüssel exportiert. Zu beachten ist, dass dies nichts damit zu tun hat, wie sehr man dem Besitzer eines Schlüssels glaubt, tatsächlich der zu sein, der er zu sein vorgibt. Diesen Befehl sollte man regelmässig ausführen, da diese Einstufung bei jedem neu importierten Schlüssel nötig ist. Das muss interaktiv passieren, deshalb macht es keinen Sinn, einen Cronjob dafür zu planen.
Zum Backup der geheimen Schlüssel sollte man ab und zu gpg --export-secret-keys --armor ausführen und den Output an einem sicheren Ort speichern. Zwar ist der Schlüssel mit der Passphrase geschützt, aber nur darauf sollte man sich auf keinen Fall verlassen. Die öffentlichen Schlüssel kann man zwar von Schlüsselservern neu holen, aber wenn man schon mal dabei ist: gpg --export --armor.
Es ist auch sinnvoll, immer wieder zu kontrollieren, ob das Ablaufdatum des Schlüssels nicht kurz bevor steht. Da es einige Zeit braucht, bis alle Kommunikationspartner einen aktualisierten Schlüssel holen, sollte man früh genug damit beginnen, das Ablaufdatum wieder nach hinten zu verschieben und den öffentlichen Schlüssel über die Keyserver zu verteilen.
Als stolzer Schlüsselbesitzer sollte man regelmässig versandte Mails signieren. Das ist wahrscheinlich der effektivste Weg, herauszufinden, ob man nicht unter seinen regelmässigen Kommunikationspartnern auch GnuPG Anwender hat. Ausserdem wird so oft die Rückfrage kommen, was denn “diese komischen Zeichen” sein sollen. Ein sehr praktischer Weg, um ein Gespräch über sichere E-Mailkommunikation zu beginnen. 🙂
Was man sonst noch tun kann
Natürlich sollte man über diesen Vorschlägen nicht vergessen, den Schlüssel einfach auch mal zu verwenden. Zum Signieren und Verschlüsseln von E-Mails, Signieren von Softwarepaketen, Verschlüsseln von Dateien, die man sicher aufbewahren will und einiges mehr.
Die wichtigste Regel im Umgang mit E-Mail Sicherheit ist meiner Meinung die gleiche, die ich für Wiederbelebung in der Ersten Hilfe gelernt habe: Hauptsache, man tut’s. Auch wenn man sich nicht ans Handbuch hält und vielleicht nicht alles perfekt ausführt, ist es immer noch viel, viel besser, als nichts zu tun. Bei beidem gilt jedoch auch, dass man immer nur Chancen verschieben kann. 100% Erfolgschance gibt es bei beidem leider nicht, auch wenn man noch so gut vorbereitet ist. Je besser man sich vorbereitet, umso höher sind aber die Chancen des Erfolges. Sicher ist nur eines: Macht man nichts, sieht’s düster aus.
Für alle, die sich dennoch gerne vorbereiten wollen, soll dieser Artikel einen Anhaltspunkt für den E-Mail Teil des Vergleichs geben, für den Rest gibt’s hier, hier und bei vielen anderen Stellen, die ich leider hier aus Platzgründen nicht mehr nennen kann, Angebote.
Für die Nerds und Geeks unter den Lesern findet sich viel Spass mit Graphen und Statistiken zu Schlüsseln auf http://pgp.cs.uu.nl/
Natürlich gibt es noch viel mehr, was man mit GnuPG und GPG Schlüsseln machen kann, was sich im täglichen Leben als praktisch und/oder sicher erweist, aber als Start sollte dieser Artikel einige Anhaltspunkte geben. Sollte Bedarf bestehen, können gerne Einführungsanleitungen folgen. Eine wunderbare Anwendung des Kommentarfeldes, solchen Bedarf anzumelden. 🙂
Noch eine Anmerkung: Sicherheitstechnologien sind einem ständigen Wandel unterworfen. Es lohnt sich also immer, mal kurz nach dem aktuellen Stand der Technik zu suchen, um zu vergleichen, ob die Informationen nicht schon wieder überholt sind. Bei Kommunikationstechnologien ist das doppelt wichtig, da sich Sender und Empfänger auf einen Satz an Technologien einigen müssen. Dafür wird  oft eine gewichtete Liste konfiguriert, welche Technologien unterstützt werden und welche bevorzugt werden. Das sollte nicht zu restriktiv gehalten werden, sonst kann es schon zu Problemen beim Versand von E-Mails von sehr konservativen Betriebssystemen an Bleeding-Edge OS und umgekehrt kommen. Beispiele solcher Listen finden sich oben in dem Beispiel der Konfigurationsdatei.
Für weitere Vorschläge anderer Best Practices bietet sich ebenfalls die Kommentarfunktion an.
Ein paar weiterführende Links zum Thema:

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...