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

[Marc Haber <mh+uugrn@xxxxxxxxxxxx>]

On Sun, Jan 06, 2008 at 01:14:10PM +0100, Thomas Jaeger wrote:
> Marc Haber wrote:
> >Vor allen Dingen, weil ein gekauftes Zertifikat ja obendrein auch noch
> >weniger sicher ist als ein selbst gebautes: Die kommerziellen CAs
> >haben im Prinzip alle schonmal Mist gebaut (z.B. einem Cracker ein
> >Zertifikat auf den Namen Microsoft ausgestellt); bei der eigenen CA
> >kann ich selbst fuer die Sicherheit gerade stehen.
> 
> Das halte ich fuer ein Geruecht (mit der Sicherheit). Sicher kann mal was 
> schiefgehen, bei offiziellen Stellen faellt dies zumindest auf.

Tut es das?

> Welchen Sinn haben denn Zertifikate?
> 1) Verschluesselung
> 2) Identitaet sichern

Die Verwendung von Zertifikaten zur Verschluesselung musst Du mir
erklaeren.

> 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.

>  Weiterhin muessen offizielle Zertifikatsstellen fuer Ihre Zertifikate
>  gerade stehen.

Welche Haftungssummen stehen denn in den typischen AGBs von
kommerziellen CAs?

>  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?

>  Hast Du fuer Deine einmal ausgerollten Zertifikate aehnliche
>  Rueckholmoeglichkeiten?

Nun, wenn ich Wert darauf lege, mache ich eine eigene CA auf und
verteile nicht meine selbst signierten Zertifikate, sondern mein
Root-Zertifikat.

>  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?

>  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.

> >Irgendwie ist https total kaputt: Man kann kein name-based virtual
> >hosting machen
> 
> 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.

>  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. 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.

> >Ma "fangen wir mal mit STARTTLS ueber http an" rc
> 
> Damit loest Du allerdings nur das name-based virtual hosting (der 
> Hostname koennte vor der Verschluesselung uebertragen werden).

Genau, das ist ja schonmal ein Anfang.

> Die Zertifikats-Infrastruktur wirst Du damit nicht los.

Das habe ich auch nie behauptet.

Gruesse
Marc, gerade gestern ueber
http://www.enyo.de/fw/security/notes/pki-loses-tls.html geblogged habend

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190
-- 
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/