debianforum.de

Ich stelle das mal hier rein, damit es nicht im Smalltalk untergeht, auch wenn es nur um Informationen geht und keine Anwendung.

Kann mir jemand helfen, TLS und diese Geschichte mit den Middleboxen besser zu verstehen?

https://www.heise.de/newsticker/meldung ... 95607.html

Diese Meldung hat mich überrascht und schockiert, weil ich keine Ahnung hatte, daß TLS-Verkehr so breit mitgehört wird (von wem?). Klar können NSA und Co wohl fast jede Verschlüsselung knacken, aber das hier klingt eher danach, als sei das bei TLS auch sonst weithin üblich. Ich verwende TLS für die Kommunikation mit meinen IMAP-Servern und hielt das bis eben für sicher genug, das auch in fremden Netzwerken zu tun, wenn ich unterwegs bin. Muß ich meine Meinung da revidieren?

Wie schnell / anwenderfreundlich kann denn geprüft werden,
ob das benutzte Cert einer TLS-Kommunikation der einer früheren entspricht?

Und was nutzt das, wenn zBsp. web.de sein Cert an polizeiproxy.web.de überträgt?
Die "berechtigten" Behörden dürfen sowieso vom Provider gar nicht nachvollziehbar innerhalb des Providers mithorchen.

Zunächst sollte man nicht primär an NSA und Co denken, die definitiv nicht alles knacken können. Es geht dabei sogar um weitaus niedere Belange.

Stell Dir einfach mal ein Unternehmen vor, was sicherstellen will, dass da keine sensiblen Daten nach draussen gelangen. Wäre an sich nicht möglich das festzustellen wenn die Daten via TLS verschlüsselt sind. Hier kommen so genannte Middelboxen ins Spiel, die das Original-Zertifikat speichern und den Datenverkehr abfangen, dem Browser weiterhin eine sichere Verbindung mit einem anderen vertrauenswürdigem Zertifikat vorgaukeln, und dann den Inhalt untersuchen. Wird darin nun nichts Relevantes gefunden, werden die Inhalte wieder mit dem ursprünglichen Zertifikat verschlüsselt, und an ihren Bestimmungsort geschickt. Zwar sehr vereinfacht ausgedrückt, aber so in der Art kann man sich das vorstellen. Und da der Browser hierbei nicht meckert, kommt ja ein Zertifikat zum Einsatz was entsprechend beglaubigt wurde, und dem vollständig vertraut wird. Das ist das Problem. Eine vergleichbare Unart wird auch von gängigen Antivirenprogrammen durchgeführt, um verschlüsselte Verbindungen untersuchen zu können. Nur wurde hier schon oftmals mit mangelhaftem Code gearbeitet, dass die Verbindungssicherheit hinterher mitunter sogar signifikant herabgesetzt wurde. Im Beispiel von Kaspersky, auf RSA mit 32-Bit von gängigen 2048-Bit.

Ich habe schon seit langer Zeit ein Problem mit SSL/TLS, und kann das beim besten Willen nicht als valide und sichere Verschlüsselung betrachten. Hieran hängen zu viele Faktoren denen man zwingend immer vertrauen muss, was die Grundidee von Verschlüsselung wieder untergräbt. Also mehr eine Frage von: Sicher vor wem? Den Nachbarn wird es sicher davon abhalten mitzulesen, und in einer Firma geht idR. auch alles über Proxys die alles untersuchen, was nicht weniger als einer Totalüberwachung gleicht. Ich würde nicht mal einem Repository das mittels TLS abgesichert ist, mehr Sicherheit beimessen als der alleinigen GPG-Signatur. Dieses ganze Konzept von TLS empfinde Ich als hochgradig ungenügend, nur es wird entscheidende Stellen geben, die sich gegen höhere Sicherheit zur Wehr setzen werden, da diese Möglichkeit TLS aufzubrechen zu gerne missbraucht wird.

Hier muss keine der "Berechtigten Stellen" Verschlüsselung "aufbrechen". Auf den Servern liegen ohne Ende-zu-Ende-Verschlüsselung Mails im Klartext vor.
Und dann greift:

Umsetzung von Überwachungsmaßnahmen (§ 110 TKG)

Auf Grund der gesetzlichen Vorschriften hat jeder, der geschäftsmäßig Telekommunikationsdienste erbringt oder daran mitwirkt, bei Vorliegen einer entsprechenden schriftlichen Anordnung den berechtigten Stellen die Überwachung und Aufzeichnung der Telekommunikation eines Beschuldigten zu ermöglichen und die entsprechenden Auskünfte zu erteilen. Ob und in welchem Umfang die zur Mitwirkung verpflichteten Telekommunikationsunternehmen Vorkehrungen für die Umsetzung von Überwachungsmaßnahmen oder die Erteilung von Auskünften treffen müssen, wird in § 110 des Telekommunikationsgesetzes (TKG) und der Telekommunikations-Überwachungsverordnung (TKÜV) geregelt. Die Bundesnetzagentur ist zuständig für die Erarbeitung der technischen Vorgaben und die Kontrolle der entsprechenden technischen Einrichtungen und organisatorischen Maßnahmen.

nach oben
Auskunftserteilung (§ 113 TKG)

Wer geschäftsmäßig Telekommunikationsdienste erbringt oder daran mitwirkt, hat auf Verlangen der berechtigten Stellen, beispielsweise auf der Grundlage der StPO, Auskünfte über Bestands- und Vertragsdaten zu erteilen. Wer mehr als 100.000 Kunden hat, ist verpflichtet, für die Beauskunftung von Bestandsdaten eine gesicherte elektronische Schnittstelle zu betreiben. Die Bundesnetzagentur ist zuständig für die Erarbeitung der technischen Vorgaben und die Kontrolle der entsprechenden technischen Einrichtungen. Mit der durch die Bundesnetzagentur vorgegebenen Schnittstelle ist es gleichermaßen möglich, Verkehrsdaten zu beauskunften.

https://www.bundesnetzagentur.de/DE/Sac ... -node.html

mit dieser Technischen Richtlinie: https://www.bundesnetzagentur.de/DE/Sac ... erung.html

TKG §110 betrifft m. E. die Inhalte der Kommunikation, also nicht nur Bestands- und Metadaten:

(3) Die Bundesnetzagentur legt technische Einzelheiten, die zur Sicherstellung einer vollständigen Erfassung der zu überwachenden Telekommunikation und zur Auskunftserteilung sowie zur Gestaltung des Übergabepunktes zu den berechtigten Stellen erforderlich sind, in einer im Benehmen mit den berechtigten Stellen und unter Beteiligung der Verbände und der Hersteller zu erstellenden Technischen Richtlinie fest. Dabei sind internationale technische Standards zu berücksichtigen; Abweichungen von den Standards sind zu begründen. Die Technische Richtlinie ist von der Bundesnetzagentur auf ihrer Internetseite zu veröffentlichen; die Veröffentlichung hat die Bundesnetzagentur in ihrem Amtsblatt bekannt zu machen.

https://www.gesetze-im-internet.de/tkg_2004/__110.html

Grundlage, Berechtigte Stellen, Organistation: G10-Gesetz

Gesetz zur Beschränkung des Brief-, Post- und Fernmeldegeheimnisses (Artikel 10-Gesetz - G 10)
§ 10 Anordnung
(1) Zuständig für die Anordnung von Beschränkungsmaßnahmen ist bei Anträgen der Verfassungsschutzbehörden der Länder die zuständige oberste Landesbehörde, im Übrigen das Bundesministerium des Innern.
(2) Die Anordnung ergeht schriftlich. In ihr sind der Grund der Anordnung und die zur Überwachung berechtigte Stelle anzugeben sowie Art, Umfang und Dauer der Beschränkungsmaßnahme zu bestimmen.
(3) In den Fällen des § 3 muss die Anordnung denjenigen bezeichnen, gegen den sich die Beschränkungsmaßnahme richtet. Bei einer Überwachung der Telekommunikation ist auch die Rufnummer oder eine andere Kennung des Telekommunikationsanschlusses oder die Kennung des Endgerätes, wenn diese allein diesem Endgerät zuzuordnen ist, anzugeben.
(4) In den Fällen der §§ 5 und 8 sind die Suchbegriffe in der Anordnung zu benennen. Ferner sind das Gebiet, über das Informationen gesammelt werden sollen, und die Übertragungswege, die der Beschränkung unterliegen, zu bezeichnen. Weiterhin ist festzulegen, welcher Anteil der auf diesen Übertragungswegen zur Verfügung stehenden Übertragungskapazität überwacht werden darf. In den Fällen des § 5 darf dieser Anteil höchstens 20 vom Hundert betragen.
(5) In den Fällen der §§ 3 und 5 ist die Anordnung auf höchstens drei Monate zu befristen. Verlängerungen um jeweils nicht mehr als drei weitere Monate sind auf Antrag zulässig, soweit die Voraussetzungen der Anordnung fortbestehen.
(6) Die Anordnung ist dem nach § 2 Abs. 1 Satz 1 oder 3 Verpflichteten insoweit mitzuteilen, als dies erforderlich ist, um ihm die Erfüllung seiner Verpflichtungen zu ermöglichen. Die Mitteilung entfällt, wenn die Anordnung ohne seine Mitwirkung ausgeführt werden kann.
(7) Das Bundesamt für Verfassungsschutz unterrichtet die jeweilige Landesbehörde für Verfassungsschutz über die in deren Bereich getroffenen Beschränkungsanordnungen. Die Landesbehörden für Verfassungsschutz teilen dem Bundesamt für Verfassungsschutz die in ihrem Bereich getroffenen Beschränkungsanordnungen mit.

https://www.gesetze-im-internet.de/g10_2001/

G10-Gesetz ist vom Grundgesetz, Artikel 10 abgeleitet:

(1) Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich.
(2) Beschränkungen dürfen nur auf Grund eines Gesetzes angeordnet werden. Dient die Beschränkung dem Schutze der freiheitlichen demokratischen Grundordnung oder des Bestandes oder der Sicherung des Bundes oder eines Landes, so kann das Gesetz bestimmen, daß sie dem Betroffenen nicht mitgeteilt wird und daß an die Stelle des Rechtsweges die Nachprüfung durch von der Volksvertretung bestellte Organe und Hilfsorgane tritt.

Der Artikel lautete ursprünglich:
„Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich. Beschränkungen dürfen nur auf Grund eines Gesetzes angeordnet werden.“
Im Zuge der Notstandsgesetze wurde im Siebzehnten Gesetz zur Ergänzung des Grundgesetzes[3] ab 28. Juni 1968 die heutige Fassung festgeschrieben. Es wurde mit 384 Ja-Stimmen, 100 Nein-Stimmen und einer Enthaltung am 30. Mai 1968 im Bundestag verabschiedet.[4]

https://de.wikipedia.org/wiki/Artikel_1 ... d#Wortlaut

Ende-zu-Ende-Verschlüsselung und Quellen-Telekommunikationsüberwachung:

Quellen-Telekommunikationsüberwachung

Durch die zunehmende Verbreitung verschlüsselter Kommunikation wird die Überwachung der Telekommunikation zunehmend erschwert. Einige Ermittlungsbehörden reagierten darauf mit einer von ihnen als „Quellen-Telekommunikationsüberwachung“ (Quellen-TKÜ) bezeichneten Maßnahme. Dabei wird auf dem Computer, mit der die zu überwachende Kommunikation getätigt wird, ein Programm installiert, welches die Kommunikation vor der Verschlüsselung mitschneidet und an die Ermittlungsbehörde übermittelt. Die technische Umsetzung ähnelt dabei derjenigen des Bundestrojaners, allerdings wird – laut Mitteilung der Bundesregierung – nur die Kommunikation überwacht und keine weiteren Daten erhoben. Inwieweit diese Quellen-TKÜ durch die Gesetze zur Telekommunikationsüberwachung rechtlich legitimiert ist oder einen unzulässigen Eingriff in die Grundrechte des Betroffenen darstellt, ist umstritten.[7]

2010 wurde bekannt, dass der deutsche Zollfahndungsdienst die Quellen-Telekommunikationsüberwachung benutzt, um mittels einer speziell entwickelten Software Inhalte von Gesprächen über Skype, noch bevor sie verschlüsselt werden, auf einen bestimmten Server auszuleiten.[8]

Am 8. Oktober 2011 veröffentlichte der Chaos Computer Club (CCC) eine Analyse eines Programmes zur Quellen-TKÜ und deckte dabei auf, dass die Fähigkeiten des Programmes die Überwachung der Telefonie übersteigen. Das untersuchte Programm ermöglichte nebenher ein Nachladen von beliebigen Programmen aus dem Internet, das Erstellen von Bildschirmfotos und enthielt ein Modul welches einen Mitschnitt der Tastaturanschläge ermöglicht. Des Weiteren können durch den Trojaner auch einfache Daten, wie z.B. Bilder, auf den Computer aufgespielt werden, also auch etwaige gefälschte Beweise oder sonstiges kompromittierendes Material.[9] [10]

https://de.wikipedia.org/wiki/Telekommu ... berwachung

Über die Zusammenarbeit "Berechtigter Stellen" als Handlanger ausländischer Geheimdienste steht genug im Netz.

Edit:
Text erweiter um "Quellen-Telekommunikationsüberwachung".

Jana66 hat geschrieben:Hier muss keine der "Berechtigten Stellen" Verschlüsselung "aufbrechen". Auf den Servern liegen ohne Ende-zu-Ende-Verschlüsselung Mails im Klartext vor.

Es geht ja gar nicht nur um Mail.

Immer mehr Webseiten sind SSL-geschützt, was eine effektive Filterung mit einem Proxy verhindert. Ob über die verschlüsselte Verbindung nun noch Werbemüll oder Tracking-Skripte mitgeschickt werden, den man eigentlich lieber gefiltert hätte oder sogar Viren, kann dann im Proxy nicht mehr untersucht werden. Es sei denn, der Proxy entschlüsselt, untersucht und filtert, und gibt dann neu verschlüsselt die Daten an den Browser weiter.

Es gibt Szenarien, bei denen ein Aufbrechen der Verschlüsselung sicherlich willkommen ist, z.B. um Werbung/Viren (was eigentlich schon fast das Gleiche ist) rauszufiltern. Auch Mobilfunkanbieter haben ein Interesse daran, z.B. Bilder stärker zu komprimieren als ursprünglich vom Webserver ausgeliefert, um Bandbreite zu sparen.

Allerdings führt das die Verschlüsselung komplett ad Absurdum. Denn wenn die Provider oder Firmenproxies das können, kann es jeder andere auch, auch der "Bösewicht", der deine Verbindung mit deiner Onlinebank mitlesen will, um dein Konto zu plündern.

Man kann es vielleicht vergleichen mit der Installation von Software aus Paketquellen (Debian) und Software aus dem Internet (meist Windows). Der Anwender verliert durch mcTLS den Zugriff auf die Ziel-Zertifikate. Man kann Server nicht verifizieren. Die Gefahren sind offensichtlich.

Schauen wir uns folgende verschlüsselte Seite an: https://www.debianforum.de

Das zugehörige Zertifikat hat den SHA-256-Fingerprinft:
1A:19:F0:4F:DF:4D:31:5B:E1:15:AE:B8:7C:1F:04:BB:0E:BE:27:C4:91:B5:C4:3E:AE:5D:15:39:88:B9:2B:B3
(bitte auch mal selbst raussuchen)

Was da sonst noch steht ist egal.

Mit mcTLS wird ein Zwischenzertifikat (z.B. Proxy) vergeben, welches natürlich einen anderen Fingerprint hat bzw. haben muss.
Heute könnte ich unseren Webmaster Sebastian Feltel anrufen bzw. fragen ob er mir nicht mal den aktuellen SHA-256-Fingerprint nennen mag. Stimmt der ist die Welt in Ordnung. Natürlich könnte er den SHA-256-Fingerprint auch sonstwo im Internet veröffentlichen bzw. eigentlich regeln das heute die Zertifikatsebenen über Let's Encrypt und DA Root CA X3. DA Root CA X3 sollste im Browser verankert sein. Der Browser prüft nur diese Ebene. Sollte Sebastian mir persönlich das Zertifikat bestätigen, könnte er auch ein nicht signiertes Zertifikat nutzen. Wäre genauso sicher. Nur dann würden ihn alle Anwender fragen müssen.

Mit mcTLS habe ich diese Möglichkeit nicht mehr. Mein Browser wird irgendwelchen Zwischenzertifikaten glauben (weiteres Zertifikat im Firefox oder abgeleitet von einem eingetragenen Zertifikat). Die Verbindung ist nur sicher bis zum Proxy. Was danach passiert entscheiden andere. Sebastian sieht in den Serververbindungen auch nur das Zwischensystem.

Aber natürlich gibt es auch gegen mcTLS bereits Lösungen wie z.B. https://github.com/bitwiseshiftleft/sjcl oder https://code.google.com/archive/p/crypto-js
Man darf bei mcTLS der Transportverschlüsselung nicht mehr vertrauen und muss die Daten auf Anwendungsebene verschlüsseln. Dieses muss serverseitig (z.B. phpBB) implementiert werden und wird clientseitig per Javascript initiiert. Sollte einfach umzusetzen sein. Interessant vor allem für alle Kriminiellen falls jemand mitliest Natürlich gibt es Software, die darauf bereits beruht siehe z.B. http://tutorialzine.com/2013/11/javascr ... -encrypter

http://tutorialzine.com/2013/11/javascript-file-encrypter/ hat geschrieben:When it comes to encrypting data and securing information, people naturally expect the page to be loaded through HTTPS. In this case I believe it is not necessary, as apart from the initial download of the HTML and assets, no data is transferred between you and the server – everything is done client-side with JavaScript. If this bothers you, you can just download the demo and open it directly from your computer.

MSfree hat geschrieben: Es geht ja gar nicht nur um Mail.

Ich dachte bei meinem Post aber gerade daran.
Beim Browser gibt es addons wie calomel und browsereigenes Tool zur schnellen Anzeige/Kontrolle des Cert,
ein Mail-Client hat wohl auch solche Hilfsmittel.
Bei einem smarthost-postfix müßten erst kilometerlange Logs durchgesehen werden?
Auch besteht hier die Erschwernis herauszufinden, mit welchem Host eigentlich kommuniziert wird, reverse-dns zBsp.

Aber gut, wenn ich die (unverschlüsselte) Mail einem MTA übergebe,
akzeptiere ich ja gleichzeitig, daß jeder andere beteiligte MTA sie lesen kann/darf.

Wir sind wohl etwas von der eigentlichen Sache abgekommen. Ich zitiere aus dem verlinkten Heise-Artikel:

Middleboxen sind transparent, also für den Nutzer unsichtbar agierende Netzwerkgeräte, mittels denen zum Beispiel Netzbetreiber den IP-Verkehr lenken, indem sie Optionen aus dem IP-Header stillschweigend löschen oder ändern. Viele Middleboxen können auch verschlüsselten Verkehr knacken und um die ist ein Streit in der IETF entbrannt: Könnte eine Standardisierung von solchen Funktionen unter dem Dach der IETF gut sein, weil die Organisation auf diese Weise noch schlimmere Hacks verhindern könnte? Oder wäre es besser, dieses und überhaupt jegliches Ansinnen abzulehnen, welches das Ende-zu-Ende-Prinzip in der Verschlüsselung gefährdet oder gar aushebelt?

Fakt ist, dass in Firmen zur Vermeidung von Spam und Viren Middleboxen, UTM-/NG-Firewalls (Unified Thread Management) bereits eingesetzt werden. Diese müssen nicht standardisiert werden, die gibt es schon lange. Es geht nun darum, für Netzbetreiber eine Standardisierung einzuführen, bzw. eine kompromissfähige Lösung zu schaffen. Aus meinen persönlichen Erfahrungen weiß ich, dass Netzbetreiber kein eigenes Interesse an teurer Überwachung und (Vorrats-) Datenspeicherung haben. Aber dann kommen leicht absehbar "die Anderen".

Aus Sicht des Hauptautors David Naylor verbessert mcTLS sogar die Sicherheit und die Privatheit, weil an beiden Endpunkten transparent wird, wer Einsicht in den verschlüsselten Verkehr hat. Zusätzlich wird ausgehandelt, was die Mittelboxen dürfen: Nur lesen oder auch Daten verändern, etwa Teile des Headers. Dazu werden Teilschlüssel erzeugt und je nach Kontext an die verschiedenen Mittelboxen verteilt. So sollen die Eingriffe der Mittelboxen auf das Notwendige reduziert werden.
Naylor weist darauf hin, dass aktuelle Mittelboxen auf solche Feinheiten verzichten. Stattdesen nutzen heutige Mittelboxen einfach globale Root-CA-Zertifikate und gaukeln damit den Clients vor, sie seien selbst der angefragte Server. Das ist besonders in Enterprise-Netzen der Fall – mit derart konfigurierten Mittelboxen werden TLS-Verbindungen der Mitarbeiter zu externen Diensten per Man-in-the-Middle Attacke geöffnet. Damit hält Naylor Kritikern entgegen, dass das Abhören schon allgemeine Praxis sei – seine mcTLS-Technik mache die Vorgänge aber transparent.

Transportlayersicherheit dient doch vorrangig dem Schutz vor "Bösen Buben" auf dem Weg zu einem Server, wo dann eh alle Informationen entschlüsselt und im Klartext vorliegen (Online-Banking, -Shops, Mailserver), nicht unbedingt der Privatspäre. Das Finanzamt schaut auch in Konten mit sicherem Online-Banking.

TLS verschlüsselt nur die Kommunikation zwischen zwei Stationen. Es sind Szenarien in serviceorientierten Architekturen denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird. Wenn jede Station nur einen Teil der Nachricht lesen darf, reicht TLS nicht aus, da jede Station alle Daten der Nachricht entschlüsseln kann. Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann.

https://de.wikipedia.org/wiki/Transport_Layer_Security

Wenn https in Middleboxen entschlüsselt wird, hat TOR wohl wenig Sinn. Eine entsprechende Standardisierung würde das (hoffentlich) transparent machen.
Knackpunkt ist wohl nicht die Standardisierung sondern der Einsatz überhaupt: Standardisierte Geräte können in Massen verkauft werden. Was es gibt, wird benutzt, sobald man (mehr) Geld wittert. Oder per Dekret vorgeschrieben, siehe lawful interception (Überwachung von Inhalten).

Jana66 hat geschrieben:Wir sind wohl etwas von der eigentlichen Sache abgekommen. Ich zitiere aus dem verlinkten Heise-Artikel:

Middleboxen sind transparent, also für den Nutzer unsichtbar agierende Netzwerkgeräte, mittels denen zum Beispiel Netzbetreiber den IP-Verkehr lenken, indem sie Optionen aus dem IP-Header stillschweigend löschen oder ändern. Viele Middleboxen können auch verschlüsselten Verkehr knacken und um die ist ein Streit in der IETF entbrannt: Könnte eine Standardisierung von solchen Funktionen unter dem Dach der IETF gut sein, weil die Organisation auf diese Weise noch schlimmere Hacks verhindern könnte? Oder wäre es besser, dieses und überhaupt jegliches Ansinnen abzulehnen, welches das Ende-zu-Ende-Prinzip in der Verschlüsselung gefährdet oder gar aushebelt?

Fakt ist, dass in Firmen zur Vermeidung von Spam und Viren Middleboxen, UTM-/NG-Firewalls (Unified Thread Management) bereits eingesetzt werden.

In Firmen werden diese Dinger gerne nicht nur zu Spam und Virenabwehr eingesetzt, sondern auch um einen Datenstrom von innen nach außen auf Inhalt kontrollieren zu können. Das setzt aber voraus, dass der Datenstrom nicht zusätzlich verschlüsselt ist (zB verschlüsselte zip Datei).

Dass jede Technik auch heftige Nebenwirkunge haben kann zeigt die Warnung des US CERT (https://www.us-cert.gov/ncas/alerts/TA17-075A) . Mittels Aufruf der Seite https://badssl.com/ kann jeder Browsernutzer, der hinter einer solchen Middlebox sitzt, feststellen inwieweit Schutzmechanismen (Zertifikatsprüfung auf Alter bspw.) ausgehebelt werden.

Jede auf den ersten Blick sinnvolle Sicherheitsmaßnahme führt zu neuen Risiken, die man ernsthaft abschätzen muss. Die Middleboxen müssen auch irgendwie aktualisiert werden, da sie natürlich auch Sicherheitslücken haben wie jede Software. Wahrscheinlich werden sie automatisch über TLS/SSL-Verbindungen aktualisiert, diese Verbindungen werden wohl nicht über Middleboxen anderer Hersteller abgesichert. Warum nicht? Das ist inkonsequent. Wie bei Virenscannern. Dem Anwender keine Adminrechte zugestehen und der Virenscanner macht was er will mit Administratorrechten.

uname hat geschrieben:Dieses muss serverseitig (z.B. phpBB) implementiert werden und wird clientseitig per Javascript initiiert. Sollte einfach umzusetzen sein. Interessant vor allem für alle Kriminiellen falls jemand mitliest Natürlich gibt es Software, die darauf bereits beruht siehe z.B. http://tutorialzine.com/2013/11/javascr ... -encrypter.

Bitte lasse die Finger von so einem Bullshit. Verschlüsselung per Javascript kann niemals sicher sein.
Der grund ist ganz einfach: Das javascript zum verschlüsseln kann nicht signiert übertragen werden. (Weil es zum überprüfen der Signatur ja sich selbst bräuchte.) So kann ein Angreifer jederzeit ein Backdoor in das Javascript einbauen, ohne dass du davon was merkst.

Das gleiche Problem existiert für TLS. Zuersteinmal TLS 1.2 ist sicher. Keiner kann das knacken auch nicht die NSA. (Zumindest nicht als Snowden da noch gearbeitet hat.) Nur deswegen können die so erpicht auf das finden von schlüsseln durch Sicherheitslücken im Browser gewesen sein.
Und hier kommt das Problem: TLS 1.2 ist nur so lange sicher, wie a) der Schlüssel nur bei den beiden Parteien bleibt und b) wirklich TLS 1.2 gesprochen wird. Wird dir dein Browser vom Arbeitgeber bereitgestellt kann der natürlich beliebigen Schmu mit dem Browser treiben. Insbesondere dafür sorgen, Schlüssel zu benutzen, die der Arbeitgeber kennt.
Alle Browser bieten da extra Schnittstellen für. Der Firefox kennt sogar die Option die genutzten Schlüssel direkt weiterzugeben. (Was Virenscanner dann ganz gerne mal nutzen.) Alles direkt über den Einstellungsdialog. Prinzipiell könnten die der Arbeitgeber aber auch selber einprogrammieren. Ist ja Open Source. Einzig der Internetexplorer könnte eine Manipulation dank Secureboot wirklich sinnvoll verhindern. Tut es aber nicht.

Kurz: Mit Defaulteinstellungen kann da niemand mitlesen. (Außer die CAs und die bekommen mittlerweile wirklich ärger, wenn sie dabei erwischt werden. Siehe Symanteck. Das debianforum musste sein Zertifikat austauschen, weil die aus den Browsern fliegen. Btw. nicht weil sie mitgehört haben sondern lediglich schwache Singnaturalgorithmen nutzten.) Es gibt aber durchaus Einstellungsdialoge mit denen man das ändern kann.
Der Berühmteste dürfte derda sein:


Und nun zu mcTLS: Prinzipiell funktioniert TLS immer so:
Zwei kommunizierende kennen den Schlüssel. Ein weiterer (die CA) sorgt dafür, dass die beiden den gleichen Schlüssel nutzen (Kennt ihn aber nicht.) Prinzipiell kann TLS schon heute nicht verhindern dass eine der Parteien Schlüssel weiterverrät sieht es aber eben nicht vor. (=> Man kann auch nicht kommunizieren dass man den Schlüssel weitergegeben hat. Und vor allem: Wer den Schlüssel hat, kann auch Inhalte abändern) mcTLS will das jetzt offiziell machen: Es kann Sessions mit mehr als 2 Nutzern geben. Vor allem auch mit Teilnehmern, die nicht ändern aber wohl mitlesen können.
Das ist Prinzipiell nichts schlechtes: PGP kennt sowas schon immer für Mails mit mehreren Empfängern. Die Frage ist, welche sinnvolle Anwendung es da für TLS gäbe. Und der ist eher nicht gegeben. Alles was da jetzt in Aussicht ist, ist dass unberechtigte (Provider, der Staat) sich da irgend wie mit Gewalt einschmuggeln und dann halt der Adel einer Standardkoformen mcTLS Verbindung bleibt. Statt dass wie bisher das weitergeben der Schlüssel an den Typ mit der Knarre nicht mehr standardkonform ist.
Das ist vor allem deswegen wichtig: die CA kann schon heute dafür sorgen, dass falsche (ihr bekannte) Schlüssel benutzt werden (und deswegen prinzipiell schon jetzt mitlesen, obwohl sie die Schlüssel nicht kennen sollte.) Sowas kann aber auffliegen. (Die beiden Seiten sehen ja welche Schlüssel genutzt werden.) Treffen die sich und merken, dass die unterschiedlich sind, wissen sie dass die CA scheiße gebaut hat und können das sogar nachweisen, da das Signiert ist. Wenn Google (oder Mozilla) davon Wind bekommt, dann bekommt die CA auf die Fresse und ist keine CA mehr. (Das ist Selbstmord und deswegen macht die sowas eher nicht für irgend einen kleinen Diktator. Meint irgend ein Ajatollah dass jetzt falsche Zertifikate ausgestellt werden wird die lieber den Ajatollah statt alle Chromeuser weltweit verlieren.)
Mit mcTLS kann sich die CA jetzt rausreden, dass das doch alles legitim und von den Nutzern gewollt war.

Wenn https in Middleboxen entschlüsselt wird, hat TOR wohl wenig Sinn.

Tor bietet (im Gegensatz zu den Browsern) keine Einstellungen, die das weitergeben von Schlüsseln an andere erlaubt. Prinzipill ist die Software OpenSource und könnte abgeändert werden. Der Aufwand ist aber viel größer und wurde entsprechend nie gemacht: Tor wird immer ganz verboten oder halt sicher ausgeliefert. Ist ja auch nicht so, dass man von dem Ding abhängig ist, wie von den Browsern. Wenn dein Arbeitgeber dir erlaubt TOR zu installieren wird er da ziemlich sicher nicht mitlesen. Auch kennt Tor nur eine CA. Die von Tor. Eine andere Nummer als die hunderten im FF.

Jana66 hat geschrieben:Aus meinen persönlichen Erfahrungen weiß ich, dass Netzbetreiber kein eigenes Interesse an teurer Überwachung und (Vorrats-) Datenspeicherung haben.

Das war mal. Längst ist sowas billiger als es wider einbringt. Angefangen hat das mit Vodafone: Die haben die Bilder auf ihren Leitungen durch Pixelmatsch ersetzt, wenn kein TLS gefahren wurde. Spart Bandbreite.
Heute macht das fast jeder Handyanbieter. Bevor youtube auf TLS umgestellt hat, gab es praktisch in keinem Handynetz youtube in HD.
Und diverse Provider in den USA machen jetzt Vorratsdatenspeicherung zum Weiterverkauf zu Werbezwecken.
Auch in Deutschland haben fast alle Anbieter die VDS laufen lassen. Die einführung war teuer und deswegen haben sich viele dagegen gewehrt. Aber wo das mal implementiert ist… Vielleicht kann man es ja nochmal gebraucht.
Sieht man immer wieder bei Gerichtsverhandlungen, dass Provider wohl über Monate weiterspeichern. Schon alleine damit man der Polizei alles geben kann was die will und sie schnell wider los hat. Auch wenn die nicht berechtigt dazu sind. Wegen zu viel haben die noch nie ärger gemacht.
Kenne mindestens eine UNI die das aus genau dem Grund heimlich macht. Offiziel wird nur in Ausnahmefällen aus technischen Gründen gespeichert, damit die Studenten nicht auf die Barrikaden gehen. Inoffiziell bekommt die Staatsanwaltschaft immer alles was sie will, damit die keinen weiteren ärger macht. Kosten für die Aktion sind mittlerweile lächerlich.

spiralnebelverdreher hat geschrieben:Mittels Aufruf der Seite https://badssl.com/ kann jeder Browsernutzer, der hier einer solchen Middlebox sitzt, feststellen inwieweit Schutzmechanismen (Zertifikatsprüfung auf Alter bspw.) ausgehebelt werden.

Nein, das kann eben nicht jeder. Die Ausgabe von https://badssl.com/ erfordert schonmal profunde Kenntnisse, um die reine Fülle an Ausgaben überhaupt interprätieren zu können. Lieschen Müller fängt damit jedenfalls rein gar nichts an und selbst mir fällt es schwer, die Ausgaben auf der Webseite zu interprätieren.

Davon abgesehen habe ich das gerade mit Telekom, Arcor/Vodafone, O2 und aus dem Firmennetz getestet und jedesmal die Antwort bekommen, daß ich belauscht werde, und, daß das Zertifikat von badssl.com abgelaufen ist.

Der Test ist irgendwie für den Popo.

wann hat geschrieben:Bitte lasse die Finger von so einem Bullshit. Verschlüsselung per Javascript kann niemals sicher sein.
Der grund ist ganz einfach: Das javascript zum verschlüsseln kann nicht signiert übertragen werden. (Weil es zum überprüfen der Signatur ja sich selbst bräuchte.) So kann ein Angreifer jederzeit ein Backdoor in das Javascript einbauen, ohne dass du davon was merkst.

Ich denke schon, dass es Mittel und Wege gibt: https://developer.mozilla.org/en-US/doc ... _Integrity
Es ist aber richtig, dass diese Möglichkeiten viel zu selten genutzt werden. Laut Doku funktioniert es wohl aktuell auch nur beim Firefox.

Zudem habe ich lieber einmalig den Angreifer auf dem Zielserver (z.B. Google, gehacktes Joomla, ...) als mit mcTLS immer irgendwo dazwischen. 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. Verschlüsselung auf Anwendungsebene bei Webanwendungen wird kommen bzw. gibt es heute schon. Zudem besser diese Verschlüsselung eben zusätzlich einbauen als gar keine haben. Man muss es ja Angreifern nicht unnötig einfach machen. TLS ist eben eine Transportverschlüsselung und mit Javascript erreicht man eine Anwendungsverschlüsselung. Das ist was ganz anderes.

wanne hat geschrieben:Tor bietet (im Gegensatz zu den Browsern) keine Einstellungen, die das weitergeben von Schlüsseln an andere erlaubt. Prinzipill ist die Software OpenSource und könnte abgeändert werden. Der Aufwand ist aber viel größer und wurde entsprechend nie gemacht: Tor wird immer ganz verboten oder halt sicher ausgeliefert. Ist ja auch nicht so, dass man von dem Ding abhängig ist, wie von den Browsern. Wenn dein Arbeitgeber dir erlaubt TOR zu installieren wird er da ziemlich sicher nicht mitlesen. Auch kennt Tor nur eine CA. Die von Tor. Eine andere Nummer als die hunderten im FF.

Danke für diese Erklärung!.

MSfree hat geschrieben:

spiralnebelverdreher hat geschrieben:Mittels Aufruf der Seite https://badssl.com/ kann jeder Browsernutzer, der hier einer solchen Middlebox sitzt, feststellen inwieweit Schutzmechanismen (Zertifikatsprüfung auf Alter bspw.) ausgehebelt werden.

Nein, das kann eben nicht jeder. Die Ausgabe von https://badssl.com/ erfordert schonmal profunde Kenntnisse, um die reine Fülle an Ausgaben überhaupt interprätieren zu können. Lieschen Müller fängt damit jedenfalls rein gar nichts an und selbst mir fällt es schwer, die Ausgaben auf der Webseite zu interprätieren.

Davon abgesehen habe ich das gerade mit Telekom, Arcor/Vodafone, O2 und aus dem Firmennetz getestet und jedesmal die Antwort bekommen, daß ich belauscht werde, und, daß das Zertifikat von badssl.com abgelaufen ist.

Der Test ist irgendwie für den Popo.

Klar, wer nicht weiß was ein Zertifikat ist und welche Eigenschaften es haben kann ist mit dem Testergebnis überfordert. Aber wir sind ja hier im debianforum, Abteilung Fortgeschrittenen Themen und Sicherheit Und wenn du das "dashboard" auf dieser Seite aufrufst bekommst du schon farbig markierte Hinweise zu bedenklichen Einschränkungen.

Ich habe den Test mit badssl.com mit Chrome (Android) in meinem Mobilfunknetz gemacht (blau) und bin auf keine Einschränkungen aufmerksam gemacht worden die dem Netzbetreiber anzulasten wären. Das Ergebnis bei Firefox (Android) sah deutlich anders aus, der akzeptiert zertifikatsmäßig jeden Mist.

Was mich sehr wundert ist deine Aussage, dass das Zertifikat von badssl.com abgelaufen ist. Auf meinem Smartphone ist das Comodo Zertifikat für *.badssl.com (SHA-256-Figerabdruck endend mit 88 12 BD AE 0D 35) gültig bis zum 06.09.17.

Oder sprichst du vom Zertifikat (SHA-256-Figerabdruck endend mit C8 20 14 D2 1B 4F) , welches dir bei Besuch der Seite https://expired.badssl.com/ präsentiert wird? Das _soll_ natürlich veraltet sein.

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.

Danke, allen. Das hilft mir brutal weiter.

uname hat geschrieben: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)

uname hat geschrieben:Laut Doku funktioniert es wohl aktuell auch nur beim Firefox.

Chrome war IMHO der erste, der es implementiert hat.

uname hat geschrieben: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.

uname hat geschrieben: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.

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?

@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")

uname hat geschrieben: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. )

uname hat geschrieben: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.

uname hat geschrieben: 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.

uname hat geschrieben: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.

uname hat geschrieben: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. )

uname hat geschrieben: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.

uname hat geschrieben: 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.

uname hat geschrieben: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.