Login
Newsletter
Werbung

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

4 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
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