ubuntuusers.de

Moin Moin,

Warum gibt´s eigentlich kein https://*.ubuntuusers.de?
Dann müsste man sich nicht immer im Klartext anmelden, sei es Forum oder Wiki. Außerdem wäre es eine klasse Gelegenheit für ubuntuusers.de ein Zeichen zu setzen, in dem ein kostenloses cert von cacert.org implementiert wird.

Danke für den Vorschlag, ich leite das mal weiter ☺

warum wurde das nicht umgesetzt?

ich finde eine ssl-verbindung wirklich wichtig ...

kann das vielleicht einfach nochmal thematisiert werden und nach dem umstieg auf inyoka umgestellt werden??

gruß, ska.ndal

Gabs den Vorschlag nicht früher schon und das Team meinte dann, dass die Server die zusätzliche Last nicht verkraften würden? An irgendsowas glaube ich mich erinnern zu können. Ansonsten fände ich SSL auch gut ☺

Gruß,
maschino

Wir teilen uns die Server mit anderen Communities aus der eu, und es gibt immer noch Probleme bei vhosts + SSL bzw. TLS, weshalb das leider nicht möglich ist.

Was für Probleme? Vielleicht kann man die ja lösen... ich setze auf einem Server mehrere VHOSTS mit SSL ein und sehe da momentan kein Problem.

OnIce hat geschrieben:

Was für Probleme?

Ich denke es geht vor allem um den Resourcenverbrauch, den die Verschlüsselung verschlingt. Vor allem bei den Milliarden an Nutzern, die hier Stündlich vorbeischneien. Und das Caching der Seiten ist dann wohl auch nicht mehr ohne weiteres möglich.

Bei name based virtual Host muss der Browser bei jeder Anfrage einen Host-Header mitschicken, an dem der Webserver dann erkennt um welchen Host es sich handelt (wir haben zu wenig IPs um alle ubuntu-eu Domains und Subdomains zu versorgen). Da bei TLS die Verbindung aber verschlüsselt ist, kann der Webserver nicht mehr erkennen an wen das Paket gerichtet ist und mit welchen Zertifikat er es entschlüsseln muss.

Was spricht denn dagegen, dass alle Ubuntu-Eu-Domains das gleiche Zertifkat nutzen?

Was spricht denn dagegen, dass alle Ubuntu-Eu-Domains das gleiche Zertifkat nutzen?

Es würde zu einer Zerfitikatswarnung führen und verunsichert die Anwender wohl noch mehr.

Mal als Beispiel das Zertifikat CN=www.verisign.com

https://www.verisign.com (korrekter Aufruf, da Name mit CN übereinstimmt)
https://65.205.249.60 (Warnung, da der Name nicht mit der CN übereinstimmt)

Was macht eigentlich der Browser, wenn man CN (common name) frei lässt? Kommt dann die Frage, ob Ubuntu Europe der Besitzer von ubuntuusers.de ist? Muss ich mal ausprobieren. Und eine IP-Adresse kann man nicht nehmen?

Soweit ich weiß ist CN ein Pflichtfeld und selbst wenn man es weglassen könnte würde es zu dem oben angesprochenen Fehler führen. Die IP-Adresse kann man auch schlecht nehmen, da man dann nicht virtuelle Webserver nutzen kann. Vielleicht irgendwie mit Unterverzeichnissen, sieht aber bestimmt ziemlich dumm aus.
Es müsste SSL-basierte Authentisierungsserver geben. Der Anwender würde sich SSL-verschlüsselt dort anmelden, würde irgendein Key oder sonstwas erhalten und würde dann normal mit dem eigentlichen HTTP-Server in Klartext mit einer Art Challenge-Response-Authentifizierung kommunizieren. Mag es aber wohl schon geben.

Man darf eine IP-Adresse nehmen, aber nicht wenn man sie über eine Domain erreicht? In welcher RFC steht das? Wahrscheinlich muss man sein SIP-Zertifikat dann auch ändern, wenn man ENUM nutzt... Das ergibt wirklich keinen Sinn.

OnIce hat geschrieben:

...ein Zeichen zu setzen, in dem ein kostenloses cert von cacert.org implementiert wird.

Nützt im Moment nur noch nichts, weil der Warnhinweiss auch weiterhin kommen wird.
cacert.org ist (noch) nicht offiziell anerkannt.

SnowMann

Moin,
die cert warnung könnte man doch erklären z.b. im wiki, wenn jemmand danach sucht.