SSL und TLS

Transport Layer Security (TLS) oder Secure Sockets Layer (SSL) ist ein hybrides Verschlüsselungsprotokoll für Datenübertragungen im Internet. TLS 1.0, 1.1 und 1.2 sind die standardisierten Weiterentwicklungen von SSL 3.0 (TLS 1.0 steht neu für SSL 3.1). SSL wird also nun unter dem Namen TLS weiterentwickelt. Hier wird die Abkürzung SSL für beide Bezeichnungen verwendet.

Zentral für die Sicherheit von verschlüsselten Verbindungen ist die Integrität der Stellen (Certificate Authorities = CAs) die Zertifikate ausgeben. Einbrüche bei diesen Anbieter führen dazu, dass gültige Zertifikate von unberechtigten Personen erstellt und für das Ausspähen dritter verwendet können ¹⁾.

• eigene CA für SSL

Testbefehle:

openssl s_client -connect SERVER:443
nmap -p 443 --script ssl-enum-ciphers SERVER

• genaue Funktionsweise des SSL-Verbindungsaufbaus
• SSLtest
• diverse Tests (auch E-Mail)
• SSLCheck @ globalsign
• Cipher Suites die der Browser unterstützt
• SSL-Serversniff: Zeigt Informationen über das SSL-Zertifikat von SSL-Servern an und prüft, welche Verschlüsselungsverfahren der SSL-Server unterstützt.
• E-Mail-Verschlüsselung austesten - Diagnose von POP3, IMAP und SMTP via SSL
• Mitigating the BEAST attack on TLS
• Workshop: SSL Stripping erkennen und bekämpfen
• Heartbleed und das Sperrproblem von SSL

Man-in-the-middle (MITM)-Attacken sind im Zusammenhang mit SSL ein Problem, besonders wenn der Angreifer im gleichen (lokalen) Netz ist. Beide Partner glauben mit dem jeweils anderen Daten auszutauschen, dabei geht der Verkehr tatsächlich über den Angreifer. Der Client hat mit dem Angreifer und der Angreifer mit dem Server jeweils Verbindungen aufgebaut. Der Angreifer gibt sich jeweils als Partner aus und schickt dabei die Daten (ausspioniert) an den eigentlichen Adressaten weiter. Programme wie dsniff können die Prozedur automatisieren indem z.B. die DNS-Anfragen des Clients mit einer falschen Antwort (einer IP die vom Angreifer kontrolliert wird) beantwortet.

Da SSL auch auf einer Serverauthentifizierung basiert, ist es allerdings nicht unbemerkt möglich sich als Server auszugeben, da der Angreifer nicht im Besitz des geheimen Schlüssels des Servers ist. Der Angreifer kann vier Wege gehen (sortiert von 1. leicht bis 4. schwer):

1. ein selbst-signiertes Zertifikat oder ein Zertifikat einer anderen Domain vorzeigen. Die Folge ist eine Fehlermeldung im Browser (Zertifikat nicht vertrauenswürdig, passt nicht zur Domain) die aber viele Nutzer leichtfertig wegklicken.
2. den Client überzeugen, die eigene Root-CA (Zertifizierungsstelle) zu akzeptieren. Falls er gelingt ist der Angreifer in der Lage für sämmtliche Domains eigene (gültige und ohne Fehlermeldung akzeptierte) Zertifikate auszustellen. Das kann insbesondere bei (ungesicherten) öffentlichen Rechern sehr erfolgreich sein. Wenn man transparente SSL-Proxies verwendet, ist dies sogar nötig.
3. eine Root-CA (Zertifizierungsstelle) dazu bewegen, ein Zertifikat für die Zielseite auszustellen. Das sollte schwer sein, denn jede Zertifizierungsstelle ist angehalten Zertifizierungsanträge (und die Identität des Antragstellers!) genau zu überprüfen.
4. ein Zertifikat einer anerkannten Root-CA (Zertifizierungsstelle) zum Ausstellen von Zertifikaten benutzen. Das setzt vorraus, das man sich vorher ein solches gestohlen hat (z.B. durch einen korrupten Mitarbeiter).

Die einzige Lösung ist sowohl Server- als auch Clientauthentifizierung (letztere nicht durch Passwort). Das Problem ist auch eher die DNS-Anfrage die man im herkömmlichen DNS nicht verifizieren kann. Lösung: DNSSEC einsetzen.

Der Vortrag „SSL-Datenübertragung - Lauschangriff“ demonstriert einen erfolgreichen Angriff.

Darunter versteht man Zertifikate die nicht direkt unter einem Stammzertifikat stehen, sondern noch ein- oder mehrere Zertifikate dazwischen haben, die dann eine Zertifizierungskette bilden. Sie werden auch auch intermediate bzw. chained certificates genannt.

Damit diese Zwischenzertifikate auch korrekt funktionieren, muss auf dem Server die ganze Kette bekannt sein.

openssl s_client -connect SERVER:443

openssl s_client -connect SERVER:443 | openssl x509 -noout -dates

openssl s_client -connect SERVER:995

openssl s_client -connect SERVER:995

openssl s_client -connect SERVER:465

openssl s_client -connect SERVER:25 -starttls smtp

openssl s_client -connect [your-hostname]:21 -starttls ftp

• How to use chained SSL certificates
• Download the Intermediate CA bundle for Thawte SSL123 certificates

Wichtig ist das eine Zertifizierungsautorität ohne Warnung („Zertifizierungsstelle root CA unbekannt“) in den wichtigen Clients (Browser Mailprogramme etc.) akzeptiertz wird.

Anbieter:

• Verisign
• Thawte.
• Geotrust
• Cybertrust
• Entrust
• Comodo
• Identrust

Günstiger Angebote funktionieren jedoch auch in den wichtigsten Clients:

Grund: Die Aussteller führen eine recht genaue Identitätsprüfung durch und lassen sich ihre besondere Stellung dann natürlich auch versilbern.

1. selbst-signieren → dann hat man aber auf jeden Fall immer mindestens eine Warnmeldung.
2. CaCert - Integration nur in einigen Browsern bisher (z.B. nicht im Internet Explorer)
3. https://cert.startcom.org/Startcom - ist in einigen Browsern integriert

• DER zu PEM

  openssl x509 -inform der -in certificate.cer -out certificate.pem

• PEM zu DER

  openssl x509 -outform der -in certificate.pem -out certificate.der

• PKCS#12 Datei (.pfx .p12) mit privatem und Zertifikaten nach PEM:

  openssl pkcs12 -in keyStore.pfx -out keyStore.pem -nodes

• PEM-Zertifikat and privater Schlüssel nach PKCS#12 Datei (.pfx .p12):

  openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

Anleitung für Apache-Webserver

Bei Linux erkennt openSSL Root-zertifikate die unter /usr/share/ca-certificates liegen und die Endung .crt besitzen. Durch den Aufruf von

dpkg-reconfigure ca-certificates

wird die Liste unter /etc/ssl/certs aktualisiert. Dies sind vor allem symbolische Links auf die Dateien in /usr/share/ca-certificates.

Das Programm SSLscan zeigt die unterstützten Verschlüsselungsmethoden und ob der Verbindungsaufbau klappen würde (ja? „Accepted“ nein? nein? „Failed“ oder falls der Server diese Methode nicht zulässt („Rejected“).

Falls die ganzen Ausgabe nicht benötigt wird sondern nur die funktionierenden Algorithmen („WWWSERVER“ im folgenden durch einen korrekten Servername ersetzen):

sslscan WWWSERVER | grep Accepted

Video-Anleitung (Download und Benutzung): Windows: Unsichere Verschlüsselung finden Ubuntu: Unsichere Verschlüsselung finden |

                   _
           ___ ___| |___  ___ __ _ _ __
          / __/ __| / __|/ __/ _` | '_ \
          \__ \__ \ \__ \ (_| (_| | | | |
          |___/___/_|___/\___\__,_|_| |_|

                  Version 1.8.2
             http://www.titania.co.uk
        Copyright Ian Ventura-Whiting 2009

Testing SSL server WWWSERVER on port 443

  Supported Server Cipher(s):

    Failed    SSLv3  256 bits  ECDHE-ECDSA-AES256-SHA384
    Rejected  SSLv3  256 bits  ECDHE-RSA-AES256-SHA
    ...
    Accepted  TLSv1  128 bits  DHE-RSA-AES128-SHA

Chrome/Chromium: chrome://net-internals/#hsts → Delete domain security policies → Domain: https://webserver.domain.tld → Delete