Unfassbar unsicher!

[warJaSoKlar]

Ich kann es nicht nachvollziehen, wie z.B. ein Anbieter wie GMX es zulassen kann, dass man sich auf http://www.gmx.net/ noch OHNE TLS in sein Postfach einloggen kann.
Der Otto-Normal-Nutzer pustet hier seine Zugangsdaten dann im Klartext durch's Netz und GMX nimmt das offenbar fahrlässig in Kauf. Eigentlich müsste er sie unmittelbar danach wieder ändern.

Ich würde mir auch von Golem wünschen, auf solche krassen Missstände einzugehen, damit so etwas endlich ein Ende findet.

Davon gibt es leider nicht wenige und Mail-Anbieter, wo alle Fäden und Fall-Backs anderer Dienste zusammenlaufen, dürfen sich in meinem Augen so etwas einfach nicht erlauben.

[NeoTiger]

warJaSoKlar schrieb:
--------------------------------------------------------------------------------
> Ich kann es nicht nachvollziehen, wie z.B. ein Anbieter wie GMX es zulassen
> kann, dass man sich auf www.gmx.net noch OHNE TLS in sein Postfach
> einloggen kann.

Kurzer Blick in den Quellcodes des Form-Elementars für die Login-Maske:

<form id="formLoginFreemail" class="form-l form-login" data-formerror-check="servererror" novalidate="novalidate" accept-charset="UTF-8" action="https://service.gmx.net/de/cgi/login?hal=true" method="post" name="loginForm">

Hmm ... ich sehe hier eine https:-URL als Empfänger der Login-Daten. Wie kommst du also auf die Vermutung, dass hier eine unsichere Verbindung verwendet würde? Nur weil die Startseite reines http ist?

[Popkornium18]

Gut, unsicher ist es wohl nicht, aber einen schlechten Eindruck hinterlässt es trotzdem. Besonders da die HTTPS Seite ja existiert, aber nicht als standard genutzt wird.

[warJaSoKlar]

You're right (zunächst). Nach einem tieferem Blick in den Code scheint da tatsächlich TLS im Spiel zu sein. Ich kann aber dann die Loginseite sehr leicht manipulieren oder den tatsächlichen Aufruf danach umleiten. Mit einer vollständig TLS Lösung von Anfang bis Ende wäre das deutlich sicherer. So eine sparsame Lösung ist in meinen Augen leider also trotzdem unbefriedigend.

[Spitfire777]

Der Credential-Austausch funktioniert bei diesem Anbieter per HTTPS.

Der Grund, warum der Rest der Seite nicht per HTTPS übertragen wird, ist die Werbung. Diese wird von externen Seiten geladen. Das würde ein normaler Browser unter HTTPS nicht zulassen.

[NeoTiger]

Ich frage mich bis heute, warum es den Anbietern von Webseiten noch nicht gelungen ist Werbebanner von Drittanbietern über ihre eigenen Webserver auszuliefern und sichere Standards zu schaffen, damit die Click-Zählungen unmanipuliert an dieser zurück gehen. Adblock und Co wären auf einen Schlag unbrauchbar und all ihre Probleme wären gelöst.

Als Adblock-Benutzer bin ich froh drum.
Als Techniker ärgere ich mich, dass noch niemand eine Lösung dafür gefunden hat.

[Missingno.]

NeoTiger schrieb:
--------------------------------------------------------------------------------
> Ich frage mich bis heute, warum es den Anbietern von Webseiten noch nicht
> gelungen ist Werbebanner von Drittanbietern über ihre eigenen Webserver
> auszuliefern
Das ist einfach. Man konfiguriert den Server so, dass er als Proxy fungiert.

> und sichere Standards zu schaffen,
Das ist damit aber hinfällig, weil man mittels Proxy potentiell wieder Scheunentore aufreißt. ;-)

> Adblock und Co wären auf einen Schlag unbrauchbar und all ihre Probleme wären gelöst.
Inwiefern?

--
Dare to be stupid!

[Cok3.Zer0]

Dann müsste für jede Seite eine Filterregel eingefügt werden; dadurch ginge der Speicherverbrauch extrem nach oben.

[Bachsau]

Schlimmer ist, dass bis vor wenigen Jahren SSL noch ein "Premium"-Feature war. Nur zahlende Kunden durften sich darüber einloggen.