ubuntuusers.de

Das würde nur die Unart fördern Warn-/Fehlermeldungen ungelesen wegzuklicken. Das Problem ist nicht die Fehlermeldung die dann bei UU erscheinen würde, sondern dass dann andere Meldungen in den Augen des Users an Wichtigkeit verlieren.

Da ist was mit Zertifikat blah blah blah bei meiner Bankseite. ... Ach bei UU klick ich so ne Meldung auch immer weg...

Sofern das nicht vollkommen problemlos für den Nutzer umgesetzt werden kann, und Warnungen jeglicher Art haben nichts mit problemlos zu tun, gibt es ein klares "Nijet" von mir. Ubuntu-Anfänger sind schon verwirrt genug, wenn sie ein neues Betriebssystem nutzen, da müssen nicht noch Zertifikat-Warnungen dazukommen.

Denkbar für mich wäre eine per SSL verschlüsselt übertragene Loginseite, die nicht groß beworben wird und wo auch nochmal beschrieben wird, dass der Browser eine Warnung ausgeben wird. So wäre allen Seiten geholfen

* Der SSL Login erzeugt sicherlich nur eine marginale Last
* Die User, die ein SSL-Login haben wollen, haben eines
* Menschen ohne Paranoia 😉 werden nicht mit dem mangelhaften SSL-Zertifikat in Berührung kommen

Irgendwie liest keiner die anderen Posts in dem Thread hier, oder? 🙄

Es ist nicht die Last das Problem, und auch nicht das wir bei einer Zertifizierungstelle ein Zertifikat beantragen müssten (da könnte der Verein sicher was machen...). Außerdem hat es auch wenig Sinn nur die Login-Seite zu verschlüsseln, weil dann hätte ein potentzieller Angreife halt noch nicht bei der Anmeldung, sondern erst beim 2ten Request den Zugang über die Session...

Das Problem ist, das wir a) viele Domains haben und b) nicht alleine auf den Servern sind. Und da wir nicht soviele IPs bekommen gibt es keine Möglichkeit die Anfragen dann zu unterscheiden.

Gruß
Christoph

Dieses Zertifikat wurde auf die IP 213.95.41.11 ausgestellt. Da Sie die Verbindung aber durch Eingabe der Domain ubuntuusers.de hergestellt haben, kommt hier eine böse Warnmeldung. Geben Sie nächstes mal bitte die IP-Adresse direkt ein. Ihr Browser ist nämlich nicht in der Lage die IP-Adresse mit dem Zertifikat zu vergleichen, wenn in der Adressleiste etwas anderes als die IP-Adresse angeben wurde.

Das ist das Problem. Auf diese Fehlermeldung beziehen sich Fury1306, agra und Chrissss, denke ich.

Ist aber genauso sinnlos, da man Ubuntuusers nicht über eine IP erreichen kann... (Stichwort vhosts wie oben erklärt).

ubuntuusers.de ist über die IP-Adresse 213.95.41.11 / 2001:780:0:25::80 mit Angabe des Hosts http://ubuntuusers.de erreichbar. HTTP-Daten werden erst übertragen, nachdem die Transportschicht aufgebaut wurde. Also wird erst nach der Verschlüsselung der Host über HTTP angegeben.

Wenn man halt mehrere Zertifikate hat:

• Benutzer tippt ubuntuusers.de

• ubuntuusers.de wird zu 213.95.41.11 aufgelöst

• Client: Hallo, Server 213.95.41.11 auf Port 443!

• Server (denkt sich): Oh nein, ich habe verschiedene Zertifkate für verschiedene Domains! Welches soll ich nur vorzeigen? Ich darf nicht das falsche vorzeigen. Na dann warte ich mal auf TLS 1.2. Bei diesem kann die gewünschte Domain mitangegeben werden.

• Server: Ich kann leider keine Verbindung aufbauen. Sorry!

Das geht aber auch so:

• Benutzer tippt ubuntuusers.de

• ubuntuusers.de wird zu 213.95.41.11 aufgelöst

• Client: Hallo, Server 213.95.41.11 auf Port 443!

• Server: Ich hab hab ein tolles Zertifkat für meine IP-Adresse! Ich schick es dir mal!

• Client: Scheint alles korrekt zu sein. Du bist tatsächlich 213.95.41.11. Dann fahren wir jetzt mit der verschlüsselten Kommunikation fort.

• Client: Also ich hätte jetzt eine HTTP-Anfrage an http://ubuntuusers.de

• Server schaut nach dem geeigeneten vhost

• Server: OK. Hier der Inhalt von http://ubuntuusers.de.

• Client: Danke. Wir sehen uns dann später wieder!

Die Verschlüsselung kommt schon vor den vhosts. TLS ist schließlich eine Ebene unter HTTP.

Das TLS das Frame für HTTP ist, ist ja genau das Problem, daher ist ja auch der Host-Header verschlüsselt (wie in deinem ersten Beispiel).

Das man Zertifikate auch auf IP Ebene austellen kann, hab ich bisher noch nicht probiert (also ka ob das geht), ist aber bei uns trotzdem noch problematisch, da wir dann ein Shared-Zertifikat hätten, was ja auch nicht der Sinn von Zertifikaten ist. Da geht es ja genau darum die Gegenstelle zu authentifizieren. Außerdem ändert sich die Server Topologie öfters (jetzt z.B. aufgrund des Releases, später dann mit Inyoka, und es ist auch schon ein paar mal vorgekommen, dass wir das RZ gewechselt haben) wodurch da was IP basiertes irgendwie zu unflexibel wäre.

Also warten wir mal auf TLS 1.2 ☺

wenn man das ca-zertifikat installiert, kommen die warnungen nichtmehr - vorausgesetzt CN stimmt überein.
Man könnte also ein self-signed CA im ubuntu release mit integreieren, somit wäre die Warnung vom Tisch

Es scheint möglich zu sein, ein Zertifikat für mehrere Domains zu nutzen: http://wiki.cacert.org/wiki/VhostTaskForce

Und warum nimmt ihr nicht jetzt ein Zertifikat in dem mehrere Domains stehen?

In der Juni-Ausgabe vom Linux-Magazin wurde genau dieses Problem besprochen. Die Lösung lautet "Server Name Inication". Das ganze auch wie weiter oben erwähnt in http://wiki.cacert.org/wiki/VhostTaskForce unter Punkt 5 beschrieben.
Der Vorteil einer verschlüsselten Loginseite ist ganz klar: Benutzername/Passwort werden nicht mehr im Klartext übertragen.

Ist das nun eine Lösung oder wird doch auf TLS 1.2 gewartet?

Gizzmo schrieb:

Der Vorteil einer verschlüsselten Loginseite ist ganz klar: Benutzername/Passwort werden nicht mehr im Klartext übertragen.

Ohne Frage. Ein Zertifikat einer anerkannten CA kostet aber Geld.

Ich arbeite in einer Bank und da werden https-Server mit "self-signed certificates" oder mit Zertifkaten von unbekannten Ausstellern nicht angezeigt.

Vielleicht lohnt es sich noch einmal einen Gedanken an OpenID zu verschwenden.

Gruss

Dirk

tux21b schrieb:

Also warten wir mal auf TLS 1.2 ☺

Und das ist seit August 2008 freigegeben. ☺