Angriffe wie diese, würden auch keine Zertifikats Warnungen auslösen und ich behaupte einfach mal das sehr viele User nicht mitbekommen werden das in der url das „s“ in https fehlt.
Traffic between the client and web server is intercepted.
When an HTTPS URL is encountered sslstrip replaces it with an HTTP link and keeps a mapping of the changes.
The attacking machine supplies certificates to the web server and impersonates the client.
Traffic is received back from the secure website and provided back to the client.
The process works quite well and as far as the server is concerned it
is still receiving the SSL traffic it wants to, it doesn’t know the
difference. The only visible difference in the user experience is that
the traffic will not be flagged as HTTPS in the browser, so a cognizant
user will be able to notice that something is amiss.
SSLStrip Funktioniert nicht auf HSTS Webseiten, aber bei allen anderen ohne Probleme.
Dir wird https vorgegaukelt und auch ein favicon eingebunden was aussieht wie das Schloss…
Firefox implementiert ab Version 37 übrigens opportunistische Verschlüsselung bei Verwendung von HTTP/2 oder SPDY.
Wer also einen Webserver mit HTTP/2 oder SPDY laufen hat, und auf Biegen und Brechen kein ordentlichen Zertifikat bekommen kann, kann ein selbstsigniertes hinterlegen und sollte das imo auch dringend tun. Der Browser zeigt dann eine normale HTTP-Verbindung an, d.h. der User bekommt keinen Hinweis, dass verschlüsselt wird. Im Hintergrund läuft die Verbindung jedoch verschlüsselt, aber natürlich nicht authentifiziert. Daher gibt es auch keine Warnung.
Das bedeutet dann, dass MITM-Angriffe immer noch möglich sind. Aber zumindest ein passiver Angreifer (quasi der „perverse Spanner“), der mangels krimineller Energie dann doch keinen aktiven MITM-Angriff fährt sondern nur mitliest, wird wenigstens ausgesperrt. Und sollte die NSA nur mitschneiden und nicht alle Verbindungen bei jedem aktiv angreifen, haben die auf jeden Fall mehr Datenmüll zu dekodieren
Äh. Wenn man HTTPS nicht unterstützt, warum ist dann Port 443 offen?
CAcert-Zertifikate sind nicht falsch. Sie sind halt nicht anerkannt, anders als die Myriaden von Kommerz-CAs, die im Zweifel mehr Teil des Problems denn Teil der Lösung sind. Und in Android sind sie defacto ein Zugriffshindernis (der Browser verweigert stumpf, ohne Ausnahmeoption, die Kontaktaufnahme). Muß jeder wissen, was er tut … Aufgrund der normativen Kraft des Faktischen, hier: Googles Android, setze ich als CAcert-Assurer selbst kein CAcert-Zertifikat ein …
Ersteinmal ist es keine »Domain«, sondern bestenfalls ein »FQDN«. Und ja, der Prefix »www« ist seit der Defnition von URLs obsolet, aber auch heute noch erlebt man durchaus spannende Effekte, wenn man nur den nackten Domainnamen eingibt. Ich pflege prinzipiell KEINEN »www« Eintrag bei meinen Domains, und auch www.guetersloh.freifunk.net existiert als CNAME nur, weil es bei Drucklegung leider Mißverständnisse gab.
In most cases, you should ensure that the certificate works with and without the www prefix
Begründung: Users gonna use. Gibt halt immer einen Deppen der aus Gewohnheit das www-Präfix im Link nutzt wo keins hingehört. Aber man kann halt auch sagen, dass einem die Leute egal sind.
Die zweite Aussage von mir, dass HSTS davon kaputt geht, stimmt aber wohl nicht
Ist also nur ein Usability-Problem, technisch kann man es natürlich halten wie man möchte.
trotzdem sind server falsch konfiguriert und cert falsch, weil das cert entweder nur www. covert, nicht aber ohne www, und weil der server automatisch sowohl mit als auch ohne www. immer auf https Umleitung erzwingen müsste.
Andere Banken haben das.
und um gefälschten certs auszuweichen gibt es halt DNSSEC und für Emails DANE
Es geht also, wenn man sich die Mühe macht.
Ist natürlich nicht überall notwendig, muss jeder entscheiden, wo er so aufwendig sichern will, und wenn ich so sehe, dass viele z.B.bei Gmail ihr Mailaccount haben, dann ist das eh wertlos, darüber zu reden. Das ist Lieferung „frei Haus“
Indem man den »www«-Unsinn im DNS gar nicht erst einträgt, erschlägt man dieses Problem nachhaltig. Und nein, wenn ich »firmware.some.doma.in« kommuniziere, muß »www.firmware.some.doma.in« auch nicht funktionieren.
Ist leider erstmal wieder aus, da es MIMT-Angriffe, zumindest in der aktuellen Implementierung, begünstigte.
Ich hab grad so den Eindruck als ob Du provozieren möchtest… Ich kann mir nämlich eigentlich nicht vorstellen dass Du nicht verstehst warum es sinnvoll ist nicht nur „xyz.domain.de“ sondern auch „www.xyz.domain.de“ zu haben. Genausowenig kann ich mir erklären, warum Dir kein Grund einfällt wozu ich auf meinem Server Port 443 verwende, oder das es in den Zertifikatsfehlermeldungen der Browser keine „nicht wirklich falschen“ CACert Zertifikate gibt, sondern es für den Browser bei CACert Zertifikaten (standardmäßig) aus dem gleichen einen Grund Names „falsches Zeritifikat“ zur Meldung kommt, egal welche Argumente für CACert sprechen oder welche Vorteile CACert haben mag. Selbstsignierte, abgelaufene, falsche Zertifikate, usw. kommen vor, ich wundere mich wie es passiert dass Du diese Punkte scheinbar einfach überlesen hast.
Seriously? Es gibt keinen Grund, www.some.doma.in einzutragen. Der »www«-Prefix entstammt einer Zeit, als im DNS noch WKS, »well known services« definiert wurden — das ist 20+ Jahre her. Es ist an der Zeit, die Massen zu erziehen, nicht zwanghaft »www.« voranzustellen, wollen sie eine Website erreichen. Jede verfsckte URL kann zu einem Webserver führen, ein Präfix »www.« ist weder notwendig noch sinnvoll.
Naja, typischerweise für SSL-verschlüsselten HTTP-Verkehr. Nach »es gibt keine https Version von librefunk.net» macht es aber keinen Sinn, wenn ein Webserver auf https://librefunk.net mit etwas anderem als 501 oder 301 (zu http://librefunk.net) antwortet.
Der Webserver ist nicht nur für eine Domain zuständig. Das kann man daran sehen wenn man ihn per IP ohne Hostheader anspricht, oder eben mal schaut was auf Port 443 rauskommt.
Hostheader gibts jetzt schon ziemlich lange… Ist auch eigentlich nichts seltenes.
Du hast scheinbar keine Ahnung was für eine Rolle SSL bei HTTPS spielt. Es ist nicht möglich einen HTTP Statuscode zurück zu liefern, ohne vorher die Zertifikatswarnung zu triggern.
Was möglich wäre ist SNI umzusetzen und einen (für den Anwender obskuren) SSL Fehler kommen zu lassen. Das würde dann auch nur für bestimmte Browser gehen und auch nur wenn ich auf Port 443 überhaupt SSL spreche. Wenn ich dort z.B. VPN machen würde, was ich auf anderen IPs auch mache, würde das auch nicht gehen.
Und wozu? Nur weil Du der Ansicht bist man müsste das tun?
Es wäre schön wenn Du Dich mit Behauptungen, wie ich Dinge tun müsste, zurückhalten würdest und zudem nur Dinge als selbstverständlich forderst die auch technisch möglich sind.
Das die hier eingeführten Beispiele ja eh „nur“ die „Dachverbände“ sind und dort direkt gar kein Online-Banking oder so stattfindet, ist es jetzt nicht so wichtig.
Ja, stimmt, sauberer wäre auch ohne „www“ mit ins Zertifikat aufzunehmen. Sauberer wäre auch, auch die https-Varianten auf mit „www“ umleiten zu lassen, wenn man sich entschieden hat, dass das die „richtige“ Variante ist.
Selben Inhalt ohne Redirect unter unterschiedlichen FQDN ausliefern, ist eigentlich immer hässlich und führt irgendwann zu Fehlern.
Ändert aber alles nix daran, dass der „Normal“-Benutzer kaum noch Zertifikats-Warnungen zu Gesicht bekommt, daher auch nicht mehr daran gewöhnt ist, die wegzuklicken, was die Browser inzwischen auch sehr, sehr aufwändig gemacht haben, und daher MITM-Angriffe auf HTTPS zumindest deutlich nicht-trivial geworden sind.
Die SSL-Verschlüsselung ganz wegzunehmen und dem Endbenutzer HTTP ohne Verschlüsselung präsentieren geht allerdings noch. Da hilft wohl nur Erziehen der Anwender, dass sie ohne „grünes Schlösschen“ nix wirklich kritisches eingeben.
Fakt ist glaube ich das eine Menge Leute Webserver bedienen obwohl sie nur 10% verstehen von dem was sie machen.
Spätestens wenn so was immer mehr zusprecher findet und in die Tat umgesetzt wird, werden die ganzen crypto Analphabeten mal handeln müssen
