Dienstag, 19. August 2008
SSL-Verhalten in Firefox 3 abstellen
Trackbacks
Trackback-URL für diesen Eintrag
Keine Trackbacks
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
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 
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..
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...
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...
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...
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...
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.
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.
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.
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.
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.
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.
"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
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
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.
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.
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.
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
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
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?
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?
hi find das mit den kleinen Tipps im blogg super. würde mich über eine tägliche/wöchentliche kleine Tipp Runde freuen.
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.
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.
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.
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.
IPv4 vs. IPv6
Du bist hier via
Suche
Zensur-freies Internet
Ökostrom
Vorratsdatenspeicherung
Kalender
Kommentare
Do, 11.03.2010 02:31
Dann hatte ich wohl noch nie r
ichtig Last auf der Netzwerkka
rte. Ich habe 2.6.32.9 am Lauf
en und keine wirklichen [...]
Mi, 10.03.2010 22:15
Wer an eine G80 gewöhnt ist, h
at für ne G83 nur ein mildes L
ächeln übrig...
Mi, 10.03.2010 21:14
Hier ein WICHTIGER Hinweis zum
2.6.33 Kernel. FINGER WEG.
Ab 2.6.32.8 gibt es GROßE Pr
obleme mit dem NFS Treib [...]
zu 2K8
Mi, 10.03.2010 21:13
Wobei ich zugeben muss, als IT
-Dienstleister auch von einem
"Weh-Zwo-Ka-Drei" oder eben ak
tueller von einem "Weh-Z [...]
zu 2K8
Mi, 10.03.2010 21:12
Ich weiss - die anderen antwor
ten sind lustiger aber...
Bei
der Arbeit haben wir 2k für W
indows 2000 in Hostnamen [...]
Mi, 10.03.2010 20:08
entweder verstehe ich die sehr
feine Ironie nicht, oder du s
pürst den Strom nicht mehr wen
n du in die Steckdose pa [...]
