WWW: Schwache Authentisierung durch Passwortschutz

(Basic Authentication)

• Teil der HTTP-Spezifikation.
• Zugriffskontrolle mit Benutzername/Passwort.
• Zugriffskontrollisten (ACL) (.htaccess oder Konfigurationsdatei des WWW-Servers).
• Benutzergruppen möglich.
• Zugriff auf bestimmte IP-Adressen beschränkbar.

Probleme:

• Passwörter gehen im Klartext übers Netz.
• Dokumente ebenfalls.
• IP-Nummern fälschbar.
• Keine Sicherung der Integrität.
• Für jeden Dienst eine neue Passwortabfrage.

Einbau von Sicherheitsdiensten in HTTP

• PGP in NCSA httpd + Mosaic verwendbar (auch RIPEM)
• S-HTTP -
  • Erweiterung des HTTP-Protokolls shttp://...
  • Referenzimplementation in Mosaic
• SSL (TLS) von Netscape,
  • eingebaut in Netscape-Server und -Navigator.
  • RSA und RC4,
  • Exportversion nur mit 40-Bit-RC4-Schlüsseln.
• Kerberos -
  • kerberisiertes NCSA httpd und Mosaic.
  • DCE-Web - basierend auf Kerberos.

SSL hat sich durchgesetzt, wird inzwischen von allen Browsern verstanden und ist in alle Server leicht einbaubar.

SSL

• SSLref von Netscape (nur US, kostenlos)
• SSLeay von Eric Young <eay@mincom.com> und Tim Hudson <tjh@mincom.com> (weltweit, Public Domain). Aktuelle Weiterentwicklung:
• OpenSSL

Netscape - Sicherheitsstatus

Ein Dokument ist

• sicher,
• unsicher
• oder gemischt.

URL für sichere Server beginnt mit https://... bzw. snews://...

Sicherheit also Server-gesteuert.

Warnung bei unsicherem submit-Prozess (Passwort, Kreditkarten-Nummer, ...)

Keine Verwendung für private Benutzer-Schlüssel,

• Sitzungsschlüssel beim Client erzeugt,
• an Server übermittelt.

In SSL 3.0 erstmals Client-Zertifikate vorgesehen; diese auch für E-Mail nutzbar.

Was ist falsch an der gängigen SSL-Praxis?

Die gängigen Implementationen von SSL verwirklichen nicht eine PKI, sondern sind eine zur Unkenntlichkeit verstümmelte Karikatur einer PKI.

• Zertifikatsanforderung des Browsers führt zu kommerzieller CA, die Schlüssel erzeugen will. Selbst erzeugte Schlüssel sind nur schwer einzubauen.
• Die CAs verdienen an Zertifikaten, obwohl diese nichts aussagen ... (Beispiel: Auf den Namen Microsoft ausgestelltes Server-Zertifikat)
• ... und obwohl man Zertifikate kostenlos selbst herstellen kann (OpenSSL). Der Nutzer muss sich nur beim ersten Besuch eines Servers mit Hilfe des Fingerprints von der Korrektheit des öffentlichen Schlüssels überzeugen.
• Von Verisign oder Thawte erhält man Zertifikate, die nur besagen, dass man unter der (damals) angegeben Adresse E-Mail empfangen kann.
• Die kommerziellen CAs haften für nichts.
• Microsoft versucht mit Hilfe des Code-Signing, andere Software-Hersteller als nicht vertrauenswürdig hinzustellen.
• Vernebelung des Begriffs »Zertifikat«. Der Unterschied zwischen privatem und öffentlichen Schlüssel wird versteckt. Die eigentliche Bedeutung wird verschleiert; der Nutzer erhält den Eindruck, Server seien in irgendeiner Weise für ihre Sicherheit oder Qualität »zertifiziert«.
• CA-Zertifikate von Verisign u. a. CAs fest eingebaut: Ungerechtfertigter Vertrauensvorschuss - Server, die ihr Zertifikat von einer solchen CA haben, werden automatisch als vertrauenswürdig behandelt.
• Anzeige der Server-Zertifikate gibt keine Information über anwendbare Verschlüsselungsstärke.
• Ein SSL-geschütztes Web-Formular sorgt nicht für verschlüsselte Übertragung der Daten - nur wenn das auswertende CGI-Skript auch SSL-gesichert ist. Das Schloss-Symbol im Browser ist hier irreführend.
• Auf einer SSL-geschützten Web-Seite mit Zertifikat können beliebige Logos eingebunden werden und einen falschen Eindruck erwecken.
• Installation von Client-Zertifikaten umständlich.
• Verwendung von Zertifikaten auf Chipkarten nicht direkt möglich.

»SSL at best has this weird system in which Verisign has somehow managed to charge web sites a toll for the use of SSL even though for the most part the certificates assure the users of nothing whatsoever. (If you don't believe me about the assurance levels, read a Verisign cert practice statement sometime.« (Perry Metzger in der Kryptographie-Liste cryptography@wasabisystems.com am 26 Dec 2001)

Single Login (Single Sign-On, SSO)

1. Dezentrale Lösung:
   • Der Nutzer meldet sich einmal an: bei seinem PSE (Chipkarte) mit PIN oder Passphrase.
   • Alle Dienste authentisieren den Nutzer durch Challenge-Response direkt mit dem PSE.
   Bei webbasierten Diensten regelt das der Browser.
2. Zentralistische Lösung:
   • Der Nutzer meldet sich einmal bei einem zentralen Server an.
   • Alle anderen Dienste holen sich Authentisierungs-Informationen von dort (z. B. dort gespeicherte Passwörter und Kredikarten-Informationen)
   Der zentrale Server ist mächtig - ein selbsternannter Treuhänder »Trent«. Beispiel: Microsofts Passport (Teil von .NET).

Zukunft Passport?

Mit solchen völlig fehlkonstruierten Authentisierungsdiensten werden die Firmen in Zukunft mehr Geld verdienen, als sie es mit einer PKI jemals könnten.

Weitere Informationen

• Die Einrichtung sicherer HTTP-Server
• openSSL
• DFN-PCA: X.509v3/SSL-Zertifizierung
• mod-SSL
• apache-SSL
• SSL-FAQ