Sherlock Holmes und Professorin Moriarty

Hadmut, erstmal Gratulation, auch wenn der Rezensent offenbar auch vorher schon Deiner Meinung war. Aber die Überschrift ist echt klasse!!

>>die Frauenquote bei den Bösewichtern<< wird doch gerade im mittlel-/südamerikanischen Drogenbandenmilieu schön angehoben, oder woher kommen die ganzen Meldungen gerade? Wobei das ja gut angesehen sein muss bei den Genderistinnen: Biologische Frauen (nur mal angenommen, dass es die gäbe), die eben nicht per rosa Überdosis zu sozialen Frauen verformt wurden. Schon mal an die Zücht … Heranbildung rein weiblicher Spezialeinheiten bei den Armeen der Welt denken. Nein, haha, nicht wegen der "Waffen der Frauen", sondern wegen der Quote.

Schick. Ich bin noch am überlegen, ob ich es will.

PS: Ist das eigentlich so gewollt, dass das Block nicht mit HTTPS funktioniert? (Gibt einen 404.)

@Svenska: Gewollt nicht, aber technisch derzeit nicht möglich.

Der Server, auf dem diese Webseiten laufen, wird von knapp 30 Leuten benutzt, die jeweils mehrere Webseiten betreiben, weshalb größenordnungsmäßig etwa 100 virtuelle Webserver auf der Maschine laufen. Das ist kein Problem, denn HTTP unterstützt das ja extra. Der Client teilt in der Anfrage nicht nur den Teil des URLs nach dem Servernamen per HTTP-Request mit, sondern im Header auch den Namen des logischen Servers. Deshalb weiß der Server, welchen man anfragt, und kann den richtigen auswählen. Deshalb funktioniert es übrigens nicht, wenn Du die IP-Adresse statt des DNS-Namens in den URL schreibst, weil der Server dann nicht weiß, welchen virtuellen Server Du meinst.

Bei HTTPS besteht aber das Problem, dass die SSL-Verbindung ausgehandelt werden muss, bevor ein HTTP-Request übertragen wird. Der Server kann beim Aufbau der SSL-Verbindung noch nicht wissen, welchen virtuellen Server man anfragt und deshalb auch nicht wissen, unter welchem Namen er angesprochen wird. Er muss aber ein Zertifikat präsentieren, in dem dieser Name drinsteht, damit der Browser es für echt hält und nicht wegen Betrugsverdacht abbricht. Damit der Server das passende Zertifikat wählen kann, müsste er also schon vorher wissen, welchen virtuellen Server (also in diesem Fall http://www.danisch.de) er anspricht, bevor der Client es mitgeteilt hat. Geht nicht.

Eine theoretisch denkbare Lösung dafür wäre es, ein Zertifikat zu erstellen, in dem einfach alle virtuellen Server aufgelistet sind. Habe ich mal vor einiger Zeit ausprobiert, fressen die Browser aber nicht.

Eine andere Lösung des Problems existiert noch, man hat vor Jahren mal ein Protokoll ersonnen, in dem der Browser schon vor der Verschlüsselung mitteilt, welchen virtuellen Server er ansprechen will, damit der Server das richtige Zertifikat wählen kann. Ist aber erstens nicht komplett vertraulich und zweitens nie richtig und flächendeckend in den Browsern implementiert worden. Würde mein Problem lösen, ist aber einfach nicht breit verfügbar.

Eine dritte Lösung wäre, das Blog in dem nicht-virtuellen Teil des HTTPS-Servers, also einfach unter einem anderen URL einzublenden. Das hatte ich anfangs sogar, damit bei der Administration, wenn ich Artikel schreibe usw. Inhalte, Passworte usw. nicht im Klartext übers Netz gehen. WordPress ist aber so katastrophal vermurkst (worüber ich schon des öfteren gefluch-blogt habe), dass es einfach nicht funktioniert. WordPress kann das nicht, weil die Autoren von WordPress jeden erdenklichen JavaScript-Klimbim implementieren, aber auf Sicherheit pfeifen und sie auch nicht verstehen.

Eine vierte Lösung wäre, es auf nicht-virtualisierte Art zu machen. Dazu bräuchte man aber entweder für jeden logischen Webserver einen separaten Port, was viele Firewalls nicht akzeptieren. Oder eine separate IP-Adresse. Dafür haben wir nicht genug IPv4-Adressen. Mit IPv6 wär’s wohl möglich, wir hatten aber noch nicht genug Zeit und genug Heim-IPv6-Anschlüsse, um das so zu testen, dass das in den Produktivbetrieb gehen kann. Wir haben schon einiges unter IPv6 laufen, aber nur Testsysteme. Ich habe bei mir zu Hause seit einiger Zeit kein IPv6 mehr, weil der Provider den 6to4-Tunnel blockiert bzw. auf einen nichtfunktionierenden Router routet.

Mich ärgert’s auch, aber eine brauchbare Lösung ist gerade nicht in Sicht.

Schade. Ich bin auch mal über das Problem gestolpert und wusste nicht weiter. Wenigstens weiß ich jetzt, dass Experten auch nicht weiterwissen…

Naja, nicht weiterwissen ist die falsche Formulierung. Am Wissen liegt’s ja nicht, sondern an den Browsern, die da draussen rumfliegen. Es ist halt wieder mal typisch so ein Fall, wo sich eine nicht sonderlich durchdachte Lösung verfestigt hat und dann niemand mehr für zuständig war, das zu korrigieren.

Wenn ich mich recht erinnere war die Ursache des Problems, dass man erst HTTPS und erst danach die Virtualisierung eingeführt hat, und das deshalb nicht mehr gepasst hat.

@Hadmut

Wäre es nicht möglich, einfach in das HTTPS Protokoll eine Möglichkeit zu bauen, den Host zu wechseln und auch die Verschlüsselung neu auszuhandeln?
Dann könnte sich der Server einfach mit einem Cert unter seinem Reverse-DNS Namen melden.

Hat es nur noch keiner versucht oder denke ich viel zu kurz?

@Phil: Sowas in der Art hat man ja erfunden. RFC irgendwas. Hat sich aber meines Wissens nicht durchgesetzt. Ich habe ja oben erwähnt, dass es eine Protokollerweiterung gab, wonach der Client vorher sagt, mit wem er reden will.

Im Prinzip gibt es sowas auch in den anderen Protokollen wie SMTP und IMAP, wo man entweder das Protokoll in SSL einwickelt (alte Methode) oder umgekehrt im Rahmen des Protokolls TLS startet (neue Methode), also erst mal guten Tag sagt, bevor man verschlüsselt.

Siehe dazu Server Name Indication und RFC 4366.

Eigentlich ist das Problem schon gelöst, aber nach meinem letzten Wissensstand (schon was älter, habe aber nichts neues gehört) unterstützen das viele Browser eben noch nicht.

…und würde eben auch das Problem nicht lösen, dass WordPress damit nicht klarkommt, unter zwei verschiedenen URLs aufzutauchen.

Selbst wenn die Browser da alle mitspielen würden, es würde nichts daran ändern, dass das Blog unter https://www.danisch.de/ und https://www.danisch.de/ auftauchen müsste, und das kann WordPress einfach nicht. Ich hab sowas mal versucht und hatte nur Probleme mit WordPress. Ging einfach nicht, ständig irgendwelche Fehler und falschen URLs.

Selbst wenn ich auch https://www.danisch.de/ anbieten würde, ich könnte das Blog nicht an beiden URLs einspiegeln. (Es sei denn, sie haben die Probleme endlich gelöst, was ich bei der krautigen Struktur von WordPress aber nicht glaube.)

Hm, hier funktioniert das seit Jahren out of the box. Laut Handbuch ist es möglich:
http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhost

Das geht mit eigentlich allen gängigen Browsern, sogar mit lynx.

@dochpalese: Wir hatten es vor einiger Zeit mal getestet, da lief es mit den meisten getesteten Browsern nicht.

Allerdings haben wir jetzt auch nicht die Zeit, ständig herumzuprobieren und herumzutesten. Der Server muss vor allem stabil laufen, und da kommen solche Experimente nicht so gut.

Wenn du auf Internet Explorer unter Windows XP verzichten kannst, dann gibt es keinen Grund, SNI nicht einzusetzen:

http://en.wikipedia.org/wiki/Server_Name_Indication#Support
http://en.wikipedia.org/wiki/Server_Name_Indication#No_support

Es nutzt mir ja nichts solange WordPress nicht auf mehreren URLs eingeblendet werden kann.

Davon abgesehen ist Explorer unter XP immer noch in ziemlich vielen Firmen im Einsatz.

Übrigens nutze ich, wie ich schon erwähnt habe, den Server nicht alleine, sondern teile ihn mir mit knapp 30 Leuten. Ich kann nicht einfach nach Lust und Laune dran rumkonfigurieren, nur weil mir das gerade in den Kram paßt. Stabilität geht vor.

Wir kennen das ja alle aus Krimis: Wenn bestimmte Figuren immer wieder auftauchen, dann stinkt da etwas und ebendiese Figuren erweisen sich früher oder später als mit dem Verbrechensgeschehen verbunden.

Auch im realen Leben der Kripo gehört es zum Handwerkszeug, nicht nur mehrfach auftauchende Gegenstände oder Muster sondern auch mehrfach auftauchende Personen als im Zusammenhang mit der Tat stehend zu vermuten.
(z.B. 4 alte Damen wurden ausgeraubt und ermordet. In allen Fällen wird von Zeigen in der Umgebung des Geschehens ein dunkelblauer oder grüner PKW der Marke X beobachtet und in allen Fällen waren die alten Damen Kundinnen von Geschäften, in denen Fr. Y für eine externe Dienstleistung zuständig war. Gewisse Tatmerkmale weisen zudem auf einen (Serien)Täter hin …)

Da darf es doch zweifellos als zulässig, ja vernünftig und naheliegend gelten, das fast schon zuverlässige Auftauchen gewisser Personen (hic: Unprofessorin Baer) und gewisser Tatmerkmale und Muster bei allerlei Untaten nicht für zufällig sondern für kriminalistisch relevant zu halten.

Statt H. Danisch so vage und und unbelegt wie erbost als frauenfeindlich zu bezichtigen steht es den Damen ja frei, seine Ausführungen in dem Buch (und andernorts) gegebenenfalls als belegbar unzutreffend aufzuzeigen.
Dass sie darauf, auf das sachlich gebotene Vorgehen verzichten und Zuflucht in plärrender – aber in der Sache unbelegter – Empörung suchen, sagt doch deutlich und unmissverständlich, was diese Damen, nicht anders als andere Lügner und Betrüger auch, so dringlich ungesagt lassen wollen: Sie haben ausser getroffen und entlarvt sein und daraus resultierendem Lärm nichts zu ihrer Entlastung vorzubringen.

Was dann auch gleich die Überleitung zu einem interessanten, wenn auch unerfreulichem aber weithin “unbeachteten” Thema ist: Weibliche Aggression, insbesondere taktisch eingesetzte.

Belege dafür, die hier von eifrigen Damen angeboten werden, werde ich gerne gebührend würdigen.

So ganz die erste Buchrezension war das nicht, denn es gab ja schon vorher auf der Amazon-Seite des Buchs einige Kundenrezensionen.

Naja, die bei Amazon findet man aber erst, wenn man sowieso schon nach dem Buch schaut. Es gibt auch noch eins zwei weitere, aber da hat mir jetzt der Titel gefallen. 😉