====== SSL und TLS ======
[[wpde>Transport Layer Security|Transport Layer Security (TLS) oder Secure Sockets Layer (SSL)]] ist ein [[security:verschlüsselung#hybride verschlüsselung|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 ((siehe [[http://www.heise.de/newsticker/meldung/DigiNotar-Hack-Kritische-Infrastruktur-war-unzureichend-geschuetzt-1337378.html|DigiNotar-Hack: Kritische Infrastruktur war unzureichend geschützt]])).


  * [[eigene CA für SSL]]

**Testbefehle:**
<code bash>
openssl s_client -connect SERVER:443
nmap -p 443 --script ssl-enum-ciphers SERVER
</code>

===== Links =====

  * [[http://de.wikipedia.org/wiki/Transport_Layer_Security#Funktionsweise|genaue Funktionsweise des SSL-Verbindungsaufbaus]]
  * **[[https://www.ssllabs.com/ssltest/|SSLtest]]**
  * [[https://internet.nl/|diverse Tests (auch E-Mail)]]
  * **[[https://sslcheck.globalsign.com|SSLCheck @ globalsign]]**
  * [[https://cc.dcsec.uni-hannover.de/|Cipher Suites die der Browser unterstützt]]
  * [[http://serversniff.de/content.php?do=ssl|SSL-Serversniff]]: Zeigt Informationen über das SSL-Zertifikat von SSL-Servern an und prüft, welche Verschlüsselungsverfahren der SSL-Server unterstützt.
  * [[http://www.heise.de/security/artikel/E-Mail-Verschluesselung-austesten-785451.html|E-Mail-Verschlüsselung austesten - Diagnose von POP3, IMAP und SMTP via SSL]]
  * [[https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls|Mitigating the BEAST attack on TLS]]
  * [[http://www.tecchannel.de/sicherheit/identity_access/2039671/grundlagen_und_hintergruende_workshop_ssl_stripping_erkennen_und_bekaempfen/|Workshop: SSL Stripping erkennen und bekämpfen]]
  * [[http://www.heise.de/security/meldung/Heartbleed-und-das-Sperrproblem-von-SSL-2174254.html|Heartbleed und das Sperrproblem von SSL]]


===== Man-in-the-middle Attacken gegen 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 [[http://www.monkey.org/~dugsong/dsniff/|dsniff]] können die Prozedur automatisieren indem z.B. die [[netzwerke: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):

  - 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.
  - 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 [[server:proxyserver#SSL-Proxies]] verwendet, ist dies sogar nötig.
  - 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.
  - 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 [[netzwerke:DNS]]-Anfrage die man im herkömmlichen [[netzwerke:DNS]] nicht verifizieren kann. Lösung: [[wpde>DNSSEC]] einsetzen.

:!: Der Vortrag "[[http://www.linux-magazin.com/videos/ssl_datenuebertragung_lauschangriff|SSL-Datenübertragung - Lauschangriff]]" demonstriert einen erfolgreichen Angriff. 


===== Zwischenzertifikate =====

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.


^ Serversoftware ^ Konfigurationsdirektive ^ Testbefehl ^
| Apache (Webserver) | ''SSLCACertificateFile'' gibt die Datei mit den Zwischenzertifikaten an. | <code bash>openssl s_client -connect SERVER:443</code> **Ablaufdatum**:  <code bash>openssl s_client -connect SERVER:443 | openssl x509 -noout -dates</code> |
| Dovecot | normale Direktive mit Zwischenzertifikaten in Reihenfolge von unten (zuerst) nach oben (zuletzt) | pop3s: <code bash>openssl s_client -connect SERVER:995</code>imaps: <code bash>openssl s_client -connect SERVER:995</code> |
| Postfix (SMTP) | normale Direktive mit Zwischenzertifikaten in Reihenfolge von unten (zuerst) nach oben (zuletzt) | smtp over SSL: <code bash>openssl s_client -connect SERVER:465</code> SMTP mit starttls: <code bash>openssl s_client -connect SERVER:25 -starttls smtp</code> |
| Pure-ftpd (FTP-Server)  | normale Direktive mit Zwischenzertifikaten in Reihenfolge von unten (zuerst) nach oben (zuletzt)  | <code bash>openssl s_client -connect [your-hostname]:21 -starttls ftp</code> |


  * [[http://www.geeklab.info/2011/01/how-to-use-chained-ssl-certificates/|How to use chained SSL certificates]]
  * [[https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=AR1372|Download the Intermediate CA bundle for Thawte SSL123 certificates]]



===== SSL Zertifikate für Webserver =====

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

Anbieter:
  * [[http://www.verisign.de/|Verisign]]
  * [[http://www.thawte.de/|Thawte]].
  * [[http://www.geotrusteurope.com/de/ssl-zertifikat/index.htm|Geotrust]]
  * [[http://www.cybertrust.com/|Cybertrust]]
  * [[http://www.entrust.com/|Entrust]]
  * [[http://www.comodo.com/|Comodo]]
  * [[http://www.identrust.com/|Identrust]]


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

^ Anbieter ^ 1 Jahr ^ 2 Jahre ^ 3 Jahre ^
| Günstiger sind [[http://www.psw.net/ssl.cfm|PSW]] ("Bronze" RapidSSL/GeoTrust) | 29€ | 49€ | 69€ | 
| [[http://www.instantssl.com/|InstantSSL]] |  |  |  | 
| [[http://www.df.eu/de/ssl-zertifikate/produktdetails/|domainfactory]] | ab 20€ | - | - |

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

==== Alternativen ====
  - selbst-signieren -> dann hat man aber auf jeden Fall immer mindestens eine Warnmeldung.
  - [[http://www.cacert.org/|CaCert]] - [[http://wiki.cacert.org/wiki/InclusionStatus|Integration nur in einigen Browsern bisher]] (z.B. nicht im [[software:browser#Internet Explorer]])
  - [[https://cert.startcom.org/Startcom]] - ist in [[https://cert.startcom.org/?app=140|einigen Browsern]] integriert

==== Zertifikate konvertieren ====

  * DER zu PEM <code bash>openssl x509 -inform der -in certificate.cer -out certificate.pem</code>
  * PEM zu DER <code bash>openssl x509 -outform der -in certificate.pem -out certificate.der</code>
  * PKCS#12 Datei (.pfx .p12) mit privatem und Zertifikaten nach PEM: <code bash>openssl pkcs12 -in keyStore.pfx -out keyStore.pem -nodes</code>
  * PEM-Zertifikat and privater Schlüssel nach PKCS#12 Datei (.pfx .p12): <code bash>openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt</code>

==== Zertifikat erstellen ====
[[apache:ssl#ssl-zertifikat_fuer_eine_zertifizierungsstelle_erstellen|Anleitung für Apache-Webserver]]



===== Liste der Root-Zertifikate =====
Bei [[linux: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''.


===== SSLscan =====

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): <code bash>sslscan WWWSERVER | grep Accepted</code>


Video-Anleitung (Download und Benutzung): [[https://www.youtube.com/watch?v=pN2ERGrJ_Wk|Windows: Unsichere Verschlüsselung finden]] [[https://www.youtube.com/watch?v=a11fio-H6Kc|Ubuntu: Unsichere Verschlüsselung finden]] | 

<file>                   _
           ___ ___| |___  ___ __ _ _ __
          / __/ __| / __|/ __/ _` | '_ \
          \__ \__ \ \__ \ (_| (_| | | | |
          |___/___/_|___/\___\__,_|_| |_|

                  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
</file>

===== HSTS-Einstellungen löschen =====

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