Julius: mannmannmann...

Beitrag lesen

Hallo Nils-Hero,

Ich interessiere mich für die meisten Konzepte hinter HTTPS und Co. herzlich wenig.

Das scheint mir auch dein Hauptproblem zu sein: Du siehst an jeder Ecke die CIA, den BND und die Illuminaten, verkennst aber konkrete Sicherheitsprobleme. Dagegen hilft nur, sich umfassend zu informieren.

<Vergleich, nicht zitiert, weil ich sonst an das Zeichenlimit des Forums gestoßen wäre... 😂>

Der Vergleich hinkt.

Du nutzt eine Eigenschaft (keine Verschlüsselung) eines Protokolls (BTW: HTTP hängt historisch eng mit HTML zusammen) aus, das zu Verwendung in sicheren Kontexten (in der Anfangszeit des Internets war man noch „unter sich“) gedacht war, anfangs noch kaum Interaktionsmöglicheit mit sensiblen Daten (Formulare wurden erst 1995 mit HTML2.0 eingeführt) – das Web2.0 musste sich erst entwickeln und nicht zuletzt waren die kryptografischen Möglichkeiten der 90er – nicht zuletzt wegen des Kryptowars – beschränkt. Dieser Mangel wurde erkannt und wird konsequent ausgemerzt.

Natürlich nur, wenn die Werkzeuge auch funktionieren (=Browser Plugins, die nach Update des Browsers nicht mehr lauffähig sind)."

Bisher haben die jedes Browser-Update überlebt (es ist ja nicht so, dass die Entwickler ihre Software nicht mit den Beta-Versionen der Browser testen) und selbst wenn sie nicht mehr weiter entwickelt würden, würde jemand anderes sie forken – der Bedarf ist da. Der Bedarf an leicht einzurichtenden HTTPS-Proxys aber anscheinend nicht.

Mit dem Argument wird also der Umstand abgekanzelt, daß https und Co. lokale Proxies kaputt gemacht haben. Das ist natürlich ein Ärgernis.

kannst Du mal ein bischen konkreter werden?

Nein (...)

Siehst Du?

Was ist daran verkehrt? Ich habe so ein Ding mangels Bedarf noch nie aufgesetzt und kann daher nicht mit Erfahrungen dienen. Die allgemeine Vorgehensweise, dass du praktisch eine eigene Certificate-Authority aufsetzen musst und dann deren Root-Zertifikat in deinem Browser als vertrauenswürdig hinterlegen musst, hatte ich ja bereits im Ansatz erklärt und wäre auch problemlos in jedem zweiten Artikel über SSL-Interception zu finden gewesen.

Ich verstehe das von dir zitierte Zitat (ich habe mir erlaubt, den zweiten und letzten Satz zu ergänzen) so (...)

Das kannst Du Dir zurechtlegen wie Du willst, aber der Satz ist an der entscheidenden Stelle eindeutig: "das, was Du denkst, was SSL für Dich macht, ist fundamental kaputt." Du willst mir also etwas, dessen Funktionsweise fundamental kaputt ist, als eine unverzichtbare Notwendigkeit verkaufen.

In dem Artikel, aus dem das Zitat stammt, geht es um „SSL inspection software“ und ihre Probleme. In dem Absatz, aus dem das Zitat stammt, heißt es „SSL and TLS do not provide the level of end-to-end security that users may expect.“, was aber nicht bedeutet, dass TLS und Verschlüsselung allgemein komplett nutzlos und sind, was scheinbar deine These ist.

Es ist wohl leider auch nicht sinnvoll zu verhindern (...)

Doch! man verschlüsselt nicht!

Unverschlüsselt kann jeder beliebige Dritte (und das sind viele!), der auf dem Weg zwischen dir und dem Server mit den Inhalten steht, alles mitlesen und nach Belieben verändern – und du machst ernsthaft dir Sorgen um eine theoretische Möglichkeit von vielen (die nichts mit HTTPS zu tun haben), dich zu tracken?!?

Ist ja auch für 95% der Webseiten gar nicht notwendig. Und der so begeistert zitierte Mann in der Mitte interessiert sich für diese Webseiten überhaupt nicht.

Woher willst du das so genau wissen? Nicht du bestimmst, was man aus den über dich gesammelten Daten an Informationen gemacht wird, sondern deine Feinde.
Die einzige Gegenmaßnahme ist hier, so wenig wie möglich preiszugeben (die Möglichkeit, über HSTS zu tracken, ist Pillepalle gegenüber den möglichen Angriffvektoren bei unverschlüsselter Kommunikation!).

man könnte höchstens die dafür benutzten Domains in die Filterlisten der Tracker-Blocker aufnehmen, wie es mit klassischen Tracking auch gemacht wird.

Es erzeugt also einen zusätzlichen Arbeitsaufwand.

Genauso wie das Aufsetzen eines Proxys, der mit heutigen Technologien klar kommt? – Wasch mich, aber mach mich nicht nass!?

Um dich über HSTS bzw. allgemein sinnvoll (im Sinne des Trackenden) über mehrere Seiten hinweg tracken zu können, müssen schon mehrere Websites mitmachen und diese Technologie zum Tracken verwenden. Das fällt garantiert auf und die landen dann auf Tracking-Listen, das Vorgehen dürfte kein anderes sein, als den neusten Tracker eines Werbenetzwerks zu bannen. (Ich war letztens überrascht, dass uBlock sogar die Tracking-Pixel im golem-RSS-Feed erkennt, sie also auf einer Liste stehen müssen.)

Das Problem dürfte sich allerdings durch HSTS Preload (Liste mit verschlüsselt erreichbaren Websites, die mit allen Browser ausgeliefert wird und daher auch überall gleich ist) und die zunehmende Verbreitung von HTTPS (HTTPS als Standard, vor HTTP wird gewarnt) irgendwann auflösen.

Also eine globale Liste, wo sich jeder registrieren muss, der im Internet mitmacht. Aktiv oder ungefragt passiv durch das Besuchen der registrierten Webseite.

Müssen tust du nichts. HSTS-Preload dient dem besseren Schutz deiner Nutzer. Es kostet dich nichts, du musst keine persönlichen Daten angeben und die registrierte Domain muss nur die technischen Anforderungen erfüllen und dann stehst du sofort auf der Liste.

Der Punkt ist aber nicht unbedingt, dass es diese Liste zwangsläufig geben muss. Sie ist nur ein Notbehelf, irgendwann wird die Zeit kommen, wo man vor HTTP warnen kann, weil 99% der Seiten verschlüsselt erreichbar sind.

Und der Schlüssel liegt an einer einzigen Stelle. Da freut sich die CIA.

Wieso sollte die CIA hier eingreifen und beispielsweise Domains von der Liste entfernen? Der HSTS-Header würde ja weiterhin gesendet und die Nutzer sind damit auch ohne HSTS-Preloading geschützt. Ergebnis: Nichts. – Mach dir mal lieber Gedanken, ob dein Browser, der – oh Schreck – von US-amerikanischen Firmen bzw. Instutionen entwickelt wird, nicht vielleicht doch kompromittiert ist.

Da existieren offensichtlich Datenschutz-Löcher, die in großem Umfang von den üblichen Verdächtigen – Werbeagenturen, Geheimdienste, AV-Hersteller – nachweislich genutzt werden.

Hast du einen Beleg für den Missbrauch von HSTS als Super Cookie in der Praxis?

Das habe ich auf TLS bezogen.

Aber wo geht es da um das Datenschutz-Problem von TLS? Es geht um gravierende Sicherheitsprobleme von Software, die unsauber mit TLS in einer Weise umgeht, die so nicht geplant war. Um davon betroffen zu sein, muss man aber diese Software einsetzen.

Nicht abzustreiten ist, dass TLS Probleme hat (noch zu geringe Verbreitung, intransparente Certificate-Authorities), aber hier ging es bisher um den Sinn von Verschlüsselung im Allgemeinen. Und da ist HTTPS trotz aller Probleme ein Fortschritt gegenüber unverschlüsseltem HTTP. Stück für Stück wird TLS verbessert und Probleme aus dem Weg geschafft. Um das Web oder Internet zu verbessern, bedarf es kleiner evolutionärer Schritte, Revolutionen funktionieren meist nicht.

Nein, ich tue nicht so. Ich werte bloß den konkreten Sicherheitsgewinn durch HTTPS höher als eine theoretische Möglichkeit, mich zu tracken.

Wenn es theoretische möglich ist, wird es auch passieren. Und daß Google dieses Tracking nicht unterbindet, spricht Bände.

Die Frage war, ob es relevant und machbar ist und die hat man sich bei Google wohl auch gestellt und verneint. Bei Mozilla war man anscheinend etwas vorsichtiger, was ich für keine schlechte Entscheidung halte.

Wird denn aktuell über HSTS getrackt? Bitte liefere einen Beweis, Murphy vorzuschieben, wenn man etwas nicht konkret belegen kann, ist schwach.

[…] Jeder wird beeinträchtigt.

Stell Dir das unverschlüsselte HTTP als einen Fluss vor, die Informationen sind das Wasser. […]

Das Beispiel hinkt gleich an mehren Stellen:

  1. HTPS ist keine Zensur, jeder kann weiterhin seine Inhalte anbieten
  2. Ein Schloss kann man nur bedingt als Veranschaulichung für moderne, asymmetrische Kryptografie benutzen, wie sie bei TLS eingesetzt wird:
    Der Job einer Certificate-Authority ist, im Kontext von TLS festzustellen, ob du Inhaber einer Domain bist und ggf. noch zusätzlich, ob du die Person oder Institution bist, die du vorgibst zu sein (Extended Validation). Dadurch kann sie aber nicht den Datenverkehr mitlesen, der mit diesen Zertifikaten abgewickelt wird, weil der Private Schlüssel von dem Zertifikatsinhaber generiert wird und der Zertifizierungsstelle nicht bekannt ist. Mittlerweile gibt es sogar Techniken, die selbst bei nachträglicher Kompromittierung des Privaten Schlüssels schützen.
    Dummerweise kann aber jede anerkannte Zertifizierungsstelle unberechtigterweise Zertifikate für jede Domain ausstellen, was vorkommt, aber auch erkannt wird. Für CAs hat ein solcher Fauxpas ernste Konsequenzen.
  3. Die öffentlichen Zertifikate, die jedem Browser beiliegen, waren und werden wohl auch immer kostenfrei bleiben (sonst wäre das Geschäftsmodell der CAs nichtig). Die Zertifikate, die ein Website-Betreiber benötigt, waren bis vor einiger Zeit nicht leicht zu bekommen. Let’s Encrypt hat das geändert. Es ist unwahrscheinlich, dass Let’s Encrypt vom Markt verschwindet oder Geld verlangt, schau dir mal die Liste der Unterstützer an. Zudem ziehen andere CAs mittlerweile nach und auch Hoster bieten mittlerweile Pakete mit inklusiv-Zertifikaten anderer Anbieter an oder integrieren Let’s Encrypt. Das ist keine Zensurmaßnahme – im Gegenteil, HTTPS erschwert Zensur.

Eine bessere Veranschaulichung für die Wirkung von TLS wäre folgende:
Im Sinne von HTTP stellt man sich auf den Markt und feilscht dort öffentlich mit dem Händler. Falls man nicht möchte, dass andere, ggf. sogar Konkurrenten mitbekommen, was und zu welchen Konditionen man kauft, kann man den Händler auf dem Markt bitten, sich in einem abhörsicheren Raum (der Raum hat aber Prinzip-bedingt nur Platz für zwei Personen ⇒ zwei Kommunikationspartner bei TLS) zu treffen und dort die eigentlichen Geschäfte zu machen, zusätzlich kannst du sicherheitshalber die Papiere des Händlers inspizieren (Ausweis, Gewerbeschein ⇒ Zertifikat überprüfen).

Wenn du nun jemanden Drittes einbinden möchtest, zum Beispiel damit er die Verhandlungen führt, weil er das besser kann als du, kannst du ihn im Falle von HTTP einfach mit auf den Markt nehmen und ihr geht zusammen zum Händler. Bei HTTPS und dem geschlossenen Raum geht das nicht mehr so ohne Weiteres. Ihr löst das dann so, dass dieser Dritte mit dem Händler im Raum sitzt und dann ab und an zu dir in einen anderen abhörischeren Raum geht.

Das ist das Problem mit HTTPS und Co und anderen 'Schutz'mechanismen. Es sind Kontrollmechanismen die sich als Sicherheitsmechanismen tarnen.

Du irrst und kommst nicht aus deiner Filterblase heraus.

Kennst du die Electronic Frontier Foundation, die sich für Grundrechte im Digitalen Zeitalter einsetzt? Wie passt es in dein Bild von HTTPS, dass sie HTTPS für ihre Website einsetzen, ja sogar erzwingt – und noch viel arger – sogar auf der HSTS-Preload-Liste steht? Und es kommt noch besser: Sie entwickeln eine Browser-Erweiterung, die die Verbreitung HTTPS fördert.

Gruß
Julius

1 68

mannmannmann...

Regina Scheißklug
  • sonstiges
  1. 0
    TS
  2. 3
    Gunnar Bittersmann
    1. 0
      Henry
      1. 0
        Gunnar Bittersmann
        1. 1
          Rolf b
          1. 2
            Gunnar Bittersmann
            1. 1
              MudGuard
          2. 0
            Absolute Beginner
            1. 0
              Gunnar Bittersmann
              1. 0
                Rolf b
                1. 0
                  Camping_RIDER
            2. 0
              Henry
            3. 0
              Auge
              • browser
              • sonstiges
              1. 0
                dedlfix
            4. 0
              TS
  3. -3
    1unitedpower
    1. 0
      Henry
      1. 0
        Matthias Apsel
        • sonstiges
        • zu diesem forum
        1. 0
          MudGuard
    2. 0
      Regina Scheißklug
      1. 2
        1unitedpower
        • javascript
        • progressive enhancement
        1. 2
          Auge
          1. 0
            1unitedpower
        2. 3
          Gunnar Bittersmann
          1. 0
            JürgenB
            1. 0
              Gunnar Bittersmann
              1. 0
                JürgenB
                1. 0
                  Auge
                  1. 0
                    1unitedpower
                    1. 0
                      Gunnar Bittersmann
                      1. 0
                        TS
                        1. 0
                          dedlfix
                          1. 0
                            TS
                            1. 0
                              Julius
                            2. 0
                              Auge
                              • javascript
                              • progressive enhancement
                              • sicherheit
                              1. 0
                                TS
                                1. 0
                                  Auge
                    2. 0
                      Auge
                      1. 1
                        1unitedpower
                    3. -1
                      Regina Scheißklug
                  2. 0
                    JürgenB
          2. 0
            1unitedpower
          3. 0
            Gunnar Bittersmann
        3. 0
          Regina Scheißklug
          1. 0
            1unitedpower
            1. 0
              Auge
              • meinung
              • menschelei
              1. 0
                Christian Kruse
                1. 0
                  Auge
                2. 0
                  Regina Scheißklug
                  1. 0
                    Christian Kruse
                    1. -2
                      Regina Scheißklug
            2. 0
              Regina Scheißklug
  4. 1
    Julius
  5. 0
    Nils-Hero
    1. 0
      Henry
      • browser
      • sonstiges
    2. 0
      Julius
      • browser
      • datenschutz
      • sicherheit
      1. 0
        Tabellenkalk
        1. 0
          Julius
      2. 0
        Nils-Hero
        1. 0
          Julius
          • browser
          • datenschutz
          • verschlüsselung
          1. 0
            Nils-Hero
            1. 0
              Julius
              1. 0
                Nils-Hero
                1. 6
                  Julius
                  1. 0
                    Nils-Hero
            2. 0
              TS
  6. 0
    pl