F\u00fcr die Installation seines SSL\/TLS-Zertifikats befolgte Herr K. einen Leitfaden, der sich sp\u00e4ter eher als Leidfaden herausstellte: Lange Ladezeiten, zeitweise Unerreichbarkeit seiner Website und Mutma\u00dfungen, um Unsicherheiten verwirrten Herrn K. Unser technischer Support flickte mit Herrn K. die Konfigurationsfehler zusammen, um die Daten seiner Websitebesucher tats\u00e4chlich zu sch\u00fctzen.<\/p>\n
<\/p>\n
Mit der j\u00fcngst 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\u00fcr Herrn K. auch, seine Website zu verschl\u00fcsseln. Zwar unterh\u00e4lt Herr K. keinen Webshop, aber seinen Kunden steht ein Login-Bereich zur Verf\u00fcgung, der zur Auftragsabwicklung mit genutzt wird. Da seine Kunden hier auch Kontaktdaten angeben, war ihm das Verschl\u00fcsseln seiner Website nicht nur als Wettbewerbsfaktor, sondern eben auch f\u00fcr den Schutz der Daten wichtig.<\/p>\n
Herr K. entschied sich f\u00fcr ein SSL\/TLS-Zertifikat von einem Anbieter, der h\u00f6chsten Schutz in wenigen Handgriffen versprach. Herr K. hatte sich ins Thema eingelesen und war von der anf\u00e4nglichen \u00dcberlegung, dass ein domainvalidiertes Zertifikat ausreichen w\u00fcrde, abgekommen. Er entschied sich f\u00fcr die Mittelklasse und bestellte ein organisationsvalidiertes SSL\/TLS-Zertifikat. Auf die unterschiedlichen Validierungsstufen sind wir bereits im ersten Beitrag unserer aktuellen Serie<\/a> eingegangen. Zu seiner Freude existierte ein Installationsleitfaden, den Herr K. Schritt f\u00fcr 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<\/a> herausstellte.<\/p>\n Als Herr K. sich mit uns in Verbindung setzte, schickte er das Testergebnis des SSL Server-Tests mit, da die Ergebnisse f\u00fcr 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\u00fccksichtigt \u2013 fatal, denn es verlassen sich viele Menschen darauf.<\/p>\n So fehlte leider jeder Hinweis darauf, SSL in der Version 3 auszuschalten. Die Unsicherheit der Verschl\u00fcsselungsprotokolle SSLv3 und RC4 ist schon lange bekannt und an Alternativen mangelt es wahrlich nicht. Im Oktober 2015 entschied sich der Suchmaschinenriese Google dazu<\/a>, sich von diesen unsicheren Standards zu verabschieden. Unsere Empfehlung an Herrn K. lautete ganz klar, s\u00e4mtliche SSL-Protokolle zu deaktivieren und TLS in den Versionen 1.0, 1.1 sowie 1.2 zu nutzen.<\/p>\n Weiter begutachteten wir den Schl\u00fcsseltausch. Der SSL-Test von Qualys f\u00fchrt daf\u00fcr Handshake-Simulationen durch. SNI-Support existierte, auf PFS verzichtete Herr K. jedoch bislang. PFS k\u00fcrzt „Perfect Forward Secrecy“ ab und ist ein Feature, das einen Sitzungsschl\u00fcssel („Session Key“) daf\u00fcr verwendet, Kommunikationen im Nachhinein nicht mehr entschl\u00fcsselbar zu machen. Der Session Key wird also nach der Sitzung entsorgt und die Kommunikation bleibt geheim. In unserem Blogbeitrag „Perfect Forward Secrecy konfigurieren“<\/a> erfahren Sie weitere Details. Anstelle der einstigen Konfigurationsfehler, die Herr K. machte, folgte er nun den Cipher-Suite-Empfehlungen des IETF.<\/p>\n Weiter erkl\u00e4rten wir Herrn K., dass auch die Laufzeit des Zertifikats, die Vertrauensw\u00fcrdigkeit der Zertifizierungsstelle und verwendete Hashalgorithmen in die Bewertung einflie\u00dfen. Herr K. hatte sein SSL\/TLS-Zertifikat ansonsten gut ausgew\u00e4hlt, sodass einer besseren Bewertung nur noch wenig im Wege stand. Klar: EV-Zertifikate werden grunds\u00e4tzlich besser bewertet, das war Herrn K. jedoch schon vorher klar, hier erlaubte er sich zu sparen. Dennoch achtete er auf einen langen privaten Schl\u00fcssel, den er selbst auf einem sicheren Rechner speicherte. Er deckte mit seinem Zertifikat s\u00e4mtliche Namen ab, die er f\u00fcr seine Seite verwenden m\u00f6chte. Der Teufel steckt aber auch hier im Detail; Konfigurationsfehler machen das beste Zertifikat unn\u00fctz.<\/p>\n Herr K. hatte sich dazu entschlossen, Cookies einzusetzen. Eine entsprechende Warnmeldung f\u00fcr seine Websitebesucher hatte er eingerichtet, in seinen Datenschutzbedingungen wies Herr K. brav darauf hin. Jedoch hatte er ein Detail \u00fcbersehen: auch Cookies m\u00fcssen sicher gemacht werden, ansonsten sind Man-in-the-Middle-Attacken (MITM-Attacken) m\u00f6glich. Mit den sogenannten Secure-Flags von Cookies legen Sie fest, ob Cookies \u00fcber sichere HTTPS- oder auch \u00fcber unsichere HTTP-Verbindungen \u00fcbertragen 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\u00e4ter kommt der Website-Besucher zur\u00fcck, 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\u00e4hen, sich als Anwender ausgeben und nun frei agieren.<\/p>\n Wie Sie sehen, liegt ein gro\u00dfes Problem in der M\u00f6glichkeit, verschl\u00fcsselte Websites via HTTP, also \u00fcber die unsichere Variante, anzusteuern. HSTS steht f\u00fcr „HTTP Strict Transport Security“ und beugt genau diesem Problem vor. S\u00e4mtliche modernen Browser verstehen den Standard bereits und erzwingen die HSTS-Nutzung. Mit dem aktivierten HSTS-Zusatz geben (HTTP-)Server vor, eine verschl\u00fcsselte Verbindung zu nutzen. Weiter werden Anwendungsprogramme durch den Standard dazu gezwungen, ausschlie\u00dflich verschl\u00fcsselt mit der Website zu kommunizieren. Kurzum: HSTS verhindert HTTP- und f\u00f6rdert HTTPS-Aufrufe.<\/p>\n Das SSL\/TLS-Zertifikat von Herrn K. enth\u00e4lt eine URL, n\u00e4mlich 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\u00fcft, um festzustellen, ob das Zertifikat wom\u00f6glich gesperrt wurde. Es sollen also Missbr\u00e4uche 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\u00e4tzliche Verbindungsaufbau zum Responder f\u00fcr eine erh\u00f6hte Latenz sorgt.<\/p>\n Mit dem Verfahren „OCSP-Stapling“ (die Standardisierung k\u00f6nnen Sie sich an dieser Stelle anschauen<\/a>) werden die Probleme, die durch OCSP entstehen, gel\u00f6st. Der Webserver bezieht in bestimmten Intervallen, beispielsweise st\u00fcndlich, eine OCSP-Antwort \u00fcber 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\u00f6tig. Die Sicherheit des Verfahrens ist durch die Tatsache gew\u00e4hrleistet, dass die OCSP-Antwort vom OCSP-Responder der CA immer signiert ist und diese Signatur vom Browser verifiziert wird.<\/p>\n Ist ein Zertifikat aus einer Zertifikatskette vertrauensw\u00fcrdig? – Dieser Frage geht das sogenannte HTTP Public Key Pinning, kurz: HPKP nach. Mittels Public Key Pinning wird festgestellt, wann der \u00f6ffentliche Schl\u00fcssel von einem Zertifikat f\u00fcr einen bestimmten Host ge\u00e4ndert wurde. Bei kompromittierten Zertifikaten kann dies vorkommen. Damit wird HPKP zu einem Mechanismus, der die Echtheit von SSL\/TLS-Zertifikaten \u00fcberpr\u00fcft.<\/p>\n Nat\u00fcrlich ist es nicht das Schlechteste, einem Leitfaden zu vertrauen \u2013 jedoch sollte dieser Leitfaden aktuelle Standards ber\u00fccksichtigen. Vermeiden Sie Konfigurationsfehler durch vertrauensvolle Quellen:<\/p>\n Die folgenden Empfehlungen sind allgemein gehalten und dienen damit als Richtlinie. Konfigurationsfehler k\u00f6nnen Sie damit bereits vermeiden:<\/p>\n Und im Zweifel: machen Sie es wie Herr K. und fragen Sie nach! Heutzutage verf\u00fcgt nahezu jeder Unternehmer \u00fcber eine Website. Im Mindesten ist es dann m\u00f6glich, Newsletter zu abonnieren oder mit dem Unternehmen in Kontakt zu treten \u2013 es werden also Kommunikationen stattfinden und diese sind zu sch\u00fctzen. Niemand verlangt von Ihnen, Profi auf dem weiten Feld der Verschl\u00fcsselung zu sein. Holen Sie sich deshalb hilfreiche Unterst\u00fctzung!<\/p>\n Unser Support kommuniziert mit Ihnen auf Augenh\u00f6he und steht f\u00fcr Ihre Fragen bereit. Testen Sie uns<\/a> \u2013 wir freuen uns auf Sie!<\/p>\nKonfigurationsfehler durch veralteten Leitfaden<\/h3>\n
Konfigurationsfehler auch im Schl\u00fcsseltausch vermeiden<\/h3>\n
Cookie Policy: Cookies m\u00fcssen sicher sein<\/h3>\n
HSTS arbeitet gegen Konfigurationsfehler<\/h3>\n
Erh\u00f6hte Latenz durch OCSP<\/h3>\n
HPKP zum weiteren Erh\u00f6hen der Sicherheit<\/h3>\n
Konfigurationsfehler vermeiden: Diesen Leitf\u00e4den k\u00f6nnen Sie vertrauen<\/h3>\n
\n
Allgemeine Empfehlungen zum Vermeiden von Konfigurationsfehlern<\/h3>\n
\n