Login
Newsletter
Werbung

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

37 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 Verfluchtnochmal_5987108 am Mo, 14. Oktober 2019 um 21:49 #

                Core2 und modern in einem Satz? Sorry, aber die paar clients deiner Familie spielen keine Rolle und für die gibt es chacha, einfach mal nach cloudflare und chacha googeln

                Das was bei dir die Zukunft ist wurde 2018 eigentlich flächendeckend umgesetzt, Verschlüsselung bei allen Websites und nein es war am cluster keine höhere CPU last zu sehen

                • 0
                  Von klopskind am Mo, 14. Oktober 2019 um 22:19 #

                  Core2 und modern in einem Satz? Sorry, aber die paar clients deiner Familie spielen keine Rolle [...]
                  Die Diskussion ging so:
                  1. Ich: "[...], und AES-NI bieten fast ausschließlich modernere x86-, ARMv8- oder SPARC-Recheneinheiten."
                  2. Sie: "aes-ni bieten nur moderne Recheneinheiten? mit Verlaub mit Verlaub sandybridge ist aus 2011, prinzipiell gab es aes instructions weit früher [...]. keine Hardware die 2019 noch Relevanz und Verbreitung besitzt fälltiin deine [...] Argumentation"
                  3. Ich: "Das ist eine Frage der Definition von "modern". Innerhalb meiner Verwandtschaft und Bekanntschaft läuft [...], so z.B. zwei Core2 Duos, ein Phenom II, viele nicht-Exynos-prä-ARMv8-Android-Kommunikatoren usw."

                  Und nun kommen Sie mir mit gequirlten Scheiße? Sagen Sie mal, sind Sie eventuell ein bisschen dämlich?
                  Übrigens stehen "Core2" und modern nicht im einem Satz. Es war ledigleich eins von mehreren Gegenbeispielen (siehe 3.) für "modern" nach meiner Definition, um Ihr Gegenargument zu entkräften und mein Argument zu stützen, mehr nicht.
                  Was Sie da für einen Strick draus drehen, grenzt an Wahnsinn.

                  Das was bei dir die Zukunft ist wurde 2018 eigentlich flächendeckend umgesetzt, Verschlüsselung bei allen Websites [...]
                  "... ganz Gallien?" Nein, falsche Aussage! Gegenbeispiel: http://www.ard.de/

                  [...] und nein es war am cluster keine höhere CPU last zu sehen
                  Und Sie sind wohl in diversen Rechenzentren von Google, Facebook, Amazon, Netflix, Akamai, etc. daheim, um solche Sprüche klopfen zu dürfen...

                  • 0
                    Von Verfluchtnochmal_5987108 am Mi, 16. Oktober 2019 um 14:00 #

                    Die paar clients die wirklich noch mehr Strom für Verschlüsselung ziehen sind komplett irrelevant weil zum einen sehr wenige und zum anderen ziehen die auch ohne Verschlüsselung mehr als halbwegs moderne mit

                    Die ARD Website geht auch mit https

                    Nein, mein cluster läuft nicht bei Google sondern steht im Büro undhhosted knapp 1000 domains die seit mehr als 12 Monaten https only sind

                    • 0
                      Von klopskind am Mi, 16. Oktober 2019 um 14:33 #

                      Die paar clients die wirklich noch mehr Strom für Verschlüsselung ziehen sind komplett irrelevant weil zum einen sehr wenige und zum anderen ziehen die auch ohne Verschlüsselung mehr als halbwegs moderne mit
                      Diese Aussage ist haltlos, denn erstens nennen Sie keine belastbaren Beweis oder harte Fakten (etwa wie in diesem Kommentar), und zweitens ziehen Sie einen falschen Vergleich (altes Gerät ohne Verschlüsselung vs modernes Gerät mit Verschlüsselung). Es ging allein um den für Verschlüsselung zusätzlichen Energie-/Strombedarf. Die An- oder Abwesenheit von (verpflichtender) Verschlüsselung war und ist in diesem Zusammenhang unabhängig davon, ob sie auf eine alte oder modernen Maschine stattfindet (oder nicht). Für einen sinnvollen und aussagekräftigen Vergleich müssen die Szenarien der also ein konkretes Gerät An- bzw. Abwesenheit von (verpflichtender) auf der selben Hardware stattfinden. Natürlich wäre es repräsentativer den selben Vergleich auf mehreren Geräten durchzuführen.

                      Außerdem entfällt der erhöhte Energie-/Strombedarf nicht nur auf die Klienten.

                      Die ARD Website geht auch mit https
                      http://www.ard.de/ war nur ein Beispiel einer Webseite, die nicht verschlüsselt oder weiterleitet, um Ihre Aussage (s.o.) zu widerlegen. Was wollen Sie?

                      Falls Ihnen das nicht reicht, müssen Sie nicht weit schauen, [0].

                      Nein, mein cluster läuft nicht bei Google sondern steht im Büro undhhosted knapp 1000 domains die seit mehr als 12 Monaten https only sind
                      Und Sie haben die gemessene Last sicherlich auch auf das Volumen der Requests (Anzahl und Größe) normiert, bevor Sie diese vergleicht haben, korrekt?
                      Falls nein, so würden Ihre Messungen nichts taugen, da sie in diesem Zusammenhang nicht vergleichbar/belastbar wären. Nur die Spitzen- oder Durchschnittslast zu betrachten, reicht hier nicht.


                      [0] - Alexa Top100 Analysis

                      • 0
                        Von Verfluchtnochmal_5987108 am Mi, 16. Oktober 2019 um 15:35 #

                        Natürlich reicht die durchschnittliche CPU Last am Cluster denn nur die zählt und nicht die 0.5 Prozent Ausreißer die auf einem Liniendiagramm noch nicht mal zu sehen sind weil die für den gesamten Energieverbrauch schlichtweg keine Rolle spielen

                        Wenn die durchschnittliche Anzahl Requests und Traffic unverändert sind und du von einem Tag auf den anderen knapp 1000 domains auf https umstellst und sich in der durchschnittlichen Last auf der darunter liegenden Hardware nichts ändert was schliesst du daraus?

                        • 0
                          Von klopskind am Mi, 16. Oktober 2019 um 16:37 #

                          Wenn die durchschnittliche Anzahl Requests und Traffic unverändert sind und du von einem Tag auf den anderen knapp 1000 domains auf https umstellst und sich in der durchschnittlichen Last auf der darunter liegenden Hardware nichts ändert was schliesst du daraus?
                          ... in diesem Zusammenhang reichlich wenig, denn - wie ich ja bereits schrieb - muss man die Last (auch / vor Allem) bezüglich des Volumens der verschlüsselt übertragenen Daten normieren. Haben Sie das berücksichtigt?

                          Zudem lässt sich von einer unveränderten Durchschnittslast (Über welche Definition von "Durchschnitt" reden wir eigentlich? Pro Zeitintervall gemessene Last durch diskretisierte Zeitdifferenz/Zeitintervallänge bzw. Messdauer?) nur bedingt auf die zeitliche Verteilung jener Last, bzw. der sie verursachenden Requests (Anzahl & Volumen) schließen. Die zeitlich integrierte Lastverteilung (nennen wir sie doch Lastsumme mit der Einheit Last mal Zeit) kann für zwei verschiedene Lastverteilungen die selbe sein. Hinter Ihren Daten können sich also verschiedene Lastverteilungen verstecken.
                          Wie haben Sie gemessen? Über welche Dauer? Mit welcher Messauflösung?

                          Unabhängig davon arbeitet Hardware bei einer vorgeschriebenen "Lastsumme" (Definition s.o.) für gewöhnlich weitaus effizienter, wenn diese als konstante Lastverteilung statt mit kurzzeitig stark variierender Spitzenlasten anliegt. Denn so liegt die Rechenleistung der Hardware nicht brach (Hardware braucht auch im Idle Strom), die Hardware muss nicht wild zwischen Lastszenarien wechseln (kostet Zeit in Form von Rechenzyklen und Energie), und sie muss nicht ganz so hoch takten (Energiebedarf steigt üblicherweise superlinear oder überproportional mit dem Takt).
                          Demnach können unterschiedliche Lastverteilungen bei gleicher "Lastsumme" unterschiedlichen Energiebedarf wecken.
                          Oder können Sie diese Effekte anderweitig ausschließen?

                          Also lässt sich Ihre Aussage über die Irrelevanz von Verschlüsselung bezüglich der Durchschnittslast bzw. der daraus resultierende Energiebedarf auf der Grundlage dieser Daten nicht belastbar belegen. Es ist komplizierter als Sie hier zu verstehen geben. Ihre Ausführungen sind zu einfach.

                          Und angenommen, Ihre Aussage wäre korrekt, ließe sich daraus schlussfolgern, dass der durch Verschlüsselung zusätzlich anfallende Rechenaufwand keinen zusätzlichen Energiebedarf wecken würde. Das wäre wissenschaftlich nicht plausibel nachvollziehbar (Perpetuum mobile lässt grüßen!).

                          • 0
                            Von Verfluchtnochmal_5987108 am Do, 17. Oktober 2019 um 01:04 #

                            Wenn man so gar keine Ahnung wie du hat weiss man natürlich nicht dass die Datenmenge sekundär ist denn der hauptsächliche overhead bei https liegt im Handshake während dir aes-ni zwischen 2500 und 3000 MB pro Sekunde verschlüsselt (Megabyte, nicht Mbit)

                            Es ist nicht komplizierter, der cluster zeichnet ein Liniendiagramm mit der durchschnittlichen CPU last aller VM's auf allen nodes in MHz

                            Und nein, es ist nicht sehr wahrscheinlich dass genau am selben Tag wo man alles auf https umstellt nach 5 Jahren die Zugriffe auf alle Kundeseiten zufällig gewaltig einbrechen und den von dir behaupteten Anstieg der Last durch die Verschlüsselung zufällig verstecken

                            Natürlich wird es ein paar Rechenzyklen brauchen aber nicht signifikant sonst hätten wir 2018 nach Spectre/Meltdown und 2 Monate nach Umstellung auf https nicht bei der neuen Hardware nichtsschlicht und ergreifend die CPUs halbiert weil nach PHP7 zweijJahre zuvor die Hardware nur Däumchen gedreht hat

                            Wenn du dämlich recht hättest wäre der neue Cluster physisch gleich stark geblieben und wir hätten uns darüber gefreut dass die Optimierungen der letzten beiden Jahre Ressourcen für https frei geschaufelt haben, war aber nicht der Fall und ja der Austausch war seit 2015 geplant

          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 Verfluchtnochmal_5987108 am Sa, 12. Oktober 2019 um 00:00 #

              Ein SSL terminator nimmt
              Anfragen auf Port 443 entgegen und antwortet auf Port 80?
              Hast du getrunken?

              • 0
                Von Robert am Sa, 12. Oktober 2019 um 12:54 #

                :) Das wäre einfach ein nginx.
                RewriteCond %{HTTP:X-Forwarded-Proto} =https
                RewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

                • 0
                  Von Verfluchtnochmal_5987108 am Mo, 14. Oktober 2019 um 21:45 #

                  Und weiter? Das ist ein redirect du Genie, interessiert aber nicht in dem Kontext, führt sobald der Client einmal erfolgreich per https verbunden hat dank HSTS nicht

                  • 1
                    Von Robert am Di, 15. Oktober 2019 um 18:42 #

                    Ich beziehe mich auf diese Aussage "Einen Scheissdreck kannst du als MITM" Sie ist nicht nur asozial formuliert, sondern auch absolut FALSCH. Selbst wenn dein ProfiRouter nicht selber einen DNS Dienst hostet, spielt das keine Rolle, dann baue ich einfach ein side to side VPN zu mir. In meinem internen Netzwerk gibt es dann 8.8.8.8 oder ach ne ganze root zone. Also lass doch diese peinlichen/kindischen und vor allem falschen aussagen.

                    • 0
                      Von Verfluchtnochmal_5987108 am Mi, 16. Oktober 2019 um 14:04 #

                      Und weiter?

                      Wir hosten rund 1000 domains, wenn der Client einmal eine Seite geöffnet hat wird er die nächsten 12 Monate dank HSTS nie mehr eine Verbindung auf Port 80 versuchen und mit preloading tut er das auch beim ersten Kontakt nicht

                      Es bleibt also dabei dass du einen scheissdreck als MITM machen kannst und was deine root zone damit zu tun hat weisst wohl nur du, also mach den Kopf zu

            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