Janotta und Partner Cybersicherheit. Sichere Verbindungen. SSL / TLS sicher einrichten

Transkript

1 Janotta und Partner Cybersicherheit Sichere Verbindungen SSL / TLS sicher einrichten

2 Vertrauliche Daten wie Kreditkarteninformationen sollten nur über eine sichere, verschlüsselte Verbindung mit Authentifizierung zwischen Webserver und Client übertragen werden. mod_ssl bietet mittels der Protokolle Secure Sockets Layer (SSL) und Transport Layer Security (TLS) eine sichere Verschlüsselung für die HTTP- Kommunikation zwischen einem Client und dem Webserver. Wenn Sie SSL/TSL v erwenden, wird zwischen dem Webserver und dem Client eine private Verbindung eingerichtet. Die Datenintegrität bleibt dadurch gewährleistet und Client und Server können sich gegenseitig authentifizieren. Zu diesem Zweck sendet der Server vor der Beantwortung von Anforderungen an eine URL ein SSL-Zertifikat mit Informationen, die die Identität des Servers nachweisen. Dies garantiert, dass der Server eindeutig der richtige Endpunkt der Kommunikation ist. Außerdem wird durch das Zertifikat eine verschlüsselte Verbindung zwischen dem Client und dem Server hergestellt, die sicherstellt, dass Informationen ohne das Risiko der Freigabe sensitiver Klartextinhalte übertragen werden. mod_ssl implementiert die SSL/TSL-Protokolle nicht selbst, sondern fungiert als Schnittstelle zwischen Apache und einer SSL-Bibliothek. In opensuse wird die OpenSSL-Bibliothek verwendet. OpenSSL wird bei der Installation von Apache automatisch installiert. Die Verwendung von mod_ssl in Apache erkennen Sie in URLs am Präfix (statt Erstellen eines SSL-Zertifikats Wenn Sie SSL/TSL mit dem Webserver einsetzen möchten, müssen Sie ein SSL-Zertifikat erstellen. Dieses Zertifikat ist für die Autorisierung zwischen Webserver und Client erforderlich, damit beide Endpunkte jeweils die Identität des anderen Endpunkts überprüfen können. Zum Nachweis der Zertifikatintegrität muss das Zertifikat von einer Organisation signiert sein, der jeder der beteiligten Benutzer vertraut. Sie können drei Zertifikatsarten erstellen: ein Dummy -Zertifikat, das nur zu Testzwecken verwendet wird, ein selbst signiertes Zertifikat für einen bestimmten Benutzerkreis, der Ihnen vertraut, und ein Zertifikat, das von einer unabhängigen, öffentlich bekannten Zertifizierungsstelle (CA) signiert wurde.

3 Die Zertifikaterstellung besteht im Grunde nur aus zwei Schritten: Zunächst wird ein privater Schlüssel für die Zertifizierungsstelle generiert und danach wird das Serverzertifikat mit diesem Schlüssel signiert. Weiterführende Informationen Weitere Informationen über das Konzept von SSL/TSL und diesbezügliche Festlegungen finden Sie unter Erstellen eines Dummy -Zertifikats Die Erstellung eines Dummy-Zertifikats ist einfach. Rufen Sie lediglich das Skript /usr/bin/gensslcert auf. Dieses Skript erstellt oder überschreibt die folgenden Dateien: /etc/apache2/ssl.crt/ca.crt /etc/apache2/ssl.crt/server.crt /etc/apache2/ssl.key/server.key /etc/apache2/ssl.csr/server.csr Außerdem wird eine Kopie der Datei ca.crt im Verzeichnis /srv/www/htdocs/ca.crt zum Herunterladen bereitgestellt. Hinweis beim einrichten von SSL Verwenden Sie Dummy-Zertifikate niemals in Produktionsumgebungen, sondern nur zum Testen. Erstellen eines selbst signierten Zertifikats Wenn Sie einen sicheren Webserver für Ihr Intranet oder einen bestimmten Benutzerkreis einrichten, reicht unter Umständen ein von Ihrer eigenen Zertifizierungsstelle signiertes Zertifikat aus.

4 Die Erstellung eines selbst signierten Zertifikats ist ein interaktiver Vorgang, der aus neun Schritten besteht. Wechseln Sie dazu zunächst in das Verzeichnis /usr/share/doc/packages/apache2 und führen Sie den folgenden Befehl aus:./mkcert.sh make --no-print-directory /usr/bin/openssl /usr/sbin/ custom. Diesen Befehl sollten Sie keinesfalls außerhalb dieses Verzeichnisses ausführen. Das Programm gibt eine Reihe von Eingabeaufforderungen aus, von denen einige Benutzereingaben erfordern. Erstellen eines selbst signierten Zertifikats mit mkcert.sh -Festlegen des für Zertifikate zu verwendenden Signaturalgorithmus -Wählen Sie RSA aus (R, die Standardeinstellung), da einige ältere Browser Probleme mit DSA haben. -Generating RSA private key for CA (1024 bit) (Privaten RSA-Schlüssel für CA (1024 Bit) erstellen) -Keine Eingabe erforderlich. -Generating X.509 certificate signing request for CA (X.509-Zertifikatsignierungsanforderung für CA erstellen) Hier erstellen Sie den DN (Distinguished Name) der Zertifizierungsstelle. Dazu müssen Sie einige Fragen, z. B. nach dem Land oder der Organisation, beantworten. Geben Sie an dieser Stelle nur gültige Daten ein. Schließlich wird alles, was Sie hier eingeben, später im Zertifikat angezeigt. Sie müssen nicht alle Fragen beantworten. Wenn eine Frage nicht auf Sie zutrifft oder Sie eine Antwort offen lassen möchten, geben Sie ein.. Allgemeiner Name ist der Name der CA selbst. Wählen Sie einen aussagekräftigen Namen wie CA mein Unternehmen. -Generating X.509 certificate for CA signed by itself (Von CA selbst signiertes X.509-Zertifikat für CA erstellen) -Wählen Sie Zertifikatversion 3 aus (die Standardeinstellung).

5 -Generating RSA private key for SERVER (1024 bit) (Privaten RSA-Schlüssel für SERVER (1024 Bit) erstellen) -Keine Eingabe erforderlich. -Generating X.509 certificate signing request for SERVER (X.509-Zertifikatsignierungsanforderung für SERVER erstellen) Hier erstellen Sie den DN für den Serverschlüssel. Es werden nahezu die gleichen Fragen gestellt wie für den DN der Zertifizierungsstelle. Ihre Antworten betreffen jedoch den Webserver und müssen nicht unbedingt identisch mit den für die Zertifizierungsstelle eingegebenen Daten sein (der Server kann sich z. B. an einem anderen Standort befinden). Auswahl eines Common Name für die sichere Einrichtung von SSL Als Common Name (allgemeiner Name) müssen Sie hier den vollständig qualifizierten Hostnamen des sicheren Servers eingeben (z. B. Anderenfalls gibt der Browser beim Zugriff auf den Webserver eine Warnung mit dem Hinweis aus, dass das Zertifikat nicht mit dem Server übereinstimmt. -Generating X.509 certificate signed by own CA (Von eigener CA signiertes X.50 Zertifikat erstellen).wählen Sie Zertifikatversion 3 aus (die Standardeinstellung)..-Encrypting RSA private key of CA with a pass phrase for security (Privaten RSA-Schlüssel der CA aus Sicherheitsgründen mit einem Passwort verschlüsseln) -Aus Sicherheitsgründen empfiehlt es sich, den privaten Schlüssel der Zertifizierungsstelle mit einem Passwort zu verschlüsseln. Wählen Sie daher J aus und geben Sie ein Passwort ein. -Encrypting RSA private key of SERVER with a pass phrase for security (Privaten RSA-Schlüssel des SERVERS aus Sicherheitsgründen mit einem Passwort verschlüsseln)

6 -Wenn Sie den Serverschlüssel mit einem Passwort verschlüsseln, müssen Sie dieses Passwort bei jedem Start des Webservers eingeben. Dies macht den automatischen Start des Webservers beim Hochfahren des Computers oder einen Neustart des Webservers nahezu unmöglich. Aus diesem Grund sollten Sie diese Frage mit N beantworten. Denken Sie aber daran, dass Ihr Schlüssel in diesem Fall ungeschützt ist, und stellen Sie sicher, dass nur autorisierte Personen Zugriff auf den Schlüssel haben. Verschlüsseln des Serverschlüssels für sichere Kommunikation Wenn Sie den Serverschlüssel mit einem Passwort verschlüsseln möchten, erhöhen Sie den Wert für APACHE_TIMEOUT in /etc/sysconfig/apache2. Anderenfalls bleibt Ihnen unter Umständen nicht genügend Zeit für die Eingabe des Passworts, bevor der Startversuch des Servers wegen Zeitüberschreitung abgebrochen wird. Die Ergebnisseite des Skripts enthält eine Liste der generierten Zertifikate und Schlüssel. Die Dateien wurden allerdings nicht, wie im Skript angegeben, im lokalen Verzeichnis conf erstellt, sondern in den passenden Verzeichnissen unter /etc/apache2/. Der letzte Schritt besteht darin, die Zertifikatdatei der Zertifizierungsstelle aus dem Verzeichnis /etc/apache2/ssl.crt/ca.crt in ein Verzeichnis zu kopieren, in dem die Benutzer auf die Datei zugreifen können. Aus diesem Verzeichnis können die Benutzer die Zertifizierungsstelle in ihren Webbrowsern der Liste der bekannten und vertrauenswürdigen Zertifizierungsstellen hinzufügen. Wäre die Zertifizierungsstelle nicht in dieser Liste enthalten, würde der Browser melden, dass das Zertifikat von einer unbekannten Zertifizierungsstelle ausgegeben wurde. Das neu erstellte Zertifikat ist ein J ahr lang gültig. Eigensignierte SSL Zertifikate Verwenden Sie selbst signierte Zertifikate nur auf einem Webserver, auf den Benutzer zugreifen, denen Sie bekannt sind und die Ihnen als Zertifizierungsstelle vertrauen. Für einen öffentlichen Online-Versand wäre ein solches Zertifikat z. B. nicht geeignet Anfordern eines offiziell signierten Zertifikats

7 Es gibt verschiedene offizielle Zertifizierungsstellen, die Ihre Zertifikate signieren. Zertifizierungsstellen sind vertrauenswürdige unabhängige Parteien. Einem Zertifikat, das durch eine solche Zertifizierungsstelle signiert wurde, kann daher voll und ganz vertraut werden. Sichere Webserver, deren Inhalte für die Öffentlichkeit bereitstehen, verfügen in der Regel über ein offiziell signiertes Zertifikat. Die bekanntesten offiziellen Zertifizierungsstellen sind Thawte ( und Verisign ( Diese und andere Zertifizierungsstellen sind bereits in Browsern kompiliert. Zertifikate, die von diesen Zertifizierungsstellen signiert wurden, werden daher von Browsern automatisch akzeptiert. Wenn Sie ein offiziell signiertes Zertifikat anfordern, senden Sie kein Zertifikat an die Zertifizierungsstelle, sondern eine CSR (Certificate Signing Request, Zertifikatsignierungsanforderung). Zur Erstellung einer CSR rufen Sie das Skript /usr/share/ssl/misc/ca.sh -newreq auf. Das Skript fragt zunächst nach dem Passwort für die Verschlüsselung der CSR. Danach müssen Sie einen Distinguished Name (DN) eingeben. Dazu müssen Sie einige Fragen, z. B. nach dem Land oder der Organisation, beantworten. Geben Sie an dieser Stelle nur gültige Daten ein. Alles, was Sie hier eingeben, wird überprüft und später im Zertifikat angezeigt. Sie müssen nicht alle Fragen beantworten. Wenn eine Frage nicht auf Sie zutrifft oder Sie eine Antwort offen lassen möchten, geben Sie ein.. Allgemeiner Name ist der Name der CA selbst. Wählen Sie einen aussagekräftigen Namen wie CA Mein Unternehmen. Zum Schluss müssen Sie noch ein Challenge Passwort (zur Vernichtung des Zertifikats, falls der Schlüssel kompromittiert wird) und einen alternativen Unternehmensnamen eingeben. Die CSR wird in dem Verzeichnis erstellt, aus dem Sie das Skript aufgerufen haben. Der Name der CSR-Datei lautet newreq.pem. Konfigurieren von Apache mit SSL Port 443 ist auf dem Webserver der Standardport für SSL- und TLS-Anforderungen. Zwischen einem normalen Apache-Webserver, der Port 80 überwacht, und einem SSL/TLS-aktivierten Apache-Server, der Port 443 überwacht, kommt es zu keinen Konflikten. In der Tat kann die gleiche Apache-Instanz sowohl HTTP als auch HTTPS ausführen. In der Regel verteilen separate virtuelle Hosts die Anforderungen für Port 80 und Port 443 an separate virtuelle Server.

8 Firewall-Konfiguration für SSL Verbindnungen Vergessen Sie nicht, die Firewall für den SSL-aktivierten Apache-Webserver an Port 443 zu öffnen. Sie können dazu YaST verwenden (siehe Abschnitt , Konfigurieren der Firewall mit YaST ). Zur Verwendung von SSL muss SSL in der globalen Serverkonfiguration aktiviert sein. Zur Aktivierung öffnen Sie /etc/sysconfig/apache2 in einem Editor und suchen Sie nach APACHE_MODULES. Fügen Sie der Modulliste ssl hinzu, sofern dieser Eintrag noch nicht vorhanden ist (mod_ssl ist standardmäßig aktiviert). Suchen Sie anschließend nach APACHE_SERVER_FLAGS und fügen Sie SSL hinzu. Wenn Sie sich zuvor entschieden haben, Ihr Serverzertifikat durch ein Passwort zu verschlüsseln, sollten Sie nun den Wert von APACHE_TIMEOUT heraufsetzen, damit Ihnen beim Start von Apache genügend Zeit für die Eingabe des Passworts bleibt. Starten Sie den Server anschließend neu, damit die Änderungen wirksam werden. Ein Neuladen des Servers reicht dazu nicht aus. Das Verzeichnis der virtuellen Hostkonfiguration enthält die Vorlage /etc/apache2/vhosts.d/vhost-ssl.template. Diese enthält SSL-spezifische Direktiven, die bereits an anderer Stelle hinreichend dokumentiert sind. Informationen über die Basiskonfiguration eines virtuellen Hosts finden Sie unter Abschnitt , Virtuelle Hostkonfiguration. Für den Anfang sollte es ausreichen, die Werte der folgenden Direktiven einzustellen: 1. DocumentRoot 2. ServerName 3. ServerAdmin 4. ErrorLog 5. TransferLog

9 Namensbasierte virtuelle Hosts und SSL Auf einem Server mit nur einer IP-Adresse können nicht mehrere SSL-aktivierte virtuelle Hosts laufen. Benutzer, die versuchen, eine Verbindung mit einer solchen Konfiguration herzustellen, erhalten bei jedem Besuch der URL eine Warnung mit dem Hinweis, dass das Zertifikat nicht mit dem Namen des Servers übereinstimmt. Für die Kommunikation auf Grundlage eines gültigen SSL-Zertifikats ist eine separate IP-Adresse bzw. ein separater Port für jede SSL-aktivierte Domäne erforderlich. Testen Sie zum Schluss SSL auf Sicherheit Auf der OWASP-Webseite sind zahlreiche Werkzeuge zu finden, die unsichere SSL-Konfigurationen aufspüren. 6 Fazit Weitere SSL-Schwachstellen werden auch in Zukunft entdeckt werden. Die Zertifizierung einer SSL-Middleware schafft zwar Vertrauen, ist aber keine Garantie für ihre Fehlerfreiheit. Wie bei jeder Zertifizierung ist es hilfreich, nachzulesen, was eigentlich zertifiziert wurde. Folgende Checkliste fasst für Entwickler kurz zusammen, wie sie eine SSL-Anwendung sicher bzw. sicherer implementieren können: Zertifikatsprüfung korrekt durchführen Die Zertifikatsprüfung darf für die Produktion keinesfalls deaktiviert werden. Die gesamte Zertifikatskette überprüfen. Self-signed-Zertifikate (mit der Ausnahme eines Wurzelzertifikats) ablehnen. Hostnamen-Validierung durchführen. SSL-Middleware sicher einsetzen Sicherheitsparameter für SSL-Middleware immer explizit setzen. Auf komplexe APIs der SSL-Middleware achtgeben und die API-Dokumentation verstehen. Überprüfen, ob die Zertifikatsprüfung der Middleware korrekt durchgeführt wurde. Unsichere Testartefakte von Produktionscode entkoppeln SSL-Anwendungen und Konfigurationen ausreichend testen: zahlreiche Werkzeuge bieten Unterstützungen. SSL sicher zu implementieren ist eine komplexe Aufgabe. Sie kann aus der Sicht des Systems Security Engineerings betrachtet werden. Die Sicherheit eines auf SSL basierenden Systems ist das Produkt der Interaktionen zwischen den beteiligten Systemkomponenten: Das Gesamtsystem ist nur so sicher wie das schwächste Glied in dieser Kette. Die Interaktionen (d. h. die APIs, über die die Komponenten aufeinander zugreifen) müssen so entworfen werden, dass die Semantik auf einer geeigneten Abstraktionsebene konsistent ist. Bei einem System macht jede Komponente Annahmen über die Komponenten, mit denen sie interagiert. Allein die Annahme, dass eine andere Komponente angemessene Sicherheitsqualitäten besitzt, gewährleistet keine Sicherheit und ist somit nicht haltbar.

10 Sichere Verbindungen - Hinweise zum Schluss Komponenten muss überprüft werden. So werden Annahmen missbraucht, um Verantwortung zu verschieben. Beispielsweise verlagert eine SSL-Middleware bei unvollständigen Zertifikatsprüfung die Verantwortung an die Anwendungsebene. Ein Anwendungsentwickler wiederum verschiebt über Warnmeldungen die Verantwortung an die Anwender. Die Hoffnung, dass ein Anwender dann richtig entscheidet, erfüllt sich leider meist nicht. Die Implementierung von SSL ist interdisziplinär. Security-Experten, Entwickler, Anwender und Angreifer sind involviert. Dabei besteht zwischen diesen Gemeinden oft eine große Kluft. Das fehlende Verständnis, wie SSL funktioniert und insbesondere welche Bedeutung die korrekte Zertifikatsprüfung dabei spielt, ist eine wesentliche Ursache für die Schwachstellen in SSL-basierten Anwendungen. SSL zu implementieren ist nicht nur eine technische Herausforderung. Neben dem Secure Coding und den aktuellen Diskussionen um die Sicherheit der Open Source Software spielen Usability, Psychologie und auch Politik (insbesondere bei den Zertifizierungsstellen) eine entscheidende Rolle. Unser Team freut sich auf Ihre Projekt Anfrage.

11 Janotta und Partner Breslaustrasse Schweinfurt T +49 (9721) E + info@janotta-partner.de Kontaktformular Projektanfrage

12 Leistungsprofil Leistungen Beratung Tests Audits und Analysis Consulting Workshops Sicherheits-Konzeption IT Beratungen Produkt Tests Forschungsaufträge Tägliches, komplettes Backup Eigene Backup Infrastruktur Durchführung von System- und sicherheitsrelevanten Updates Trainings und Schulungen Produkte Security Awareness Kurse User Experience Security Engineering Cybersecurity Kurse Cyberterrorismus Kurse und nach aktueller Ausschreibung IT Sicherheit Projekt DEFENSE Zero Day und DDOS Schutz Sicherheitssystem für Onlineshops und Server SucoBox Familie Netzwerk Firewall, IDS, und Security Cloud Cybersicherheit Penetrationstest Netzwerke, Software, Applikationen, Web Apps, Schwachstellenanalysen von Produkten Technische Pre-Auditierung, Seitenkanalanalysen und Fehlerangriffe auf eingebettete Systeme Fehlererkennung und Fehlertolerierung in digitalen Schaltungen. Embedded Systems Security Evaluation (Grey-, Black-, Whitebox) Tamper Resistent Strategien. Entwicklung und Weiterentwicklung von Gegenmaßnahmen System- und Anwendungsanalysen Entwicklung von Testszenarien Prüfung auf Datenschutzkonformität von Cloud-Services, Web-Servern etc. IT Forensik und Gegenmaßnahmen Verschlüsselung und Kryptographie IT Sicherheitscheck Anwendungssicherheit Web App Sicherheit Analyse & Beratung Schulung Server Sicherheit für Unternehmen Desktop Sicherheit Browser Security BOX Überwachungsmanagement Kommunikation Sichere Entwicklung und Programmierung Sicher in das Internet Suchvolumenanalyse Partnerschaften Berufsfachschule Informationstechnik Botfrei ev. Verband der Internet Wirtschaft. Weitere Partnerschaften mit Herstellern und Providern.