Tracking via SSL Session Resumption und SSL Session-ID
Beim Aufbau einer verschlüsselten HTTPS-Verbindung wird eine sogenannte Session initialisert. Diese Session kann für 48h genutzt werden. Das beschleunigt das Laden der Webseite bei erneutem Zugriff, da die Details der Verschlüsselung zwischen Browser und Webserver nicht jedes mal neu ausgehandelt werden müssen. Da diese Session eindeutig ist, kann sie für das Tracking genutzt werden. Das Verfahren ist im RFC 5077 beschrieben.
Die SSL-Session-ID kann von nahezu allen Webserven für das Tracking der Zugriffe genutzt werden. IBM WebSphere, Apache und andere bieten eine API für den Zugriff auf die SSL Session-ID. Einige Webshops sind für das Tracking via SSL Session-ID vorbereitet (z.B. die xtcModified eCommerce Shopsoftware).
Dieses Tracking-Verfahren ist so gut wie nicht nachweisbar, da es vollständig durch den Webserver realisiert wird und keine Spuren im Browser hinterlässt.
In Firefox 58+ ist der SSL Session Cache in den Surf-Containern gekapselt. Unser Konzept aktiviert folgende Schutzmaßnahmen gegen das Tracking via SSL-Session:- FirstParty.Isolation verhindert das webseite-übergreifende Tracking beim Surfen.
- Löschen des Cache und der SiteSettings beim Schließen des Browsers verhindert das langfristige Tracking über einen längeren Zeitraum.
Tracking via HTTP Strict Transport Security (HSTS)
HTTP Strict Transport Security (HSTS) wurde als Schutz gegen den ssl-stripe Angriff eingeführt, den Moxie Marlinspike auf der Black Hack 2009 vorstellte. Der Angriff wurde beispielsweise 2012 von mehreren Bad Tor Exit Nodes aktiv genutzt.
Als Schutz gegen ssl-stripe Angriffe sendet der Webserver beim Aufruf einer Webseite einen zusätzlichen HSTS-Header, um dem Browser mitzuteilen, dass diese Website für eine bestimmte Zeit immer via HTTPS aufgerufen werden soll. Außerdem enthält Firefox die HSTS Preload List mit mehr als 1.000 Webseiten, die nur via HTTPS aufgerufen werden dürfen. Das verhindert einen Downgrade auf unverschlüsselte HTTP-Verbindungen.
S. Greenhalgh hat ein Verfahren publiziert, wie man HSTS für das Tracking von Surfern verwenden kann. Entwickler bei Apple haben im März 2018 beobachtet, dass dieses Verfahren in-the-wild eingesetzt wird, veröffentlichten aber keine Details. Sie schlagen eine Modifikation des Standards vor, um Tracking via HSTS Cookies zu verhindern.
Ob man HSTS im Browser deaktiviert, um sich gegen ein Trackingverfahren zu schützen, oder ob man HSTS aktiviert, um sich besser gegen ssl-stripe Angriffe zu schützen (Standard im Firefox), ist also eine Wahl zwischen Skylla und Charybdis.
Einige Überlegungen dazu:- In der Regel nutzt man nur eine begrenzte Anzahl von Websites regelmäßig, bei denen sensitive Informationen durch SSL-Verschlüsselung wirklich geschützt werden müssen (E-Mail Provider, Website der Bank, Diskussionsforen, bevorzugte Suchmaschine....). Mit dem Add-on HTTPSEverywhere kann man SSL-Verschlüssung für diese Websites erzwingen, wenn diese Webseiten nicht in der HSTS Preload List enthalten sind. Damit ist man auch ohne HSTS überwiegend gegen ssl-stripe Angriffe geschützt.
- Die HSTS-Einstellungen für Websites werden in den SiteSettings gespeichert. Wenn man SiteSettings beim Schließen des Browsers alle löscht, dann ist man gegen langfristiges Trackig geschützt. privacy.clearOnShutdown.siteSettings = true Schutz gegen Tracking während einer Surf-Session ist nicht Ziel unserer Empfehlung, das kann ein Webmaster auch relativ einfach mit Cookies realisieren. Es gibt keinen Grund, für den Schutz gegen HSTS Cookies strenger Maßstäbe anzulegen, als für den Schutz gegen Tracking mit Cookies.
- Innerhalb einer Surf-Session kann man alle Super-Cookies bei Bedarf mit der Tastenkombination STRG-SHIFT-ENTF löschen. Zum Löschen der HSTS-Werte ist unter Details die Option "Website-Einstellungen" zu aktivieren.
