14Jun/170

Das SSL Zertifikat

Oft fragt man sich, in welchen Situationen ein SSL Zertifikat wirklich Sinn macht. In diesem Tutorial zeigen wir Ihnen, wann und wo Zertifikate genutzt werden sollten um von Verschlüsselung zu profitieren.

Ein Zertifikat besteht meist aus zwei Teilen, einem privaten und einem öffentlichem Schlüssel.
Um das Verfahren genauer zu verstehen, haben wir folgende Abbildung angefertigt.

 

ssl

Der Client kontaktiert den Server und bietet dem Server seine unterstützten Verschlüsselungsmodi an, am Ende einigen sich beide auf eine Verschlüsselungsart. Nun sendet der Server dem Client den öffentlichen Schlüssel, mit diesem Schlüssel kann der Client seine Daten verschlüsseln.  Startet man nun einen Paketmitschnitt bekommt man nur verschlüsselte Daten. Man benötigt den privaten Schlüssel, um verschlüsselte Daten entschlüsseln zu können, diesen Schlüssel hat nur der Server. Der private Schlüssel darf auf keinen Fall Dritten zugänglich gemacht werden, das birgt ein enormes Sicherheitsrisiko weil jegliche verschlüsselte Daten der Clients entschlüsselt werden können.

Für einen kleinen Test haben wir ein HTML Formular erstellt, in dem man einen Nutzernamen und ein Passwort eingeben kann, eine solche Login-Maske findet man sehr häufig auf Webseiten.

Unser Loginname war: test@contabo.de

Das Passwort war : "unencryptedpassword"

Mit einem gängigen Netzwerktool wurden Pakete mitgeschnitten um den Unterschied deutlich zu machen.

Ohne Verschlüsselung konnten wir mühelos den Nutzernamen und das Passwort in Klartext sehen, theoretisch könnten wir auch nachvollziehen, welche Seiten aufgerufen wurden.

pw_unencrypted

Mit Verschlüsselung konnten wir keinerlei Passwörter, Benutzernamen oder die Seiten, die aufgerufen worden sind, darstellen.
Es zeigt sich uns nur ein Datenpaket, was dieses Paket beinhaltet, kann ohne Entschlüsselung nicht festgestellt werden.
In diesem Fall sollte der Benutzername und das Passwort in folgendem Paket übermittelt worden sein (ganz genau kann man es nicht bestimmen).

pw_encrypted

Um wirklich professionell aufzutreten, sollte man seinen Kunden in jedem Fall eine verschlüsselte Verbindung zur Verfügung stellen, vor allem dann, wenn sensible Daten wie E-Mail Adressen, Benutzernamen, Passwörter oder auch Kreditkarteninformationen eines Kunden übermittelt, verarbeitet und gespeichert werden.

Es gibt natürlich verschiedene Arten von Verschlüsselungen, wir befassen uns hier jedoch nur mit dem Thema der SSL-Zertifikate, die für eine Verschlüsselung benötigt werden. Selbst Verschlüsselungsalgorithmen aus den 90er Jahren bieten einen sehr guten Schutz, hier muss man sich prinzipiell nur bei einem "Finetuning" wirklich Gedanken machen.

 


Das Mysterium der unsicheren Verbindungen wird gelüftet:

Jene, die ein Webinterface (cPanel, Plesk, Webmin etc.) installiert haben, haben sicherlich schon einmal folgende Warnmeldung gesehen:

ssl_err_ger

"Dem Zertifikat wird nicht vertraut, da es vom Aussteller selbst signiert wurde", normalerweise sollte man sich jetzt zweimal überlegen ob man trotzdem die Seite laden möchte, unter Umständen wurde man auf einen anderen Server umgeleitet, in unserem Fall besteht hier keine Gefahr. Die Warnung besagt nur, dass keine öffentliche Institution das Zertifikat unterzeichnet hat. Das Zertifikat an sich hat nichts mit der Stärke der Verschlüsselung zu tun, die Verschlüsselung wird vom Client und Server ausgehandelt.

Es ist natürlich ärgerlich, wenn jeder Kunde eine solche Meldung bekommt - diese Meldung wird oft falsch interpretiert, die Verbindung ist selbstverständlich "sicher" und verschlüsselt.

Abhilfe schafft hier nur ein Zertifikat, welches von einer öffentlichen Institution signiert wurde, die Preise für solche Zertifikate sind meist extrem hoch und übersteigen schnell das Budget. Daher sollte man sich vorher überlegen wie viel Sicherheit man selbst benötigt, bzw. wie viel Sicherheit man seinen Kunden zur Verfügung stellen möchte.

Zertifikate von Institutionen, wie bspw. "Lets Encrypt" sind eine tolle kostenlose Alternative, vor allem wenn man ansonsten unverschlüsselt übertragen würde. Sicherheit für die eigene Website bieten domainvalidierte Zertifikate, welche Sie auch bei uns erwerben können. Diese Art von Zertifikaten ist sehr weit verbreitet, es erfolgt hier eine einfache Prüfung der Domain, das Zertifikat ist dann für diese Domain gültig.

Diese Prüfungen gehen so weit, dass zum Teil notariell beglaubigte Urkunden eingesendet werden müssen, dies nennt man dann "Extended Validation". Ziel ist natürlich immer ein möglichst seriöser Auftritt im Web.

Sobald man sich für ein Zertifikat entschieden hat, egal ob domainvalidiert oder eines mit einer Extended Validation, verschwindet die Warnmeldung und die Website ist fortan für jedermann ohne Warnmeldung erreichbar.

Ebenfalls sehr wichtig ist die Entscheidung, ob man das Zertifikat für eine oder gleich mehrere Domains, bzw. Subdomains benötigt. Ein Wildcard-Zertifikat gilt für eine Vielzahl an Domains, bspw. *.domain.tld, während ein einfaches Zertifikat meist nur für eine Domain gültig ist, z.B. subdomain.domain.tld. Oft wird auch die "www" Subdomain in das Zertifikat integriert, sodass ein Zertifikat durchaus für mehrere Subdomains gültig sein kann. Ein solches Zertifikat, das für mehrere Domains gültig ist, nennt man Multi-Domain-Zertifikat oder auch UCC (Unified Communications Certificate).

Ist die Suche nach dem passenden Zertifikat abgeschlossen und das Zertifikat bestellt, muss lediglich die Konfiguration des Webservers angepasst werden. Anleitungen bekommt man meist von der ausstellenden Institution.

ssl_ok

Wichtig :
Zertifikate bzw. Verschlüsselung spielen nicht nur bei Webservern eine Rolle, Nutzernamen und Passwörter können überall im Klartext abgegriffen werden, egal ob beim Mailversand, FTP Transfer oder sonst einem Dienst. Man sollte möglichst eine verschlüsselte Verbindung vorziehen oder eine unverschlüsselte Verbindung verweigern.

Posted by: Gianni-Donato | Tagged as: , , , , No Comments
17Nov/160

Let’s Encrypt!

In der heutigen Zeit ist Datensicherheit sehr wichtig und Verschlüsselung ist ein wichtiger Bestandteil dieses Themas. Leider ist das Verschlüsseln in vielen Fällen ein komplexer Prozess, welcher von vielen Benutzern aufgrund fehlender Fachkenntnisse nicht oder nur ungenügend bewältigt werden kann. Um eine Webseite via Secure Socket Layer (SSL) beziehungsweise über Transport Layer Security (TLS) abzusichern, sodass diese über das Hypertext-Transfer-Protocol Secure (HTTPS) erreichbar ist, ist ein Zertifikat notwendig.

Dieses Zertifikat dient als Basis für verschlüsselte Verbindungen. Wenn ein Benutzer auf eine via HTTPS verschlüsselte Seite zugreifen möchte, wird eine verschlüsselte Verbindung aufgebaut.  Bevor diese Verbindung aufgebaut werden kann, wird das vom angefragten Server präsentierte Zertifikat überprüft. Hierbei wird überprüft, ob dem vom Server übermittelten Zertifikat vertraut werden kann.  Diese Vertrauensüberprüfung funktioniert etwas vereinfacht dargestellt folgendermaßen:

  1. Überprüfung der Signatur des Zertifikats auf Basis der Vertrauenskette
  2. Überprüfung ob die aufgerufene Domain mit der für das Zertifikat hinterlegten übereinstimmt

Was genau ist die Vertrauenskette des Zertifikats?

Im Prinzip sind in jedem Betriebssystem und zum Teil auch in Browsern wie Mozilla Firefox und Google Chrome Zertifikate von vertrauenswürdigen Zertifizierungsstellen vorinstalliert. Diesen Zertifikaten wird, sofern sie nicht zwischenzeitlich für ungültig erklärt wurden, immer vertraut. Bei der Überprüfung der Vertrauenskette wird, vereinfacht ausgedrückt, überprüft, ob der Signatur des Zertifikats bereits von den vorinstallierten Zertifikaten der vertrauenswürdigen Zertifizierungsstellen vertraut wird. Man spricht hier von einer Vertrauenskette, da es zum Beispiel möglich ist, dass der Signatur von Let's Encrypt auf Ihrem System nicht vertraut wird, allerdings wurde das Let's Encrypt Zertifikat, welches zum Signieren Ihres Zertifikats benutzt wurde, ebenfalls von einer dritten Zertifizierungsstelle signiert, welcher auf Ihrem System vertraut wird. Somit bürgt Let's Encrypt dafür, dass Ihr Zertifikat vertrauenswürdig ist und die dritte Zertifizierungsstelle, welcher auf Ihrem System vertraut wird, bürgt für die Vertrauenswürdigkeit von Let's Encrypt.

Wo und wie ist das Let's Encrypt Projekt einzuordnen?

Da der Aufbau und Betrieb einer vertrauenswürdigen Zertifizierungsstelle aufwändig und mit Kosten verbunden ist, war es bisher gang und gäbe, dass man für ein signiertes Zertifikat, dessen Signatur bereits von den vorinstallierten Zertifikaten vertraut wird, bezahlen muss. Let's Encrypt hat ebenfalls eine vertrauenswürdige Zertifizierungsstelle aufgebaut, welche kostenlos Zertifikate signiert und den Prozess der Zertifikatserstellung und Installation weitestgehend vereinfachen und automatisieren möchte. Der Hauptgedanke ist dabei, ein sichereres Internet voranzutreiben.

Automatische Zertifikate bei unseren Webspace Paketen

Wie wir bereits ausführlich im Post Webspace: Kostenlose SSL-Zertifikate sind ab sofort verfügbar informiert haben, ist auf unseren Webspace Paketen automatisch ein Zertifikat für die hinzugefügten Domains via Let's Encrypt aktiviert. Selbst das manuelle Erneuern der Zertifikate ist nicht mehr notwendig, da es ebenfalls automatisch passiert.

Let's Encrypt via AutoSSL in cPanel

Seit cPanel & WHM Version 58.0.17 wird Let's Encrypt offiziell von cPanel unterstützt. Zum jetzigen Zeitpunkt muss die Integration in AutoSSL vom Benutzer noch selbständig via Shell angestoßen werden. Hierfür muss das Installationsskript unter

/scripts/install_lets_encrypt_autossl_provider

 

als root Benutzer ausgeführt werden.

Nach erfolgreicher Installation kann Let's Encrypt unter Home >> SSL/TLS >> Manage AutoSSL als Zertifikat Provider ausgewählt werden.

autossl_lets_encryptEinstellungen für spezifische Benutzer können unter dem Reiter "Manage Users" vorgenommen werden.

Let's Encrypt über eine Erweiterung in Plesk

Auch Plesk unterstützt ab Version 12.5 Let's Encrypt über eine Erweiterung. Die Installation und Konfiguration in dieser Anleitung funktioniert für Linux und Windows Installationen gleichermaßen.

Um die Erweiterung zu installieren, gehen Sie bitte in Plesk zu:

"Tools & Settings" >> Oberpunkt "Plesk" >> "Updates & Upgrades"

Es öffnet sich ein neuer Tab, für den Sie eventuell im Browser noch ein selbst signiertes Zertifikat bestätigen müssen. In diesem Tab wechseln Sie bitte zu: "Add/Remove Components".

plugin

Wählen Sie bitte die Erweiterung, wie in Bild oben dargestellt, zur Installation aus und bestätigen Sie mit "Continue". Sobald das Plugin installiert ist, wird die Meldung "All operations with products and components have been successfully completed." erscheinen. Mit einem Klick auf OK kommen Sie wieder in das Hauptmenü. Sie können den Tab nun schließen.
Nun müssen Sie nur noch ein Zertifikat beziehen und es für die Domain aktivieren. Bitte wechseln Sie hierfür zu "Websites & Domains" und klappen Sie alle Optionen für die gewählte Domain auf. Hier ist nun die Option Let's Encrypt hinzugekommen:

letsencrypt

Öffnen Sie bitte diese Verlinkung und überprüfen Sie die E-Mail Adresse. Überlegen Sie, ob die Seite auch über www erreichbar sein soll und setzen Sie gegebenenfalls den Haken bei "Include www.ihredomain.de as an alternative domain name.". Schicken Sie abschließend, mit einem Klick auf "OK", die Anfrage für das Zertifikat ab. Sobald der Vorgang abgeschlossen ist, sollte Ihre Seite bereits über https aufrufbar sein. Zur Sicherheit können Sie aber auch noch in die "Hosting Settings" für Ihre Domain gehen, dort im Bereich "Security" die permanente Weiterleitung auf https aktivieren und das soeben bezogene Zertifikat aktiv auswählen, falls es noch nicht gesetzt ist. Wenn es bei dem Anfordern des Zertifikates zu einer Fehlermeldung kam, sollten Sie überprüfen, ob der A-Record für die gewählte Domain auf Ihre Server IP zeigt. Das gilt auch für die eventuell aktivierte Subdomain "www".

Benutzung von Let's Encrypt ohne Administration Panel (Debian 8)

Es wird empfohlen, Certbot in Verbindung mit Let's Encrypt zu benutzen. In unserem Beispiel benutzen wir Apache als Webserver und Debian 8 als Betriebssystem.

Als root Benutzer müssen folgende Befehle ausgeführt werden um Certbot für Apache und dessen Abhängigkeiten zu installieren:

# Debian Jessie backports repository aktivieren

echo "deb http://ftp.debian.org/debian jessie-backports main" >> /etc/apt/sources.list && apt-get update

 

# Certbot installieren

apt-get install python-certbot-apache -t jessie-backports

 

Nach dem Abschluss der Installation ist es via Certbot möglich, vollautomatisch signierte Zertifikate für Ihre Domains zu generieren. Diese werden dann, ebenfalls automatisch, in Apache für Sie konfiguriert. Folgender Befehl startet einen Konfigurationsdialog  in dem benötigte Informationen wie, Domain Namen und E-Mail Adresse abgefragt werden. Nach der Eingabe der erforderlichen Informationen und dem Bestätigen der AGB von Let's Encrypt, werden Ihre signierten Zertifikate bezogen und automatisch in Apache konfiguriert. Es ist ebenfalls möglich zu konfigurieren, ob Ihre Domains via HTTP und HTTPS oder nur via HTTPS erreichbar sein sollen.

# Automatischen Konfigurationsdialog starten

certbot --apache

Falls man das Zertifikat selbst konfigurieren möchte, kann folgender Befehl benutzt werden welcher nur das Zertifikat erstellt.

# Zertifikat Erstellen ohne automatische Konfiguration in Apache

certbot --apache certonly

Certbot funktioniert nicht nur in Verbindung mit dem Apache Webserver und Debian 8, es sind viele Betriebssystem und Webserver Kombinationen möglich, welche unter folgendem Link eingesehen werden können: Certbot.

Installation von Let's Encrypt ohne Administration Panel (CentOS 7.2)

Da die Benutzung von Certbot auf CentOS exakt wie auf Debian 8 funktioniert, wird im folgenden nur kurz auf die Installation von Certbot auf CentOS eingegangen. Da die Apache/httpd default Installation (yum install httpd) auf CentOS nicht das SSL Modul installiert, muss darauf geachtet werden, dass dieses ebenfalls installiert ist.

# Extra Packages for Enterprise Linux und optional mod_ssl installieren

yum install epel-release mod_ssl 

# Certbot installieren

yum install python-certbot-apache

 

Automatische Verlängerung der Zertifikate einrichten

Da Zertifikate von Let's Encrypt nur eine Gültigkeit von drei Monaten haben, ist es wichtig, eine automatische Verlängerung einzurichten.

Bei der Installation des Debian 8 Pakets von Certbot wurde solch ein "cron-job" bereits automatisch eingerichtet. Auf CentOS wird dieser nicht automatisch eingerichtet, allerdings kann man diesen, wie unten stehend, auf einer Standard CentOS Installation anlegen.

# /etc/cron.d/certbot

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew

 

Dieser cron-job wird alle 12 Stunden ausgeführt und erneuert die Gültigkeit aller Zertifikate, falls diese weniger als 30 Tage Gültigkeit aufweisen. Es wird empfohlen, dass alle 12 Stunden die Gültigkeit der Zertifikate überprüft wird, damit man zeitnah mitbekommt, ob Zertifikate für ungültig erklärt wurden.

 

 

Posted by: Dirk | Tagged as: , , , No Comments