https und Contentfilter

[uname]

Am Zertifikat ist es bei EV-SSL immer zu erkennen. Blödsinn was oben geschrieben steht. Wenn doch: Beweis wie individuell das EV-SSL inkl. Hierachie vorgetäuscht wird. Bei EV-SSL gibt es wahrscheinlich ein Firmen-Zertifikat ohne EV-SSL, dass immer gleich ist.

[DeletedUserReAsG]

Wenn jemand Kontrolle über den Browser hat, kann er ihm alles Mögliche unterschieben. In der Situation ist das hübsche Grün für EV-Cert in der Adresszeile keinen müden Champignon wert.

[uname]

Normalerweise wird im Browser nur ein Zertifikat hinzugefügt. Unter der Annahme die Software des Browsers wird nicht manipuliert, müsste man individuell die Zertifikate austauschen. Bei manipulierter Software hast du Recht.

[wanne]

Normalerweise wird im Browser nur ein Zertifikat hinzugefügt.

Ja. Dann funktioniert es nicht.
Aber schon mit dem hinzufügen von 2-3 Zertifikaten funktioniert es.
Eis EV (mit passender OID einer "echten" EV CA.) eines nicht EV und eines für OSCP. Wobei das für OSCP ja das selbe sein kann wie ein vorheriges.

Bei manipulierter Software hast du Recht.

Das war mein Kommentar in FF und Chrome geht das einfacher.
Das ist im Chromium halt einfach eine Liste mit OIDs die EV sind. Ist jetzt nicht so anspruchsvoll die um einen Eintrag zu erweitern. Das kannst du mit etwas Geschick sogar binary patchen. (Also ohne neu-Kompilieren) Ich wette irgend ein gammel Virenscanner macht das schon heute. Frage ist in wiefern Windows merkt wenn man ihm den IE manipuliert. Erfahrungsgemäß ist der ziemlich hartneckig.

Beweis wie individuell das EV-SSL inkl. Hierachie vorgetäuscht wird.

Ich habe dir bereits ein Produkt verlinkt, dass das kann. Samt Erklärung wie das geht. Was soll ich mehr machen? Eien Screenshot schicken, von dem du dann meinst, dass er manipuliert ist?

Gibt es für User noch andere Chancen, zu erkennen ob gefiltert wird, außer der Annahme es wird grundsätzlich überwacht?

Nein. Manipulieren ist das eine. Das machen halt 99% über den Proxy, der einen anderen Fingerprint hat. (Und Plugins kann man sich ja auch anzeigen lassen.) Aber eine 100% Sicherheit ist das natürlich nicht.
Aber überwachen? Es hunderte Wege wie man das noch machen kann. Du kannst natürlich gucken ob SSLKEYLOGFILE gesetzt ist. Unter Linux unter

Code: Alles auswählen

/prco/$PROWSERPID/environ | sed 's,\x00,\n,g' | grep SSLKEYLOGFILE

Wird unter Windows was ähnliches geben.
Und natürlich Prüfsummen vom Browser überprüfen.
Aber am Ende gibt es halt hunderte Möglichekeiten zu mitzuhören und der, der den Browser kontrolliert kann dir je nach Perfektionswillen des Beseitzers anzeigen was er will.

[uname]

Falls du dann doch mal vertrauliche Daten senden willst.

Info: https://privatebin.info
Test: https://privatebin.net

Natürlich unter der Vorgabe, dass nicht auch Javascript im Browser manipuliert wurde und die vollständige URL nicht an Dritte übertragen wurde
Hoste die Anwendung selbst, kontrolliere die Anwendung auf Korrektheit und beachte die Einschränkungen.

Der MitM wird die Daten nicht mitlesen können selbst wenn er TLS aufbricht.
Er muss schon entweder die vollständige URL auf den Client mitlesen (Trojaner) oder Javascript-Funktionen (im Browser) oder Javascript-Bibliotheken on the fly manipulieren. TLS ist weniger wichtig, da die Sicherheit gar nicht darauf aufbaut.
Es ist so sicher, dass man sogar gleich auf TLS verzichten kann.

[wanne]

Javascript-Bibliotheken on the fly manipulieren. TLS ist weniger wichtig, da die Sicherheit gar nicht darauf aufbaut.
Es ist so sicher, dass man sogar gleich auf TLS verzichten kann.

Diese Cryptopads gehen seit Kim Dotcom (aus anderem Grund) damit angefangen hat, gerade extrem stark mit diesen und ähnlichen Versprechungen um.
Ich finde auch diese Hinweise extrem gefährlich. Die passenden Javascript-Bibliotheken zu fälschen ist deutlich einfacher als dein TLS kaputt zu machen. Klar muss das für jede neu machen. Und erst mal setzen die meisten auf TLS. und deswegen sind die Anleitungen in Richtung TLS deutlich ausführlicher und werden auch häufiger genutzt. Aber es ist eben Security by obscurity.
Sobald sich die passenden libs durchsetzen und bekannt werden ist es eben nicht mehr sicher. Proxys die das Manipulieren können sind schnellst möglichst erstellt. (ettercap oder die burbsuit bieten extra Baukästen dazu. Da sind das dann drei vier Zeilen Code.) Und im Gegensatz zu TLS, das wirklich auf echte Sicherheit setzt und damit nur per Manipulation im Browser gebrochen werden kann, kann das eben jeder dahergelaufene machen, der irgend wo an der Leitung sitzt.
Und so vielfältig ist das eben bei weitem nicht. Am ende nutzt deine Seite halt auch die sjcl. Wenn auch eine lokale Kopie davon dürfte das nicht schwer sein die automatisch zu erkennen. (Und passende Gegenmaßnahmen einzuleiten.) Daneben gibts noch crpytojs und dann hat es sich eigentlich. Die beiden abfangen dürfte nicht großartig schwer sein. (Wenn auch etwas komplizierter wenn man alle Uralt Versionen davon erkennen will.)
Ganz abgesehen, dass Crypto in JS sowieso immer ein Haufen Quatsch ist, weil entweder implementierst du dir deine Primitiva selbst, dann hast du ohne Ende Sidechannels, weil JS eben Quar Definition an X stellen Sidechannels zulässt. (Keine Aussagen über Laufzeiten, Manipulation von Datenstrukturen durch externe...)
Oder du nimmst die native Web Cryptography API, dann tut dir das zeug u.u. aber nicht im IE und du bist eben wieder bei Crypto aus dem Browser. (Und vor allem total leichter Manipulierbarkeit, weil es gibt eben genau ein window.crypto gibt. Das musst du überladen und jede Implementation, die auf die setzt ist kaputt.)
Die dinger ohne TLS sind absolut unsicher.

[uname]

Stimmt. Geht aber eher darum den Firma-Mainstream-Scanner zu umgehen.

[DeletedUserReAsG]

Bald braucht die Firma dann solche schmutzigen Tricks gar nicht mehr: https://www.etsi.org/news-events/news/1 ... management

[wanne]

Das ist weitestgehend die genannte SSLKEYLOGFILE Lösung für TLS 1.3.