Hallo, ich möchte eine Webapp absichern, so dass niemand gezielt sensible Daten abfragen kann. Allerdings müssen pro Client Anfragen mit hoher Frequenz beantwortet werden, und alle Pakete per SSL zu verschlüsseln würde die Webapp zu sehr ausbremsen. Meine Hoffnung ist, dass es eine Möglichkeit gibt, nur die Authentifizierung über SSL abzuwickeln, den späteren Datenverkehr aber unverschlüsselt und trotzdem sicher zu implementieren. Mir fehlt es etwas an Vorstellungskraft, mir hierfür sichere und effiziente Konzepte auszudenken. Eine Idee wäre folgende: Während der Authentifizierung schickt der Server dem Client verschlüsselt einige 100000 Keys, die der Client später in der selben Reihenfolge Stück für Stück bei jedem Request mitschickt. Klar, das verhindert nicht, dass jemand, der den http-Verkehr mithören kann, die empfangenen Daten mitliest. Jedoch sollte es dritten trotzdem unmöglich sein, gezielte Anfragen an den Server zu schicken. Oder habe ich etwas übersehen? Wahrscheinlich ist meine Idee entweder unbrauchbar, oder etwas ähnliches ist längst fertig implementiert ohne dass ich davon weiß. Könnt ihr mir Stichworte nennen, die mir sinnvolle Lösungen liefern? Danke Frank
Nein, das haben schon viele Leute geglaubt. Danach kann jemand, zum Beispiel das Cookie zur Authentifizierung nutzen, oder gar die Daten einfach mitsniffen oder verändern. Oder man kann Javascript rein schleusen was einfach den ganzen Code den Du vorher verschlüsselt übertragen hast auf einmal an einen Drittserver schickt, usw. Übrigens, wenn Du viele kleine Datenpakete übertragen willst, dann ist wahrscheinlich Websocket das, was Du nutzen möchtest. Da kannst Du viele kleine Objekte über eine Verbindung übertragen.
Kann es sein das bei dir https nur so "langsam" ist, weil du immer eine neue Verbindung aufbaust? Mit http 1.1 kann man die Verbindung offen lassen, damit braucht man nur einmal den Schlüsselaustausch. Die eigentliche Verschlüsselung sollte fast keine CPU zeit verbrauchen. Alternative über https einfach eine AES Schlüssel austauschen, und dann die Daten mit http und verschlüsselt mit AES übertragen.
Frank S. schrieb: > und alle Pakete per SSL zu verschlüsseln würde die Webapp zu > sehr ausbremsen. Weisst du das, oder vermutest du das?
Christian Berger schrieb: > Danach kann jemand, zum > Beispiel das Cookie zur Authentifizierung nutzen, oder gar die Daten > einfach mitsniffen oder verändern. Das ist nicht richtig. Der Client erhält zu Anfang auf sicherem Weg ausreichend Einweg-Keys. Der Server weiß jeweils, welchen Key er als Nächstes mit der Anfrage erwartet. Was hilft es jemandem, mitzulesen? Dass er evtl. Daten abfangen kann, ist in meinem Fall nicht kritisch. Er darf nur nicht in der Lage sein, selbst gezielte Anfragen zu schicken.
Fälschen von Daten stört nicht? Problemlos möglich.
Frank S. schrieb: > Das ist nicht richtig. Der Client erhält zu Anfang auf sicherem Weg > ausreichend Einweg-Keys. aber wozu der aufwand? Reicht nicht ein key? klar könnte man darüber nachdenken, nach ein paar Megabyte eine neue Schlüssel zu verwenden, aber doch nicht bei jeden Transfer. Aber wie schon oben geschrieben, wenn man bei https die Verbindung offen lässt sollte das auch ohne große CPU last gehen.
Peter II schrieb: > Kann es sein das bei dir https nur so "langsam" ist, weil du immer eine > neue Verbindung aufbaust? Mit http 1.1 kann man die Verbindung offen > lassen, damit braucht man nur einmal den Schlüsselaustausch. ja, so mache ich es schon > Die eigentliche Verschlüsselung sollte fast keine CPU zeit verbrauchen. Beim Server nicht. Aber lauf Profile verschwenden langsamere Clients über 99% ihrer CPU an die Entschlüsselung. > Alternative über https einfach eine AES Schlüssel austauschen, und dann > die Daten mit http und verschlüsselt mit AES übertragen. Bringt überhaupt nichts, da der Aufwand für die Entschlüsselung derselbe ist.
Frank S. schrieb: > Beim Server nicht. Aber lauf Profile verschwenden langsamere Clients > über 99% ihrer CPU an die Entschlüsselung. was haben denn die Clients für CPUs?
Peter II schrieb: > aber wozu der aufwand? Reicht nicht ein key? > > klar könnte man darüber nachdenken, nach ein paar Megabyte eine neue > Schlüssel zu verwenden, aber doch nicht bei jeden Transfer. Ein Key kann bei der ersten Anfrage mitgeschnitten werden. Danach kann ein Eindringling seine eigene Anfrage mit demselben Key formulieren, wenn er weiterhin gültig ist. Hast du dich schon mal mit Verschlüsselung beschäftigt?
Frank S. schrieb: > Beim Server nicht. Aber lauf Profile verschwenden langsamere Clients > über 99% ihrer CPU an die Entschlüsselung. Wenn du eine Internet-Anbindung hast, die schneller ist als ein normaler Allerweltsprozessor einen AES Stream entschlüsseln kann, dann trifft dich mein ganz aufrichtiger Neid.
Frank S. schrieb: > Ein Key kann bei der ersten Anfrage mitgeschnitten werden. wie soll das bei https gehen? > Hast du dich schon mal mit Verschlüsselung beschäftigt? ja Verschlüsselung und Authentifikation sind verschiedene Dinge.
Peter II schrieb: > Frank S. schrieb: >> Ein Key kann bei der ersten Anfrage mitgeschnitten werden. > wie soll das bei https gehen? Außer der Authentifizierung und der Übermittlung der Einwegschlüssel soll die Kommunikation OHNE https laufen. Das war der Kern meiner Frage.
Du könntest den Client die Nachrichten jeweils signieren lassen, bräuchtest dafür aber eine laufende Nummer oder eine Referenz auf die vorhergehende Nachricht um Replay-Attacken zu verhindern. Das ist insofern nervig das immer nur eine Anfrage parallel gestartet werden kann, nicht ganz eindeutig ist was bei verlorenen Requests passiert, und die Server sich auch immer merken müssen was denn als nächstes kommen darf. Langlebige Verbindungen sind wie schon angesprochen vermutlich sehr hilfreich, der initiale Schlüsseltausch bei HTTPS ist teuer, die eigentliche Übertragung danach nicht mehr.
Frank S. schrieb: > Peter II schrieb: >> Frank S. schrieb: >>> Ein Key kann bei der ersten Anfrage mitgeschnitten werden. >> wie soll das bei https gehen? > > Außer der Authentifizierung und der Übermittlung der Einwegschlüssel > soll die Kommunikation OHNE https laufen. Das war der Kern meiner Frage. Richtig. Aber die wozu Einwegschlüssel? Da der Schlüssel eh nicht übertragen wird, kann man ihn auch mehrfach verwenden zum verschlüsseln der Daten. Um gefälschte Daten zu erkennen schickt man einen laufenden Zähler und eine Prüfziffer. Aber wie auch schon von A. K. angemerkt, es kann fast nicht sein das eine symmetrische Verschlüsselung so viel CPU zeit braucht. ein ARM mit 50Mhz soll schon über 2Mbyte/s verarbeiten können.
Peter II schrieb: > ein ARM mit 50Mhz soll schon über 2Mbyte/s verarbeiten können. Fand grad einen Test von 2011, demgemäss Truecrypt auf einem Sandy Bridge Prozessor 1,5GB/s durchsetzt, wenn der AES Befehlssatz zum Tragen kommt. Ohne den waren es immerhin noch 277MB/s (Bytes pro Sekunde). Ok, bei einem SSL Stream wirds sicherlich weniger, weil weniger aggressiv optimiert und parallelisiert, aber es sollte sogar für schnellstes TV-Kabel noch ausreichen. Da macht eher der Server schlapp, denn wer denkt, ein Server wäre immer das Schnellste unter der Sonne, der irrt oft. Die sind im Mittel älter als die Desktops, die drauf zugreifen.
:
Bearbeitet durch User
Peter II schrieb: > Richtig. Aber die wozu Einwegschlüssel? > > Da der Schlüssel eh nicht übertragen wird, kann man ihn auch mehrfach > verwenden zum verschlüsseln der Daten. Sorry, aber das wird mir jetzt zu blöd. Man sollte sich aus Diskussionen heraushalten, wenn man nur Bahnhof versteht.
Lol, sagt der Richtige. Niemand hat davon geredet dass du einen Key im klartext rumschicken sollst den man "mitschneiden" könnte, also erklär doch das Angriffsszenario mal genauer dass er nicht versteht.
Frank S. schrieb: > Allerdings müssen pro Client Anfragen mit hoher Frequenz beantwortet > werden, und alle Pakete per SSL zu verschlüsseln würde die Webapp zu > sehr ausbremsen. SSL braucht weniger CPU als du denkst.
Frank S. schrieb: > Sorry, aber das wird mir jetzt zu blöd. Man sollte sich aus Diskussionen > heraushalten, wenn man nur Bahnhof versteht. Der einzige der nur Bahnhof versteht bist Du. Entschuldige, aber die Idee mit tausenden Einwegschlüsseln ist absoluter Blödsinn. Nimm https und gut ist. Wie schon mehr als einmal gesagt: - bei https ist der initiale Schlüsselaustausch teuer - danach ist es eine normale, symmetrische Verschlüsselung - das kriegst du mit deinen tausenden Einwegschlüsseln auch nicht schneller hin - im Gegenteil. Wo sollen die gespeichert werden? Was machst du wenn mal ein Paket verloren geht? Du hast das nicht zu ende gedacht...
Ich würde das Problem so sehen: Nur authentifizierte Clients dürfen Anfragen stellen. Die Anfrage und Antwort selbst dürfen aber mitgelesen werden. Mal ein paar unreine Gedanken -- Frage: Wenn ein nicht autorisierter Client eine bereits mitgelesene Anfrage schickt, darf er dann die damalige Antwort (mit den damaligen Daten) erhalten? Dies dürfte keine Geheimnisse verletzen. Problematisch wäre es, wenn er eine neue Antwort mit aktuellen Daten erhält. Dann könnte man sich für eine Zeit die bereits beantworteten Anfragen merken, und vielleicht die selbe Antwort oder einen Fehler zurückgeben. Dann muss man natürlich garantieren, dass sich der Client entweder nach einer Zeit neu authorisiert, oder aber jede Anfrage mit einem (verschlüsselten) Zeitstempel versehen, so dass sie nur eine gewisse Zeit erneut gestellt werden darf. -- Zurück zu den 100000 Keys: Müssen die alle in der richtigen Reihefolge geschickt werden? Ansonsten könnten die auch gruppiert werden, und man muss nur einen Key aus der Gruppe mitschicken. Das könnte das Problem mit dem vorlorenen Packet lösen. Ansonsten könnte man auch einen Zähler mitschicken, so dass der Antworter ein verlorenes Packet erkennt; danach könnte er einfach eine neue Authorisierung veranlassen. -- Anstelle der 100000 Keys könnte man auch auf beiden Seiten einen Pseudozufallszahlen-Generator verwenden, dessen Anfangswert bei der Authorisierung ausgetauscht wird. --- Eine weitere Idee wäre, anhand a) der Anfrage (z.B. durch einen Hash), b) einem aktuellen Zeitstempel und c) einem gemeisamen Geheimnis aus der Authentifizierung einen Token zu generieren, der mit der Anfrage mitgeschickt wird. Dann braucht nicht mehr die ganze Nachricht entschlüsselt zu werden, sondern nur noch der Hashwert. Wenn es nicht ganz so kritisch ist, könnte man sich vielleicht sogar auf einen Teil der Nachricht beschränken, aus dem der Hash berechnet wird. Die Wahl des Teils könnte vom gemeinsamen Geheimnis abhängen. Zeitkritisch ist natürlich die Erzeugung des Hashwertes.
>Allerdings müssen pro Client Anfragen mit hoher Frequenz beantwortet
werden, und alle Pakete per SSL zu verschlüsseln würde die Webapp zu
sehr ausbremsen.
Nee. Muss ein Client nicht. Ein Client hat alle Zeit der Welt. Die
Telephonverbindung kann auch weniger gut wie ideal sein.
Allenfalls muss man sich bei einem Server Gedanken ueber die Last
machen.
Frank S. schrieb: >> Die eigentliche Verschlüsselung sollte fast keine CPU zeit verbrauchen. > > Beim Server nicht. Aber lauf Profile verschwenden langsamere Clients > über 99% ihrer CPU an die Entschlüsselung. Falls das Apache ist: Setz mal den KeepAliveTimeout für den entsprechenden VHost hoch. Der Default von 5 Sekunden bedeutet in der Praxis das für jeden Klick vom Nutzer ein neuer Verbindungsaufbau mit Schlüsselaustasch (teuer, IMO auch auf dem Server) nötig ist. Ich würde so 30-60 Sekunden Timeout vorschlagen und dann mal nach der Last auf dem Server schauen. Falls das nicht Apache ist: Andere Server sollten analoge Einstellungen kennen. Was anderes als https ist ziemlicher Mist IMHO und würde mobile Clients noch viel stärker ausbremsen, insbesondere wenn man unautorisierte Veränderung von Daten erkennen möchte.
Jetzt Nicht schrieb: >>Allerdings müssen pro Client Anfragen mit hoher Frequenz > beantwortet > werden, und alle Pakete per SSL zu verschlüsseln würde die Webapp zu > sehr ausbremsen. > > Nee. Muss ein Client nicht. Ein Client hat alle Zeit der Welt. Die Schwachsinn. Zeitkritische Daten müssen nun einmal mit einer bestimmten Frequenz abgespielt werden. Behauptest du das auch von deinem CD-Player, dass er alle Zeit der Welt hat, wenn er die Musik nur mit 1k Samples/s wiedergibt, obwohl sie mit 44kHz aufgezeichnet wurde? > Telephonverbindung kann auch weniger gut wie ideal sein. Dein Deutsch kann auch weniger wie ideal sein. Das entschuldigt trotzdem keine sinnfreien Behauptungen.
Hm, wo treten eigentlich die größeren Probleme auf: Beim Verschlüsseln der Anfrage auf dem Client, den Entschlüsseln der Antrage auf dem Server, den Verschlüsseln der Antwort auf dem Server oder dem Entschlüsseln der Antwort auf dem Client? Ich tippe mal, dass es das Entschlüsseln auf dem Client ist. Als Szenario für ein Gedankenexperiment konstruiere ich mal eine Multimedia-Plattform, die persönliche Videostreams an Settop-Boxen von Kunden mit langsamer aber handelsüblicher Hardware verteilt. Über http kann man auch verschlüsselte Binär-Daten übertragen. Wie wäre es mit folgender Kombination: Bei Beginn und in zeitlichen Abständen kommunizieren Client und Server über sicheres HTTPS und tauschen Zweit-Schlüssel aus. Die eigentliche Massendaten werden über einen einfacheren, performateren Algorithmus mit diesen Zweitschlüsseln verschlüsselt, oder vielleicht auch nur verschleiert.
Achim Hensel schrieb: > Ich tippe mal, dass es das Entschlüsseln auf dem Client ist. Worauf gründet diese Vermutung? Gängige symmetrische Verfahren wie AES sind auch hinsichtlich der Performance einigermassen symmetrisch.
Achim Hensel schrieb: > Bei Beginn und in zeitlichen Abständen kommunizieren Client und Server > über sicheres HTTPS und tauschen Zweit-Schlüssel aus. Die eigentliche > Massendaten werden über einen einfacheren, performateren Algorithmus mit > diesen Zweitschlüsseln verschlüsselt, oder vielleicht auch nur > verschleiert. Gratuliere! Du hast soeben HTTPS, SSL/TLS und IPSEC erfunden. ;-) Genau das passiert da nämlich. Ein aufwändiges asymmetrisches Verfahren wird verwendet, um den Schlüssel eines performanten symmetrischen Verfahrens zu vereinbaren. Der bei längeren Verbindungen ab und zu ausgetauscht wird. Weshalb hier auch schon erwähnt wurde, dass der ganze Trick nur darin besteht, die SSL Verbindung (HTTPS ist HTTP über SSL) deutlich länger offen zu halten. Auch PGP arbeitet nach diesem Schema. Das aufwändige Verfahren überträgt nur den zufällig erzeugten Schlüssel des performanten symmetrischen Verfahrens für den eigentlichen Inhalt.
:
Bearbeitet durch User
Sorry. Wenn ich eine CD, resp Musik von einem Server downloade, kann ich nicht davon ausgehen, dass das in Echtzeit geschieht. Das Internet ist redundant designt, es muss auch bei suboptimalen Bedingungen laufen. Falls man hohen Durchsatz will, muss man sich eben von TCP verabschieden und mit UDP arbeiten, wo auch mal was verloren gehen kann. Wie Skype, da ruckelt es manchmal. Skype ist uebrigens auch verschluesselt.
Jetzt Nicht schrieb: > Das Internet ist redundant designt, es muss auch bei suboptimalen > Bedingungen laufen. Falls man hohen Durchsatz will, muss man sich eben > von TCP verabschieden und mit UDP arbeiten, wo auch mal was verloren > gehen kann. Wie Skype, da ruckelt es manchmal. Skype ist uebrigens auch > verschluesselt. wenn aber alle Daten wichtig sind und nichts verloren gehen darf, dann bringt eine UDP auch nichts.
Sprach/Video-Daten in Live-Übertragung arbeiten eigentlich immer per UDP. Mit Durchsatz hat das aber überhaupts nichts zu tun, sondern mit der Art des übertragenen Inhalts. Es ergibt schlicht keinen Sinn, verlorene Daten zu wiederholen. Der Versuch würde das Problem nur vergrössen. Hohen Durchsatz erreicht man auch mit TCP. Ein Beispiel dafür ist NFS, das früher per UDP arbeitete, mittlerweile aber überwiegend per TCP arbeitet.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.