Firefox 44 erlaubt Webseiten-Aufruf trotz schwacher Verschlüsselung
Wenn es um die Sicherheit bei HTTPS-Verbindungen geht, dann gilt Firefox als besonders streng und verweigert unter Umständen sogar den Aufruf komplett. Mit Firefox 44 führt Mozilla die Möglichkeit ein, die Webseite in einem solchen Fall trotzdem zu besuchen.
Wer eine Webseite über HTTPS aufruft, deren Verschlüsselung als unsicher gilt, hat als Firefox-Nutzer ein Problem: Während zum Beispiel Chrome die Webseite einfach darstellt, zeigt Firefox nur eine Fehlermeldung. Der Nutzer hat in dem Fall auch nicht wie bei anderen Zertifikatsproblemen die Möglichkeit, eine Ausnahme hinzuzufügen, Firefox verweigert den Zugriff komplett.
Während es aus Sicherheitsgründen sinnvoll ist, den Zugriff bei schwacher Verschlüsselung zu verweigern, und Firefox in einem solchen Fall auch weiterhin ausdrücklich warnen und die Verbindung zunächst verweigern wird, gibt Mozilla dem Nutzer ab Firefox 44 zumindest die Möglichkeit, die Webseite dennoch aufzurufen.
Weitere aktuelle Artikel aus der Kategorie „Firefox“
- 09.10.2024Sicherheits-Update Firefox 131.0.2 veröffentlicht
- 08.10.2024Die Neuerungen von Firefox 131
- 24.09.2024Neue Sprachen für Übersetzungsfunktion von Firefox
- 23.09.2024Firefox 132: Tabs auf anderen Geräten schließen
- 22.09.2024Neue Hoffnung für Unterstützung von Bildformat JPEG-XL (JXL) in Firefox und Chrome
Und was ist da in FIrefox 44 eigentlich mit der „Diesen Fehler melden“-Schaltfläche passiert? Die ist ja auch weg?
Oder werden die Fehler dann etwa automatisch an Mozilla gemeldet?(!)
Gute Frage, was damit ist. 🙂 Ich weiß aber ehrlich gesagt auch nicht, wohin diese Berichte vorher gingen und ob sie überhaupt ausgewertet worden sind. Das ist ein Feature, über welches ich gar nichts weiß.
Na , in den Fällen kann man auch fix auf Chrome ausweichen ohne zu verzweifen. Restrisiko bleibt eh immer…
Meiner Meinung nach ist das eine sehr sinnvolle Änderung. Es gibt genügend Webseiten, die HTTPS einfach aus Prinzip verwenden (obwohl gar keine sichere Verbindung nötig wäre) und dann aber streiken (wie im 1. Bild gezeigt), wenn man unsichere Algorithmen (z.B. RC4) deaktiviert.
ich finde es eigtenltich richtig das es ausnahmen gibt, aber izwischen kann man sich schon für wenig Geld Zertifikat kaufen, und es ist ja nicht so schwer den Server auf den aktuellen Stand zu bringen und den Server so zu konfgurieren das TSL aktiviert ist und das die bestmöglichste Verschlüsselung genutzt wird.
Eigentlich sollte der Firefox unterscheiden können was eine starke und was eine schwache Verschlüsselung ist so wie es z.B. das Add-on Calomel macht.
Verschlüsselungen wie RC4 sollte man auch nicht mehr verwenden, genaus soll anscheinend SHA-1 als unsicher gelten und nicht mehr verwenden sondern nur noch SHA-2
Aber der Firefox erkennt jede Verbindung mit einem Zertifikat als sicher, nur wenn man kein Zertifikat hat da motzt er dann.
> Ich weiß aber ehrlich gesagt auch nicht, wohin diese Berichte vorher gingen und ob sie überhaupt ausgewertet worden sind.
Okay, ich hab mich da mal umgeschaut.
Die URL, an welche die gesendet werden, kann man in about:config unter security.ssl.errorReporting.url sehen Das ist aktuell: https://data.mozilla.com/submit/sslreports
Mehr Informationen dazu konnte ich hier finden:
* Im Support-Artikel erwähnt ist es hier: https://support.mozilla.org/de/kb/sicherheitszertifikate-von-webseiten#w_unsichere-zertifikate-melden (wobei dieser nicht sehr aussagekräftig ist)
* Und hier im WIki: https://wiki.mozilla.org/Security/Features/SSL_Error_Reporting
Im Wiki steht allerdings nicht viel zum Backend und ob/wie dies ausgewertet wird. Außerdem ist es angeblich noch „In progress“.
Zumindest in einem Bugzilla-Kommentar wurde erwähnt, wie es reported wird und, dass es nur 5 Tage gespeichert werden muss. Da war es allerdings noch in der Planung.
Ein weitereres Bugzilla-Ticket darüber ist übrigens dieses: https://bugzilla.mozilla.org/show_bug.cgi?id=846489
Mir fallen so auf Anhieb keine Seiten ein, bei denen dies der Fall wäre.
Das wäre mal interessant zu erfahren! Ich habe die „Fehler melden/senden“-Funktion bisher nur einmal auf einer HPKP-Fehlerseite ausprobiert und da anschließend nur eine einfach „wurde gesendet“-Bestätigung kam, aber keine Info wohin und was damit passiert, hab ich das nicht mehr gemacht.
Die Fehlermeldung errorReporting.title habe ich hier im Quelltext (um Zeile 513) gefunden. In Zeile 528 gibt es dann den Senden-Button mit der ID reportCertificateError, den man dann z.B. hier wiederfindet. Dann bin ich aber mit meinem Quellcode-Latein am Ende… Vielleicht möchte jemand den Spuren weiter nachgehen und verraten, wohin die Reports gesendet werden? Hier kann man den Mozilla/Firefox Quellcode durchsuchen…
@Alex
Auch ich habe mir das schon angeschaut. (siehe meinen Kommentar oben)
Um zu erfahren, wo das ganze hin gesendet wird, muss man dabei noch nicht mal in den Quellcode schauen. In about:config findet man schon die URL.
Wie zu erwarten: Es wird an Mozilla gesendet.
Mehr konnte ich auch nicht herausfinden.
@Christian T:
Firefox unterscheidet ja, ansonsten würde dieser Artikel keinen Sinn ergeben.
Wie kommst du denn darauf? Das stimmt doch überhaupt nicht. Wie es auch im Artikel steht: Firefox gilt sogar als besonders streng, also das genaue Gegenteil von dem, was du meinst.
@rugk:
Danke, sehr informativ.
@Anon:
Mir schon. Wofür brauche ich beispielsweise auf firefoxosdevices.org HTTPS? (Und ja, ich verwende dort HTTPS). Aber die Seite ist Read-only, Nutzer übertragen keinerlei Daten. Die Dateneingabe meinerseits erfolgt über eine ganz andere Seite. Ich sehe auch hier auf dem Blog (wo ebenfalls HTTPS verwendet wird) ehrlich gesagt keine zwingende Notwendigkeit. Da haben andere Seiten wesentlich mehr von. Dass HTTPS einen positiven Ranking-Einfluss bei Google hat, ist da fast noch der interessanteste Aspekt. 😉
@rudk: Danke, sehr interessante Links! Nachdem ich das jetzt alles gelesen habe, glaube ich aber, dass die Leute von Mozilla beim HTTP Public Key Pinning (HPKP) etwas falsch verstanden haben und die „Fehler melden“-Funktion jetzt auf Basis des Missverständnisses (nur) falsch genutzt wird?!
Im Link:IETF-Draft zu HPKP heißt es, dass der Webseitenbetreiber, der HPKP verwendet, gemeinsam mit den PINS optional eine URL angeben kann, an welche die „violations“ gemeldet werden sollen. Ich hatte das mal bei einer eigenen Testdomain mit absichtlich geänderten PINS ausprobiert, Firefox hatte bei meinem Test aber keine Fehlermeldung an die von mir angegebene URL gesendet.
In den von dir verlinkten Mozilla-Seiten wird die „Fehler melden“-Funktion an mehreren stellen damit begründet, dass dies für HPKP erforderlich sei. Das ist an sich richtig, der Fehler sollte aber nicht an Mozilla gehen, sondern an die im HPKP-Eintrag angegebe URL (soweit angegeben).
Nach meiner Auffassung hat Mozilla das also falsch verstanden und jetzt landen die Fehlerberichte bei irgend einem Mozilla-Mitarbeiter „[:msmedber]“ und es ist nicht wirklich transparent, was damit geschieht. „the security-group should be alerted for further action“ – und was passiert dann? Mir wäre nicht bekannt, dass Firefox eingegebene URLs mit einer Blacklist abgleicht und den Aufruf blockiert, wenn es eine SSL oder HPKP Violation gab – oder habe ich hier etwas verpasst?
Ich verstehe durchaus den Sinn/Nutzen, dass Mozilla anhand freiwillig gesendeter Telemetry oder in diesem Fall Zertifikats-Violation-Meldungen auswerten kann, ob das UI funktioniert und angenommen wird. Aber der HPKP „report error“ ist nicht für Mozilla gedacht, sondern für denjenigen, der seine Website mit HPKP absichert. Damit der Webmaster selber weiß/erfährt, wenn es einen MITM-Angriff beim Aufruf der eigenen Website gab…
Oder habe ich das jetzt komplett falsch verstanden mit dem HPKP „report-error“ und der Firefox „Fehler melden“ Funktion?