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

Frank

Chefredakteur
Teammitglied
Dabei seit
März 2001
Beiträge
5.483
#1
Dabei seit
Okt. 2015
Beiträge
570
#3
Sehr gute Entscheidung seitens Google. Ich hoffe andere Browser Entwickler ziehen bald nach. TLS ist heute einfach ein Muss!
 

andr_gin

Lt. Commander
Dabei seit
Jan. 2004
Beiträge
1.785
#4
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.
 
Dabei seit
Mai 2010
Beiträge
3.227
#5
Tja. Dann ist das so.
Auch Messenger Kommunikation wird zunehmend verschlüsselt, auch wenn es nur um die Mensa Verabredung geht
 
Dabei seit
Sep. 2016
Beiträge
756
#6
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

Lt. Commander
Dabei seit
Apr. 2008
Beiträge
1.931
#7
@andr_gin: Doch doch das geht schon noch, dank Deep Packet Inspection alles kein Problem.
 
Dabei seit
Sep. 2016
Beiträge
3.424
#9
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 :evillol:

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.
 
Zuletzt bearbeitet:
Dabei seit
Mai 2012
Beiträge
241
#11
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.
 
Zuletzt bearbeitet:
Dabei seit
Okt. 2007
Beiträge
1.566
#12
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.
 
Dabei seit
Feb. 2012
Beiträge
527
#13
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. :cool:
 
Dabei seit
Mai 2012
Beiträge
241
#14
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).
 
Zuletzt bearbeitet:
Dabei seit
Nov. 2007
Beiträge
7.722
#15
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"
 
Dabei seit
Mai 2012
Beiträge
241
#16
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.

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.
 
Dabei seit
Apr. 2012
Beiträge
574
#17
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? :rolleyes:
Ohne Verschlüsselung kann ein übertragener Inhalt nicht verifiziert werden. Und dem Computer ist es egal ob man es "statisch" nennt oder nicht.
 
Dabei seit
Okt. 2007
Beiträge
1.566
#18
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.
 
Dabei seit
Mai 2012
Beiträge
241
#19
MITM-Angriffe sind bei Statischem Content also kein Problem? :rolleyes:
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).

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.
 
Zuletzt bearbeitet:
Dabei seit
Okt. 2015
Beiträge
570
#20
Top