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

[Frank]

Ab Juli 2018 wird der Browser Google Chrome HTTP-Websites ohne HTTPS-Unterstützung noch stärker als bisher als unsicher deklarieren, um den Wechsel zu verschlüsselten Verbindungen durch die Betreiber weiter zu forcieren. Dieser Schritt ist allerdings nicht neu und bereits seit Jahren der von Google für Chrome aufgezeigte Weg.

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

 

[Krautmaster]

Bei mir läuft jede Seite eh auf http2, mit let'sencrypt ja wirklich ein Leichtes auf auf ssl umzusteigen.

 

[Overkee]

Sehr gute Entscheidung seitens Google. Ich hoffe andere Browser Entwickler ziehen bald nach. TLS ist heute einfach ein Muss!

 

[andr_gin]

Toll dann ist jede normale Homepage bald SSL verschlüsselt und es ist für Firewallsysteme so gut wie unmöglich noch irgendwas zu filtern. Für Onlinebanking, Paypal etc. hat https ja seine Berechtigung, für die normale Homepage ist das jedoch ziemlicher Unfug.

 

[Gandalf2210]

Tja. Dann ist das so.
Auch Messenger Kommunikation wird zunehmend verschlüsselt, auch wenn es nur um die Mensa Verabredung geht

 

[El_Chapo]

Kenne da noch einige Provider die ihre Kundenlogins ohne SSL anbieten... und wenn man mal die logindaten hat, kann man die ganze homepage und mailverkehr lahmlegen. rip

 

[IndianaX]

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

 

[Schwabe66]

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

 

[owned_you]

na ist doch gut ... die MassenDAUs denken dann das sie damit sicher sind ... obwohl längst nachgewiesen ist das SSL nix gegen Viren und Malware hilft ...und gehackte Seiten auch nicht daran hintern tut diese fleißig unters Volk zu bringen ... kriegste praktisch Viren mit Zertifikat

Nimmt man dann noch solche verbrecherischen CAs wie Symantec dazu ... wird es erst richtig zum Schildbürger Streich! Aber Hauptsache HTTPS gesichert ... und der Mob klatscht Beifall.

 

[IIIIIIIIIIIIIII]

Dem durchschnittlichen Nutzer wird das aber nicht auffallen...

 

[N1truX]

Sehr gute Entscheidung seitens Google. Ich hoffe andere Browser Entwickler ziehen bald nach. TLS ist heute einfach ein Muss!

Weil... Wenn ich nur Static-Content ausliefere (die meisten Firmen-Webseiten (abseits von Foren/Formularen), redaktioneller Inhalt ohne Kommentarfunktion etc.), verlangsamt die Herstellung der Verschlüsselung nur den Seitenaufbau.

Abgesehen davon will ich gar nicht wissen wie viel Energie verschwendet wird, um abermilliarden von Seiten + Assets zu ver- und entschlüsseln, bei denen das komplett unnütz ist. Klar reden wir hier wsl. über 0,x% vom Stromverbrauch des gesamten Internets. Aber in Summe kommt da trotzdem einiges zusammen.

 

[Der-Orden-Xar]

Dann nutzt du einfach ein modernes(*) System und dann lieferst du deinen Content via https schneller aus als via http.
Gibt ja so einige nette Optimierungen dahingehend.

Achja: Und falls dein Static-Content via Werbung finanziert wird, wäre es doch schön, wenn niemand die Werbung austauscht - oder die Meinung, die jemand in seinem Blog vertritt.

 

[Genscher]

Endlich.
Es ist der logische Schritt von Google, jetzt wo Let's Encrypt so ein großer Erfolg ist und jeder kostenlos Zertifikate bekommen kann. Auch die Installation ist komplett automatisiert.

Mit https wird auch http2 in den Vordergrund rücken und das alte http endlich in den wohlverdienten Ruhestand lassen.

 

[N1truX]

Dann nutzt du einfach ein modernes(*) System und dann lieferst du deinen Content via https schneller aus als via http.

Und wie? HTTP/2 wird von den Browser-Anbietern künstlich auf https-Verbindungen beschränkt. Ich werde also gezwungen den Seitenaufbau zu verlangsamen (https) um ihn beschleunigen zu können (HTTP/2).

Achja: Und falls dein Static-Content via Werbung finanziert wird, wäre es doch schön, wenn niemand die Werbung austauscht - oder die Meinung, die jemand in seinem Blog vertritt.

Und was hat das mit TLS-Verschlüsselung zu tun? Wenn ich Werbung und/oder Inhalte austauschen will, greife ich den Server und nicht einzelne Verbindungen an.

Bei TLS geht es primär darum, dass niemand mitlesen kann. Den Datenstrom abzufangen und zu verändern... Das geht schon deutlich über Script-Kiddie-Niveau hinaus. Mal abgesehen davon schützt auch https nicht grundlegend vor Man-In-The-Middle-Attacken (siehe HTTPS Inspection).

 

[DieRenteEnte]

HTTPS nutzt eine zwischen Browser und Server Ende zu Ende verschlüsselte Kommunikation, so dass die Daten nicht durch weitere Teilnehmer des Netzwerks mitgelesen werden können.

Also kann nicht mal Google als dritte Person die Daten mitlesen?
Stichwort: "google analytics"

Oder der Staat oder andere Behörden?
Stichwort: "NSA"

 

[N1truX]

Also kann nicht mal Google als dritte Person die Daten mitlesen?
Stichwort: "google analytics"

Google Analytics arbeitet als Script auf deinem PC (Browser), nicht irgendwo tief versteckt im Netz HTTPS ja oder nein spielt folglich keine Rolle.

Oder der Staat oder andere Behörden?
Stichwort: "NSA"

Unmöglich ist nichts. Mit genug Rechenleistung und/oder Zugriff aufs Zertifikat kommt man schon an die Daten. Für eine echte "Massenüberwachung" ist TLS/SSL aber in der Tat eine Hürde.

 

[T0a5tbr0t]

Weil... Wenn ich nur Static-Content ausliefere (die meisten Firmen-Webseiten (abseits von Foren/Formularen), redaktioneller Inhalt ohne Kommentarfunktion etc.), verlangsamt die Herstellung der Verschlüsselung nur den Seitenaufbau.

MITM-Angriffe sind bei Statischem Content also kein Problem?
Ohne Verschlüsselung kann ein übertragener Inhalt nicht verifiziert werden. Und dem Computer ist es egal ob man es "statisch" nennt oder nicht.

 

[Der-Orden-Xar]

Und wie? HTTP/2 wird von den Browser-Anbietern künstlich auf https-Verbindungen beschränkt. Ich werde also gezwungen den Seitenaufbau zu verlangsamen (https) um ihn beschleunigen zu können (HTTP/2).

Wie stark verlangsamt denn https?
Jeder halbwegs aktuelle Server sollte AES-NI besitzen, Desktop-Clients ebenso.
Mozilla hat vor kurzem einen Teil von NSS (das auch Google mitbenutzt) optimiert, damit - insbesondere wen AES-NI fehlt - die Performance von AES im GCM-Mode (was als das einzige wahre derzeit gilt) verbessert.
Ich behaupte, du könntest gefühlt keinen Unterschied zwischen http und https feststellen.

Und was hat das mit TLS-Verschlüsselung zu tun? Wenn ich Werbung und/oder Inhalte austauschen will, greife ich den Server und nicht einzelne Verbindungen an.

Außer du bist ein ISP (so geschehen vor ein paar Jahren in den USA) und schiebst einfach in jede Verbindung deiner Kunden Werbung, an denen du und nicht der Webseitenbetreiber verdient.
Und was das mit TLS zu tun hast, beantwortest du dir selbst: TLS dient ua der Integrität der übertragenen Daten.

 

[N1truX]

MITM-Angriffe sind bei Statischem Content also kein Problem?

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.

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).

Wie stark verlangsamt denn https?

Das kann dir jeder Browser mit Entwickler-Tools sagen. Die eigentliche Ver- und Entschlüsselung ist zu vernachlässigen (da dauert das Rendering länger). Problematisch ist vor allem der Handshake zu Beginn, vor allem auf Mobilgeräten sowie generell mit hohem Ping.

Und Du hast meine Frage nicht beantwortet: Wie kann ich mit https-Featuren Geschwindigkeit wieder herausholen? HTTP/2 ist nicht https-exklusiv - leider nur die Implementierung in den meisten Browsern. Und genau die kritisiere ich ja.

Außer du bist ein ISP (so geschehen vor ein paar Jahren in den USA) und schiebst einfach in jede Verbindung deiner Kunden Werbung, an denen du und nicht der Webseitenbetreiber verdient.

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 (siehe z.B. SSLsplit). 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.

 

[Overkee]

Weil...

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.