Re: Was darf Sicherheit kosten und was sollte Sie uns wert sein?

Autor: Thomas Jäger <jaeger_at_thjaeger.org>
Datum: Mon, 07 Jan 2008 00:35:01 +0100
Hallo,

Marc Haber wrote:
> On Sun, Jan 06, 2008 at 01:14:10PM +0100, Thomas Jäger wrote:
>> Marc Haber wrote:
> Die Verwendung von Zertifikaten zur Verschlüsselung musst Du mir
> erklären.

Das Handshake im SSL/TLS Protokoll (genauer der Austausch des 
Folgeschlüssels) wird mit dem Zertifikat zugehörigen privaten Schlüssel 
verschlüsselt. Erst nach der Aushandlung eines (temporären) Schlüssels 
wechselt die Verschlüsselung auf die effizientere (da symmetrische) Methode.
Wenn Du auf eine präzisere Wortweise hinaus möchtest:
Das Zertifikat enthält die Signatur des CAs des öffentlichen Schlüssels 
sowie den öffentlichen Schlüssel für den privaten Schlüssel aus obiger 
initialer Verschlüsselung.
Mir ist jedoch die Intention Deiner Frage nicht ganz klar, da Du sie Dir 
mit Deinem Wissen gut selbst beantworten kannst?

>> Zur Verschlüsselung würden vorerst selbst-signierte Zertifikate 
>> ausreichen, wenn man nicht das Man-in-the-middle Problem hätte:
>> Kapert man die Verbindung, so würde man ohne 2) und die zugehörige 
>> Browserwarnung nicht erkennen, dass mit dem Zertifikat etwas nicht in 
>> Ordnung ist.
> 
> Das ist richtig. Ich habe nie behauptet, dass man bei selbstsignierten
> Zertifikaten nicht irgend eine Art von Identitätsprüfung vornehmen
> muss. Und ich würde einem selbstsignierten Zertifikat, dessen
> Fingerprint ich persönlich vom Aussteller verifiziert habe, mehr
> vertrauen, als einem von Verisign.

Wenn Du Verisign misstraust (was scheinbar der Fall ist), so kannst Du 
Verisign ja aus Deinen akzeptierten Rootzertifikaten herausnehmen. Ich 
für meinen Teil traue eher Verisign als einem selbstsignierten 
Zertifikat und finde die Warnung der Browser sinnvoll und notwendig. 
Wenn die CA persönlich bekannt ist, ist es sicherlich anders, aber wie 
häufig kommt das schon vor?
Dumm, und da stimme ich dem Vorredner zu ist nur, dass die Verbindung 
durch die Warnung als unsicherer als http empfunden wird.

>>  Weiterhin müssen offizielle Zertifikatsstellen für Ihre Zertifikate
>>  gerade stehen.
> 
> Welche Haftungssummen stehen denn in den typischen AGBs von
> kommerziellen CAs?

Ich reduziere mal auf das deutsche Recht:
- Betrug: Wenn zu Betrugszwecken absichtlich falsche Zertifikate 
erstellt werden.
- Fahrlässigkeit: Auch wenn durch Fahrlässigkeit dem Benutzer (hier 
Zertifikatsnehmer) ein Schaden entsteht ist die Firma durchaus haftbar.
Die Haftungsgrenze liegt bei Verisign (soweit ich es in Erinnerung habe) 
bei $100000 (Klasse 3 Zertifikat).
Im Falle Deines Beispieles (Microsoft) geht es ebenfalls um Betrug vom 
Antragsteller und könnte rechtlich verfolgt werden.

Dies trifft zwar auch (begrenzt) für selbst-signierte Zertifikate zu, 
jedoch verdient eine Firma wie Verisign ihr Geld mit Zertifikaten und 
kann sich einen schlechten Ruf nicht leisten. Dein Beispiel zeigt es: 
dieser Vorfall ist bereits fast 7 Jahre her, betrifft "nur" 
Softwarezertifikate und es ist einmal vorgekommen. Oder gibt es einen 2. 
Fall, der mir entgangen ist?

>>  Passiert ein Unfall, so können relativ schnell die Rootzertifikate
>>  aus den Browsern/Umgebungen ungültig gemacht werden (Securityupdates
>>  der OS/Browser Hersteller oder CRLs).
> 
> Welche kommerzielle CA hat ihre CRL konsequent im Griff? Ich sehe,
> dass dieses "Problem" von den meisten kommerziellen CAs durch
> Weggucken gelöst wird. Hat der IE überhaupt den Zugriff auf die CRLs
> der kommerziellen CAs automatisch implementiert?

Z.B.: http://www.verisign.com/repository/crl.html
Hier sind meines Erachtens die Webbrowserhersteller gefragt, für alle 
ausgelieferten (Root-) Zertifikate auch die entsprechenden CRLs zu 
hinterlegen und standardmässig OCSP zu aktivieren. Firefox ist hier 
(fast) vorbildlich.
Zum IE: Keine Ahnung. Wir reden doch hier von Sicherheit?

>>  Zu Deinem selbst-signierten Zertifikat: Schreiben wir uns demnächst
>>  unsere Personalausweise in Zukunft auch selbst, weil wir dann dafür
>>  gerade stehen? ;) Sinn und Zweck ist es, dass jemand dem ich vertraue
>>  Deine Identität bestätigt. Von Dir selbst kannnst Du ja schliesslich
>>  behaupten was Du willst.
> 
> Es sei denn, ich kann mich anderweitig, z.B. durch meinen
> Personalausweis, autentifizieren.
> 
> Willst Du _WIRKLICH_ Versign vertrauen?

S.o. Was hast Du Ihnen denn vorzuwerfen? Wenn es konkret ist, sollte man 
die Deutsche Bank, die DiBa oder die Dresdner Bank (um nur einige Kunden 
zu nennen) informieren ;)
Verstehe mich nicht falsch, dass ich hier für Verisign Werbung machen 
würde. Nur klang die Diskussion schon ein bisserl nach "Evil Empire" und 
Verschwörung (was ich vielleicht auch überinterpretiere).

>>  Aus diesem Grund finde ich das "Web of Trust" von CA Cert nicht
>>  schlecht, da es diese Bekanntschaftsverhältnisse dezentral auflöst.
>>  Rechtlich ist dies jedoch vermutlich sehr wackelig.
> 
> Und technisch leider genauso unbrauchbar wie eine lokale Klein-CA oder
> selbstsignierte Zertifikate, weil die allermeisten Netzbenutzer mit
> dem Import eines Root-CA in den Ceritificate Store ihrer Anwendung
> völlig überfordert sind.

Aber hier hätte man einen Ansatzpunkt. Debian kommt bereits mit ca-certs 
root Zertifikaten mit. Wie sich die Browserhersteller dazu verhalten 
steht (noch) auf einem anderen Blatt.

 >> Dies ist nunmal der Sinn und Zweck von Verschlüsselung.
> Du musst mir erklären, inwieweit IP-based virtual hosting sicherer ist
> als name-based virtual hosting.

Sorry, habe die Ironie-Tags vergessen. Man kann auch zuviel verschlüsseln.

>>  Soll ja keiner mitlesen können ;) Aber auch hier gibt es Lösungen:
>>  HTTPS-Terminierung durch den Loadbalancer um dann in der DMZ normales
>>  name-based virtual hosting zu machen. Siehe hierzu auch die
>>  Bedingungsanleitung Deiner BIG-IP ;)
> 
> Ich würde an dieser Stelle Foundry bevorzugen, aber das ist eine
> Geschmacks- und Politikfrage. 

Wollte auch keine Werbung machen, mit denen hatte ich halt bisher am 
meisten zu tuen.

> Außerdem musst Du mir erklären, wie eine
> Loadbalancinglösung entscheiden kann, welches Zertifikat sie an einen
> Client überträgt, der außer der angesprochenen IP noch keinen Request
> übermittelt hat und von dem ich also im Falle von name-based virtual
> hosting noch nicht weiß, welchen virtuellen Host er überhaupt
> ansprechen möchte.

Etwas missverständlich von mir, da ich (stillschweigend) nicht von der 
technischen Umsetzung ausgegangen war:
Named based virtual hosting ist m.E. eine Lösung, die im wesentlichen 
Konsolidierung der Hardware und Konfigurationsarbeit ermöglicht. Nicht 
jede Domain braucht einen eigenen Webserver => Ziel ist es also meines 
Erachtens, nur einen logischen (im Sinne von Anzahl) Webserver 
bereitzustellen.
Obiges Szenario mit LB ist nur eine Lösung hierzu. Der LB selbst hat 
dabei natürlich noch weiterhin n-IP Adressen. Aber der LB ist "sowieso 
immer da" und kann bei Bedarf SSL/TLS in Hardware. Und der Webserver 
kann das entschlüsselte HTTP entgegennehmen und seine Hosts zwecks 
Weiterbehandlung auslesen.

> http://www.enyo.de/fw/security/notes/pki-loses-tls.html

Leider fehlt dem Artikel eine Bewertung der Technologien. In welchem 
Rahmen (Internet, Intranet?) sind sie durchführbar bzw. praktikabel? So 
erscheint mir der Artikel erstmal "nur" als reine Informationssammlung.


Viele Grüße
  Thomas

-- 
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/
Empfangen am 07.01.2008

Dieses Archiv wurde generiert von hypermail 2.2.0 : 07.01.2008 CET