BenBE hat folgendes geschrieben :

Was ich in deinem Updater extrem vermisse (das hat aber bisher keiner der hier im DF vorgestellten AFAIK, obwohl das EXTREM wichtig wäre): Ich habe keine Chance, die erhaltenen Updates auf Integrität und Authentizität zu prüfen. Wenn ich das in deinem Beispiel richtig stehe, kommt das Update-Script über eine HTTP-Verbindung, dein Archiv für's Update kommt über eine HTTP-Verbindung. Leichter kann man das großflächige Infizieren mit Viren einem Angreifer nicht machen. Vor knapp 2 Jahren gab es mal im Inet ein Problem, bei dem JEGLICHE DNS-Server verwundbar waren gegen das Unterschieben falscher DNS-Antworten in Cache-Server. Resultat war, dass man beliebige Domains problemlos verbiegen konnte. Nach dem das Problem an den DNS-Servern gefixt war, zeigte sich aber ein zweiteres, wesentlich schwerwiegenderes: Kaum einer der verfügbaren Updater hätte eine Manipulation an sinen Updates festgestellt. Ich würddaher raten, eine Möglichkeit um Client-Seitig sowohl das Update-Script als auch die heruntergeladenen Dateien zu validieren, einzubauen.

BenBE hat folgendes geschrieben :

Verschlüsslung bringt zwar schon mal etwas gegen die offensichtlichen Angriffe (transparenter Zwangsproy), behebt das Problem aber nicht. Sinnvoller wäre hier die Nutzung von digitalen Signaturen, wo nur der Ersteller der Anwendung Einfluss auf die verwendeten Schlüssel hat. Eine etwas schwächere Variante wäre die Nutzung von HMACs (Message Authentication Codes) die grob als eine Art Salted Hash aufgefasst werden können.Mehr dazu erklär ich aber auch gern noch mal in nem separaten Thread

für eine genaue Erklärung wäre ich sehr dankbar

BenBE hat folgendes geschrieben :

Was ich in deinem Updater extrem vermisse (das hat aber bisher keiner der hier im DF vorgestellten AFAIK, obwohl das EXTREM wichtig wäre): Ich habe keine Chance, die erhaltenen Updates auf Integrität und Authentizität zu prüfen. Wenn ich das in deinem Beispiel richtig stehe, kommt das Update-Script über eine HTTP-Verbindung, dein Archiv für's Update kommt über eine HTTP-Verbindung. Leichter kann man das großflächige Infizieren mit Viren einem Angreifer nicht machen. Vor knapp 2 Jahren gab es mal im Inet ein Problem, bei dem JEGLICHE DNS-Server verwundbar waren gegen das Unterschieben falscher DNS-Antworten in Cache-Server. Resultat war, dass man beliebige Domains problemlos verbiegen konnte. Nach dem das Problem an den DNS-Servern gefixt war, zeigte sich aber ein zweiteres, wesentlich schwerwiegenderes: Kaum einer der verfügbaren Updater hätte eine Manipulation an sinen Updates festgestellt. Ich würddaher raten, eine Möglichkeit um Client-Seitig sowohl das Update-Script als auch die heruntergeladenen Dateien zu validieren, einzubauen.

Bei einem Updater gibt es immer mehrere Teile innerhalb eines Gesamtsystems: Eine Update-Quelle, einen Client, der das Update empfangen will, sowie eine Stelle, die sicherstellt, dass das, was als Update übertragen wurde auch dem entspricht, was bei der Update-Quelle abgesendet wurde.

Die Update-Quelle erzeugt hierbei eine Datei, in der alle für das Update notwendigen Änderungen enthalten sind. Dies kann entweder eine Kopie aller neuen Dateien sein, oder ein Diff der Änderungen. Diese Information gilt es unverändert an den Client zu übertragen, da eine fehlerhafte Übertragung entweder die Anwendung beschädigt, oder eine Manipulation von außen bedeuten kann. Dabei ist die Vertraulichkeit des Update-Inhaltes, wie er durch Verschlüsslung entstehen würde, nicht notwendig, da die durchzuführenden Änderungen an anderen Stellen (auf der Festplatte nach Installation des Updates, offizieller Download der Anwendung) eh einsehbar sind. Privatsphären-Überlegungen können aber bei inkrementellen Updatern durchaus eine Rolle spielen, da anhand der angeforderten Informationen Rückschlüsse auf die installierte Version sein können und daher durch Störung des Update-Prozesses Rückschlüsse auf den aktuell installierten, aber noch nicht aktualisierten Stand möglich werden.

Ferner ist bei der Übertragung zu beachten, dass es sich keinesfalls um eine gesicherte Ende-zu-Ende-Verbindung handelt, die von außen gegen Änderungen geschützt ist. Vielmehr ist eine typische Internet-Verbindung eine Punkt-zu-Punkt-Verbindung, bei der auf jeder Teilstrecke Inhalte eingesehen UND verändert werden können.

BenBE hat folgendes geschrieben :

Verschlüsslung bringt zwar schon mal etwas gegen die offensichtlichen Angriffe (transparenter Zwangsproy), behebt das Problem aber nicht. Sinnvoller wäre hier die Nutzung von digitalen Signaturen, wo nur der Ersteller der Anwendung Einfluss auf die verwendeten Schlüssel hat. Eine etwas schwächere Variante wäre die Nutzung von HMACs (Message Authentication Codes) die grob als eine Art Salted Hash aufgefasst werden können.Mehr dazu erklär ich aber auch gern noch mal in nem separaten Thread

Eine Möglichkeit, Inhalte zu verändern, ist die Nutzung sogenannter transparenter Zwangsproxies. Hierbei handelt es sich um spezielle Firewall-Regeln, die dafür sorgen, dass jede über die Firewall hinweg aufgebaute Verbindung an einen anderen, dafür vorgesehenen Rechner umgeleitet wird, der sich um die weitere Behandlung des Datenverkehrs dieser Verbindung kümmert. Gegenstelle ist in diesem Fall nicht mehr der eigentliche Update-Server, sondern ein unter Kontrolle eines möglichen Angreifers befindliches System, was die gesamte Kommunikation zwischen Client und Update-Server mitlesen und nach belieben verändern kann. Üblicherweise liefern transparente Proxies die gewünschten Inhalte unverändert aus, goldene Brandschutzmauern oder Erdwälle haben aber durchaus auch Manipulationsmöglichkeiten enthalten.

Der beste Schutz, wenn man nun manipulationen an seinen Daten ausschließen möchte, ist daher nicht, diese zu verschlüsseln, sondern dafür zu sorgen, dass man jegliche Änderungen zuverlässig erkennt. Diese Eigenschaft nennt man in der Kryptographie "Integrität" einer Nachricht. Diese wird von den üblichen Prüfsummen-Verfahren wie CRC32 (nunja, Kopfrechenaufgabe ), MD5 (hmmm, k, zu Staube zerfallen), SHA1 (bröckelt), SHA512 bzw. Whirlpool unterschiedlich gut erledigt. Eine korrekte Prüfsumme unter einem Update sagt also schon einmal aus, dass das Update richtig übertragen wurde, gibt aber keinerlei Informationen über den Ursprung. Solange ein Angreifer also neben seinen Manipulationen an der Übertragung auch die Prüfsummen unter Kontrolle hat (was üblicherweise der Fall ist), kann er einem Client beliebige, korrekt erscheinende Updates unterschieben, die das Vorhandensein der aktuellen Dateiversion von evil.com/0day/trojaner.exe als Teil von Müller&Maier's Unbedenkliches Freeware-Tool v5.39 sicherstellt.

Fehlt die zweite wesentliche Forderung an einen Updater: Die Authentizität: Ich muss sicherstellen können, dass eine Nachricht wirklich vom vorgegebenen Absender stammt. Je nach Anwendungszweck gibt es hierfür mehrere Mögliche Ansätze:

1. Message Authentication Codes: Diese stellen eine Art Prüfsumme dar, der ein nur dem Absender und dem Empfänger bekanntes Geheimnis vorangestellt ist. Ohne Kenntnis des Geheimnisses kann die korrekte Prüfsumme nicht berechnet werden. Problematisch ist hierbei, dass sowohl Absender wie auch Empfänger das Geheimnis kennen müssen, wodurch das Geheimnis als Teil eines Updaters z.B. durch Reverse-Engineering leicht gefunden werden kann.
   
2. Asymetrische Verschlüsslungsverfahren: Diese können relativ einfach zum Erzeugen von Signaturen verwendet werden. der Schlüssel zum Erzeugen und zum Überprüfen einer Signatur unterscheiden sich hierbei auf Absender (privater Schlüssel) und Empfänger-Seite (öffentlischer Schlüssel). Ein Angreifer kann nur die Integrität eines Updates prüfen, kann aber nicht auf einfachem Wege eine gültige Prüfsumme mit Unterschrift für sein manipuliertes Update erzeugen.
   

glotzer hat folgendes geschrieben :

für eine genaue Erklärung wäre ich sehr dankbar

Für Details einfach gezielt nachhaken.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

zu Asymetrische Verschlüsslungsverfahren:

wie kann man sowas ohne viel aufwand anstellen?

glotzer hat folgendes geschrieben :

zu Asymetrische Verschlüsslungsverfahren: wie kann man sowas ohne viel aufwand anstellen?

Dafür verweise ich mal kurz auf die Crypto-API von Windows, die kann das IIRC. Alternativ gibt's für RSA aber auch fertige Units, mit denen man das impleentieren kann. Ansonsten wäre ein Blick auf (Wide)OpenSSL empfehlenswert, weil Du dann gleich Support für X.509-Zertifikate hast und damit z.B. die üblichen Client-Zertifikate zum Signieren der Updates nutzbar sind.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

hmm das wird ja ne schöne Arbeit :p

naja ich werd mich denk ich mal drumm kümmenr den Updater sicher zu bekommen

/edit: ich liebe die indys, 5 zeilen code und fertig war es

das würde mich jetzt mal interessieren:
wie genau lauten denn diese 5 Zeilen?

Siehe hier:
www.delphi-forum.de/viewtopic.php?t=100262

ja, da kann man es finden(aber leider noch nicht getested da ich zur zeit keinen server da hab...)
im algemeinen hab ich es so gelöst:



wobei

(NICHT getested da kein server da, und wird nur gehen wenn die nötigen zertificate im anwendungsordner sind, der code stammt von den indy beispielen zu openSSL)

Ja so fügt man SSL Support hinzu. Aber da ist ja noch nix mit Zertifikaten drin, oder?

soweit ich das gelesen hab werden diese mit verarbeited... aber sicher bin ich mir nicht (wie gesagt kann gerade nicht testen...) ich werd später mal schauen

/edit: grade getestet: nix is es... mach ich es halt schnell selbst...

wäre cool, wenn du deine Ergebnisse dann hier posten könntest!

türlich, mach ich.
wird alerdings noch ein bisal dauern... das ist nicht so ganz einfach^^