Aus dem verschlüsselten Nähkästchen: Konfigurationsfehler verhindern Sicherheit

Für die Installation seines SSL/TLS-Zertifikats befolgte Herr K. einen Leitfaden, der sich später eher als Leidfaden herausstellte: Lange Ladezeiten, zeitweise Unerreichbarkeit seiner Website und Mutmaßungen, um Unsicherheiten verwirrten Herrn K. Unser technischer Support flickte mit Herrn K. die Konfigurationsfehler zusammen, um die Daten seiner Websitebesucher tatsächlich zu schützen.

Konfigurationsfehler: Wenn die Konfiguration nicht stimmt, nützt das beste Zertifikat nichts!

Mit der jüngst beschlossenen EU-Datenschutz-Grundverordnung im Nacken wollte Herr K. schon jetzt alles vorbereiten: Er passt die Prozesse in seinem Unternehmen bereits heute schon an, um zum Start der EU-DSGVO bereit zu sein. Das bedeutete für Herrn K. auch, seine Website zu verschlüsseln. Zwar unterhält Herr K. keinen Webshop, aber seinen Kunden steht ein Login-Bereich zur Verfügung, der zur Auftragsabwicklung mit genutzt wird. Da seine Kunden hier auch Kontaktdaten angeben, war ihm das Verschlüsseln seiner Website nicht nur als Wettbewerbsfaktor, sondern eben auch für den Schutz der Daten wichtig.

Herr K. entschied sich für ein SSL/TLS-Zertifikat von einem Anbieter, der höchsten Schutz in wenigen Handgriffen versprach. Herr K. hatte sich ins Thema eingelesen und war von der anfänglichen Überlegung, dass ein domainvalidiertes Zertifikat ausreichen würde, abgekommen. Er entschied sich für die Mittelklasse und bestellte ein organisationsvalidiertes SSL/TLS-Zertifikat. Auf die unterschiedlichen Validierungsstufen sind wir bereits im ersten Beitrag unserer aktuellen Serie eingegangen. Zu seiner Freude existierte ein Installationsleitfaden, den Herr K. Schritt für Schritt durchging. Aber irgendetwas stimmte nicht! Seine Seite lud langsam, zuweilen war sie gar nicht erreichbar, und wirklich sicher schien sie auch nicht zu sein, wie sich beim SSL Server Test von Qualys SSL Labs herausstellte.

Konfigurationsfehler durch veralteten Leitfaden

Als Herr K. sich mit uns in Verbindung setzte, schickte er das Testergebnis des SSL Server-Tests mit, da die Ergebnisse für ihn selbst eher nichtssagend waren. Wir baten Herrn K., uns auch den Leitfaden des SSL/TLS-Zertifikat-Anbieters zu senden. Bei diesem stellte sich heraus, dass er den aktuellen Stand der Technik nicht berücksichtigt – fatal, denn es verlassen sich viele Menschen darauf.

So fehlte leider jeder Hinweis darauf, SSL in der Version 3 auszuschalten. Die Unsicherheit der Verschlüsselungsprotokolle SSLv3 und RC4 ist schon lange bekannt und an Alternativen mangelt es wahrlich nicht. Im Oktober 2015 entschied sich der Suchmaschinenriese Google dazu, sich von diesen unsicheren Standards zu verabschieden. Unsere Empfehlung an Herrn K. lautete ganz klar, sämtliche SSL-Protokolle zu deaktivieren und TLS in den Versionen 1.0, 1.1 sowie 1.2 zu nutzen.

Konfigurationsfehler auch im Schlüsseltausch vermeiden

Weiter begutachteten wir den Schlüsseltausch. Der SSL-Test von Qualys führt dafür Handshake-Simulationen durch. SNI-Support existierte, auf PFS verzichtete Herr K. jedoch bislang. PFS kürzt „Perfect Forward Secrecy“ ab und ist ein Feature, das einen Sitzungsschlüssel („Session Key“) dafür verwendet, Kommunikationen im Nachhinein nicht mehr entschlüsselbar zu machen. Der Session Key wird also nach der Sitzung entsorgt und die Kommunikation bleibt geheim. In unserem Blogbeitrag „Perfect Forward Secrecy konfigurieren“ erfahren Sie weitere Details. Anstelle der einstigen Konfigurationsfehler, die Herr K. machte, folgte er nun den Cipher-Suite-Empfehlungen des IETF.

Weiter erklärten wir Herrn K., dass auch die Laufzeit des Zertifikats, die Vertrauenswürdigkeit der Zertifizierungsstelle und verwendete Hashalgorithmen in die Bewertung einfließen. Herr K. hatte sein SSL/TLS-Zertifikat ansonsten gut ausgewählt, sodass einer besseren Bewertung nur noch wenig im Wege stand. Klar: EV-Zertifikate werden grundsätzlich besser bewertet, das war Herrn K. jedoch schon vorher klar, hier erlaubte er sich zu sparen. Dennoch achtete er auf einen langen privaten Schlüssel, den er selbst auf einem sicheren Rechner speicherte. Er deckte mit seinem Zertifikat sämtliche Namen ab, die er für seine Seite verwenden möchte. Der Teufel steckt aber auch hier im Detail; Konfigurationsfehler machen das beste Zertifikat unnütz.

Cookie Policy: Cookies müssen sicher sein

Herr K. hatte sich dazu entschlossen, Cookies einzusetzen. Eine entsprechende Warnmeldung für seine Websitebesucher hatte er eingerichtet, in seinen Datenschutzbedingungen wies Herr K. brav darauf hin. Jedoch hatte er ein Detail übersehen: auch Cookies müssen sicher gemacht werden, ansonsten sind Man-in-the-Middle-Attacken (MITM-Attacken) möglich. Mit den sogenannten Secure-Flags von Cookies legen Sie fest, ob Cookies über sichere HTTPS- oder auch über unsichere HTTP-Verbindungen übertragen werden. Setzen Sie keine Secure-Flags, passiert, kurz zusammengefasst, das: Ihr Website-Besucher ruft Ihre Site via HTTPS auf und der Cookie macht sich an seine Arbeit, trackt Ihren Besucher also. Später kommt der Website-Besucher zurück, diesmal ruft er Ihre Site jedoch via HTTP auf. Der Cookie jedoch wird immer noch an die Webanwendung gesendet. Ein Angreifer kann den Cookie nun ausspähen, sich als Anwender ausgeben und nun frei agieren.

HSTS arbeitet gegen Konfigurationsfehler

Wie Sie sehen, liegt ein großes Problem in der Möglichkeit, verschlüsselte Websites via HTTP, also über die unsichere Variante, anzusteuern. HSTS steht für „HTTP Strict Transport Security“ und beugt genau diesem Problem vor. Sämtliche modernen Browser verstehen den Standard bereits und erzwingen die HSTS-Nutzung. Mit dem aktivierten HSTS-Zusatz geben (HTTP-)Server vor, eine verschlüsselte Verbindung zu nutzen. Weiter werden Anwendungsprogramme durch den Standard dazu gezwungen, ausschließlich verschlüsselt mit der Website zu kommunizieren. Kurzum: HSTS verhindert HTTP- und fördert HTTPS-Aufrufe.

Erhöhte Latenz durch OCSP

Das SSL/TLS-Zertifikat von Herrn K. enthält eine URL, nämlich die des OCSP-Responders, der von der CA betrieben wird, die sein Zertifikat ausgestellt hat. Diese URL wird von Browsern beim Aufrufen der HTTPS-Site geprüft, um festzustellen, ob das Zertifikat womöglich gesperrt wurde. Es sollen also Missbräuche ausgeschlossen werden. Nachdem die Verbindung mit der Website aufgebaut ist, wird eine weitere Anfrage an den OCSP-Responder gesendet. Schon die Kurzbeschreibung des Vorgangs zeigt, dass der zusätzliche Verbindungsaufbau zum Responder für eine erhöhte Latenz sorgt.

Mit dem Verfahren „OCSP-Stapling“ (die Standardisierung können Sie sich an dieser Stelle anschauen) werden die Probleme, die durch OCSP entstehen, gelöst. Der Webserver bezieht in bestimmten Intervallen, beispielsweise stündlich, eine OCSP-Antwort über das eigene Zertifikat. Diese wird direkt im initialen Handshake zum Browser des Nutzers gesendet. Eine Verbindung zwischen Browser des Users und OCSP-Responder wird unnötig. Die Sicherheit des Verfahrens ist durch die Tatsache gewährleistet, dass die OCSP-Antwort vom OCSP-Responder der CA immer signiert ist und diese Signatur vom Browser verifiziert wird.

HPKP zum weiteren Erhöhen der Sicherheit

Ist ein Zertifikat aus einer Zertifikatskette vertrauenswürdig? – Dieser Frage geht das sogenannte HTTP Public Key Pinning, kurz: HPKP nach. Mittels Public Key Pinning wird festgestellt, wann der öffentliche Schlüssel von einem Zertifikat für einen bestimmten Host geändert wurde. Bei kompromittierten Zertifikaten kann dies vorkommen. Damit wird HPKP zu einem Mechanismus, der die Echtheit von SSL/TLS-Zertifikaten überprüft.

Konfigurationsfehler vermeiden: Diesen Leitfäden können Sie vertrauen

Natürlich ist es nicht das Schlechteste, einem Leitfaden zu vertrauen – jedoch sollte dieser Leitfaden aktuelle Standards berücksichtigen. Vermeiden Sie Konfigurationsfehler durch vertrauensvolle Quellen:

• Best Practice-Leitfaden von Qualys
• „Secure Your Site with HTTPS“ von Google
• „Security/ Server Side TLS“ von Mozilla
• Dokumentation des IETF
• Broschüre über HSTS (inklusive Konfigurationsanleitung)
• Broschüre über HPKP (inklusive Konfigurationsanleitung)
• Infografiken „Maßnahmen zum Schutz gegen unberechtigt ausgestellte Zertifikate“

Allgemeine Empfehlungen zum Vermeiden von Konfigurationsfehlern

Die folgenden Empfehlungen sind allgemein gehalten und dienen damit als Richtlinie. Konfigurationsfehler können Sie damit bereits vermeiden:

• HTTPS: nutzen Sie sichere Verbindungen für alle Webservices.
• automatische Umleitung: um unverschlüsselte Aufrufe zu verhindern, richten Sie eine automatische Umleitung auf die HTTPS-Version Ihrer Site ein.
• TLS-Bibliotheken: setzen Sie auf die neuesten Versionen! Mit der Verwendung von TLS schließen Sie niemanden aus; jedoch schließen Sie potenzielle Angreifer ein, wenn Sie das unsichere SSL verwenden.
• Setzen Sie auf HSTS, um sicherzugehen, dass unverschlüsselte Verbindungen ausgeschlossen werden. Zwei Wege führen dahin: Entweder ergänzen Sie den HSTS-Header, um Browser anzuweisen, nur noch die HTTPS-Version aufzurufen. Oder Sie setzen Ihre Website auf die HSTS Preload-Liste. Diese sagt modernen Browsern, dass sie HTTP-Aufrufe automatisch auf HTTPS umleiten. Googles Liste inkludiert etliche andere Browserlisten; Sie finden sie hier.
• Bestellen Sie SSL/TLS-Zertifikate ausschließlich bei vertrauenswürdigen Stellen.
• Nutzen Sie idealerweise Extended Validation-Zertifikate. Das erhöht das Vertrauen Ihrer Websitebesucher in die Identität Ihrer Site.
• Spätestens seit Heartbleed wissen Sie um die Wichtigkeit der Flexibilität von Zertifizierungsstellen und Zertifikate-Anbietern. Stellen Sie sicher, dass Ihr Anbieter kompromittierte Zertifikate zügig austauscht.
• Setzen Sie auf Maßnahmen wie PFS, um Daten auch im Nachhinein nicht entschlüsselbar werden zu lassen.

Und im Zweifel: machen Sie es wie Herr K. und fragen Sie nach! Heutzutage verfügt nahezu jeder Unternehmer über eine Website. Im Mindesten ist es dann möglich, Newsletter zu abonnieren oder mit dem Unternehmen in Kontakt zu treten – es werden also Kommunikationen stattfinden und diese sind zu schützen. Niemand verlangt von Ihnen, Profi auf dem weiten Feld der Verschlüsselung zu sein. Holen Sie sich deshalb hilfreiche Unterstützung!

Unser Support kommuniziert mit Ihnen auf Augenhöhe und steht für Ihre Fragen bereit. Testen Sie uns – wir freuen uns auf Sie!