In Formular auf http-Seite eingegebene Login-Daten per SSL!??

[Raffael]

Hallo!

Ich bräuchte mal einen Denkanstoß, wie ich folgendes Problem am leichtesten löse.

Auf jeder Site unserer Web-Präsenz hat der User die Möglichkeit sich einzuloggen. Die Seiten laufen unverschlüsselt über http. Nun sollen aber von einer solchen http-Seite dann die Login-Daten verschlüsselt an den Server zu überprüfung gesendet werden. SSL-Zertifikat für die Domain www.domain.de liegt vor.

Zum Beispiel ... reicht es vllt schon, wenn ich als Wert von "action" des betreffenden Formulars "https://www.domain.de/logincheck.php" angebe?

Beste Grüße

Raffael

[Der Martin]

Hallo Raffael,

Auf jeder Site unserer Web-Präsenz hat der User die Möglichkeit sich einzuloggen. Die Seiten laufen unverschlüsselt über http. Nun sollen aber von einer solchen http-Seite dann die Login-Daten verschlüsselt an den Server zu überprüfung gesendet werden. [...]
Zum Beispiel ... reicht es vllt schon, wenn ich als Wert von "action" des betreffenden Formulars "https://www.domain.de/logincheck.php" angebe?

im Prinzip ja. Das Absenden der Formulardaten erfolgt dann bereits über eine verschlüsselte Verbindung. Es kann aber sein, dass der eine oder andere Browser dem Nutzer dann eine Meldung an den Kopf schmeißt, dass er jetzt auf eine verschlüsselte Seite umgelenkt wird. Das ist zwar nicht schlimm (andersrum wäre es möglicherweise ein Problem), aber es könnte die Leute verunsichern.

Außerdem würde ich dir empfehlen, für Beispiel nicht wahllos ausgesuchte, real existierende Domainnamen anzugeben, sondern solche, die extra dafür vorgesehen sind. Oder bist du ein Mitarbeiter der Sedo GmbH, auf die die von dir verwendete Domain momentan registriert ist? - Dachte ich's mir doch.

So long,
 Martin

[Raffael]

Hallo!

Danke für die Antworten, wobei ich die "Sedo-Bemerkung" nicht ganz verstehe.

Das MITM-Risiko bin ich bereit einzugehen, weil ich es in unserem Fall für gering halte. Da würde sich ein Angreifer potentere Ziele wählen.

Aus eigener praktischer Erfahrung heraus weiß ich aber, dass eine nicht-SSL-Verschlüsselung schon ziemlich fahrlässig ist, weil Mitlauschen unter entsprechenden Umständen wirklich sehr problemlos möglich ist.

Der Grund, weshalb ich den halben https-Weg nehmen werde ist einmal die genannte Performanceeinbuße und außerdem verursacht Google hier leider seltsame Probleme bei der Indizierung.

Beste Grüße

Raffael

[Der Martin]

Hi,

Danke für die Antworten, wobei ich die "Sedo-Bemerkung" nicht ganz verstehe.

welchen Teil davon verstehst du nicht?

Du hast für deine Beispiele den Domainnamen "domain.de" verwendet. Diese Domain ist aber (zur Zeit) auf die Sedo GmbH registriert.

Um solche Verwechslungen und/oder daraus resultierenden Ärger zu vermeiden, sollte man für Beispiele bitte die dafür vorgesehenen Domainnamen example.org, example.net usw. benutzen (deshalb hatte ich RFC 2606 verlinkt) - und nicht einen willkürlich gewählten, der wahrscheinlich irgendjemandem zugeteilt ist.

Ciao,
 Martin

[Raffael]

Ich würde sagen das ist Haarspalterei ... ;-)

[Der Martin]

Hallo,

Ich würde sagen das ist Haarspalterei ... ;-)

nein, das kann mehrere sehr konkrete Gründe haben:

* Man möchte selbst vermeiden, dass das eigene Projekt durch einen unachtsam gewählten Beispiel-Domainnamen mit anderen Webinhalten in Verbindung gebracht wird, schließlich weiß man ja nicht einmal, was tatsächlich unter dieser Domain angeboten wird. Vielleicht Kinderpornographie? Vielleicht ein Nachrichtenportal der Al Qaida?

* Rennommierte Unternehmen möchten ebenfalls nicht, dass ihre Namen - dazu gehört auch der Webauftritt und somit die Domain - mit Inhalten in Verbindung gebracht wird, die dem Ruf des Unternehmens schaden könnten

* Allein der nutzlos entstehende Traffic, wenn jemand aus Neugier die angegebene Domain aufruft und dann feststellt, dass sie nichts mit dem beschriebenen Problem zu tun hat, kann entscheidend sein. Ich möchte nicht wissen, wieviel Traffic auf der äußerst bekannten Domain der Stiftung Warentest durch solchen Missbrauch entsteht.

Und darum gehören Domainnamen, auf die man sich nicht wirklich inhaltlich beziehen möchte, ebensowenig "zufällig" genannt wie irgendwelche Telefonnummern.

Ciao,
 Martin

[Kai345]

[latex]Mae  govannen![/latex]

Ich würde sagen das ist Haarspalterei ... ;-)

Nein. Stell dir mal kurz vor, die verwendete Domain würde _dir_ gehören und du müsstest dich, nur weil andere diese Domain für Beispiele benutzen, durch tausende von Spam-Mails kämpfen bzw. aufwendige Maßnahmen zur Vermeidung desselben treffen. Und das ist nur _einer_ der Aspekte.

Cü,

Kai

[Christian Seiler]

Hallo,

Zum Beispiel ... reicht es vllt schon, wenn ich als Wert von "action" des betreffenden Formulars "https://www.domain.de/logincheck.php" angebe?

Ja, aber das ist für die Besucher keine gute Idee. Hintergrund ist der: SSL soll sowohl die Übertragung verschlüsseln (damit keiner mitlauschen kann) als auch davor schützen, dass jemand so tut, als wäre er Deine Webseite, obwohl er es gar nicht ist [1]. Wenn das Formular selbst *nicht* per SSL übertragen wird, dann kann der Besucher sich nicht sicher sein, dass das Ziel des Formulars wirklich legitim ist (ein Angreifer kann das Formular und damit das action-Attribut ja Man-in-the-Middle-mäßig austauschen) - und damit wäre es egal, wenn das ursprüngliche Ziel des Formulars sicher wäre, der Besucher bekommt davon gar nichts mit. Wenn jedoch schon das Formular sicher übertragen wird, dann weiß der Besucher, dass das Formular (und damit auch das action-Attribut) wirklich von Dir kommen und kann dem daher seine Logindaten anvertrauen.

Klar, wenn das aus irgendwelchen Gründen bei Dir nicht geht, ist das mit dem https:// im action-Attribut immer noch besser als gar nichts (schützt dann zumindest vor passivem Mitlauschen, weil die Logindaten dann verschlüsselt übertragen werden), ich würde Dir aber vielleicht nahelegen, zu überlegen, ob es nicht sinnvoll wäre, die ganze Seite zu verschlüsseln.

Viele Grüße,
Christian

[1] Ich weiß nicht ob das immer noch gemacht wird, aber vor einiger Zeit gab's auf Flughäfen mal die Masche, so zu tun, als wäre man ein bekannter WLAN-Hotspot (z.B. von einer Telekommunikationsfirma o.ä.) und dabei jedoch bestimmte Anfragen aber auf eigene Seiten umzuleiten, um Passwörter etc. zu stehlen.

Viele Grüße,
Christian

[Tom]

Hello,

Ja, aber das ist für die Besucher keine gute Idee. Hintergrund ist der: SSL soll sowohl die Übertragung verschlüsseln (damit keiner mitlauschen kann) als auch davor schützen, dass jemand so tut, als wäre er Deine Webseite, obwohl er es gar nicht ist [1]. Wenn das Formular selbst *nicht* per SSL übertragen wird, dann kann der Besucher sich nicht sicher sein, dass das Ziel des Formulars wirklich legitim ist (ein Angreifer kann das Formular und damit das action-Attribut ja Man-in-the-Middle-mäßig austauschen) - und damit wäre es egal, wenn das ursprüngliche Ziel des Formulars sicher wäre, der Besucher bekommt davon gar nichts mit. Wenn jedoch schon das Formular sicher übertragen wird, dann weiß der Besucher, dass das Formular (und damit auch das action-Attribut) wirklich von Dir kommen und kann dem daher seine Logindaten anvertrauen.

Das ist genau das, was ich mich bei Freemail schon die ganze Zeit gefragt habe: Was nützt es, erst ab der Anmeldung auf https umzuschalten und nicht schon für die Anmeldeseite?

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[ChrisB]

Hi,

Das ist genau das, was ich mich bei Freemail schon die ganze Zeit gefragt habe: Was nützt es, erst ab der Anmeldung auf https umzuschalten und nicht schon für die Anmeldeseite?

Wenn auch die Anmelde- bzw. Einsteigsseite, die bei vielen Freemail-Anbietern als umfangreicheres "Portal" realisiert ist, mit allem moeglichen an (un)wissenwerten Infos, Nachrichten, Bildern etc. pp., schon verschluesselt ausgeliefert werden soll, dann kostet das erst mal Performance und damit in zweiter Konsequenz auch Zeit - server- und clientseitig, denn mein Client muss ja auch die ganzen Daten wieder entschluesseln, inklusive aller Promi-Bilder und sonstigem Schiet, den die Seite beeinhaltet.

Manche Webmail-Interfaces wickeln ja sogar nur den reinen Login-Vorgang ueber HTTPS ab, und leiten danach zur Anzeige der Mails wieder auf ein unverschluesseltes Dokument (bzw. lassen das vom Nutzer konfigurieren).

MfG ChrisB