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
|
September '10 |
|
||||
| Mo | Di | Mi | Do | Fr | Sa | So |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
Kommentare
Do, 02.09.2010 21:06
Ich könnte mir gut vorstellen,
dass das kein Bluff war.
A
ls Anbieter wo man sich relati
v frei und einfach anmel [...]
Do, 02.09.2010 20:57
kommt auf den Programmieraufwa
nd an.
Ist es auch möglich
nur jede dritte Stelle durch e
in X zu tauschen?
zu Archiv-Flut
Do, 02.09.2010 18:33
Gegen Feuer und (etwas eingesc
hränkter) Wasser helfen Brands
chutzschränke zur Lagerung - v
or allem - der Buchhaltu [...]
Do, 02.09.2010 18:19
Die Leistung wurde bis auf die
Domain durchaus erbracht, Web
space etc. wurde ja angelegt.
Das mit der Anzeige war [...]
Do, 02.09.2010 17:14
Also ich kann es verstehen, be
i uns haben auch diverse Leute
zugriff auf ein Kundenmenü, a
llerdings geht es keinem [...]
Do, 02.09.2010 16:33
Ja irre beim Hosting-Panel ein
fach den Zugang löschen der no
ch nicht einmal genutzt worden
sein kann weil Domain j [...]
Do, 02.09.2010 15:33
Wer auf einem PC in einem Inte
rnetcafé Zugangsdaten zu so se
nsiblen Bereichen eingibt, dem
geschieht das ganz recht.
Do, 02.09.2010 14:23
Zumindest die Bearbeitung des
Widerspruchs hat durchaus Kost
en verursacht, die über die 6
Euro hinaus gehen dürften.
Do, 02.09.2010 14:07
Wenn man z.B. im Internetcafé
die Seite auf hat und einer üb
er die Schulter schaut, dann h
at der die Nummer. Klar, [...]
Do, 02.09.2010 12:40
Vielleicht wars ja wirklich wi
e geschildert. Aber wenn ich j
emanden beauftrage sich über P
reise zu informieren und [...]
