Login
Newsletter
Werbung

Thema: Google plant für Chrome weitere Einschränkungen bei HTTP-Inhalten

25 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von klopskind am Do, 10. Oktober 2019 um 09:31 #

Mit Chrome 81 fällt auch diese Ausnahme weg und Bilder werden wie Audio oder Video blockiert, wenn sie ausschließlich über HTTP geladen werden können.

Die Gefahren von Mixed Content sieht Google in der Möglichkeit, dass Angreifer HTTP-Inhalte unbemerkt manipulieren oder austauschen können, während die Seite insgesamt als sicher ausgegeben wird. Selbst wenn ein Angreifer den Inhalt einer Website nicht verändere, bestehe die Gefahr des Trackings der User solcher Seiten über den Mixed Content.

Ich kapier' die Begründung irgendwie nicht. Mag mir jemand auf die Sprünge helfen?

Dass Seiten mit Mixed Content vom Browser nicht als sicher deklariert werden sollten, bspw. über die Anzeige eines grüngefärbten Vorhängeschlosses in der Adressleiste, wäre fahrlässig. Das sehe ich ein.

Aber ein Angreifer, der dazu fähig ist, unbemerkt HTTP-Inhalte zu belauschen, zu manipulieren oder auszutauschen, stellt bereits ein MitM dar. Und bei MitM-Angriffen hat man derzeit sowieso verloren, etwa durch Manipulation des unverschlüsseltem Netzwerkverkehrs, also bspw. DNS-hijacking - direkt oder via Manipulation auf der Ebene von DHCP oder Zeroconf (mDNS), oder aber auf NTP-Ebene durch Manipulation der Systemzeit, der bei der Prüfung von für Verschlüsselung relevanten Zertifikaten (z.B. für TLS) vertraut wird, oder SNMP usw.
Verschlüsselungsmethoden à la DoH im Browser könnten hier zwar Abhilfe schaffen, aber waren bisher und sind auf absehbare Zeit in Google Chrome nicht verpflichtend.

Zudem erscheint eine vollständig transparente Tarnung etwaiger massenhafter Manipulationen von unverschlüsselten Bild-, Audio- oder Videoverkehrsdaten wegen der Vielzahl alternativer Kommunikationsmittel und -kanäle nur unter enormen Aufwand möglich. Denn falls ein darauf basierender Missbrauch aufgedeckt würde, wären vermutlich viele stinksauer.
Die vorauseilende Macht des Faktischen solcher Massenmanipulationen sollte man natürlich trotzdem nicht unterschätzen.
Außerdem wird es bei individuellen/zielgerichteten Manipulationen dieser Art für die Opfer umso komplizierter. Allerdings ist dann auch das Verhältnis von Aufwand zu Nutzen sehr viel höher, und man sollte nicht so naiv sein, zu glauben, dass Staaten, Sicherheitsbehörden und andere Mächte keine anderen Angriffsmöglichkeiten zur Verfügung stünden. Ich wage zu bezweifeln, dass es den Chrome-Entwicklern an dieser Stelle tatsächlich um die Verhinderung oder Erschwerung dieser Art von Manipulation und Einflussnahme geht.

Hinzu kommt der globale, zusätzliche Mehrbedarf an Energie, der für die verpflichtend angekündigte Verschlüsselung jener Verkehrsdaten (Bild, Audio & Video) notwendig sein wird und hier bisher leider unterschlagen wurde. Schließlich betrifft dies den allergrößten Teil des alltäglichen Internetverkehrsaufkommens. Gibt es hierfür sinnvolle Abschätzungen?

  • 0
    Von ManInTheMiddle am Do, 10. Oktober 2019 um 13:38 #

    Es reicht,wenn man den Router hackt,
    dann kann man http manipulieren und dann Javascript auf den PCs einschleusen.

    Mit https kann der Router das nicht.

    • 0
      Von klopskind am Do, 10. Oktober 2019 um 14:07 #

      Wer "den Router hackt", ist MitM. Das heißt, dass man alles machen, was ich bereits beispielhaft angeführt hatte. Etwa die Manipulation der für TLS relevanten Systemzeit via Manipulation auf NTP-Ebene bzw. DHCP-Ebene, falls diese den NTP-Server angibt. HTTPS bringt da also meines Verständnisses nach nichts, siehe hier unter dem Eintrag "In Search of a Secure Time Source" etwa in der Mitte der Seite. Damit wären wir also wieder beim Ausgangspunkt meiner Verständnisfrage.

      • 0
        Von Verfluchtnochmal_5987108 am Fr, 11. Oktober 2019 um 01:10 #

        Einen Scheissdreck kannst du als MITM wenn die Seite nicht von einem Idioten betrieben wird weil spätestens wenn von der Domain einmal etwas geladen wurde Strict-Transport-Security dafür sorgt dass für lange Zeit keine Verbindung auf Port 80 mehr versucht wird, ganz egal was in der URL steht

        Das Ziel steht schon lange fest: Mittelfristig jeglichen unverschlüsselten Traffics im Internet zu verhindern

        Nachdem wir das vor weit über einem Jahr bei hunderten Kunden im Zuge des dsgvo lückenlos umgesetzt haben wundert es mich viel mehr dass es unverschlüsseltes http überhaupt noch wo gibt

        Firefox mag mixed content für Video Ressourcen seit Jahren nicht, damals war das noch ein Problem, mittlerweile kann das ganze Zeug lückenlos https

        • 0
          Von klopskind am Fr, 11. Oktober 2019 um 09:30 #

          Einen Scheissdreck kannst du als MITM wenn die Seite nicht von einem Idioten betrieben wird [...]
          Dieser Fall, denn Sie hier rigoros ausschließen, ist sicherlich noch nie eingetroffen... Und ich erkenne an dieser Stelle mittelfristig keine Besserung dieser Situation - leider.

          [...] weil spätestens wenn von der Domain einmal etwas geladen wurde Strict-Transport-Security dafür sorgt dass für lange Zeit keine Verbindung auf Port 80 mehr versucht wird, ganz egal was in der URL steht
          Ja wunderbar, noch eine weitere Annahme, die Sie so ohne Weiteres blind voraussetzen... Hätte, hätte, Fahradkett.

          Genau darum ging es doch bei meiner Verständnisfrage. Wieso diese ganzen Maßnahmen (siehe Artikel), wenn es im Endeffekt trotzdem anfällig bleibt?

          Das Ziel steht schon lange fest: Mittelfristig jeglichen unverschlüsselten Traffics im Internet zu verhindern
          No shit Sherlock! Wer behauptet das Gegenteil? Ergo: unnötig füllendes Strohmann-Argument.

          Inwiefern ist beantwortet das meine Frage?

          Nachdem wir das vor weit über einem Jahr bei hunderten Kunden im Zuge des dsgvo lückenlos umgesetzt haben wundert es mich viel mehr dass es unverschlüsseltes http überhaupt noch wo gibt
          Ja, ich befürworte Verschlüsselung auch. Aber nur dort, wo es tatsächlich sinnvoll erscheint.

          Verschlüsselung hat ihren Preis:
          - Entwicklungsaufwand (fehlerfreie TLS-Bibliotheken und deren korrekte und verständliche Dokumentation wachsen nicht auf Bäumen),
          - korrekte Umsetzung und Integration ist notwendig (Anwendungsentwickler müssen entsprechend geschult sein und fehlerfrei arbeiten; Wie oft schon wurde die weit verbreitete OpenSSL-API falsch verwendet?)
          - Verwaltung weiterer Softwarekomponente mit dem Risiko weiterer Fehler (Admins müssen ebenfalls im Umgang mit Verschlüsselung entsprechend geschult sein, und sie müssen auf jeden Workflow angepasste und sinnvolle Maßnahmen ergreifen, sowie diese hinreichend kommunizieren und kontrollieren),
          - zusätzliche Rechenzyklen sind notwendig, d.h. mehr Ressourcen für Hardware sind nötig, d.h. potenter (und teurer), sowie mehr elektrische Energie

          Den letzten Punkt sollte man nicht unterschätzen, denn außer für AES sind mir nur wenige Hardwareimplementierungen via spezieller Instruktionen für andere Blockchiffren bekannt, und AES-NI bieten fast ausschließlich modernere x86-, ARMv8- oder SPARC-Recheneinheiten.
          Und dann kommt da noch das zu verschlüsselnde Volumen an Daten, die bald verschlüsselt übertragen werden müssen. Ein Youtube oder Netflix mag sich soetwas aufgrund riesiger Rechenzentren zwar leisten können, aber verteuert letztlich das angebotene Produkt (Hardware- & Stromkosten). Kleinere Klitschen und Start-Ups haben dadurch einen höheren Initialaufwand. Reichten die Ressourcen gestern noch für die Übertragung unverschlüsselter Inhalte, so könnte das durch den bald de-facto verpflichtenden, zusätzlichen Verschlüsselungsaufwand in naher Zukunft ganz anders aussehen. Wettbewerbsfreundlicher ist diese Situation also jedenfalls auch nicht.

          Firefox mag mixed content für Video Ressourcen seit Jahren nicht, damals war das noch ein Problem, mittlerweile kann das ganze Zeug lückenlos https
          Inwiefern ist beantwortet das meine Frage?

          • 0
            Von Verfluchtnochmal_5987108 am Fr, 11. Oktober 2019 um 23:48 #

            Welchen Preis hat denn Verschlüsselung 2019?

            Wenn die Seite selbst schon https ist wurde das Thema libraries längst zu den Akten gelegt sonst würdest du gar nicht in den Genuss kommen dass dein Browser irgendwas nachladen und einbinden will

            • 0
              Von klopskind am Sa, 12. Oktober 2019 um 21:00 #

              Und die restlichen Argumente meines Kommentars haben Sie gekonnt ausgeblendet. Eine Glanzleistung Ihrer selektiven Wahrnehmung!

              So argumentiert man 2019. Muss ich mir unbedingt merken!

            0
            Von Verfluchtnochmal_5987108 am Fr, 11. Oktober 2019 um 23:53 #

            aes-ni bieten nur moderne Recheneinheiten?

            mit Verlaub sandybridge ist aus 2011, prinzipiell gab es aes instructions weit früher denn rate mal wofür das "ni" steht

            keine Hardware die 2019 noch Relevanz und Verbreitung besitzt fälltiin deine vertrottelte Argumentation

            • 0
              Von klopskind am Sa, 12. Oktober 2019 um 21:09 #

              Das ist eine Frage der Definition von "modern". Innerhalb meiner Verwandtschaft und Bekanntschaft läuft nicht zu vernachlässigender Anteil an Hardware ohne Instruktionen dieser Art, so z.B. zwei Core2 Duos, ein Phenom II, viele nicht-Exynos-prä-ARMv8-Android-Kommunikatoren usw.

              Das meinte ich an dieser Stelle mit "modern".

              deine vertrottelte Argumentation
              Worthülsen jener Art besitzen eine inhärent disqualifizierende Wirkung. :down:

          0
          Von Kein Azubi am Fr, 11. Oktober 2019 um 18:34 #

          Hoffentlich arbeitest du nicht in der IT den du hast von Tüten und blasen keine Ahnung, wenn jemand deinen Router hackt manipuliert er einfach dein dns und kommst ganz woanders raus.

          • 0
            Von Robert am Fr, 11. Oktober 2019 um 19:10 #

            So ist es, ein ssl terminator nimmt dann einfach anfragen auf Port 443 entgegen und antwortet auf Port 80. Die Seite ist ausgeliefert und dein Browser hat sie geladen.

            0
            Von klopskind am Fr, 11. Oktober 2019 um 19:58 #

            Hoffentlich arbeitest du nicht in der IT den du hast von Tüten und blasen keine Ahnung, [...]
            Ganz unabhängig vom Thema erlaube ich mir an dieser Stelle, die Klärung Ihrer Befürchtung vorwegzunehmen. Verfluchtnochmal schrieb: "Nachdem wir das [Verschlüsselung] vor weit über einem Jahr bei hunderten Kunden im Zuge des dsgvo lückenlos umgesetzt haben".

            Das Wort "Kunden" impliziert eine geschäftliche Beziehung zu einem Arbeitgeber (möglicherweise er selbst), womit er Ihre Sorge bestätigt.

            0
            Von Verfluchtnochmal_5987108 am Fr, 11. Oktober 2019 um 23:44 #

            Und weiter? Was bringt dir der dns wenn du Vollhorst am Ende der Nahrungskette kein gültiges Zertifikat hast? Genau darum geht es beim Thema "everything encrypted"

            Vor wenigen Jahren war es noch kein Problem die Facebook login page nachzuahmen und den dns auf einen eigenen Server umzuleiten

            been there, done that, lustig zu sehen welche Leute im Unternehmen das Passwort der Freundin haben und deren Account probieren wenn der eigene vermeintlich nicht geht

            So, und jetzt kommst du erst wieder angeschissen wenn du eine generische Möglichkeit gefunden hast den Browser xyz nur weil du den dns kontrollierst auf deinen Nachbau umzuleiten und zwar ohne warning

            0
            Von blablabla233 am Sa, 12. Oktober 2019 um 13:04 #

            Hoffentlich arbeitest du nicht in einer Bude wo der router das dns vergiebt (das ist fuer ein haushalt oke, aber im prof umfeld schon recht naiv)

        0
        Von Alzheimer am Fr, 11. Oktober 2019 um 14:12 #

        Wenn man einen Router hackt, dann kann man auch HTTPS-Aufrufe manipulieren, in dem man eigene Inhalte mit Hilfe eines eigenen Zertifikats einschleust. Der Nutzer erhält dann zwar eine Warnmeldung, aber nicht Wenige fügen dann eine Sicherheitsausnahme hinzu.

        Ist ja im Prinzip bei Landing-Pages in öffentlichen WLANs, die über abgelaufene Online-Zeit oder aufgebrauchtes Datenvolumen informieren, auch nichts anderes.

        • 0
          Von klopskind am Fr, 11. Oktober 2019 um 15:18 #

          Danke für diese Klarstellung und die Ergänzung, dass das auch viel direkter geht als ich schrieb.

          Allerdings kann ich deswegen das Argument meines Vorkommentars nicht nachvollziehen, da Ihrer und meiner so nicht korrekt. (Oder missvertehe ich Ihren Kommentar?)

          Demnach stützt Ihr Kommentar auch meine Hypothese, dass MitM auch mit den geplanten Verschlüsselungsmaßnahmen und -richtlinien für Chrome weiterhin quasi genauso potent bleibt wie zuvor.

          • 0
            Von Alzheimer am Fr, 11. Oktober 2019 um 17:57 #

            Zunächst ist der Fall, dass jemand einen Router hackt und dabei dafür sorgt, dass der HTML-Code abgerufener Webseiten mit Schadcode manipuliert wird, zwar nicht unmöglich, aber dennoch sehr theoretisch. Denn dazu müsste man sich nicht nur einen Zugang durch eine Hintertür schaffen, sondern auch noch eine extra zu dem Zweck aufgesetzte Software-Lösung ins System integrieren - beispielsweise durch die Installation eines Proxy-Servers und an geeigneter Stelle unterbrachte Firewall-Regeln, die Webaufrufe an einen lokalen Prozess umleiten.

            Sehr viel wahrscheinlicher ist (und auch einfacher zu realisieren), dass jemand einen Proxy-Server irgendwo im Netz betreibt und ausgewählte Protokolle (entweder per NAT-Redirect oder über ein heimliches VPN) laufen lässt. Das wäre mit HTTPS genauso denkbar, wie mit HTTP. Und auch was so manche andere Dienste betrifft, lässt sich da viel zurecht faken. Selbst wenn man einen SSH-Aufruf umleiten würde, könnte man sehr viele Passwörter abgreifen, da Meldungen wegen veränderten Schlüsseln für Viele alltäglich sind und den Benutzern darum auch nicht spanisch vorkommen.

            Im Gegensatz zu einem manipulierten HTTP-Aufruf würde der Benutzer im Browser merken, dass etwas mit dem Zertifikat nicht stimmt, aber wahrscheinlich würden manche Leute dann "weiter zu unsicherer Seite auswählen". Aber unter Umständen noch nicht einmal das. Denn auch beglaubigte SSL-Zertifikate sind ziemlich einfach und ohne tiefergehende Prüfung zu bekommen. Wahrscheinlich ist es auch garkein Thema, ein Wildcard-Zertifikat für eine Domäne, die einem garnicht gehört, von einer offiziellen Registrierungsstelle zu bekommen. Schließlich muss man ja meist nur irgendwelche Wischiwaschi-Nachweise erbringen, dass man wirklich derjenige ist, für den man sich ausgibt.

            Dann würde im Falle eines manipulierten Aufrufs lediglich die Inhaber-Angaben zum Zertifikat anders sein. Aber wer merkt das schon? Ob da jetzt beim Aufruf des VR-Onlinebankings Fiducia steht (was keiner kennt) oder jemand anderes (den ebenfalls niemand kennt) macht da für einen Laien keinen Unterschied.

            • 0
              Von Verfluchtnochmal_5987108 am Sa, 12. Oktober 2019 um 00:08 #

              Für ein wildcard Zertifikat musst du nicht nur irgendeinen Wischiwaschi Nachweis bringen sondern üblicherweise den dns der Domain zum richtigen Zeitpunkt kontrollieren

              Komm, zeig mal wie du das auf einem öffentlichen access point machst

              natürlich gibt es keine 100%, die gibt es im Kontext it security defacto niemals, aber zumindest kann es nicht jeder Trottel der es schafft einen Plastikrouter anzustecken und nur darauf wartet dass sich jemand mit dem Netz verbindet

          0
          Von Verfluchtnochmal_5987108 am Sa, 12. Oktober 2019 um 00:02 #

          Es ist aber schon noch ein unterschied ob ein Trottel warnungen ignoriert oder gar nicht erst bekommt

    0
    Von Verfluchtnochmal_5987108 am Fr, 11. Oktober 2019 um 01:02 #

    Der Energiebedarf ist mit aes-ni oder neon auf arm nicht der Rede wert und die Webserver deren Port 80 nicht nur dazu da ist auf https umzuleiten kannst du langsam an den fingern abzählen

    Es gibt 2019 keinen verdammten Grund für mixed content, der ist mit letsencrypt gestorben

    • 0
      Von klopskind am Fr, 11. Oktober 2019 um 09:59 #

      Der Energiebedarf ist mit aes-ni oder neon auf arm nicht der Rede wert [...]
      1. Manche Transitverschlüsselungen via TLS laufen nicht mit AES. Im Handshake kann sich der Klient mit dem Server bspw. auf ChaCha20 etc. einigen. Meines Wissens nach gibt es für ChaCha20 noch keine speziellen Hardware-Instruktionen, die verbreitet wären.

      2. Das ist keine Abschätzung. Das ist eine subjektive Einschätzung mit vagem Interpretationsspielraum. Lässt sich allein auf dieser Grundlage und in diesem Zusammenhang sinnvoll weiterdiskutieren?

      [...] und die Webserver deren Port 80 nicht nur dazu da ist auf https umzuleiten kannst du langsam an den fingern abzählen
      Na wenn Sie das sagen, wird es wohl stimmen. Ich will damit nicht andeuten, dass diese Aussage falsch wäre, aber eine solidere Faktenbasis wünschenswert gewesen wäre.

      Und ich bezweifle, dass für meine Fritz!Box noch ein Aktualisierung erscheint, die den Port 80 schließen würde, wenn ich das entsprechende Feature des Fernzugriffs (MyFRITZ!) aktivieren würde. Weiterleitung an einen Port mit Verschlüsselung via eines selbstausgestellten Zertifikats wird meiner Erinnerung nach aber verwendet. Ich glaube mich zu erinnern, dass auch Mixed Content vorlag.
      Im lokalen Netzwerk läuft das Interface ebenfalls nur über HTTP. Die Logindaten werden also unverschlüsselt übertragen. Somit muss ich diesem Netzwerk im Endeffekt trauen können. Aber zumindest habe ich hier die Gewalt, geeignete Sicherungsmaßnahmen vorkehrend durchzuführen.
      Das wird nicht das einzige Beispiel dieser Art sein. Diese Situation existiert global vermutlich millionenfach.

      Es gibt 2019 keinen verdammten Grund für mixed content, der ist mit letsencrypt gestorben
      Let's Encrypt ist in dieser Hinsicht ein Mittel zum Zweck. Ich hinterfragte an dieser Stelle aber den Zweck, nicht das Mittel.

      Deshalb handelt es sich bei Ihrer Aussage um eine Behauptung oder Ihre Meinung ohne einer soliden Begründung.

      • 0
        Von Verfluchtnochmal_5987108 am Sa, 12. Oktober 2019 um 00:12 #

        Chacha ist allerdings verdammt effizient, einfach mal Benchmarks im Vergleich zu aes-ni machen dann blamierst du dich weniger

        chacha wählen clients ohne aes acceleration aus verdammt guten Grund, aber du hast ja nachweislich zu keinem Thema dass du hier kommentierst auch nur irgendein technisches Fachwissen

        Es gibt keinen Grund für mixed content - PUNKT

        • 0
          Von klopskind am Sa, 12. Oktober 2019 um 23:00 #

          Chacha ist allerdings verdammt effizient, einfach mal Benchmarks im Vergleich zu aes-ni machen [...]
          1. Niemand hat das Gegenteil behauptet. In diesem Sinne: strawman!

          2. Auch wenn ChaCha20 weniger energieeffizienter als AES-GCM ohne spezielle Instruktionen arbeitet, was ich nicht bezweifle, würde es trotzdem immer noch mehr Energie verbrauchenumwandeln als keine Verschlüsselung.

          [...] dann blamierst du dich weniger
          Hielten Sie das wirklich für nötig? Ich weiß bei solchen Äußerungen immer nicht, wer tatsächlich mehr disqualifiziert.

          chacha wählen clients ohne aes acceleration aus verdammt guten Grund, [...]
          ...den Sie hier der Einfachheit halber unerwähnt lassen? Worauf wollen Sie hinaus?

          Die Klienten wählen gemäß Handshake-Protokoll und lokaler Konfiguration. Letztere hängt vom Administrator ab. Einige Implementierungen entscheiden die Präferenz zur Laufzeit anhand der entsprechenden CPU-flags für die Beschleunigerinstruktionen.

          [...] aber du hast ja nachweislich zu keinem Thema dass du hier kommentierst auch nur irgendein technisches Fachwissen
          Das mag sein, ich habe das auch nie behauptet. Deshalb z.B. auch die "Verständnisfrage"...
          Ich bin begeistert, zwei strawman in einem Kommentar! Da wollte wohl jemand auf Nummer Sicher gehen :P

          Am Wort "nachweislich" in dieser Aussage störe ich mich dann aber doch. Wo sind diese Nachweise?

          (Die meisten interessanten Fragen entspringen einem gewissen Verständnis der zugrunde liegenden Materie. Aber nur so als kleiner Hinweis am Rande.)

          Es gibt keinen Grund für mixed content
          Nur, weil Sie etwas wiederholen, wird es nicht wahrer.

          [...] - PUNKT
          Haha, das hat mich jetzt überzeugt.
          Sie pflegen ein Niveau wie auf dem Pausenhof, einfach zu köstlich! Bitte weitermachen! :)


          Im Sinne einer sachlichen Diskussion ergänze ich meinen Kommentar um ein paar harte Daten in die Runde (siehe Tabellen 3 und 5), die uns in der Frage einer Abschätzung des Energieverbrauchs der Verschlüsselung auf Klientgeräten weiterhelfen könnten. Etwas besseres konnte ich auf die Schnelle nicht finden. Anmerkungen:
          1) Für die Entschlüsselung stellt diese Arbeit leider keiner für meine Zwecke relevanten Daten zur Verfügung, lediglich für die Performance im Appendix B. Letztere ist in etwa vergleichbar mit der der Verschlüsselung.
          2) Die Batterien der verwendeten Geräte ([1], [2]) laufen mit 3,85V respektive 4,4V. Damit könnte man auch die Energien (auf Seite des Klienten) abschätzen.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung