Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 37

Schritt für Schritt zur sicheren Web-App: So funktioniert Transportverschlüsselung mit TLS

(Bild: Fotolia/ kittite)

Verschlüsselte Verbindungen zwischen Client und Server in Web-Applikationen sollten in der Post-Snowden-Ära Standard sein. Die Umsetzung einer entsprechenden Transportverschlüsselung mittels TLS für den eigenen Server ist gar nicht so schwer und erhöht das Vertrauen der Nutzer. Wir zeigen, wie es geht.

Wer mit persönlichen Daten hantiert, und sei es nur eine Liste von E-Mail-Adressen für den Newsletter, ist angehalten, diese vor fremdem Zugriff zu schützen. Das verlangt auch das  Bundesdatenschutzgesetz. Dabei ist zu unterscheiden, um welche Art von Daten es sich handelt. Zum einen gibt es Daten, die Kontaktpartner innerhalb persönlicher Nachrichten austauschen, zum anderen Nutzerdaten bei Cloud-Diensten.

Point-to-Point contra End-to-End

Egal ob E-Mail oder Instant-Messaging, persönliche Nachrichten dürfen von niemandem außer ihrem Sender und ihrem Empfänger eingesehen werden. Hier eignet sich eine sogenannte Ende-zu-Ende-Verschlüsselung. Das bedeutet, dass Nachrichten vor dem Versand auf dem eigenen Gerät verschlüsselt werden. So ist sichergestellt, dass weder ein Angreifer, der die Internetleitung anzapft, noch der Serverprovider selbst die Nachrichten lesen kann.

Bei Cloud-Diensten stellt der Nutzer im Gegensatz zu persönlichen Nachrichten dem Cloudsoftware-Anbieter seine Daten ganz bewusst zur Verfügung, damit dieser sie verarbeiten kann. Beispiele sind Projektmanagement, Buchhaltung oder Dokumentenverarbeitung in der Cloud – aber auch klassisches Online-Banking. Der Nutzer vertraut hierbei dem Anbieter, dass dieser seine Daten vor dem Zugriff Dritter schützt. Dazu ist es notwendig, die Verbindung zwischen Nutzer und Server über eine sogenannte Transportverschlüsselung (auch Punkt-zu-Punkt-Verschlüsselung genannt) zu sichern.

Sowohl bei der Transport- als auch bei der Ende-zu-Ende-Verschlüsselung kommt ein Public-Key-Verfahren zum Einsatz, bei dem es einen öffentlichen Schlüssel zum Verschlüsseln und einen privaten Schlüssel zum Entschlüsseln gibt. Nur der Empfänger kann die Nachricht mit seinem privaten Schlüssel entschlüsseln. Meist wird RSA als Algorithmus für Publiy-Key-Krypto verwendet. Im Folgenden geht es um die Transportverschlüsselung und deren Implementation.

In der Praxis lässt sich eine Transportverschlüsselung sehr viel leichter einrichten als eine Ende-zu-Ende-Verschlüsselung. Das liegt daran, dass sowohl Sender (Client) als auch Empfänger (Server) beim Aufbau der Verbindung gleichzeitig online sind und die Daten nur einmalig nach dem Transport entschlüsselt werden müssen. So ist das Schlüssel-Management simpel und Schlüssel können nach einer Fehlkonfiguration oder Kompromittierung problemlos ausgetauscht werden.

Transportverschlüsselung1
Bei der Ende-zu-Ende-Verschlüsselung werden Daten im Gegensatz zur Transportverschlüsselung vor der Übertragung auf dem Gerät des Nutzers verschlüsselt. Angreifer können mit der verschlüsselten Nachrichten ohne entsprechenden Schlüssel wenig anfangen. (Bild: Fotolia/ kittite)

Auch funktioniert „Perfect Forward Secrecy“ bei Transportverschlüsselungen. Unter Perfect Forward Secrecy versteht man ein kryptographisches Verfahren, das bei jedem Verbindungsaufbau einen neuen, zufälligen Sitzungsschlüssel generiert. So können verschlüsselte Daten, die heute abgefangen werden, auch dann nicht entschlüsselt werden, wenn morgen ein Angreifer den privaten Schlüssel stiehlt.

Transportverschlüsselung bei HTTP

Spricht man von Transportverschlüsselung, ist in der Praxis meist TLS (früher SSL) gemeint. Die weit verbreitete Abkürzung HTTPS meint das Versenden von HTTP-Daten über eine TLS-Verbindung. Vorteile einer TLS-Verbindung: Der Webentwickler muss seine Webanwendung nicht anpassen, wenn diese mittels TLS kommuniziert, der Systemadministrator braucht sich beim Einrichten der TLS-Verbindung keine Gedanken darüber machen, was später einmal versendet werden soll. Allerdings weiß der Server beim Aufbau der TLS-Verbindung nicht, welche Domain aufgerufen werden soll, sodass man in der Regel pro Domain eine eigene IP-Adresse braucht.

Das TLS-Zertifikat

Ein TLS-Zertifikat bestätigt dem Nutzer des Webservices example.com, dass er tatsächlich mit dem Besitzer der Domain example.com kommuniziert und kein sogenannter Man-In-The-Middle-Angriff stattgefunden hat. Erst wenn der Client dies verifiziert hat, findet der weitere Aufbau der TLS-Verbindung statt. Technisch gesehen ist ein Zertifikat der öffentliche Schlüssel des Serverbetreibers mit einer digitalen Unterschrift einer als vertrauenswürdig angesehenen Zertifizierungsstelle (certificate authority, CA).

Um ein Zertifikat zu erstellen, generiert man mit OpenSSL einen privaten RSA-Schlüssel mit 2048 bit Stärke sowie eine Zertifikatsregistrierungsanforderung (CSR).

RSA-Schlüssel generieren

$ mkdir ~/mysslfiles
$ cd ~/mysslfiles
$ openssl genrsa -out example.com.key 2048

Listing 1

Der Einfachheit halber wird der private Schlüssel im Klartext gespeichert. Besser wäre ein Passwortschutz, den man über den zusätzlichen Parameter „-aes256“ erhält.

CSR erstellen

$ openssl req -new -key example.com.key -out example.com.csr

Listing 2

Es folgt eine Liste an Fragen, deren Antworten im späteren Zertifikat einsehbar sind. Idealerweise decken sich die Angaben mit dem WHOIS-Eintrag der Domain – das schafft Vertrauen. Bei „State or Province Name“ nimmt man in Deutschland das Bundesland und der „Organizational Unit Name“ ist im Zweifel „IT“. In „Common Name“ muss die genaue Domain enthalten sein, die von der Webanwendung benutzt wird. Viele Zertifizierungsstellen generieren dann ein Zertifikat, das für die Domain sowohl mit als auch ohne „www“ funktioniert. Die „extra attributes“ können leer bleiben. Wer das ganze noch einmal überprüfen will, bedient sich folgenden Befehls:

CSR ansehen

$ openssl req -text -in example.com.csr

Listing 3

Mit dieser CSR erhält man bei einer CA seiner Wahl das eigentliche Zertifikat. Für den Anfang reicht oft das kostenfreie StartSSL Free, das von allen gängigen Browsern akzeptiert wird und ein Jahr gültig ist. Die CA spuckt zwei Dateien aus: zum einen das Zertifikat im PEM-Textformat, das man unter „example.com.crt“ speichert, und zum anderen das „Intermediate CA“-Zertifikat von der CA. Bei StartSSL nennt es sich „sub.class1.server.ca.pem“.

Finde einen Job, den du liebst

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden