Skip to content

SSL-Verhalten in Firefox 3 abstellen

Wer das "nervige" Standard-SSL-Verhalten von Firefox 3 abstellen möchte, für den hier eine Kurzanleitung:

  • about:config
  • browser.xul.error_pages.expert_bad_cert auf true setzen
  • browser.ssl_override_behavior auf 2 setzen
  • Kommentare

    Ansicht der Kommentare: Linear | Verschachtelt

    M

    Was ändert das genau? Oder: welcher Teil davon ist nervig? Ich habe bislang nur gute/einfache Erfahrungen damit gemacht. Keine Ahnung wie es bei ungültigen Zertifikaten aussieht ;)

    Matthias

    Du musst halt erst umstaendlich in 2 - 3 Schritten eine Ausnahme definieren. Zwar nicht schlecht, da dass nicht so einfach wie ein einzelner unachtsamer Klick auf 'Akzeptieren' von der Hand geht; aber meist sind Zertifikatsprobleme ja nur auf inkompetente Admins, und nicht auf wirkliche MitM-Attacken o.ae. zurueckzufuehren..

    rae

    Was ist daran inkompetent, ein Zertifikat zu nutzen, was
    a) von CACert.org ausgestellt wurde, oder
    b) selbstsigniert ist, weil es ein privates Angebot ist, womit kein Profit erzielt wird, was aber auch keine (weiteren) Kosten verursachen soll?

    Ich wuerde sagen, mit dieser Aussage lehnst Du Dich ganz schoen weit aus dem Fenster...

    Crs

    a) CACert installiert man eh als Root-Cert im Browser, damit sind mit denen die Warnungen weg, dazu ist CACert ja (u.a.) da.
    b) Selbst signieren muss man ja nicht mehr, dank CACert.

    Ein selfsigned dessen Fingerprint ich nicht kenne (Was bei "privaten Angeboten" ja üblich ist) ist völlig sinnfrei und kann auch einfach weggelassen werden...

    Jan

    Ein Self-Signed, dessen Fingerprint ich nicht kenne und das ich als Ausnahme aufnehme, führt dazu, dass ich bei späteren Connects darauf hingewiesen werde, wenn es plötzlich ein anderes Zertifikat ist. Das ist der De-facto-Standard, wie die meisten ssh verwenden. In beiden Fällen gibt es ein Risiko, dass bei allen Verbindungsversuchen eine (dieselbe) MIM-Attacke stattfindet. Bei einem durchschnittlichen Vereins-CMS oder Onlinemitgliederverzeichnis dürfte dies aber ein sinnvolle Risikoabwägung sein und immer noch besser, als wenn ein Kollege schon mit einem Netzwerksniffer die Logindaten mitlesen kann, ohne dass ich das merke.

    Online-Banking würde ich darüber nicht machen, aber unnütz ist auch so eine Konfiguration nicht.

    BTW: Es gibt gute Gründe, CAcert nicht in der Browser zu importieren (da das "Eigentum" an einer Domain durch eine Mail ermittelt wird, könnte ich die auch mitlesen oder per DNS-Cache-Poisoning zu mir umleiten). Konsequenter Weise sollte man dann nur eine ganze Reihe der mitgelieferten Authorities auch mit rausschmeissen. Wenn man das tut, kann es trotzdem sinnvoll sein, für eine bestimmte Site wiederum eine Ausnahme einzurichten.

    rae

    Dem stimme ich zu - ein selbstsigniertes Zertifikat ist zwar nur bedingt geeignet, die Identitaet des Anbieters zu bestimmen, aber immerhin reden wir hier von SSL, sprich von einer Verschluesselungstechnik - die "dumemrweise" ohne Zertifikate nicht funktioniert... also lieber ein "selsfigned", damit ich eine verschluesselte Verbindung nutzen kann, als Klartext-Kommunikation fuer meine Verbindungsdaten

    Der mangelnden Sicherheit bei der Authentifizierung des Domaininhabers kann man recht leicht begegnen - bestimmte Funktionen stehen nur CAcert-Mitgliedern zu, die einen gewissen Vertrauensstatus erreicht haben. Man legt seinen Ausweis vor bei mindestens drei sogenannten Assurern und laesst sich damit die persönliche identitaet bestaetigen. Das heisst, dass es zwar nicht so ohne Weiteres ersichtlich ist fuer einen normalen Besucher mit Root-Zertifikat von CAcert installiert, ob jemand ein "Domain-Faker" ist, aber erstens ueberpruefen die Leute bei CAcert schon aus eigenem Interesse idR die Whois-Daten der Domain, und zweitens ist es Jedermann moeglich, den "Faulen Hund" zu identifizieren. Von daher ist dein Argument gegen einen Import der Root-Zertifikats wenn ueberhaupt nur akademischer Natur.

    Jan

    Wieso inkompetente Admins? Es gibt gute Gründe, selbstsignierte Zertifikate zu verwenden oder welche von CAcert. Dies gilt insbesondere für Sites, die nicht gewinnorientiert sind und sich die hohen Gebühren für teure und nicht notwendigerweise sicherere Zertifikate von Authorities, die in gängigen Browsern enthalten sind, nicht leisten können oder wollen.

    Matthias

    Okay - Ihr habt recht. Meine Aussage bezog sich eher auf abgelaufene Zertifikate etc. Selbst-/CAcert-signierte hab ich mal ausgenommen - die kommen ja eh meist dort zum Einsatz, wo SSL nur nice-to-have, aber keinesfalls obligatorisch ist. Und Leute die Geld mit der jeweiligen Webseite verdienen, sollten wohl in der Lage sein, ein paar Euro fuer Zertifikate auszugeben, und diese auch richtig zu pflegen.

    rae

    "Obligatorisch" ist es *ueberall*, wo Login- oder anderweitige sensible Daten ueber das Netz wandern. Ansonsten hast Du prinzipiell recht damit, dass jemand, der Umsatz mit seiner verschluesselten seite generiert, durchaus die (moralische) Verpflichtung hat, seine Zertifikate in Schuss zu halten.

    Bei CACert.org scheiden sich allerdings auch hier unsere Geister. Wenn auch Firmen das "Wagnis" mehr und mehr eingehen, die kostenlosen (und nicht unsichereren) Zertifikate von CACert.org einzusetzen, erhoeht sich der Druck auf die Browserhersteller, deren Root-Zertifikate endlich mit auszuliefern

    Matthias

    Ob zum Beispiel das Login fuer die Kommentierfunktion in diversen Blogs unbedingt SSL gesichert sein muss, halte ich fuer fraglich. Klar ist Identitaetsdiebstahl problematisch - aber man sollte immer daran denken, dass der Betreiber auch erhoehten Aufwand dafuer betreiben muss. Und sei es nur das 'Mehr' an Rechenleistung was benoetigt wird, und das 'Mehr' an Kosten, was dadurch entsteht. Wie schon oben erwaehnt: Besonders bei Privatprojekten, die verstaendlicherweise nichts investieren moechten, problematisch.

    mømø

    Was das ändert?

    http://kb.mozillazine.org/Browser.xul.error_pages.expert_bad_cert
    True - Unhide the “add exception” button on the SSL error page, allowing users to directly accept a bad certificate.
    False - Hide the advanced UI, requiring users to click through explanatory dialogs before adding an exception. (Default)

    http://kb.mozillazine.org/Browser.ssl_override_behavior
    0 - Do not pre-populate the current URL as an exception and do not pre-fetch the SSL certificate.
    1 - Pre-populate the current URL but do not pre-fetch the certificate. (Default)
    2 - Pre-populate the current URL and pre-fetch the certificate.

    franc

    Im Firefox gibt es auch die Erweiterung MitM mit der man den Käse etwas wirksamer loswird:

    https://addons.mozilla.org/de/firefox/addon/6843

    Und auch noch perspectives:

    https://addons.mozilla.org/de/firefox/addon/7974

    Damit und den oben angeführten about:config Einträgen lässt sich das Pseudo-Sicherheitsgebaren vom FF 3.x wieder ertragen :-)

    Sam

    Eigentlich hab ich das schon länger gesucht.
    Nur leider funktioniert es bei mir überhaupt nicht. Die Konfiguration ist ja schnell geändert - nur Auswirkungen auf das Verhalten des Browsers hat das irgendwie keine.
    Gibts noch irgendwo eine magische Konfiguration die sagt das diese Konfiguration genutzt werden soll?

    Knirps

    hi find das mit den kleinen Tipps im blogg super. würde mich über eine tägliche/wöchentliche kleine Tipp Runde freuen. :)

    Manuel Schmitt (manitu)

    z.B. zu was noch :-) ?

    Balu

    Danke großer Manitu!

    Matthias Versen

    CAcart hat kein security Audit gemacht das notwenig ist denn die komplette Vertrauenskette muss sichergestellt sein.
    Selbstsignierte Certs sind nur sinnvoll wenn man absolut sicher sein kann nicht duch ein Mitm betroffen zu sein während man es akzeptiert. (geschlossenes LAN).
    Die verschlüsselung nutzt absolut nichts, man kann genauso im Klartext übertragen wenn die ganze Kette unterbrochen ist durch selsbtsignierte Zertifikate oder unsichere CAcerts root zertifikate.
    Es gibt fertige MITM Tools, das geht einfacher als mit Netzwerksniffer im Klartext mitzulesen, inklusive DNS poison attack.
    Also entweder man will Sicherheit oder man braucht halt keine (http).

    Mal eben solche Tips ohne weitere Hinweise zu verbreiten halt ich für fahrlässig.

    rae

    Genau, und Du prüfst vor jeder Autofahrt den Zustand der Bremsschläuche, der Elektronik, vergewisserst Dich, dass Scheinwerfer, Nebelscheinwerfer, Ruecklichter, Bremslichter, Blinker funktionieren, stellst sicher, dass sich kein Marder unter Deiner Motorhaube eingenistet hat, und so weiter...

    Dein Sicherheitsbewusstsein in allen Ehren - ganz ohne Ironie oder Sarkasmus, denn meine tagtaegliche Erfahrung zeigt, dass jenseits von einigen "Geeks" das Thema Sicherheit so gar keine Rolle spielt. Trotzdem haben auch einfache Zylinderschloesser ihren Sinn, auch wenn sie ein professioneller Eindringling mit oder ohne geeignetem Werkzeug in wenigen Sekunden ueberwunden hat... *kopfschuettel*

    Die Frage ist immer, wieviel Aufwand ich betreiben muss um wieviel Sicherheit zu erreichen - und wie hoch ueberhaupt die reale Gefaehrdung ist. Ab einem gewissen Punkt lohnt es sich einfach nicht, bzw wird unwirtschaftlich, weil der abgewendete Schaden in keinem Verhaeltnis mehr steht zu den Aufwendungen.

    Kommentar schreiben

    Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
    Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
    Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
    BBCode-Formatierung erlaubt
    Formular-Optionen