Skip to Content.
Sympa Menu

public-l - [DENICpublic-l] Re-2: Anpassung Sicherheitseinstellungen im DENIC-Informationsdienst whois

public-l AT list.denic.de

Subject: Public DENIC mailinglist

List archive

[DENICpublic-l] Re-2: Anpassung Sicherheitseinstellungen im DENIC-Informationsdienst whois


Chronological Thread 
  • From: ambos AT ambos.de
  • To: public-l AT denic.de
  • Subject: [DENICpublic-l] Re-2: Anpassung Sicherheitseinstellungen im DENIC-Informationsdienst whois
  • Date: Fri, 19 Oct 2012 06:14:44 +0000
  • Importance: normal
  • Priority: normal

Guten Morgen Liste,

ich weiss nicht, ob mein nachfolgendes Anliegen schon mal auf dieser oder
anderer Liste Thema war, möchte es dennoch aber mal anregen.

Problem ist, dass ich ich mich regelmäßig zu blöd bei solchen Captachs
anstelle. Bevor ich häufig zum Zuge komme, steigt nach mehrfachen Vertippern
nicht selten das Aggressionspotential.

Wieso macht das Denic es nicht so wie http://www.upik.de ?
Da wird recherchieren und arbeiten zur Freude - einmal eingeloggt, gibt es
keine Captachs mehr.

So könnte das DENIC jede Abfrage dokumentieren und Missbrauch personalisiert
anprangern.


Gruß
Heiko Ambos



-------- Original Message --------
Subject: Re: [DENICpublic-l] Anpassung Sicherheitseinstellungen im
DENIC-Informationsdienst whois (18-Okt-2012 18:25)
From: Marcos Sanz <sanz AT denic.de>
To: lutz AT donnerhacke.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
>



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




Archive powered by MHonArc 2.6.19.

Top of Page