Public DENIC mailinglist

[Marcos Sanz <sanz AT denic.de>]

Hallo Lutz,

danke für Dein positives Feedback zu unserer Umstellung!

> Danke für den Wechsel zu HTTPS. Generell ist die weitere Verbreitung von
> verschlüsselter Kommunikation personenbezogener Daten wünschenswert und 
Ihr
> Schritt ein wichtiger Beitrag.

Das war auch einer unserer Gründe. Gerade wenn der abgefragte Domainname 
als zu schützende Information betrachtet wird, soll ihn auch kein 
HTTP-Proxy/Cache/... auf den Weg zu uns erfahren. Im übrigen stand der 
HTTPS-Dienst bereits seit langem zur Verfügung, wurde aber kaum genutzt. 
Wir haben deswegen nun den am meisten benutzten Eingangspunkt zum 
Web-Whois-Dienst (Eingabeformular auf der Homepage) darauf umgeleitet.

> Unglücklichweise handelte es sich bei dem reporteten Problem um eine
> gänzlich andere Fragestellung. Es nützt nichts, die Datenübertragung zu
> verschlüsseln, wenn die Daten vom Browser per Referer an Google zwecks
> reCapcha-Validierung übertragen werden.

Es nutzt schon und das berücksichtigt auch das zitierte RFC2616 bei den 
"Security Considerations":
"Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP 
request if the referring page was transferred with a secure protocol."
Und es funktioniert sogar erstaunlich gut. Auf einmal wurde nach der 
HTTPS-Umstellung in unserer Testumgebung von keinem getesteten Client ein 
Referer an Google verschickt, unabhängig von der default Konfiguration. 
Das Problem ist aber: das Beziehen von unsicheren Inhalten (vgl. src="
http://google.com/recaptcha...";) innerhalb des sicheren Kanals hat zu 
Warnungen bei manchen gängigen Browsern (in ihrer default Konfiguration) 
geführt. Eine weitere Umstellung der Anwendung zur sicheren Variante der 
reCAPTCHA-Quelle (src="https://google.com/recaptcha...";) hat diese 
Warnungen zwar unterdrückt, andere gängige Browser haben aber das Referer 
doch zu Google übertragen, und das obwohl es sich um eine ganz andere 
Quelle als die referring Seite handelt (IMHO eine etwas legere 
Interpretation der Kernaussage des RFCs).

Alles in allem haben wir uns aber dafür entschieden, diese Änderung auch 
beizubehalten, weil - wie Du gesagt hast - es in dem Fall eine 
wünschenswerte defaultmässige Kommunikationsform ist.

> Danke also für den Wechsel von GET zu POST. Damit ist der angefragte
> Domainname aus der URL verschwunden und wird nicht mehr für die 
raCaptcha
> Validierung an Dritte übertragen.

Das haben wir gemacht, um die o. g. Lücken für alle Browser komplett zu 
schließen. Gern würde ich hier in aller Breite ausführen, warum die 
richtige Methode für diese Fachlichkeit in einer REST-konformen 
Implementierung über HTTP eigentlich doch GET ist (und wie man sonst RFC 
2616 an anderen Stellen auch fehlinterpretieren kann), aber das würde das 
Thema dieses Threads sprengen. Wen es trotzdem interessiert, dem erläutere 
ich es natürlich gerne fernab der Liste ;->

Besten Gruß
Marcos Sanz

-- 
Dipl.-Ing. Marcos Sanz Grossón
Leiter Software Engineering

DENIC eG
Kaiserstraße 75-77
60329 Frankfurt am Main
GERMANY

E-Mail: sanz AT denic.de
Fon: +49 69 27235-0
Fax: +49 69 27235-235
http://www.denic.de

Angaben nach § 25a Absatz 1 GenG:
DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Sabine Dolderer, Helga Krüger, Carsten Schiefner, Dr. Jörg 
Schweiger
Vorsitzender des Aufsichtsrats: Elmar Knipp

Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht 
Frankfurt am Main

____________________________________
Mailinglist-Managenment:
http://mailinglists.denic.de/mailman/listinfo/public-l