News Google Chrome: Alle HTTP-Websites werden künftig als unsicher markiert

[T0a5tbr0t]

Wie ich oben bereits schrieben sind 1.) MITM-Angriffe auch mit HTTPS möglich und 2.) generell sehr aufwändig.

"mit HTTPS" geht es nicht. Man muss die Verschlüsselung kompromittieren.

Theoretisch kann alles irgendwie geknackt werden. Pragmatische Verbesserungen sind deswegen nicht schlecht. TLS und die Zertifikatsverwaltung wird in Zukunft besser werden. Alle Angriffe die du beschreibst sind Theoretisch vielleicht irgendwie möglich, bei Informationssicherheit muss immer bedacht werden wie nutzbar ein Angriffsvektor tatsächlich ist.
In der Theorie kannst du auch einfach jeden Logarithmus berechnen. In der Praxis nicht.

Wie kann ich mit https-Featuren Geschwindigkeit wieder herausholen?

Du hast vielleicht ein Round-trip mehr (was in Zukunft vermutlich auch weg-optimiert wird). Mit Sicherheit kann man es eh nicht aufwiegen.
Und es ist auch so viel Krams in alten Webanwendungen unnötig und langsam. Der PHP Interpreter ist im Vergleich zu C auch tierisch lahm, reicht trotzdem aus.

 

[Autokiller677]

Moderne Firwalls decrypten das und gucken dann rein, die sichere Verbindung wird zwischen Firwall und Server aufgebaut.

Modern... Wer das heute noch aufsetzt, hat einige Schüsse verpasst. Meist bringen diese Lösungen mehr Lücken und Probleme mit als sie lösen, weil die Hersteller dieser Produkte es oft nicht gebacken bekommen.
Siehe z.B. hier https://www.heise.de/security/meldu...-Hersteller-Finger-weg-von-HTTPS-3620159.html

Verbindungen aufzubrechen - auch für Firewall o.ä. - ist extreme Bad Practice und sollte möglichst unterlassen werden.

Wie ich oben bereits schrieben sind 1.) MITM-Angriffe auch mit HTTPS möglich und 2.) generell sehr aufwändig.

Oder um es so zu sagen: Da, wo sich der enorme Aufwand für eine MITM-Attacke lohnt, ist TLS nur ein Hindernis von vielen - aber kein Schutz. Wenn ich Content oder Werbebanner auf Webseiten austauschen will, suche ich mit Bots nach veralteten Wordpress, vBulletin o.ä. Installationen und nutze die bekannten Schwachstellen aus. So schon oft vorgekommen, vor allem in Foren.

Und nur weil man deine Fenster einschlagen kann, lässt du jetzt immer die Haustür auf oder was?
Nur weil es noch andere Angriffsvektoren gibt, kann man doch diesen Weg hier dicht machen.

MITM-Angriffe setzen hingegen ein Zugang zum Client (Einrichtung eines Proxy) oder physikalischem Zugang zum Netz voraus (also z.B. der Hotspot im nächsten Starbucks).

Gut erkannt. Und oft genug ist man eben in Netzwerken mit vielen anderen Teilnehmern unterwegs - bei der Arbeit, in der Uni usw.

Wie bereits erwähnt ist in dem Fall auch HTTPS kein Hindernis (siehe Wikipedia). Wenn ich zwischen Client und Server bin, muss ich mich "nur" beim TLS-Handshake dazwischenklinken. Der Client handelt mit dem Punkt in der Mitte eine HTTPS-Verbindung aus, der Server ebenfalls. Beide Seiten sehen eine verschlüsselte Verbindung mit einem gleichbleibenden Partner und validen Zertifikaten.

Dann stimmt aber die Domain der Seite nicht mehr mit der im Zertifikat überein. Und selbst wenn da eine CA mal wieder Mist baut (hallo Symantec...), gibt es Public Key Pinning, das dagegen Schutz bietet. Einfach einklinken und irgendein Zertifikat in beide Richtungen schicken klappt nicht.

 

[N1truX]

"mit HTTPS" geht es nicht. Man muss die Verschlüsselung kompromittieren.

Ja und genau das geht. Du kannst auch mit HTTPS an beiden Enden (Server, Client) einen MITM-Angriff fahren. Der "Man in der Mitte" kommuniziert mit dem eigentlichen Server genau so wie der Client. Und dem Client gaukelt man vor, man wäre der Server. Das Problem ist der initiale Schlüsselaustausch. Wenn ich mich da einklinken kann, bietet HTTPS keinen Schutz.

Alle Angriffe die du beschreibst sind Theoretisch vielleicht irgendwie möglich, bei Informationssicherheit muss immer bedacht werden wie nutzbar ein Angriffsvektor tatsächlich ist.

Danke, genau das habe ich oben ja beschrieben. Warum sollte ich mir den enormen Aufwand eines MITM-Angriffs machen, wenn ich direkt den Server attackieren kann? MITM "lohnt" sich, egal ob mit oder ohne Verschlüsselung die man umgehen muss, vor allem bei hochrangigen Akteuren/Diensten (Geheimdienste, Online-Banking etc.).

Gut erkannt. Und oft genug ist man eben in Netzwerken mit vielen anderen Teilnehmern unterwegs - bei der Arbeit, in der Uni usw.

Oft. Aber nicht die anderen Teilnehmer sind das Problem sondern der Betreiber der Infrastruktur

Einfach einklinken und irgendein Zertifikat in beide Richtungen schicken klappt nicht.

Je nach SSL/TLS-Version: Durchaus korrekt. Kritisch ist, wie oben bereits erwähnt, jedoch der Schlüsselaustausch beim Verbindungsaufbau. Mehr dazu z.B. hier.

Und nur weil man deine Fenster einschlagen kann, lässt du jetzt immer die Haustür auf oder was?

Mit hinkenden Vergleichen kann man jede Diskussion gewinnen, oder? Ernsthaft: Die offene Haustür wäre ein offener Server.

Mir geht es darum den HTTPS-Tarnanzug zum Supermarkt-Einkauf anzuziehen.

 

[T0a5tbr0t]

Public Key Pinning, das dagegen Schutz bietet.

Jup, wobei Chrome wohl davon weg gehen will und Certificate Transparency für alle Zertifikate Voraussetzen wird. Das ist zumindest der Plan für die Zukunft.

 

[ZeroBANG]

Wenn die Uhr im BIOS falsch geht, kann Windows die Uhrzeit nicht automatisch updaten, weil die Verbindung per SSL läuft, da das Datum im PC falsch ist glaubt Windows dass das SSL Zertifikat abgelaufen ist und es geht nix.

Dann geht man auf google weil man schauen will wie man die Uhr im neuen Windows 10 manuell einstellt (wieder schön in einer anderen Ecke versteckt wie man erwarten würde) und dann geht google nicht auf wegen SSL Zertifikat abgelaufen...

Ich hab ohne sch*** nen zweiten PC gebraucht um rauszufinden wie ich die UHR stelle.

Ja, tolle Sache dieses SSL, sollte man immer und überall und ständig für alles benutzen!
Ganz besonders für gut gehütete Geheimnisse wie z.B. die UHRZEIT!

 

[poly123]

HTTPS die Authentizität des Webservers und des Inhalts sicherstellt. Du kannst also sicher sein, dass du auch wirklich mit dem Server kommunizierst, mit dem du es auch vorhast und dir niemand den Content möglicherweise manipuliert mit schadhaften Code.

Und die Werbeseiten, die auf der eigentlichen Webseite eingebunden sind? - werden im selben Kontext ausgeliefert, blöd, gab es ja schon des Öfteren, nun halt bis Client durchgehend verschlüsselt, außer man bricht an forward Proxies die Verbindung auf.

0815 Webseiten mit statischen Inhalten brauchen kein Zertifikat, meine Meinung (wobei DNSSec usw. Sinn macht).

 

[Autokiller677]

Dann geht man auf google weil man schauen will wie man die Uhr im neuen Windows 10 manuell einstellt (wieder schön in einer anderen Ecke versteckt wie man erwarten würde) und dann geht google nicht auf wegen SSL Zertifikat abgelaufen...

Also klar, nervige Sache wenn sowas passiert.
Aber ernsthaft: Rechtsklick auf die Uhrzeit -> Uhrzeit einstellen. Direkter gehts wohl kaum.
Ansonsten reicht es auch aus, in die Suche im Startmenü oder in die Suche der Einstellungsapp "Uhr" einzugeben und "Uhrzeit ändern" wird angeboten. Dafür braucht man echt kein Google...

 

[Arcturus128]

Wenn die Uhr im BIOS falsch geht, kann Windows die Uhrzeit nicht automatisch updaten, weil die Verbindung per SSL läuft, da das Datum im PC falsch ist glaubt Windows dass das SSL Zertifikat abgelaufen ist und es geht nix.

Ist mir auch schon einmal passiert. Wenn man damit noch keine Erfahrung hat kommt man nicht unbedingt auf die Idee, dass die Uhrzeit falsch ist und das Problem da liegt.

 

[Der-Orden-Xar]

Je nach SSL/TLS-Version: Durchaus korrekt. Kritisch ist, wie oben bereits erwähnt, jedoch der Schlüsselaustausch beim Verbindungsaufbau. Mehr dazu z.B. hier.

Punkt 2.3 - Das Root Zertifikat auf dem Client installieren...
Wenn du mir dein Root unterschieben kannst, habe ich wohl ganz andere Probleme als die Sicherheit der TLS-Verbindung.
Wenn du das nicht kannst, sollte jegliche Verbindung, wo ein derart gefälschtes Zertifikat auftaucht eine Fehlermeldung provozieren. Mag sein, dass es einig Uninformierte gibt, die sowas erstmal ohne nachzudenken wegklicken, wenn das dann aber 5 mal passiert und 2 mal nicht wegklickbar ist, sollten diese Leute auch mal anfangen zu denken.

Und da schon ein dämlicher Vergleich kam:
Baust du auch die Airbags und Sicherheitsgurte aus deinem Auto, weil das zusätzliche Gewicht ja so viel Sprit verbraucht?

 

[Blutschlumpf]

@andr_gin: Doch doch das geht schon noch, dank Deep Packet Inspection alles kein Problem.

Was redest du denn da für einen Unsinn?
"Deep Packet Inspection" heißt nichts anderes als "Ich guck mir nicht nur die Header an sondern auch die Payload".
Wenn der Payload verschlüsselt ist, dann ist das für die Firewall nur unnützer Datenbrei mit dem die nichts anfangen kann.

Moderne Firwalls decrypten das und gucken dann rein, die sichere Verbindung wird zwischen Firwall und Server aufgebaut.

Darum geht es ja. Die einzigen Geräte, die den Kram decrypten können, sind die Firewalls oder Loadbalancer vor dem Server. Und das auch nur wenn man die mit dem Zertifikat ausstattet.
Die Firewall auf Clientseite (also auch das 200k Euro Teil bei ner Volkswagen, ner Bank, der NSA oder whatever, egal wie modern) kann da gar nicht "reingucken".


@CB: Wann macht ihr denn den Schritt und macht TLS 1.0 aus?
Bis auf ein paar alte Android-Handys oder Windows-XP User mit IE Fetisch dürfte das doch fast niemanden mehr treffen.

 

[kaktux]

korrigiert mich - aber die irre Neuheit ist das jetzt nicht gerade. Firefox macht das z.B. soweit ich weiß seit über einem Jahr. Den Vergleich zu andren Browsern hätte man ruhig im Artikel mal nennen können.

 

[Kahanamoku]

Umso mehr bin ich verwundert, das Hoster wie United Domains noch keine SSL-Verschlüsselung anbieten.

 

[T0a5tbr0t]

korrigiert mich - aber die irre Neuheit ist das jetzt nicht gerade. Firefox macht das z.B. soweit ich weiß seit über einem Jahr.

Ja und nein. In der Adresszeile beim Firefox ist auch nur ein (i) bei unverschlüsselten Verbindungen.
"Verbindung ist nicht sicher" sieht man nur wenn man auf das Symbol klickt. HTTP ohne TLS direkt als "Unsicher" anzuzeigen wird auf Dauer vermutlich bei allen Browsern Standard werden. Die Idee kommt nicht allein von Chrome Entwicklern, sondern wird schon länger von Sicherheitsforschern diskutiert.

 

[andr_gin]

@andr_gin: Doch doch das geht schon noch, dank Deep Packet Inspection alles kein Problem.

Naja so einfach ist das nicht. Die Firewall kann nicht einfach so hinein schauen. Es kann den ganzen Traffic entschlüsseln und wieder mit einem eigenen Zertifikat entschlüsseln. Das heißt jedoch, dass man das Zertifikat dann auf allen Clients installieren muss. Wenn ich auf der Firewall ein aus meiner Zertifizierungsstelle stammendes Zertifikat installiere, wo das Rootzertifikat per Domänenrichtlinie verteilt wird, dann funktioniert das zumindest mit Internet Explorer/Edge halbwegs brauchbar. Blöd nur, dass alternative Browser wie Firefox ihre eigene Zertifikatverwaltung haben, wo die Zertifikate händisch installiert werden muss. Nunja und dann sind dann noch alle teilweise privaten Android, IOS und Windows Phone Geräte in verschiedensten Versionen, wo auch in individueller Weg gefunden werden muss genauso wie für Rechner, die nicht in der Domäne hängen aber das Firmennetzwerk benutzen. Bei den Android Geräten, wo ich es probiert habe, konnte man zwar Zertifikate nachinstallieren, bekam dann aber immer eine eigene Meldung in der Benachrichtigungsleiste.

 

[Hauro]

korrigiert mich - aber die irre Neuheit ist das jetzt nicht gerade. Firefox macht das z.B. soweit ich weiß seit über einem Jahr. Den Vergleich zu andren Browsern hätte man ruhig im Artikel mal nennen können.

Bisher nur auf Seiten mit Passwort-Eingabe

HTTP ohne TLS direkt als "Unsicher" anzuzeigen wird auf Dauer vermutlich bei allen Browsern Standard werden.

Kommt mit Version 59:
Add a pref to display a negative indicator in the URL bar for non-secure sites (Reported: a year ago)

Kann aktiviert werden:
security.insecure_connection_icon.enabled
security.insecure_connection_text.enabled
security.insecure_connection_icon.pbmode.enabled
security.insecure_connection_text.pbmode.enabled

 

[birday]

Was fuer ein mist hier wieder zu lesen ist. Tls ist sicher gegen mitm attacken, denn der client bekommt einen zertifikatsfehler sollte einer den mitm machen.

und proxies koennen immer noch filtern, der client muss nur das cert des proxies als cacert bei sich adden.

 

[Zockmock]

Haha dann stellt vielleicht auch mal endlich Gamestar.de auf https um. Deren Login
läuft immer noch via http im Jahr 2018

 

[Brink_01]

Treibt die Websitenbetreiber noch mehr dazu auf HTTPS umzustellen. An Sich eine gute Sache aber ist manchmal doch etwas unnötig aufwendig.

Dank All-Inkl ging das wirklich mit nur wenigen Klick innerhalb von ein paar Minuten zusammen mit Wordpress.
Allerdings wird der Inhalt noch nicht sicher gemeldet da es von der HTTP URL nur weitergeleitet wird.
Begrüße den Umstieg dennoch sehr.

 

[dMopp]

Betrifft mich privat nicht. Längst alles auf http2(s) umgestellt dank LE. Dank Wildcards bei LE wird der overhead bald noch geringer

PS: Ich kann euch versichern, https traffic filtern ist KEIN Problem...