Warum installiert Firefox so viele CA Zertifikate?

Hi,

viele Sicherheitsbedenken kann man gegenüber SSL/TLS und X.509 äußern. Mir gefiel die Zusammenfassung
http://www.ioactive.com/pdfs/PKILayerCake.pdf.

Etliche Punkte sehen für mich nach teils ziemlich unverständlichen Bugs aus (wie z.B. kann nach einer Extended Verification weiterhin ein "grüner Zustand" angezeigt werden, wenn eine neue SSL/TLS Verbindung mit anderen Zertifikaten ausgehandelt wurde? Warum läßt sich ausgerechnet ein pishing-Schutz so austrixen? Hammer.), aber einige werden auch durch schlechte Arbeit von Certification Authorities verursacht. Da gibt es CAs, die über Klartext-E-Mails "authentifizieren" (kein Witz, das stimmt wirklich! cacert.org und rapidSSL sind wohl Beispiele dafür). Auch gibt es nette (potentielle) Kollisionsangriffe auf Hashes (MD5, MD2).

Etliche solcher CAs fand ich in der root-CA-Zertifikat-Datenbank, die Firefox automatisch installiert.

Wie wird diese Liste eigentlich zusammengestellt?

Wenn ich eine CA aus dieser Liste lösche, ist dann garantiert, dass diese CA durch kein Update wieder auftaucht (auch nicht mit neuem Zertifikat "Subject")?
Wenn ich mehrere Installationen verwende (auf mehreren Rechnern), wie kann ich diese Datenbanken synchronisieren (geht das überhaupt)?

Kann ich einstellen, dass ich angezeigt bekomme, wenn sich ein Zertifikat oder Sicherheitsparameter einer SSL-Session ändern? Ich persönlich akzeptiere nicht, wenn sich der Name einer Gegenstelle, dessen Zertifikatsverifizierungspfad oder die verwendete Kryptographie grundlegend (also z.B. plötzlich DES statt 3DES) ändert (und das am besten auch noch während einer logischen Verbindung)?

Gibt es eine Möglichkeit, beim Wiederbesuch von SSL Servern eine Warnung zu bekommen, wenn sich Zertifikats Subject, Issuer oder ein Key ändert (wie das z.B. SSH mit dem Hostkey-Checking macht, in dem der pub key gespeichert wird)?

Scheinbar sind solche Anforderungen selten, ansonsten wäre es meines Verständnisses nach nicht erklärlich, wie z.B. SSL-Renegiotation-Angriffe funktionieren (da fügen Webserver nachträglich "Sicherheit" hinzu, das kann meiner Meinung nach logisch ja schon nicht funktionieren). Wie kommt das? Sind solche Fragen nicht essentiell und wichtig? Wenn einem sein myspace account gehackt wird, ist das sicherlich Schade und nach Kräften zu vermeiden, aber beim online-Banking könnte schnell noch größerer Schaden entstehen...

Das gleichzeitige Arbeiten mit unterschiedlichen Profilen funktioniert in der Praxis auch erstmal nicht so einfach. Wird das empfohlen? Dann könnte man sich ein sicheres Profil (ohne zweifelhafte CAs) und ein Fun-Surf-Profil (default) basteln.

Leider kann ich mich nicht mehr so genau erinnern, welche CAs ich wann gelöscht habe. Nun gibt es bereits erste Probleme mit Seiten, die nicht mehr mit Firefox 2 funktionieren, so daß ich möglicherweise zu einem Update gezwungen sein werde.

Welche Handhabung empfiehlt sich hier in der Praxis?

Vielen Dank für das Lesen dieses Romans

Steffen

Zitat von Dr. Evil

Firefox bringt Zertifikate von CAs mit, die der Mozilla CA Certificate Policy entsprechen.

Ahh, danke für den Link. Läßt leider teils recht viel Interpretationsspielraum scheint mir ("reasonable measures" etc). Aber ein gewisser Interpretationsspielraum bleibt natürlich sowieso immer.

Auf http://www.mozilla.org/projects/security/certs/ habe ich jetzt auch
http://www.mozilla.org/projects/security/certs/included/ gefunden, wo die Certification Practice Statements verlinkt sind, prima, danke!

St.

Zitat von Oliver222

st1519 fragte Folgendes:

Ich meinte http://de.wikipedia.org/wiki/Extended_Validation, sorry, hatte einen falschen Begriff verwendet.

Zitat von Oliver222

... wobei Firefox bei diesem Verfahren seiner eigenen Datenbank (Firefox Certificate Store), zur Bewertung solcher „Trusted Root Certificates“ folgt. Eine Datenbank die – meiner Ansicht nach - jedoch kompromittierbar ist.

Natürlich muß man dem Betriebssystem, dem Browser und der verwendeten Datenbank (und weiterem) entsprechend vertrauen, klar.

Zitat von Oliver222

st1519 erklärte darüberhinaus Folgendes:

Das wirst Du leider akzeptieren müssen. Bezüglich vielfältiger Verschlüsselungsverfahren zweier kommunikativer Gegenstellen (Client < > Server) gilt eine Abwärtskompatibilität bezüglich des ausgehandelten Protokolls, sonst würde der Datenaustausch zweier unterschiedlich abgesicherter Systeme erschwert, bzw. unmöglich gemacht werden.

Korrekt. Datenaustausch mit Systemen, die meiner Meinung nach nicht ausreichend abgesichert sind, beispielsweise weil das verwendete Verschlüsselungsverfahrung für meine entsprechende Anwendung zu schwach ist. Das kann ich herrausfinden, in dem ich auf den "Schlüssel" oder das "Schloß" klicke. Da bekomme ich den Algorithmus angezeigt. Dann kann ich entscheiden, ob es mir reicht (z.B. 3DES) oder nicht (z.B. NULL cipher). Leider merke ich nicht, wenn sich das ändert (das ist ja bei SSL jederzeit möglich).

Ich akzeptiere das also nicht. Das der Datenaustausch dann nicht funktioniert, ist dabei natürlich genau das Ziel
Bei Sicherheitssysteme finde ich Abwärtskompatiblität grundsätzlich fragwürdig. Beispiele sind MS-CHAPv1 / LAN Manager Passwort Fallbacks oder gerade aktuell abgeklebte Chips auf Bezahlkarten. Da fragt man sich, wieso man erwartet, dass Angreifer das nicht ohnehin so machen (um den Angriff zu vereinfachen)...

(OT)

Zitat von Oliver222

Triple-DES (3 DES) nutzt im Vergleich zum konventionellen DES – meines Wissens nach - letztendlich auch nur eine effektive Schlüssellänge von 112 Bit, was zwar den Schlüsselraum (also das Berechnungsintervall) selber vergrössert, einem sicherheitskritischem Umfeld (z.B. elektronische Banktransaktionen) jedoch genau dann nicht gerecht werden kann, sofern keine sinnvolle Erneuerungsstrategie zum Generieren neuer Schlüssel initiiert wird.

Ja, 112 bit statt 56, das erhöht den Aufwand von brute-force-Angriffen um ca. 2^56 (2^56 ist sehr viel: 72.057.594.037.927.936). Soweit mir bekannt ist 3DES für elektronische Banktransaktionen international zugelassen und üblich; im deutschen Netz sicherlich der am weitaus am häufigsten verwendete Algorithmus.

Zitat von Oliver222

st1519 erklärte darüberhinaus u.A. Folgendes:

Die Seiten funktionieren nicht???

Ja, von etlichen Websites werden ältere Browserversionen nicht unterstützt. Vermutlich nicht aus Sicherheitsgründen, sondern aus Kosten- und Marketinggründen (man kann die Werbebanner u.U. besser darstellen und man spart Entwicklungskosten; beispielsweise gibt es heute etliche Websites, die ohne Flash einfach nicht mehr funktionieren).

Zitat von Oliver222

Theoretisch könntest Du Deine eigene CA austellen und im Anschluss auch gleichzeitig verifizieren.

Ich sehe mich nicht in der Lage, die Authentizität prüfen zu können. Vermutlich würde "meine CA" einen persönlichen Besuch und Besichtigung beim Antragsteller (z.B. der Firma, die ein SSL Zertifikat wollen) und Prüfung von Ausweisen/Pässen beinhalten, was Zertifikate so teuer machen würde, dass eh niemand in diese CA beauftragen würde

Zitat von Oliver222

O.T.
Entscheidend in Bezug auf Zertifikatsüberprüfungen ist meiner Ansicht nach dabei:
c. Ob sich der „Validierungspfad“ (Überprüfungskette) der einzelnen Zwischeninstanzen bei (rechtlich überregionalen) unterschiedlichen CA´s immer noch „integer“ verhält. Was bedauerlicherweise nicht immer der Fall ist.

Ohh, was meinst Du damit?

Zitat von Oliver222

Ich vertraue dabei keinem einzigen Zertifikat...

Das ist natürlich sehr sicher, schränkt leider aber auch die Funktionalität erheblich ein

Ich habe mal bei ein paar Hotlines probiert, den Fingerprint ihres Zertifikats zu erfahren. Das hat in keinem Fall geklappt. Man konnte mir nicht helfen. In einem Fall wurde mit telefonisch erklärt, wie ich das verwendete root-CA-Zertifikat permanent installiere (und ihm damit vertraue), ohne mich auf Gefahren hinzuweisen oder wenigstens zu einer Fingerprintprüfung zu veranlassen (den man mir auch auf Anfrage nicht nennen konnte).
Ein Bekannter berichtete, dass eine Hotline immerhin "ihre" Webseite geöffnet hat und den Fingerprint aus dem Browser vorlesen konnte (was jetzt ja auch nicht so im Sinne des Erfinders ist).
Interessant ist auch, wenn der Zertifikatsinhaber (O und OU im Zertifikat) nicht zur Seite paßt (hat man öfter, wenn technische Dienstleister die Server betreiben). Einmal rief ich die Hotline an, doch diese konnte mir nicht mal mitteilen, wie der technische Dienstleister heißt...

Zitat von Oliver222

st1519 erklärte Folgendes:

Somit würde sich – gemäss meiner Informationen – zwar ein ausreichendes Berechnungsintervall zur Schlüsselerzeugung selber ergeben, dessen Potential leider jedoch durch sicherheitskritische Anbieter (z.B. Online-Banken, E-Zahlungsdienstleister, etc.) weitgehendst ungenutzt verbleibt.

Könntest Du bitte Quellen nennen, die belegen, dass das Potential weitgehendst ungenutzt bleibt?
Was genau meinst Du, dass der Schlüsselraum nicht genutzt wird?

Zitat von Oliver222

st1519 erklärte darüberhinaus:

Dieser Verschlüsselungs-Standard [...] entsprach damals schon nicht mehr den gestellten Vorgaben an elektronisch-sicherheitsrelevante Infrastrukturen. (Trapdoors / Hintertüren)?

Hast Du da einen Link / Quellenangabe?
Es fällt schwer zu glauben, dass das gesammte deutsche elektronische Zahlungsnetz Hintertüren aufweisen sollte.

Zitat von Oliver222

st1519 fragte Folgendes:

Diese Zertifizierungsstelle (Root CA) muss deshalb nicht unbedingt zwangsläufig in Germany oder Europa ansässig sein. Es gibt keine „Grenzen“ für CA´s.

Für mich schon. Ich traue einer "gewöhnlichen deutschen CA" ein bißchen, weil sie etwas zu verlieren haben und daher ein gewisses Interesse daran besteht, ordentlich zu arbeiten. Ich kann auf Schadenersatz klagen.
Eine CA in China oder einem afrikanischem Zwergstaat kann ich nicht unbedingt sinnvoll verklagen, daher habe hier hier gar kein Vertrauen. CAs, die "nichts zu verlieren haben" (z.B. Hobbyprojekte wie cacert.org) kann ich persönlich nicht vertrauen und CAs, die E-Mail "Authentifizierung" anbieten auch nicht, weil ich das einfach dumm finde.

Das ist ja meine Entscheidung.

Zitat von Oliver222

Somit würde auch die SigG-Konformität - in Bezug auf CA´s in Germany / Europe – als „Vertrauensanker“ ausgehebelt werden können.

Falls Du damit auf das Signaturgesetz anspielst, muß ich wiedersprechen. Da sollte der „Vertrauensanker“ nicht ausgehebelt werden können, da in jedem Fall Gutachten erforerlich sind. Dabei bleibt natürlich die Frage, was das einem nützt.
Ich persönlich halte das Signaturgesetz für einen großen Fehler und bin dagegen. Ich möchte keinesfalls eine digitale rechtsverbindliche Unterschrift erzeugen können, da es mißbraucht werden könnte - wie auch immer das abgesichert sein mag, ein Angriff läßt sich finden.

Leider wird man sich dagegen nicht ewig wehren können (siehe ELENA)...

Zitat von Oliver222

Zertifikate, die überregional in unterschiedlichen administrativen Domänen ausgestellt werden, stellen darüberhinaus – meinen Informationen nach – ein nicht ganz unerhebliches Sicherheitsrisiko dar. (siehe z.B. Diskussion um die neuen Reisepässe.).
Oliver

Ich glaube nicht, dass es bei den neuen Pässen um Sicherheit geht, dazu gibt es viele Informationen. Soweit mir bekannt, wird von offizieller Seite weder behauptet, dass die neuen Pässe sicherer wären, noch das die Verfahren billiger würden (beides stimmt allgemein wohl aktuell auch überhaupt nicht). Bei den neuen Pässen geht es meines Verständnisses nach um Überwachung und Kontrolle; begründet wird das mit "Anti-Terror-Hype", um die Menschen zu täuschen.

Ohh, jetzt war ich sehr off-topic, sorry.

St.

(Das verlinkte Dokument ist von 1997 und beschreibt sicherlich das ganz alte ec-PIN Verfahren).
Es gibt durchaus praktikable und praktizierte technische Möglichkeiten, sehr gute Zufallszahlen zu erzeugen. In Deutschland sollte man davon ausgehen können, dass diese auch korrekt genutzt werden.