# Kurze Einführung zur Verbindungssicherheit im Web Vortrag zum TYPO3 Usergroup TiROL Treffen am 2. August 2018 (c) Clemens Riccabona; https://www.Riccabona.IT/ ## Einleitung Mittlerweile kann wohl jeder vernünftig ein Zertifikat installieren. Meist kommt let's encrypt zum Einsatz. Das ist häufig völlig ausreichend. Wichtig: unbedingt kontrollieren, ob die automatisierte Verlängerung funktioniert, sonst kann es zu abgelaufenen Zertifikaten kommen, und das ist unangenehm. Heute gibt es aber neben dem simplen Zertifikat noch etliche andere, zusätzliche oder darauf aufbauende Sicherheitsfeatures. DNSSEC, DANE, DoH und DoT (kommen zum Teil erst). Und vorallem: es sollten auch die passenden HTTP Header gesetzt werden! ## DNS Namensauflösung - Erklärung: was ist DNS, wie funktioniert es prinzipiell. Leider kennen sich viele Administratoren und DevOps nur sehr unzureichend mit DNS aus. Uns interessiert diesfalls nur DNSSEC. Das kennen noch weniger. DANE würde den Rahmen des Vortrags sprengen, es wird aber kurz erwähnt. ### DNSSEC DNSSEC ist ein asymmetrisches Kryptosystem mit dem Signaturen erstellt und mit den Domaindaten verknüpft werden können um diese DNS Daten auf Ihre Authentizität überprüfen zu können. Man benötigt dazu Nameserver, die DNSSEC unterstützen, und muss die generierten Signaturwerte in die Domain eintragen, direkt bei der Registrierungsstelle bzw. dem Registrar oder Reseller. Fast alle Registrierungsstellen unterstützen DNSSEC in der einen oder anderen Form. Eine mir bekannte Ausnahme: nic.it * Sicher: https://dnssec-debugger.verisignlabs.com/typo3.usergroup.tirol * Unsicher: https://dnssec-debugger.verisignlabs.com/www.tirol.gv.at ### DNS ist zur Zeit unverschlüsselt Zur Zeit findet quasi jede DNS-Anfrage im Internet plain, also unverschlüsselt statt, über UDP mit Port 53 Daher ist DNSSEC auch so wichtig (z.B. Cache-Poisioning). Zur Verschlüsselung der DNS Anfragen gibt es zur Zeit zwei Ansätze, DoT und DoH, die als Ergänzung zu DNSSEC und DANE gesehen werden sollten. ### DNS over TLS (DoT) DoT bedeutet: Die Namensauflösung selbst wird transportverschlüsselt. Nachteil: der DNS over TLS Traffic kann weiterhin leicht identifiziert und blockiert oder umgeleitet werden. ### DNS over HTTPS (DoH) Derzeit noch nicht standardisiert, das ist aber gerade in Arbeit. Dabei wird die DNS Anfrage über HTTPS zusammen mit anderen Anfragen geschickt. Vorteil: es wird sehr schwierig, den Traffic der durch DNS Anfragen ausgelöst wird vom übrigen HTTPS Traffic zu unterscheiden. Derzeit werden zwei Varianten diskutiert: * Centralized Firefox beispielsweise will alle DNS Anfragen über DoH an die Server von Cloudflare schicken. Hier entsteht ein "Single Point of Failure". Problematisch auch in diesem Fall, dass Cloudflare ein US-amerikanisches Unternehmen ist, Privacy kann damit IMHO nur unzureichend garantiert werden. * Decentralized Dabei könnte jeder Webserver gleich bestimmte DNS Daten via HTTPS mitliefern, also vorallem jene "externer" Links, also für Links auf Seiten die nicht auf diesem Server gehostet werden. Das heisst, dass potentiell jeder Webserver zugleich auch Nameserver wird. Das ganze nennt die IETF "Resolver-less name resolution". Nachlese unter anderem: https://www.heise.de/newsticker/meldung/IETF-DNS-ueber-HTTPS-wird-zum-Standard-4119942.html ## SSL/TLS - Transport Layer Security ### TLS - eine "neue Version" von SSL Beginnend mit Version 3.1 von SSL wurde die neue Bezeichnung TLS eingeführt. SSL 3.1 gibt es also offiziell nicht, stattdessen heisst diese Version TLS 1.0. Warum überhaupt TLS. (Sicherheit, Let's encrypt, Chrome, Google) ### Header Testen mit Nützliche Webseiten zum Testen der eigenen TLS Implementierung: * https://securityheaders.com/ by Scott Helme * https://www.ssllabs.com/ssltest/ by Qualys * Sehr umfangreiches Tool zum Testen: https://www.htbridge.com/websec/ Nachlese: * https://www.heise.de/ct/ausgabe/2018-14-DNS-mit-Privacy-und-Security-vor-dem-Durchbruch-4079547.html * https://www.heise.de/newsticker/meldung/IETF-DNS-ueber-HTTPS-wird-zum-Standard-4119942.html * Kurzer Überblick und deutschsprachige Erläuterungen: https://spacehost.de/10-apache-header-eintraege-webseite-sicher-machen/ ### Einige Beispiele aus der Praxis: * Sicher: https://securityheaders.com/?q=typo3.usergroup.tirol&followRedirects=on * Unsicher: https://securityheaders.com/?q=tirol.gv.at&followRedirects=on * Desaster: http://www.bmi.gv.at/ -> duplicate content, plain and via SSL/TLS surfable, no automated redirect, blocking securityheaders ... (dafuq?) * Desaster²: https://securityheaders.com/?q=www.bundesheer.at&followRedirects=on https://securityheaders.com/?q=https%3A%2F%2Fwww.bundesheer.at%2F -> https page redirects to http page ... (dafuq???!?) ## Beispiel Konfiguration für .htaccess und Apache-config Nicht vergessen: eventuell muss das auch auf nginx nachgezogen werden, wenn man diesen beispielsweise als reverse Proxy einsetzt um statische Dateien schneller direkt darüber auszuliefern! # funktioniert nur sehr eingeschränkt, je nach sonstiger Serverconfig Header unset "Server" # dafür gilt das selbe. Header unset X-Powered-By # HSTS - wie lange ganz generell bei dieser Domain/Subdomain gar kein Plaintext Verbindungsversuch mehr stattfinden soll, sondern gleich nach HTTPS gewechselt wird. Header always set Strict-Transport-Security "max-age=15552000" # Einstellung zu frames (und iframes). Der Wert "SMAEORIGIN" bedeutet, dass nur die selbe Domain einframen darf. Header set X-Frame-Options SAMEORIGIN # Verhindert (oder erschwert) bestimmte Cross-Site Scripting Attacken via Filter, die in den meisten modernen Browsern implementiert sind. 1; mode=block heisst, die Seite wird erst gar nicht gerendert. Header set X-XSS-Protection "1; mode=block" # Verhindert die Ausführung von Code, der nicht dem Mimetype des geladenen Dokuments entspricht. Header set X-Content-Type-Options "nosniff" # CSP: Damit soll das Einschleusen von JavaScript Code von einer in eine andere Seite verhindert werden. "upgrade-insecure-requests ist das absolute Minimum. Genau genommen müssten hier die Domains angegeben werden, von denen tatsächlich JavaScript, CSS etc... geladen werden darf. Also z.B. auch die google-analtics domain, google-fonts etc. falls diese im Einsatz sind. Hier wartet potentiell viel Arbeit, gerade wenn man Tracking Tools einsetze, oder CDNs. Header set Content-Security-Policy "upgrade-insecure-requests" # Damit wird gesteuert, welche Informationen an eine weitere Seite weitergegeben werden. Also z.B. wenn auf typo3.usergroup.tirol auf den Link zum Meetup geklickt wird. strict-origin bedeutet: die Domain wird mitgegeben, aber nicht der Pfad. Allerdings auch nur dann (strict), wenn das Protokoll weiter HTTPS bleibt! Header always set Referrer-Policy "strict-origin" # Custom header Header set X-Powered-By "www.Riccabona.IT" # Custom header -> Meme -> Scheibenwelt Romane. Header set X-Clacks-Overhead "GNU Terry Pratchett, Stephen Hawking" ## In obiger Minimal-Konfiguration fehlt einiges was sinnvoll wäre, hier ein paar kurze weitere Beispiele: * Expect-CT Hierbei geht es um die sogenannte Zertifikatstransparenz (Certificate Transparency), ein Google-Projekt zur Feststellung, ob ein Zertifikat auch wirklich zur Seite gehört, bzw. ob das Zertifikat missbraucht wird. Nachlese hier: https://scotthelme.co.uk/certificate-transparency-an-introduction/ * Public-Key-Pinning (HPKP): Mit diesem Header können für die Webseite gültige Zertifikate oder Zertifikatsstellen definiert werden. Dies soll Man-in-the-Middle Attacken verhindern, bei denen mit gefälschten, aber von anerkannten Zertifikatsstellen signierte Zertifikate zum Einsatz kommen. Ein bisschen aufwändiger zu konfigurieren, kann auch nach hinten losgehen, viele lassen davon noch die Finger. Nachlese hier: https://de.wikipedia.org/wiki/HTTP_Public_Key_Pinning * Feature Policy - der neue geile heisse Scheiss! Damit können bestimmte Features der Browser "abgeschaltet" werden für die jeweilige Sitzung, wie z.B. Zugriff auf Kamera, Mikrofon, Geo-Location, aber auch so sachen wie: payment, gyroscope, vibrate, sync-xhr. Dabei können je Feature auch noch Gültigkeitsbereiche gesetzt werden. Beispielsweise: Feature-Policy: vibrate 'self' example.com -> die Seite darf Vibrieren auslösen. Aber auch alle eingebetteten Seiten/Codes. Umfangreiche Nachlese hier: https://scotthelme.co.uk/a-new-security-header-feature-policy/ # Fazit Man sieht, dass die Serverkonfiguration immer komplexer und umfangreicher wird, und vorallem viel Informationstransfer vom Entwickler zum Sysadmin stattfinden muss, um eine sicher konfigurierte Webseite online zu bringen! ## Danke für Eure Aufmerksamkeit, jetzt gibt's hoffentlich Pizza! :-)