mcTLS ?

[uname]

und, daß das Zertifikat von badssl.com abgelaufen ist.

Das Zertifikat ist bis zum 6. September 2017 gültig. Aber vielleicht bist du ja der Zeit voraus.Eigentlich kenne ich da nur umgekehrt, dass bei einem Datum vom 01.01.1970 das Zertifikat noch nicht gültig ist. Passiert gerne bei Akkuproblemen für die Uhrzeit und Verzicht auf ntp.

[Ozelot]

Danke, allen. Das hilft mir brutal weiter.

[wanne]

Ich denke schon, dass es Mittel und Wege gibt: https://developer.mozilla.org/en-US/doc ... _Integrity
[…]
Wenn ich die Javascript-Bibliothek nicht per CDN hoste, sondern über meinen Webserver bereitstelle, kann ich es zudem als Anbieter selbst absichern selbst ohne SRI.

Aua. Das weitet den Schutz von deiner Hauptseite auf CDNs aus. Ist die Verbindung nicht durch TLS geschützt ist das sinnlos. Denn nein, nur weil du über deinen Webserver auslieferst kontrollierst du nicht, was da an Javascript ankommt. Surfe einfach mal über Vodafone auf deine http Webseite und gucke im Source, was da so an Javascript ausgeliefert wird. (Kleiner Tipp: Gleich in der 2. Zeile wirst du JS finden, dass du so nicht geschrieben hast. Und da hilft auch keine Subresource Integrity)

Laut Doku funktioniert es wohl aktuell auch nur beim Firefox.

Chrome war IMHO der erste, der es implementiert hat.

TLS ist eben eine Transportverschlüsselung und mit Javascript erreicht man eine Anwendungsverschlüsselung.

Nein. Transportverschlüsselung ist eine sehr phantasievolle Übersetzung von Transport Layer Security. Anwendungsverschlüsselung oder White Box Cryptografie ist ein haufen Bullschit der bewiesener Maßen keine Sicherheit bieten kann. Sehr analog zu Homöopathie. Nettes Spielzeug um ein paar minder bemittelte, die denken Mathe wäre irgend was abstraktes aus der Schule aber im Realen leben wären solche Erkenntnisse irrelevant einzufangen. Und ihnen möglicherweise ordentlich Geld abzuziehen. Aber das ist eine kleine Minderheit. Die meisten machen das aus Überzeugung.

Zudem besser diese Verschlüsselung eben zusätzlich einbauen als gar keine haben. Zudem besser diese Verschlüsselung eben zusätzlich einbauen als gar keine haben.

Auch hier hier finde ich die Analogie zu Homöopathie sehr gut. Prinzipiell schadet es nichts.
Aber es sorgt eben dafür, dass da plötzlich alternativen unter gleichem Namen (Medizin bzw. Kryptografie) laufen und Plötzlich kommen Leute eben wirklich auf die Idee der Hokuspokus eine könnte wirklich sinnvolle Methoden ersetzen.
Daneben besteht die Gefahr dass in dem Zug irgend wann mal tatsächlich irgend welche gfährlichen Sachen unter die Leute gebracht werde.

[DeletedUserReAsG]

Anwendungsverschlüsselung oder White Box Cryptografie ist ein haufen Bullschit der bewiesener Maßen keine Sicherheit bieten kann.

Magst du das kurz erläutern? Im weiteren Sinne ist ja auch ’ne aus dem MUA via GPG verschlüsselte Mail eine Anwendungsverschlüsselung – inwiefern ist das ein Haufen Bullshit?

[uname]

@wanne:
Leider habe ich kein Vodafone. Kannst du mal ein Beispiel hier posten.

Ich habe noch mal drüber nachgedacht. 100% sicher ist das wohl nicht.

Als Bespiel möchte ich die sehr schöne Anwendung PrivateBin [1] [2] [3] anführen. Im Beispiel [1] wird zwar SSL verwendet aber man kann sich ja mal vorstellen, dass bei mcTLS die Daten an zentraler Stelle unverschlüsselt ähnlich wie bei HTTP vorliegen.

Die zu schützenden Daten (in der Anwendung) werden trotz aller Unsicherheit von Javascript im Browser des Anwenders ver- und entschlüsselt. Unter der Annahme mcTLS hat keinen Zugriff auf den Client muss somit der Angreifer dem Anwender wohl oder übel eine falsche SJCL-Javascript-Bibliothek unterjubeln (die zudem signiert ist) oder diese mindestens deaktivieren. Das funktioniert wiederum nur mit Veränderung der zugehörigen HTML-Datei (wohl ähnlich Vodafone).
Das Risiko bzw. Problem der Manipulation ist jedoch, dass die Anwendung am Ende gar nicht mehr funktioniert, da die Anwendung an anderer Stelle z.B. die Verschlüsselung (severseitig) prüft. Im gewählten Beispiel mag das vielleicht nicht der Fall sein, da die entschlüsselten Informationen nur jeweils im Browser vorliegen. Generell müsste aber mcTLS schon recht anwendungsnah arbeiten und genau hier sehe ich die Grenzen von mcTLS.

[1[ https://privatebin.net (Anwendung)
[2] https://privatebin.info (Homepage)
[3] https://github.com/PrivateBin/PrivateBin (GitHub inkl. Sicherheitsanforderungen wie TLS siehe "What it doesn't provide")

[wanne]

Leider habe ich kein Vodafone. Kannst du mal ein Beispiel hier posten.

Heise hat da was: ( https://www.heise.de/ct/hotline/UMTS-Ko ... 69540.html)

Das enstsprechende JavaScript wird gehört nicht zu heise. (IP 1.2.3.4 ist eigentlich nur für Testzwecke. Keine offizielle. )

aber man kann sich ja mal vorstellen, dass bei mcTLS die Daten an zentraler Stelle unverschlüsselt ähnlich wie bei HTTP vorliegen.

Es bleibt dabei, dass dein Browser (bzw. eine darin verankerte CA) und der Server eine Solche stelle als vertrauenswürdig erachten muss. Es bleibt eine funktionierende Methode entsprechende CAs zu löschen.

Generell müsste aber mcTLS schon recht anwendungsnah arbeiten und genau hier sehe ich die Grenzen von mcTLS.
[…]
Die zu schützenden Daten (in der Anwendung) werden trotz aller Unsicherheit von Javascript im Browser des Anwenders ver- und entschlüsselt. Unter der Annahme mcTLS hat keinen Zugriff auf den Client muss somit der Angreifer dem Anwender wohl oder übel eine falsche SJCL-Javascript-Bibliothek unterjubeln (die zudem signiert ist) oder diese mindestens deaktivieren. Das funktioniert wiederum nur mit Veränderung der zugehörigen HTML-Datei (wohl ähnlich Vodafone).

Signierung der von JS kann immer nur durch TLS erfolgen. Genau deswegen setzt das oben beschriebene einigermaßen vernünftigen Beispiel immer TLS voraus. Die Sicherheit der Aktion steht und fällt mit dem MAC/der Signatur von TLS. Der Sinn hinter privatebin bzw. dem Original Mega ist ein anderer: Glaubhafte Abstreitbarkeit. Der Serverbetreiber erfährt bei korrektem betrieb nie, was die User machen.
Kaum ein Gesetzgeber verpflichtet das präventive Brechen von Verschlüsselung. Allerdings viele das löschen von illegalen Daten, sobald die dir bekannt sind. Außerdem sind im Falle eines (temporären) Einbruchs die Daten der User, die nicht aktiv sind geschützt. Ähnlich wie Passwort Hashing. Wer sein Passwort während eingebrochen wird eingibt hat so oder so verloren. Aber man kann nicht mal eben in 5 Minuten alles mitnehmen sondern muss warten, bis der User die Daten aktiv runterläd. – Genau wie beim mithören über mcTLS.

Das Risiko bzw. Problem der Manipulation ist jedoch, dass die Anwendung am Ende gar nicht mehr funktioniert, da die Anwendung an anderer Stelle z.B. die Verschlüsselung (severseitig) prüft. Im gewählten Beispiel mag das vielleicht nicht der Fall sein, da die entschlüsselten Informationen nur jeweils im Browser vorliegen.

Guck dir das Bild an:
a) Die setzen einfach ein eigenes JS in den Header. In dem Fall um festzustellen, wann neu geladen wird um das an den Provider zu melden. Prinzipiell könnte das aber auch so funktionieren, dass es die Variable mit dem Key (der ja in JS vorliegen muss) weitergegeben wird. Das Script ist eigenständig für sich. Selbst wenn es crached bleibt der Rest der Seite unberührt.
b) Wie man weiter unten sieht ist es offensichtlich auch ohne Probleme (Es gab da dann doch ein paar vereinzelte. Aber man konnte sich das offensichtlich leisten.) tief in den HTML-Code eingreifen und semantisch teile austauschen. Sowas kann btw. auch jedes scriptkiddie mit ettercap oder der burbsuite schön mit GUI zusammenklicken.

[wanne]

Leider habe ich kein Vodafone. Kannst du mal ein Beispiel hier posten.

Heise hat da was: ( https://www.heise.de/ct/hotline/UMTS-Ko ... 69540.html)

Das enstsprechende JavaScript wird gehört nicht zu heise. (IP 1.2.3.4 ist eigentlich nur für Testzwecke. Keine offizielle. )

aber man kann sich ja mal vorstellen, dass bei mcTLS die Daten an zentraler Stelle unverschlüsselt ähnlich wie bei HTTP vorliegen.

Es bleibt dabei, dass dein Browser (bzw. eine darin verankerte CA) und der Server eine Solche stelle als vertrauenswürdig erachten muss. Es bleibt eine funktionierende Methode entsprechende CAs zu löschen.

Generell müsste aber mcTLS schon recht anwendungsnah arbeiten und genau hier sehe ich die Grenzen von mcTLS.
[…]
Die zu schützenden Daten (in der Anwendung) werden trotz aller Unsicherheit von Javascript im Browser des Anwenders ver- und entschlüsselt. Unter der Annahme mcTLS hat keinen Zugriff auf den Client muss somit der Angreifer dem Anwender wohl oder übel eine falsche SJCL-Javascript-Bibliothek unterjubeln (die zudem signiert ist) oder diese mindestens deaktivieren. Das funktioniert wiederum nur mit Veränderung der zugehörigen HTML-Datei (wohl ähnlich Vodafone).

Signierung der von JS kann immer nur durch TLS erfolgen. Genau deswegen setzt das oben beschriebene einigermaßen vernünftigen Beispiel immer TLS voraus. Die Sicherheit der Aktion steht und fällt mit dem MAC/der Signatur von TLS. Der Sinn hinter privatebin bzw. dem Original Mega ist ein anderer: Glaubhafte Abstreitbarkeit. Der Serverbetreiber erfährt bei korrektem betrieb nie, was die User machen.
Kaum ein Gesetzgeber verpflichtet das präventive Brechen von Verschlüsselung. Allerdings viele das löschen von illegalen Daten, sobald die dir bekannt sind. Außerdem sind im Falle eines (temporären) Einbruchs die Daten der User, die nicht aktiv sind geschützt. Ähnlich wie Passwort Hashing. Wer sein Passwort während eingebrochen wird eingibt hat so oder so verloren. Aber man kann nicht mal eben in 5 Minuten alles mitnehmen sondern muss warten, bis der User die Daten aktiv runterläd. – Genau wie beim mithören über mcTLS.

Das Risiko bzw. Problem der Manipulation ist jedoch, dass die Anwendung am Ende gar nicht mehr funktioniert, da die Anwendung an anderer Stelle z.B. die Verschlüsselung (severseitig) prüft. Im gewählten Beispiel mag das vielleicht nicht der Fall sein, da die entschlüsselten Informationen nur jeweils im Browser vorliegen.

[/quote]Guck dir das Bild an:
a) Die setzen einfach ein eigenes JS in den Header. In dem Fall um festzustellen, wann neu geladen wird um das an den Provider zu melden. Prinzipiell könnte das aber auch so funktionieren, dass es die Variable mit dem Key (der ja in JS vorliegen muss) weitergegeben wird. Das Script ist eigenständig für sich. Selbst wenn es crached bleibt der Rest der Seite unberührt.
b) Wie man weiter unten sieht ist es offensichtlich auch ohne Probleme (Es gab da dann doch ein paar vereinzelte. Aber man konnte sich das offensichtlich leisten.) tief in den HTML-Code eingreifen und semantisch teile austauschen. Sowas kann btw. auch jedes scriptkiddie mit ettercap oder der burbsuite schön mit GUI zusammenklicken. Hexenwerk ist das keines. Früher hat man gesagt, das braucht zu viel Rechenleistung die zu teuer wäre. Seit ~10 Jahren ist das offensichtlich nicht mehr der Fall. Für immer mehr Provider ist es lohnender irgend welche MITM tools die auf Anwendungsebene eingreifen einzusetzen als neue Bandbreite zu verlegen.