Verschlüsselte Datenübertragung per Skript möglich?

hal77 erklärte u.A. Folgendes:

Zitat

[...]Nun, kürzlich unterbreitete mir ein Support eine neue "Sicherheitsvariante“: Verschlüsselung per Skript.[...]

Eine durch individuelle Scripte geführte lokale Verschlüsselung setzt – meinen bisherigen Erkenntnissen nach – stets voraus, das die kommunikative Gegenstelle (also Dein Kommunikationspartner) zur Dekodierung solcher vertraulichen Daten im Besitz des gleichen Scripts ist. Das „gemeinsame Geheimnis“ muss somit im Vorfeld bereits zwischen den einzelnen Kommunikationspartnern abgesprochen - bzw. ausgetauscht worden sein, um von daher eine Informationsvertraulichkeit (Information nicht einlesbar) und darüberhinaus auch einen Bezug zum Datenursprung (Identität nicht abstreitbar) gewährleisten zu können.

Unabhängig davon, existieren öffentlich zugängliche ASCII-Zeichen Kodierungsverfahren z.B. Base64, die jedoch in Bezug auf eine vertrauliche Fernkommunikation nicht als sicher zu betrachten sind.

hal77 fragte darüberhinaus Folgendes:

Zitat

[...]Und da habe ich mich eben gefragt, ob es angehen kann, dass es ein Skript gibt, welches eine gleichwertig verschlüsselte Datenübertragung gewährleistet wie per https://??[...]

Das lässt sich nicht vergleichen.
Eine Ende zu Ende Verschlüsselung des allgemeinen SSL-Protokolls (HTTPS) auf der „Transportebene“ (also Schicht 4 des OSI-Modells) ist in Bezug der „kryptografischen Stärke“ zwar als relativ sicher zu betrachten. Da die übertragenen Daten im Zuge so eines HTTPS-Verfahrens jedoch nicht signiert werden, ist somit leider die „Verbindlichkeit“ der Übertragungen nicht gesichert.

Fazit: Verschlüssele Deine vertraulichen E-Mail Texte separat. Im Zuge von z.B. Passwort-Umstellungen über gesicherte HTTPS-Webseiten, bist Du jedoch auf die „Sicherheit“ des allgemeinen SSL-Protokolls angewiesen.

Gruss nach Mexico – Lange war es her.

Oliver

http://www.multi-online.com/netzwerk/osi.php

hal77 erwiderte u.A. Folgendes:

Zitat

[...]Vielen Dank für Deine Erläuterungen, welche ich mit großem Interesse las!

Zögere nicht explizit nachzufragen. Dafür sind wir alle hier.

Hauptrache Du kannst eine (technische) Erkenntnis gewinnen...

Wissen = Dienen.

Oliver

hal77 fragte Folgendes:

Zitat

a.) Daß Webseiten, die zwar eine gesicherte https://-Verbindung dem Besucher auf ihrer Webseite zusagen, dies jedoch nicht im Internet Browser mit https:// sowie optisch in der Adresszeile (grün, blau, gelb) rückmelden, für eine sichere Datenübertragung als unsicher einzustufen sind?

Nein.

Webseiten können gleichzeitig aus gesicherten, sowie aus ungesicherten Elementen bestehen. Webseiten, welche sich in ihrer Gesamtheit mosaikartig einerseits aus ungesicherten Elementen (über http) – sowie andererseits aus gesicherten Bestandteilen (http(s)) zusammensetzen, können zwar vordergründig in der Browser-Anwahl (also als erstmaligen Abruf in Deiner URL-Leiste) als unsicher dargestellt werden. Das vertrauliche Log-In solcher passwortgeschützten Zugangskontrollen würde sich dann einem relativ gesicherten SSL-Protokoll beugen müssen, welches jedoch keine Verbindlichkeiten der E2E-Verbindungen ermöglicht. Darüberhinaus werden unter solcher SSL geschützten Vermittlung nur die Nutzerdaten der IP-Pakete verschlüsselt, was wiederum Verkehrsflussanalysen über die unverschlüsselt verbleibenden Header ermöglicht.

a. Automatische Umstellung der Anfrage auf das allgemeine (Handshake / Server-Client) SSl-Verfahren zweier Kommunikationsendpunkte. (Sichtbar in URL-Leiste).

b. Verschlüsselung der vertraulichen Zugangsinformationen über ein serverseitiges „PHP-Script“. (Vermutlich das, was Dein Support erwähnte).

Zitat

b.) Selbst dann, wenn im Quellcode der Webseite eine Verschlüsselung per Link eingebettet ist, welcher auf einen sicheren Verbindungsaufbau hinweisen könnte?[...]

Lässt sich der von Dir genannte Webauftritt mit einem vorangestellten „http(s)“ in der Browser-Zeile von vornherein unter vertraulichen Voraussetzungen erneut starten? (z.B. wie bei GMX?). Du gibst diesbezüglich bedauerlicherweise sehr wenige Informationen preis.

Zitat

c.) Dass aufgrund des vorgenannten Links sich kein gesicherter Verbindungsaufbau für den Besucher herleiten lässt, auch wenn der Support folgende Aussage macht: "Die Verschlüsselung geschieht über ein Script und wird daher nicht in der Adresszeile in Form von https:// angezeigt.

Siehe oben...

Vertrauliche Datenübertragungen liessen sich darüberhinaus mit Hilfe des Kommandozeilenprogramms (cmd) unter Windows (netstat -ano) - in Verbindung mit dem Task-Manager - auf ihre Sicherheit über „port 433“ hin überprüfen.

Oliver

Ich habe mich im Zusammenhang mit dem Thema Oauth mal mit dem Thema verschlüsselung in Javascript beschäftigt.

Das Ergebnis ist, daß solange der private Schlüssel fest im Script abgelegt ist, meines Erachtens keine sinnvolle Verschlüsselung mit Javascript möglich ist. Sämtliche Abläufe lassen sich im Debugger (z.B. Venkman) und anhand des stets bei Javascripts verfügbaren Quellcodes nachvollziehen. Der private Schlüssel kann nur sehr schwer im Code "versteckt" werden. Natürlich kann man grundsätzlich auch Javascript Quellcodes "verschleiern" (obfuscation) aber das verzögert die Sache nur.

Ebenso läßt sich der Datenverkehr in Firefox z.B. mittels des Add-ons HttpFox überwachen. Damit ist natürlich nicht der Datenstrom eines einzelnen Anwenders gemeint sondern zum Zwecke der Schlüsselermittlung allgemein.

Es wird also entweder ein Schlüssel je Benutzerkonto benötigt, der nur dem Benutzer und dem jeweiligen Serverbetreiber bekannt ist (ein längeres Kennwort z.B.) oder aber Binärkomponenten (XPCOM, Java rechne ich mal rein, oder Active-Nix..) deren privater Schlüssel nicht so leicht zu ermitteln ist.

Im großen und ganzen viel Aufwand und Unsicherheit, für etwas das man sich mit https eigentlich sparen kann. (Es sei dennman möchte die übertragenen Daten vor dem Benutzer selbst verbergen).