Netz - Rettung - Recht

SSL-Protokolle

Unter anderem lassen sich dort die Protokolle angeben, die der Server anbieten soll. “SSL” (bzw. “TLS) steht nämlich nicht für ein einzelnes Übertragungsprotokoll, sondern für eine ganze Protokollfamilie, nämlich

• SSL 2.0
• SSL 3.0
• TLS 1.0
• TLS 1.1
• TLS 1.2

TLS 1.3 wird derzeit gerade entwickelt.

Gegen SSLv2 und SSLv3 sind mögliche Angriffe bekannt, weshalb ein Server diese Protokolle nach Möglichkeit nicht mehr anbieten sollte, soweit nicht ältere Software darauf noch angewiesen ist. Firefox, Chrome und Safari unterstützen mindestens TLS 1.0 von jeher, Internet Explorer kann das jedenfalls ab IE7 und Opera ab Version 5 - das sollte also in der Regel kein Grund sein, darauf zu verzichten.

So kann das dann aussehen:

SSLProtocol all -SSLv2 -SSLv3

Der Apache 2.4 (bzw. die verwendete OpenSSL-Version) unter Debian Jessie bietet SSLv2 ohnehin nicht mehr an; dort genügt es also, SSLv3 zu verbieten.

Algorithmen

Für den Schlüsselaustausch zwischen Server und Client müssen die beiden sich auf eine Methode einigen und dann noch auswählen, mit welchem Chiffrieralgorithmus die Verbindung gesichert werden soll.

Mathematik und Kryptographie entwickeln sich ebenso fort wie sich die Leistungsfähigkeit von Computern steigert - was gestern noch ausreichend sicher war, ist es morgen vielleicht nicht mehr. Es lohnt sich also, auch hierüber ein wenig nachzudenken - was nützt die schönste verschlüsselte Verbindung, wenn sie trivial zu knacken ist, nicht nur durch Geheimdienste und Strafverfolgungsbehörden, sondern auch durch andere, böswillige Dritte?

Nun kann man sich entweder selbst in das Thema einlesen - und sollte das auch, wenn man es interessant findet oder es einem wichtig ist -, oder man vertraut Lösungen, die Dritte einem empfehlen. Egal was man tut, man sollte die SSL-Verbindung danach testen lassen und - ggf. - die Last im Auge behalten, wenn man aufwändigere, aber sicherere Algorithmen anbietet und an den Anfang der Liste stellt.

Eine Möglichkeit, die angebotenen Cipher Suites zu beschränken und ihre Reihenfolge zu sortieren, wäre die folgende:

SSLCipherSuite 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH:EDH:HIGH:+RSA:+SHA:MEDIUM:!aNULL:!MD5:!eNULL:!LOW:!EXP:!DSS:!PSK:!SRP:!RC4:!CAMELLIA'

(Ich mache hier copy & paste - Kommentare dazu gerne, nun ja, in den Kommentaren.)

Server und Client einigen sich dann auf eine der von beiden unterstützten Möglichkeiten, normalerweise anhand der Präferenzen, die der Client her, auf Wunsch aber auch in der Reihenfolge, in der die Cipher Suites vorstehend - also in der Serverkonfiguration - angegeben sind. Für letzteres ist der Parameter SSLHonorCipherOrder auf “on” zu setzen:

SSLHonorCipherOrder on

Forward secrecy

Unter Forward secrecy versteht man (vereinfacht ausgedrückt), dass der zwischen Server und Client ausgehandelte temporäre Sitzungsschlüssel, mit dem Datenverbindung verschlüsselt wird, sich nicht aus den verwendeten Zertifikaten ableiten lässt. Ohne forward secrecy kann jemand, der sich den privaten Schlüssel des Servers verschafft, nicht nur alle danach aufgebauten Verbindungen live mitlesen, er kann ggf. auch alle vorherigen (!) Verbindungen nachträglich entschlüsseln, wenn er sie mitgeschnitten hat. Die Gefährdung der zukünftigen Verbindungen kann man durch einen Schlüsseltausch verhindern, wenn und sobald man bemerkt hat, dass der private Schlüssel des Servers kompromittiert wurde. Man kann ohne forward secrecy aber nicht verhindern, dass aufgezeichnete frühere Verbindungen komplett entschlüsselbar werden.

Nicht jeder für den Schlüsselaustausch verwendbare Algorithmus bietet forward secrecy; in dem oben gegebenen Beispiel stehen die Algorithmen, die es tun, aber vorne in der Liste (DHE und ECDHE).

Weitere Parameter und Einstellungsmöglichkeiten

Das Thema SSL/TLS ist komplex, und ich bin kein Spezialist dafür; daher kann ich hier nur darauf verweisen, dass es weitere, potentiell relevante Parameter gibt, die sich der Dokumentation und einschlägigen Webseiten entnehmen lassen.

Debian bietet zudem in den Dateien /etc/apache2/mods-available/ssl.conf (globale Konfiguration) und /etc/apache2/sites-available/default-ssl (Konfiguration pro virtual host) einigermaßen umfangreiche Kommentare zur Erläuterung einiger (mutmaßlich: der wichtigsten) Optionen an.

Eine soll hier noch erwähnt werden: SSLStrictSNIVHostCheck. “Off” bedeutet, dass ein Client, der kein SNI beherrscht, dann eben immer das Zertifikat des Default-vhost präsentiert bekommt, das dann in der Regel nicht zum Domainnamen passt, den er aufrufen wollte. “On” bedeutet, dass diese Clients dann nicht - via SSL - auf den entsprechenden vhost oder - wenn es in der Serverkonfiguration oder im Default-vhost gesetzt wird - auf irgendeinen vhost zugreifen können.

Weitere Überlegungen

Neben der SSL-Konfiguration sollte der sicherheitsbewusste Serverbertreiber bzw. Webapplikationsentwickler auch noch einige andere Themen im Blick behalten:

• Werden Cookies so gesetzt, dass ihr Inhalt nur über eine veschlüsselte Verbindung an den Server gesandt wird?
  Stichwort: secure cookie

• Empfiehlt es sich, den Server bestimmte sicherheitsrelevante HTTP-Header übertragen zu lassen, und welche Bedeutung haben diese jeweils?
  Stichwort: security (related) headers

• Wie ist sichergestellt, dass ein abhanden gekommenes oder aus anderen Gründen widerrufenes Zertifikat nicht mehr als gültig akzeptiert wird? Stichworte: Certificate Revocation List (CRL) und Online Certificate Status Protocol (OCSP)

Zu dem angerissenen Thema der HTTP-Header gehört u.a. auch HTTP Strict Transport Security, kurz HSTS, mit dem der Server dem Client mitteilt, dass er derzeit und auch für die Zukunft (jedenfalls in dem durch den Server genannten Zeitraum) die Verbindung zu diesem Hostnamen (“Domain”) nur per HTTPS herstellen soll.

Wie ich bereits mehrfach betonte: ein weites Feld, und nicht unbedingt meines.

SSL-Verbindungen testen und bewerten

SSL Labs bietet einen Onlinetest für die Konfiguration des Servers und des Browsers an. Ruft man den Test (bspw.) für dieses Blog auf, werden alle möglichen Parameter getestet - ja, das dauert eine Weile - und dann mit einer Schulnote (im amerikanischen System) von A-F bewertet, wobei A die beste, F die schlechteste Note darstellt. Außerdem erhält man eine Vielzahl von auch mit Links hinterlegten Hinweisen auf Schwachstellen und Verbesserungsmöglichkeiten.

Wer lieber auf der Kommandozeile arbeitet, lädt sich am besten testssl.sh von Dirk Wetter herunter.

Wer hingegen wissen will, welche sicherheitsrelevanten HTTP-Header sein Server überträgt, ist bei securityheaders.io gut aufgehoben. Auch hier gibt es Schulnoten zur Bewertung.

Auch SSL-Tools bietet eine Vielzahl von Test, auch für Mailserver, hat allerdings offenbar noch die eine oder andere Schwäche jedenfalls im User Interface …

Disclaimer

Die Einzelheiten rund um Protokolle, Algorithmen und Parameter, sozusagen die Eingeweise der TLS-Implementationen, sind weit davon entfernt, mein Spezialgebiet zu sein. Dankenswerterweise hatte ich kompetente Korrekturleser, aber etwaiger verbliebener Blödsinn bleibt mein Verschulden und mag in den Kommentaren korrigiert werden, in denen ich auch gerne Ergänzungen entgegennehme.