Blog Logo Screenlight Blog

Safebrowsing in Firefox lässt Besucher 2 Minuten warten

HEUREKALIGHT

Ein Safety-Feature im Firefox hat bei einer Kunden-Website zu einer verzögerten Darstellung von 2 Minuten geführt.

Safebrowsing ist ein Feature, welches per Default eingeschalten ist und den Anwender vor einem Besuch einer Bösartigen Website (Trojaner Download/Phishing) warnen soll. Welche Website aktuell als bösartig eingestuft wird, ist in verschiedenen Datenbanken von verschiedenen Anbietern (unter anderem Google) abrufbar.

Damit diese Checks nicht die Privatsphäre von Benutzern kompromittiert, und für jede URL bei Google nachfragt, ob man diese besuchen soll, gibt es eine vereinfachte lokale Kopie dieser Datenbank. Diese Vereinfachung wird gemacht, damit die Datenbank nicht zu viel Speicherplatz verwendet. So wird statt einer URL lediglich ein sogenannter Hash (4-Bytes) lokal abgespeichert. Dies entspricht einem Fingerabdruck, welcher aber nicht 100% eindeutig ist. Deshalb kann es passieren, dass auch eine URL die nicht bösartig ist, einen ähnlichen Fingerabdruck hat wie eine, die es ist.

Damit der Benutzer nicht eine falsche Warnung erhält, wird bei einer Übereinstimmung des partiellen Abdrucks, noch eine vollständige Überprüfung gemacht, dies online, in der zentralen Datenbank (z.b. bei safebrowsing.google.com). Wenn die URL nun zu Unrecht verdächtigt wurde, fährt der Browser mit dem laden der Website fort. Ansonsten bricht dieser sofort ab und stellt eine Warnung dar. Dies Überprüfung geschieht für jede URL, die auf einer Seite verwendet wird, also nicht nur, für die, die aufgerufen wurde, sondern auch für alle Resourcen (Bilder, JavaScript, StyleSheets, Schriften, etc) die für die Darstellung der benötigt werden. Weil es unendlich viele Kombinationen geben kann von diesen URLs, werden auch Hashes für Teile dieser URLs überprüft, damit möglichst wenig Chancen besteht, das eine URL doch noch durchrutscht.

Ein Beispiel anhand dieser URL:

http://www.some-website.com/data/styles/de/MainStyle/reset/all.css?m=1458112181

Überprüft wird dann der Fingerabdruck folgender Teile dieser URL:

http://www.some-website.com/data/styles/de/MainStyle/reset/all.css?m=1458112181

=> Vollständiger Hash: 0467e6e685dd87aecb5b538ec0a0ffc875b34bc3cd8cd2f6c07f965d1dfe93e9
=> 4-Byte Hash: 0467e6e6

http://www.some-website.com/data/styles/de/MainStyle/reset/all.css

=> Vollständiger Hash: ca1c7a6f0cdc3ba7f892794a113a473d8dd737fc27ed38c898485ed44cb7d3ef
=> 4-Byte Hash: ca1c7a6f

http://www.some-website.com/data/styles/de/MainStyle/reset/

=> Vollständiger Hash: 5b98372b9ee07c2b2abd49a353fcd8d1c71edfe44893faa6ba83a451277cb7c0
=> 4-Byte Hash: 5b98372b

http://www.some-website.com/data/styles/de/MainStyle/

=> Vollständiger Hash: 0d1e424b917ae5570e4f1bba682dc6d9b350e30a26f68a8f7f1b30160be271e8
=> 4-Byte Hash: 0d1e424b

http://www.some-website.com/data/styles/de/

=> Vollständiger Hash: 317696a28f63d774ff4a7701cc8e478cd6d5564c8207544e9496f61873c2224c
=> 4-Byte Hash: 317696a2

http://www.some-website.com/data/styles/

=> Vollständiger Hash: efe2ffa08af99a3dc491956d92c363c156b4300f711763c1a8a9bf311e2a8824
=> 4-Byte Hash: efe2ffa0

http://www.some-website.com/data/

=> Vollständiger Hash: 740537dafa3b74740dc2723c77873264495de7fcb768e302cde75a1c0323661b
=> 4-Byte Hash: 740537da

http://www.some-website.com/

=> Vollständiger Hash: cc5641e58be45d770a5f411dcc7f4f0a3d4d17342d60f0893a65bd042482c9c6
=> 4-Byte Hash: cc5641e5

http://some-website.com/

=> Vollständiger Hash: 70558765d2d274fd4f95048fa917cbcb537a83d93543a95a0feaf040d5dbce89
=> 4-Byte Hash: 70558765

Die Hashes (auch die vereinfachten) dieser Teil-URLs sind komplett unterschiedlich und werden alle einzeln in der lokalen Datenbank geprüft. Wenn auch nur für einen dieser Hashes ein “match” gefunden wird, wird die Online-Datenbank zur Klärung aufgerufen. Dies geschieht mit allen URLs auf einer Seite.

Safebrowsing SPDY Anfrage

Sogenannte false-positives können jederzeit auftreten und sind relativ zügig aufgeklärt. Wenn dies nur für eine oder auch ein paar wenige passiert, ist das kein Problem und kaum spürbar beim Besuch einer Website. Ausserdem wird dies nur einmal gemacht, und die Anwort der Online-Datenbank wird für eine gewisse Zeit oder bis zum Browser-Neustart gecacht. Dies ist ein anderer Cache, als der übliche Browser-Cache, und kann nur über einen Neustart gelöscht werden!

Das konkrete Problem:
Wenn nun aber eine grosse Anzahl (>~100) Hashes überprüft werden müssen, dann blockiert der Verfikations-Service die Anfrage für eine Weile (~ 60 Sekunden!) bevor die restlichen Anfragen beantwortet werden können. Dies ist eher unüblich, da normalerweise nicht so viele Hashes auf ein Mal überprüft werden müssen. Wenn nun aber zufälligerweise eine Basis URL, also ein Teil der URL welche in praktisch jeder URL vorkommt, einen Match in der lokalen Datebank hat, dann werden (von Firefox) alle URLs, die mit dieser Basis-URL beginnen, einzeln geprüft. Diese Kombination von bösen Zufällen und ineffizientem Verhalten von Firefox ist Fatal für die Performance der Website und resultierte in einem nur sehr schwer nachvollziehbaren Verzögerung von 2 Minuten beim erstmaligen Besuchen der Website!

Durch reduzieren und vereinfachen konnten wir die Teil-URL, die das ganze auslöst, isolieren und das Problem reproduzieren. In unserem Fall war die URL die Base-URL (http://www.some-website.com/data/) für alle Resourcen der Website.

Das Problem trat bei Firefox 46 auf.

Die Lösung war, die Base-URL zu verändern und die Medien von einer leicht veränderten URL (http://www.some-website.com/live/data/) zu laden.

Symptome dieses Problems waren:

  • Alle Seiten mit der Base-URL (http://www.some-website.com/data/) wurden dramatisch verzögert geladen.
  • Der Browser hat während der Wartezeit auch das laden von anderen Websites komplett blockiert.
  • Das Schliessen des Browsers war ebenfalls nicht möglich.
  • Aufrufen folgender von Seiten mit folgenden Base-URLs war kein Problem:

    http://www.some-website.com/stage-live/data/

    http://stage.some-website.com/data/

  • Nur ein Neustart des Browsers (oder längeres Warten) provozierte das Problem erneut
  • Löschen das Browser-Caches hat nichts gebracht

Safebrowsing Protokoll:
https://developers.google.com/safe-browsing/developers_guide_v3

Leave a Response

No comments so far, would you like to be the first?