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

[Thomas Jaeger <jaeger@xxxxxxxxxxxx>]

Hallo,

Marc Haber wrote:
> On Sun, Jan 06, 2008 at 01:14:10PM +0100, Thomas Jaeger wrote:
>> Marc Haber wrote:
> Die Verwendung von Zertifikaten zur Verschluesselung musst Du mir
> erklaeren.

Das Handshake im SSL/TLS Protokoll (genauer der Austausch des 
Folgeschluessels) wird mit dem Zertifikat zugehoerigen privaten Schluessel 
verschluesselt. Erst nach der Aushandlung eines (temporaeren) Schluessels 
wechselt die Verschluesselung auf die effizientere (da symmetrische) Methode.
Wenn Du auf eine praezisere Wortweise hinaus moechtest:
Das Zertifikat enthaelt die Signatur des CAs des oeffentlichen Schluessels 
sowie den oeffentlichen Schluessel fuer den privaten Schluessel aus obiger 
initialer Verschluesselung.
Mir ist jedoch die Intention Deiner Frage nicht ganz klar, da Du sie Dir 
mit Deinem Wissen gut selbst beantworten kannst?

>> Zur Verschluesselung wuerden vorerst selbst-signierte Zertifikate 
>> ausreichen, wenn man nicht das Man-in-the-middle Problem haette:
>> Kapert man die Verbindung, so wuerde man ohne 2) und die zugehoerige 
>> 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 Identitaetspruefung vornehmen
> muss. Und ich wuerde einem selbstsignierten Zertifikat, dessen
> Fingerprint ich persoenlich 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 
fuer meinen Teil traue eher Verisign als einem selbstsignierten 
Zertifikat und finde die Warnung der Browser sinnvoll und notwendig. 
Wenn die CA persoenlich bekannt ist, ist es sicherlich anders, aber wie 
haeufig 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 muessen offizielle Zertifikatsstellen fuer 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.
- Fahrlaessigkeit: Auch wenn durch Fahrlaessigkeit 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 koennte rechtlich verfolgt werden.

Dies trifft zwar auch (begrenzt) fuer 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 koennen relativ schnell die Rootzertifikate
>>  aus den Browsern/Umgebungen ungueltig 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 geloest wird. Hat der IE ueberhaupt 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, fuer alle 
ausgelieferten (Root-) Zertifikate auch die entsprechenden CRLs zu 
hinterlegen und standardmaessig 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 demnaechst
>>  unsere Personalausweise in Zukunft auch selbst, weil wir dann dafuer
>>  gerade stehen? ;) Sinn und Zweck ist es, dass jemand dem ich vertraue
>>  Deine Identitaet bestaetigt. 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 fuer Verisign Werbung machen 
wuerde. Nur klang die Diskussion schon ein bisserl nach "Evil Empire" und 
Verschwoerung (was ich vielleicht auch ueberinterpretiere).

>>  Aus diesem Grund finde ich das "Web of Trust" von CA Cert nicht
>>  schlecht, da es diese Bekanntschaftsverhaeltnisse dezentral aufloest.
>>  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
> voellig ueberfordert sind.

Aber hier haette 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 Verschluesselung.
> Du musst mir erklaeren, inwieweit IP-based virtual hosting sicherer ist
> als name-based virtual hosting.

Sorry, habe die Ironie-Tags vergessen. Man kann auch zuviel verschluesseln.

>>  Soll ja keiner mitlesen koennen ;) Aber auch hier gibt es Loesungen:
>>  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 wuerde 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.

> Ausserdem musst Du mir erklaeren, wie eine
> Loadbalancingloesung entscheiden kann, welches Zertifikat sie an einen
> Client uebertraegt, der ausser der angesprochenen IP noch keinen Request
> uebermittelt hat und von dem ich also im Falle von name-based virtual
> hosting noch nicht weiss, welchen virtuellen Host er ueberhaupt
> ansprechen moechte.

Etwas missverstaendlich von mir, da ich (stillschweigend) nicht von der 
technischen Umsetzung ausgegangen war:
Named based virtual hosting ist m.E. eine Loesung, die im wesentlichen 
Konsolidierung der Hardware und Konfigurationsarbeit ermoeglicht. 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 Loesung hierzu. Der LB selbst hat 
dabei natuerlich 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 entschluesselte 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 durchfuehrbar bzw. praktikabel? So 
erscheint mir der Artikel erstmal "nur" als reine Informationssammlung.


Viele Gruesse
  Thomas

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