GETPOST: Get oder Post

Welche Datenübertragung ist besser?

Get oder Post?

Bitte um Meinungen, in jede Richtung (z.B. Sicherheit, Geschwindigkeit, Übertragbarkeit usw.)

Danke schon mal im Vorraus

MfG ein Unwissender

  1. Hallo,

    Beide sind genauso gut. GET nutzt man wenn man nur ein bischen Daten übertragen will und POST für viel Text und binäre Daten. GET kann man mit <form> aber auch in Links <a> schicken, POST geht nur mit <form> (oder natürlich mit JavaScript).

    Grüße
    Jeena Paradies

    -- Weihnachtsurlaub | Jlog | Gourmetica Mentiri
    1. Hallo,

      Beide sind genauso gut. GET nutzt man wenn man nur ein bischen Daten übertragen will und POST für viel Text und binäre Daten. GET kann man mit <form> aber auch in Links <a> schicken, POST geht nur mit <form> (oder natürlich mit JavaScript).

      naja, es gibt schon kleine Unterschiede!
      Insbesondere bzgl. Sicherheit. Ich kenne einen Dienstleister, der seit neuestem damit wirbt, daß sein Service jetzt auch SSL unterstützt. Dabei kann man jetzt auch https://.....?parameter=...
      angeben.
      Sehr sinnig, weil man damit SSL umschifft.

      Gruß
      Reiner

      1. Moin!

        naja, es gibt schon kleine Unterschiede!
        Insbesondere bzgl. Sicherheit. Ich kenne einen Dienstleister, der seit neuestem damit wirbt, daß sein Service jetzt auch SSL unterstützt. Dabei kann man jetzt auch https://.....?parameter=...
        angeben.
        Sehr sinnig, weil man damit SSL umschifft.

        Wieso denn das? Natürlich wirkt SSL, auf dem Übertragungsweg kann die angeforderte URL von niemand Drittem mitgelesen und ermittelt werden.

        Und genau das ist, was SSL leisten kann - nicht mehr, und nicht weniger.

        POST-Daten sind genauso gefährdet an den Endpunkten der Kommunikation (sprich: Browser und Server), wie GET-Daten.

         - Sven Rautenberg

        -- "Love your nation - respect the others."
        1. Wieso denn das? Natürlich wirkt SSL, auf dem Übertragungsweg kann die angeforderte URL von niemand Drittem mitgelesen und ermittelt werden.

          Echt? Ich werden die Parameter abgetrennt? Die müssen doch für das Ziel weitergegeben werden, oder? Also, alle Router müssen den URL lesen können. Die Parameter werden anders behandelt?

          Gruß
          Reiner

          1. Hallo Reiner,

            Wieso denn das? Natürlich wirkt SSL, auf dem Übertragungsweg kann die angeforderte URL von niemand Drittem mitgelesen und ermittelt werden.

            Echt? Ich werden die Parameter abgetrennt? Die müssen doch für das Ziel weitergegeben werden, oder? Also, alle Router müssen den URL lesen können. Die Parameter werden anders behandelt?

            Wovon redest Du bitte? HTTP funktioniert so: Der Browser löst der Hostnamen im URI auf und verbindet sich dann zu dieser IP-Adresse per TCP (angegebener Port oder Port 80 als Default). Über diese TCP-Verbindung (die jeder auf dem Weg mitlesen kann, per default aber nicht mitgelesen wird!) werden dann HTTP-Requests gesendet, der Form:

            ------------------- schnipp -----------------------------------------
            METHODE /pfad/zur/resource?parameter=wert HTTP/1.1
            Host: hostname_des_requests.example
            Weitere-Header: bla

            Request-Body (bei GET nicht vorhanden, bei POST sind hier die POST-Daten)

            ------------------- schnapp -----------------------------------------

            Kein einziger Router bekommt einen vollen URI mit (außer er würde den Inhalt der Pakete inspizieren, was Router per Default nicht tun), die Router interessieren nur exakt vier Angaben: Quell-IP, Quell-Port, Ziel-IP, Ziel-Port.

            HTTPS funktioniert nun so: Der Browser löst den Hostnamen im URI auf und Verbindet sich dann zu dieser IP-Adresser per TCP (angegebener Port oder Port 443 als Default). Über diese TCP-Verbindung wird nun ein TLS/SSL-Handshake durchgeführt und somit ein verschlüsselter, authentifizierter (!) Tunnel zwischen Browser und Server aufgebaut. Über diesen Tunnel wandern dann ganz normale die HTTP-Requests.

            Router dazwischen bekommen wieder nur Quell-IP, Quell-Port, Ziel-IP, Ziel-Port mit. Wenn sie bei HTTPS jedoch in die Pakete schauen, sehen sie nur Zeichensalat, ohne den richtigen Schlüssel können sie den Inhalt des Datenstroms nicht entschlüsseln und der HTTP-Request bleibt ihnen komplett verborgen. Um Man-in-the-Middle-Attacken vorzubeugen (der Router klinkt sich in die Kommunikation ein und baut zwei Tunnel auf: einen zwischen Browser und ihm selbst und einen zwischen ihm selbst und dem eigentlichen Server) gibt's bei SSL/TLS Zertifikate, um sein Gegenüber zu verifizieren.

            Außer Routern gibt's noch die Frage nach Proxies. Bei unverschlüsselten HTTP-Proxies laufen *alle* Angaben über den Proxy: Der Browser verbindet sich per TCP mit dem Proxy und sendet einen Request à la:

            ------------------- schnipp -----------------------------------------
            METHODE http://hostname:port/pfad/zur/resource?parameter=wert HTTP/1.1
            Weitere-Header: bla

            Request-Body (bei GET nicht vorhanden, bei POST sind hier die POST-Daten)

            ------------------- schnapp -----------------------------------------

            Der Proxy kann hier also alles mitschneiden. Verwendet man dagegen HTTPS über einen Proxy sendet der Browser folgenden Request:

            ------------------- schnipp -----------------------------------------
            CONNECT hostname:port HTTP/1.1

            ------------------- schnapp -----------------------------------------

            Daraufhin baut der Proxy selbst eine direkte Verbindung zu hostname:port auf und kopiert Daten zwischen den beiden Verbindungen hin- und her. Diese Daten sind dann wieder der SSL/TLS-Handshake + anschließende verschlüsselte Daten. Hier bekommt der Proxy also auch nur Zielhostnamen und Zielport mit, nicht jedoch irgendwas näheres zum Request, der über die Leitung geht. Auch hier kann der Proxy nicht eingreifen und Man-in-the-middle spielen, da hier genauso wie vorher SSL/TLS-Zertifikate überprüft werden können.

            GET/POST geben sich also sicherheitstechnisch in _dieser_ Hinsicht nichts. URL-Parameter haben jedoch einen anderen Nachteil: Wenn z.B. in der URL sensitive Daten übermittelt werden (Passwörter, Session-IDs, etc.) und jemand klickt auf einer Seite, die solche Daten in der URL enthält, einen Link an, dann wird die komplette Adresse samt Parametern als Referer an das Link-Ziel übertragen - jemand, der seine Server-Logs beobachtet, könnte damit einiges an Schaden anstellen. Deswegen verwenden diverse Webmail-Dienste Mechanismen, um bei Links eine weitere Seite dazwischenzuschalten, die "sauber" ist und die dann selbst als (harmloser) Referer im Serverlog des verlinkten auftaucht.

            Viele Grüße,
            Christian

            --
            "I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." - Bjarne Stroustrup

            1. Hallo Christian,

              HTTPS funktioniert nun so: [...] Über diese TCP-Verbindung wird nun ein TLS/SSL-Handshake durchgeführt und somit ein verschlüsselter, authentifizierter (!) Tunnel zwischen Browser und Server aufgebaut. Über diesen Tunnel wandern dann ganz normale die HTTP-Requests.
              Router dazwischen bekommen wieder nur Quell-IP, Quell-Port, Ziel-IP, Ziel-Port mit.

              Naja, wie ist denn sichergestellt, dass eben die Router -  nehmen wir mal an, jemand würde dort ordentlich mitschneiden - nichts mitkriegen? Zum Aufbau der verschlüsselten Verbindung müssen die Schlüssel ja erst mal ausgetauscht werden, womit sich die Verschlüsselung erübrigt, denn was bringt denn Verschlüsselung, wenn ich meinem Feind vorher den Schlüssel gebe?

              GET [...]  Referer an das Link-Ziel übertragen - jemand, der seine Server-Logs beobachtet,[...]

              wow, mir ist der Sinn dieser REFERER-Seiten noch nie derartig bewusst geworden. Das macht schon Sinn, GMX speichert in seinem Request-String ja ganze Bücher ab, durch den Referer wird das schön sauber abgeschnitten. Gmail macht letzteres nicht, und die Folgen kennen wir ja (*SCNR*)

              Grüße und ein Lob für die ausführliche Erklärung,

              Sven

              1. Hallo Sven,

                HTTPS funktioniert nun so: [...] Über diese TCP-Verbindung wird nun ein TLS/SSL-Handshake durchgeführt und somit ein verschlüsselter, authentifizierter (!) Tunnel zwischen Browser und Server aufgebaut. Über diesen Tunnel wandern dann ganz normale die HTTP-Requests.
                Router dazwischen bekommen wieder nur Quell-IP, Quell-Port, Ziel-IP, Ziel-Port mit.

                Naja, wie ist denn sichergestellt, dass eben die Router -  nehmen wir mal an, jemand würde dort ordentlich mitschneiden - nichts mitkriegen? Zum Aufbau der verschlüsselten Verbindung müssen die Schlüssel ja erst mal ausgetauscht werden, womit sich die Verschlüsselung erübrigt, denn was bringt denn Verschlüsselung, wenn ich meinem Feind vorher den Schlüssel gebe?

                Das ist das geniale an asymmetrischen Verschlüsselungsverfahren: Es müssen nur die öffentlichen Schlüssel ausgetauscht werden, die privaten Schlüssel behält jeder für sich. Damit kann jemand so viele übertragene Schlüssel abfangen, wie er will, er wird daraus den privaten Schlüssel nicht ableiten können (unter der Voraussetzung, dass das Verschlüsselungsverfahren keine systematischen Fehler aufweist und die Schlüssellänge groß genug ist, dass ein Versuch länger brauchen würde, als das Alter des Universums oder so ähnlich). Und dann können beide einen gemeinsamen, symmetrischen Schlüssel austauschen, der für die eigentliche Kommunikation verwendet wird (asymmetrische Verschlüsselung ist zu langsam dafür).

                Außer asymmetrischen Verschlüsselungsverfahren gibt's übrigens noch die Möglichkeit, ein Schlüsseltauschverfahren einzusetzen, z.B. Diffie-Hellman. Damit kann zwischen zwei Parteien ein Schlüssel ausgetauscht werden, ohne dass der komplette Schlüssel jemals über die Leitung wandern würde, beide Parteien hinterher jedoch den gleichen Schlüssel haben.

                Zwei mögliche Probleme:

                1) Man-in-the-middle-Attacken, d.h. der Client tauscht in Wirklichkeit mit dem Router aus und der wiederum mit dem Server und der Router würde jegliche Kommunikation dazwischen immer hin- und herkopieren und dabei aber auch mitschneiden. Für diesen Fall gibt es wie erwähnt Zertifikate, damit sich zumindest der Server authentifizieren kann (es gibt auch Client-Zertifikate, und die Browser unterstützen diese auch, allerdings habe ich noch niemanden gesehen, der das tatsächlich einsetzt; für die Client-Authentifizierung wird dann meistens doch so etwas "profanes" wie ein Passwort verwendet).

                2) Fehler in der Handshake-Implementierung bzw. im Design des Handshake-Verfahrens. Dies ist ein kryptographish sehr heikler Punkt, da sehr viele (auch sehr schlaue) Leute da schon sehr viel falsch gemacht haben. Ich habe selbst viel zu wenig Ahnung und Erfahrung, als dass ich es mir zutrauen würde, so ein Verfahren beurteilen oder gar entwerfen zu können. Das Verfahren jedoch, das zum Beispiel bei TLS eingesetzt wird, wurde von vielen Sicherheitsexperten überprüft und meines Wissens hat bisher keiner eine Schwäche darin gefunden, d.h. wenn die TLS-Implementierung sauber ist, sollte TLS eine annehmbare Sicherheit bieten.

                Viele Grüße,
                Christian

                --
                "I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." - Bjarne Stroustrup

                1. Hallo Christian,

                  1) Man-in-the-middle-Attacken [...] Für diesen Fall gibt es wie erwähnt Zertifikate, damit sich zumindest der Server authentifizieren kann

                  aber was hilft das, wenn der "böse lauschende Router" dazwischenhängt und auch das Zertifikat einfach durchreicht? Mir ist das nämlich immer noch nicht wirklich klar. Wenn ein Lauscher, z.B. ein manipulierter Router, tatsächlich alles von Anfang an mitschneidet, hat er die gleiche Information wie Server und Client und kann damit auch die gesamte abgehörte Kommunikation entschlüsseln. Schließlich bekommt er den Verbindungsaufbau und alle Daten, die dabei ausgetauscht werden, aus erster Hand mit. Oder worin besteht nun die Sicherheit?

                  So long,
                   Martin

                  --
                  Ist die Katze gesund,
                  freut sich der Hund.

                  1. Hallo Martin,

                    1) Man-in-the-middle-Attacken [...] Für diesen Fall gibt es wie erwähnt Zertifikate, damit sich zumindest der Server authentifizieren kann

                    aber was hilft das, wenn der "böse lauschende Router" dazwischenhängt und auch das Zertifikat einfach durchreicht? Mir ist das nämlich immer noch nicht wirklich klar. Wenn ein Lauscher, z.B. ein manipulierter Router, tatsächlich alles von Anfang an mitschneidet, hat er die gleiche Information wie Server und Client und kann damit auch die gesamte abgehörte Kommunikation entschlüsseln. Schließlich bekommt er den Verbindungsaufbau und alle Daten, die dabei ausgetauscht werden, aus erster Hand mit. Oder worin besteht nun die Sicherheit?

                    Ok, dann erst einmal zur Klarstellung: Ein Zertifikat ist stark vereinfacht gesagt ein öffentlicher Schlüssel, der von einer Zertifizierungsstelle digital unterschrieben wurde. Das heißt also, dass die Zertifizierungsstelle den öffentlichen Schlüssel beglaubigt hat, d.h. wenn man ein Zertifikat erhält, das von einer Zertifizierungsstelle, der man vertraut, unterzeichnet wurde, dann kann man sicher [1] sein, dass der öffentliche Schlüssel wirklich zum Gegenüber gehört. Das heißt, wenn ich mich mit einem TLS-Server verbinde und erhalte dann ein Zertifikat, dann sagt mir das zwei Dinge:

                    1) Der öffentliche Schlüssel des Servers ist der, der im Zertifikat
                       unterzeichnet wurde.
                    2) Die Zertifizierungsstelle XYZ, der ich vertraue, hat das Zertifikat
                       unterzeichnet.

                    Was hat das für Konsequenzen? Zum öffentlichen Schlüssel gehört ein privater Schlüssel. Wenn jetzt jemand etwas mit diesem privaten Schlüssel signiert und mir schickt, dann kann ich die Signatur dieser Nachricht mit dem öffentlichen Schlüssel des Zertifikats verifizieren. Ich kann also sicher sein, dass die Nachricht mit dem zum öffentlichen Schlüssel zugehörigen privaten Schlüssel signiert wurde. Da ich haber weiß, dass der öffentliche Schlüssel authentisch ist, weiß ich auch, dass die Nachricht authentisch ist.

                    Jetzt betrachte Dir zum Beispiel noch einmal den Diffie-Hellman-Schlüsseltauschalgorithmus. Was passiert denn dort genau (ohne die ganze Zertifizierungsgeschichte)?

                    Beide Seiten schicken sich gegenseitig ein paar Informationshäppchen, aus denen sie dann einen gemeinsamen Schlüssel berechnen können. Du fragst nun: Was, wenn jemand mitliest? Die einfache Antwort: der hat Pech gehabt. Wenn jemand *ausschließlich* mitliest, hat er keine Möglichkeit, herauszufinden, welchen Schlüssel sich beide ausgetauscht haben, das ist eben gerade der Witz an Diffie-Hellman. Wenn Dich die zugehörige Mathematik näher interessiert: Im verlinkten Wikipedia-Eintrag wird's erklärt.

                    Gut, Lauschen alleine ist bei DH schonmal aus Prinzip ausgeschlossen, dann bleibt die Frage, wozu dann die ganzen Zertifikate noch gut sein sollen?

                    Der Witz ist jetzt nun, dass jemand sich ja in die Kommunikation zwischen beiden Partnern einklinken könnte und nicht nur lauschen, sondern auch die Kommunikation verändert könnte. Was könnte so ein Angreifer bei DH machen? Ganz einfach: er könnte selbst mit beiden Partnern jeweils DH durchführen; d.h. (Alice und Bob wollen kommunizieren, Eve will das abfangen) Alice denkt, sie würde mit Bob einen Schlüssel austauschen, da die Kommunikation abgefangen wird, tauscht sie jedoch einen Schlüssel mit Eve aus. Genauso denkt Bob, er würde einen Schlüssel mit Alice austauschen, tauscht aber selbst wiederum einen mit Eve aus. D.h Eve hat dann zwei Schlüssel, einen für die Kommunikation mit Alice, einen für die Kommunikation mit Bob. Nun kann sie die Daten zwischen beiden Verbindungen nur noch hin- und herkopieren und kann dabei alles mitlauschen - sie kann sogar soweit gehen, dass sie die Daten sogar verändern kann. Bildlich gesprochen:

                    Normalfall:

                    +-------+ (1) DH: Austausch von Schlüssel K                  +-----+
                    | Alice |<-------------------------------------------------->| Bob |
                    |       | (2) Kommunikation abgesichert durch Schlüssel K    |     |
                    |       |<-------------------------------------------------->|     |
                    +-------+                                                    +-----+

                    Man-in-the-Middle:

                    +-------+ (1) DH: Austausch von Schlüssel K1                 +-----+
                    | Alice |<-------------------------------------------------->| Eve |
                    |       | (3) Kommunikation "abgesichert" durch Schlüssel K1 |     |
                    |       |<-------------------------------------------------->|     |
                    +-------+                                                    +-----+
                                                                                  ^   ^
                                                                                  |   |
                    +-------+ (2) DH: Austausch von Schlüssel K2                  /   |
                    | Bob   |<----------------------------------------------------    |
                    |       | (4) Kommunikation "abgesichert durch Schlüssel K2       /
                    |       |<--------------------------------------------------------
                    +-------+

                    Wie können nun Zertifikate helfen, Man-in-the-Middel zu vermeiden? Ganz einfach: Es werden nicht nur die DH-Informationen übertragen, die DH-Informationen werden zusätzlich noch mit dem eigenen privaten Schlüssel signiert. Wenn der Client nun eine Nachricht vom Server erhält, die zum einen die notwendigen DH-Informationen des Servers, zum anderen jedoch auch eine digitale Signatur mit dem privaten Schlüssel des Servers, kann sie mit Hilfe des öffentlichen Schlüssels des Servers überprüfen, ob die digitale Signatur wirklich authentisch ist, d.h. wirklich vom Sever kommt. D.h. der Server würde dem Client zwei Häppchen übermitteln: 1) Sein Zertifikat, damit der Client das überprüfen kann, 2) Seine DH-Parameter, die er mit seinem privaten Schlüssel signiert hat. Was könnte ein Angreifer tun? Er könnte zum einen ein anderes Zertifikat schicken, das zu *seinem* privaten Schlüssel passt und dann mit seinem privaten Schlüssel die DH-Parameter signieren. Woran scheitert dies? Eine Zertifizierungsstelle sollte im Idealfall einem Angreifer natürlich kein Zertifikat ausstellen, auch wenn das in der Vergangenheit leider bereits vorgekommen ist. Damit kann sich der Angreifer höchstens selbst ein Zertifikat ausstellen, aber der Zertifizierungsstelle "Angreifer" traut der Client selbstverständlich nicht, damit kann der Angriff bemerkt werden. Eine zweite Möglichkeit wäre das von Dir angesprochene: Er könnte das Zertifikat vom Server durchreichen. Problem ist hierbei nur, dass der Angreifer dann dem Client ja seine eigenen DH-Parameter zukommen lassen müsste, um sich einklinken zu können. Nur kann der Angreifer die natürlich nicht mit dem privaten Schlüssel des Servers signieren, weil er diesen nicht besitzt. Damit kann der Server keine Nachricht erzeugen, die DH-Parameter enthalten würde, die der Client akzeptieren würde. Damit scheitert auch diese Art von Angriff.

                    TLS funktioniert übrigens nicht nur mit Diffie-Hellman, es gibt auch die Möglichkeit, RSA zu verwenden. Das Verfahren ist nur etwas aufwändiger zu erklären, da ich dann tiefer in Details von TLS einsteigen müsste, die ich beim vergleichsweise einfachen Konzept "signierte DH-Parameter" einfach weglassen kann. TLS versucht nämlich eine ganze Menge teilweise richtig raffinierter Attacken auf das Handshake-Verfahren vorzubeugen und geichzeitig flexibel genug zu sein, dass man TLS später durch weitere (bessere) Verfahren erweitern kann.

                    Viele Grüße,
                    Christian

                    [1] Natürlich gibt's nie absolute Sicherheit, aber bei hinreichend großen Schlüssellängen gibt es aktuell keine bekannte Möglichkeit, gute digitale Unterschriftsverfahren auszuhebeln.

                    --
                    "I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." - Bjarne Stroustrup

                    1. Hallo,

                      ich glaube, so langsam vestehe ich das Prinzip zumindest ansatzweise, auch wenn mir einiges noch wie schwarze Magie vorkommt. Allein aus den Daten, die beim Diffie-Hellman-Handshake ausgetauscht werden, kann man also noch nicht die nachher übertragenen Daten entschlüsseln. Das muss ich mir wohl in einer ruhigen Stunde nochmal durch den Kopf gehen lassen, denn es kommt mir intuitiv irgendwie paradox vor.

                      Der Witz ist jetzt nun, dass jemand sich ja in die Kommunikation zwischen beiden Partnern einklinken könnte und nicht nur lauschen, sondern auch die Kommunikation verändert könnte. Was könnte so ein Angreifer bei DH machen? Ganz einfach: er könnte selbst mit beiden Partnern jeweils DH durchführen; d.h. (Alice und Bob wollen kommunizieren, Eve will das abfangen) Alice denkt, sie würde mit Bob einen Schlüssel austauschen, da die Kommunikation abgefangen wird, tauscht sie jedoch einen Schlüssel mit Eve aus. Genauso denkt Bob, er würde einen Schlüssel mit Alice austauschen, tauscht aber selbst wiederum einen mit Eve aus. D.h Eve hat dann zwei Schlüssel, einen für die Kommunikation mit Alice, einen für die Kommunikation mit Bob. Nun kann sie die Daten zwischen beiden Verbindungen nur noch hin- und herkopieren und kann dabei alles mitlauschen - sie kann sogar soweit gehen, dass sie die Daten sogar verändern kann.
                      Bildlich gesprochen:
                      [...]

                      Soweit kann ich folgen. Schön gezeichnet übrigens.  ;-)

                      Wie können nun Zertifikate helfen, Man-in-the-Middel zu vermeiden? Ganz einfach: Es werden nicht nur die DH-Informationen übertragen, die DH-Informationen werden zusätzlich noch mit dem eigenen privaten Schlüssel signiert.

                      Halt: Was heißt "signiert"? Eine Verschlüsselung kann es ja in dieser Phase des Handshakes noch nicht sein. Und gebe ich damit nicht gerade wieder den privaten Schlüssel preis, der die Geschichte bis hierher "sicher" gemacht hat?

                      Wenn der Client nun eine Nachricht vom Server erhält, die zum einen die notwendigen DH-Informationen des Servers, zum anderen jedoch auch eine digitale Signatur mit dem privaten Schlüssel des Servers, kann sie mit Hilfe des öffentlichen Schlüssels des Servers überprüfen, ob die digitale Signatur wirklich authentisch ist, d.h. wirklich vom Sever kommt.

                      Na gut - aber bei unserem "Woman-in-the-middle"-Szenario würde sich Eve doch Alice gegenüber als Bob ausgeben, also auch sein Zertifikat weiterreichen, ohne sich um dessen Inhalt kümmern zu müssen.

                      Eine zweite Möglichkeit wäre das von Dir angesprochene: Er könnte das Zertifikat vom Server durchreichen. Problem ist hierbei nur, dass der Angreifer dann dem Client ja seine eigenen DH-Parameter zukommen lassen müsste, um sich einklinken zu können. Nur kann der Angreifer die natürlich nicht mit dem privaten Schlüssel des Servers signieren, weil er diesen nicht besitzt.

                      Ja, aber das ist doch wurscht - der Client kennt ja den *privaten* Schlüssel des Servers auch nicht, also kann er doch gar nicht feststellen, ob der "echt" ist.

                      *in stiller Verwunderung*
                       Martin

                      -- Es existiert kein Weg, "für" etwas zu optimieren, sondern nur gegen alles andere.
                        (Cheatah)
                      1. Hallo Martin,

                        ich glaube, so langsam vestehe ich das Prinzip zumindest ansatzweise, auch wenn mir einiges noch wie schwarze Magie vorkommt. Allein aus den Daten, die beim Diffie-Hellman-Handshake ausgetauscht werden, kann man also noch nicht die nachher übertragenen Daten entschlüsseln. Das muss ich mir wohl in einer ruhigen Stunde nochmal durch den Kopf gehen lassen, denn es kommt mir intuitiv irgendwie paradox vor.

                        Zur Veranschaulichung von DH gibt's übrigens folgendes Experiment: Alice und Bob suchen sich beide eine geheime Farbe aus, die sie niemandem weitergeben. Zum Beispiel wählt Bob blau und Alice rot. Alice sucht sich dann eine dritte Farbe aus (hier z.B. gelb) und schickt Bob die Farbe (die kann jeder sehen, die dritte Farbe ist also öffentlich). Bob mischt dann die Farbe zu seiner eigenen Farbe (blau + gelb = grün) und schickt Alice das Ergebnis. Alice mischt ihrerseits wiederum die öffentliche Farbe gelb mit ihrer Farbe rot (= orange) und gibt die Farbe dann Bob. Beide mischen dann ihre geheime Farbe zur Farbe, die sie vom Gegenüber erhalten haben. Alice mischt rot + grün = braun und Bob mischt orange + blau = braun. Beide haben dann eine gemeinsame Farbe braun, die jedoch nie zwischen beiden geschickt wurde.

                        Natürlich hat das mit den Farben einen großen Haken: Wenn man sich die Farben ansieht, kann man mit etwas Ahnung von Farbenlehre ableiten, welche Farbe die geheime Farbe gewesen sein muss; wenn die öffentliche Farbe gelb ist und Bob grün zurückschickt, dann ist es für einen Menschen nicht schwierig, daraus abzuleiten, dass Bob blau gehabt haben muss. Allerdings ist zumindest das physikalische Trennen der Farbe grün in gelb und blau bestenfalls sehr, sehr schwierig. Und genau da funktioniert die Analogie wieder: Es ist mathematisch so schwierig, aus den übermittelten Informationen das Geheimnis einer Partei zu erhalten, dass man es besser gleich bleiben lässt.

                        Bildlich gesprochen:
                        [...]

                        Soweit kann ich folgen. Schön gezeichnet übrigens.  ;-)

                        Wie können nun Zertifikate helfen, Man-in-the-Middel zu vermeiden? Ganz einfach: Es werden nicht nur die DH-Informationen übertragen, die DH-Informationen werden zusätzlich noch mit dem eigenen privaten Schlüssel signiert.

                        Halt: Was heißt "signiert"? Eine Verschlüsselung kann es ja in dieser Phase des Handshakes noch nicht sein. Und gebe ich damit nicht gerade wieder den privaten Schlüssel preis, der die Geschichte bis hierher "sicher" gemacht hat?

                        Ok, signieren kann bei bestimmten Algorithmen sehr kompliziert werden, deswegen nehme ich hier einfach mal RSA an und erkläre den mal genauer. RSA ist ein asymmetrischer Verschlüsselungsalgorithmus. Für einen symmetrischen Verschlüsselungsalgorithmus kann man sich in der Regel einen beliebigen Schlüssel heraussuchen (bzw. aus Zufallsdaten erzeugen) und den dann mit dem Verfahren nutzen, das Verfahren legt der Form des Schlüssels in den meisten Fällen keine besonderen Beschränkungen auf, als AES-Schlüssel kann man z.B. alles mögliche nehmen, was 128 bit lang ist. Bei einem asymmetrischen Verschlüsselungsalgorithmus ändern sich gleich zwei Dinge:

                        1) Die Wahl des Schlüssels ist nicht mehr so einfach möglich, d.h. man kann nicht irgend etwas beliebiges als Schlüssel nutzen. Deswegen verwenden asymmetrische Verfahren auch riesige Schlüssellängen von 1024, 2048 oder gar 4096 bit während symmetrische Verfahren bei viel geringeren Schlüseellängen (256 bit) als genauso sicher gelten. Wobei es neuerdings asymmetrische Verfahren auf anderen mathematischen Überlegungen beruhend gibt, die auch mit geringeren Schlüssellängen auskommen sollen, allerdings sind die Verfahren noch sehr neu und es wurden in meinen Augen noch nicht genügend Versuche unternommen, sie zu knacken, weswegen ich da noch etwas warten würde, das einzusetzen. Das ganze nennt sich "Elliptic Curve Cryptopgrahy (ECC)".

                        2) Wenn man sich einen Schlüssel erzeugt, erzeugt man nicht nur *einen* Schlüssel, sondern ein Schlüsselpaar. Das heißt, man besitzt dann zwei Schlüssel. Die Schlüssel haben die Eigenschaft, dass es mathematisch viel zu aufwändig ist, aus dem einen Schlüssel den anderen herzuleiten und umgekehrt [1]. Einen von beiden nimmst Du dann als öffentlichen Schlüssel, den kann ruhig jeder kennen, den anderen nimmst Du als privaten Schlüssel und den _darf_ niemand außer Dir kennen.

                        Wie funktioniert nun RSA? Ganz einfach: Wenn Du etwas mit einem Schlüssel verschlüsselst, kannst Du es nur mit dem anderen entschlüsseln. Mal aufgezeichnet:

                        +-----------+               +-----------+               +-----------+
                        | Nachricht |  Schlüssel 1  |   Mit S1  |  Schlüssel 2  | Nachricht |
                        | im Klar-  |-------------->|  verschl. |-------------->| im Klar-  |
                        |   text    |               | Nachricht |               |   text    |
                        +-----------+               +-----------+               +-----------+
                              |                           |
                              | Schlüssel 2               | Schlüssel 1
                              |                           |
                              v                           v
                        +-----------+                +----------+
                        |   Mit S2  |  Schlüssel 2   | Zeichen- |
                        |  verschl. |--------------->|  salat   |
                        | Nachricht |                |          |
                        +-----------+                +----------+
                              |
                              | Schlüssel 1
                              |
                              v
                        +-----------+
                        | Nachricht |
                        | im Klar-  |
                        |   text    |
                        +-----------+

                        Mit RSA kann man nun zwei Dinge bewerkstellign:

                         * Verschlüsselung
                         * Digitale Signaturen

                        Zum Teil mit der Verschlüsselung: Stell Dir vor, ich habe mir ein RSA-Schlüsselpaar erzeugt und habe den öffentlichen Schlüssel veröffentlicht. Du willst mir nun eine verschlüselte Botschaft schicken, die nur ich lesen kann. Was machst Du? Du verschlüsselst die Botschaft mit meinem öffentlichen Schlüssel. Danach kann nur noch jemand, der meinen privaten Schlüssel besitzt (im Idealfall nur ich) die Nachricht wieder entschlüsseln. Der öffentliche Schlüssel, den jeder Angreifer auch kennen kann, ist für die Entschlüsseung nutzlos.

                        Dann digitale Signaturen: Stell Dir vor, ich will Dir eine Nachricht schicken, die zwar durchaus unverschlüsselt über die Leitung gehen darf, von der Du aber wissen können musst, dass sie wirklich von mir ist. Was mache ich? Ich hashe die Nachricht (mit SHA1 z.B.) und verschlüssele das Ergebnis des Hashes mit meinem privaten (!) Schlüssel. Das schicke ich dann zusammen mit der Nachricht selbst an Dich. Du kannst dann meinen öffentlichen (!) Schlüssel (den Du kennst) nutzen, um den Hash wieder zu entschlüsseln; dann bildest Du selbst wieder den Hash der Nachricht, vergleichst und schon weißt Du, ob die Nachricht authentisch ist, oder nicht.

                        [Wenn Dich die Mathematik zur RSA näher interessiert: Es gibt im Internet eine ganze Menge Seiten, die sich mehr oder weniger intensiv mit dem Thema auseinandersetzen.]

                        Was hier an der ganzen Sache besonders wichtig ist, ist dass Du den korrekten öffentlichen Schlüssel von mir besitzt. Der darf zwar allen bekannt sein, muss aber korrekt (!) sein. Stell Dir vor, ein Angreifer jubelt Dir einen öffentlichen Schlüssel unter, zu dem der Angreifer den privaten Schlüssel hat und behauptet, der öffentliche Schlüssel wäre meiner, obwohl das nicht stimmt. Wenn Du dann eine Nachricht mit diesem Schlüssel verschlüsselst, braucht der Angreifer die Nachricht nur abfangen, dann kann er sie selbst entschlüsseln und - damit ich keinen Verdacht hege - sie selbst mit meinem richtigen öffentlichen Schlüssel verschlüsseln und mir weiterschicken. Genauso kann er eine unterschriebene Nachricht, die von mir kommt, abfangen, den Hash entfernen, die Nachricht modifizieren, selbst mit seinem eigenen privaten Schlüssel den neuen Hash signieren und Dir das Ergebnis dann schicken - Du würdest denken, die Nachricht wäre authentisch. Aus diesem Grund gibt es bei SSL/TLS sogenannte Certification Authorities (CAs), die sich darum kümmern, öffentliche Schlüssel zu beglaubigen. Alle Browser haben einen Satz von öffentlichen Schlüsseln einiger CAs vorinstalliert, von denen die Browserhersteller denken, dass die User ihnen vertrauen können. Mit diesen öffentlichen Schlüsseln der CAs können die Browser dann die Unterschriften unter den öffentlichen Schlüsseln der Server verifizieren und so überprüfen, ob ein Serverschlüssel authentisch ist, oder nicht.

                        Wenn der Client nun eine Nachricht vom Server erhält, die zum einen die notwendigen DH-Informationen des Servers, zum anderen jedoch auch eine digitale Signatur mit dem privaten Schlüssel des Servers, kann sie mit Hilfe des öffentlichen Schlüssels des Servers überprüfen, ob die digitale Signatur wirklich authentisch ist, d.h. wirklich vom Sever kommt.

                        Na gut - aber bei unserem "Woman-in-the-middle"-Szenario würde sich Eve doch Alice gegenüber als Bob ausgeben, also auch sein Zertifikat weiterreichen, ohne sich um dessen Inhalt kümmern zu müssen.

                        Das Zertifikat weiterzureichen ist wie gesagt kein Problem, aber Du hast ja drei Dinge die übertragen werden: Zertifikat, DH-Parameter und Signatur zu den DH-Parametern. Wenn Du das Zertifikat weiterreichst, MUSS die Signatur der DH-Parameter dann sowohl zu den DH-Parametern als auch zum Zertifikat passen, d.h. wenn Du eins austauscht (Du willst die DH-Parameter austauschen, so dass Du mit dem Client einen eigenen Key aushandeln kannst und dann mit dem Server nochmal einen Key und dann den "Mittler" in der Kommunikation spielen kannst), dann musst Du auch die Signatur anpassen - das Problem ist, dass Du keine Signatur erzeugen kannst, die zum Zertifikat passt, d.h. Dir bleibt nichts anderes übrig, als auch das Zertifikat auszutauschen, was dann aber dazu führt, dass der Client das auch merkt.

                        Eine zweite Möglichkeit wäre das von Dir angesprochene: Er könnte das Zertifikat vom Server durchreichen. Problem ist hierbei nur, dass der Angreifer dann dem Client ja seine eigenen DH-Parameter zukommen lassen müsste, um sich einklinken zu können. Nur kann der Angreifer die natürlich nicht mit dem privaten Schlüssel des Servers signieren, weil er diesen nicht besitzt.

                        Ja, aber das ist doch wurscht - der Client kennt ja den *privaten* Schlüssel des Servers auch nicht, also kann er doch gar nicht feststellen, ob der "echt" ist.

                        Doch, mit dem öffentlichen Schlüssel der Servers. Das ist ja gerade das Tolle an asymmetrischen Verfahren: mit dem öffentlichen Schlüssel kann man feststellen, ob jemand im Besitz des zugehörigen privaten Schlüssels ist, ohne überhaupt den zugehörigen privaten Schlüssel zu kennen.

                        Viele Grüße,
                        Christian

                        [1] Allerdings ist es bei RSA der Fall, dass man aus einem der beiden erzeugten Schlüssel leichter (aber immer noch sehr aufwendig) den anderen herleiten kann, als umgekehrt, deswegen nimmt man den günstigeren als öffentlichen Schlüssel, damit man es den Angreifern möglichst erschwert.

                        --
                        "I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." - Bjarne Stroustrup

          2. Tach,

            Echt?

            Ja

            Ich werden die Parameter abgetrennt?

            Natürlich nicht.

            Die müssen doch für das Ziel weitergegeben werden, oder?

            Genau.

            Also, alle Router müssen den URL lesen können. Die Parameter werden anders behandelt?

            Die Parameter sind Teil der URL, die interessiert allerdings einen Router nicht im geringsten und er kann sie nicht sehen, da sie ja SSL-verschlüsselt ist; der Router kümmert sich eher um Dinge wie IP-Adressen.

            mfg
            Woodfighter

    2. Hell-O!

      [...] POST geht nur mit <form> (oder natürlich mit JavaScript).

      Wie meinst du das?

      Siechfred

      -- Ich bin strenggenommen auch nur interessierter Laie. (molily)
      Zitat des Tages || Falle Aufteilungsbescheid || RT 221 Erfurt-Altstadt i.V.
      1. Hallo,

        [...] POST geht nur mit <form> (oder natürlich mit JavaScript).

        Wie meinst du das?

        Hm was ist daran denn unverständlich?

        Grüße
        Jeena Paradies

        -- Weihnachtsurlaub | Jlog | Gourmetica Mentiri
        1. Hell-O!

          [...] POST geht nur mit <form> (oder natürlich mit JavaScript).

          Wie meinst du das?

          Hm was ist daran denn unverständlich?

          Wie willst du das bewerkstelligen, Formulardaten via POST-Methode ohne <form> und nur mit Javascript zu versenden?

          Siechfred

          -- Ich bin strenggenommen auch nur interessierter Laie. (molily)
          Zitat des Tages || Falle Aufteilungsbescheid || RT 221 Erfurt-Altstadt i.V.
          1. Hallo,

            http_request = new XMLHttpRequest(); http_request.open('POST', 'http://www.example.org/some.file', true);

            und so weiter.

            Grüße
            Jeena Paradies

            -- Weihnachtsurlaub | Jlog | Gourmetica Mentiri
            1. Hell-O!

              http_request = new XMLHttpRequest(); http_request.open('POST', 'http://www.example.org/some.file', true);

              Ach so, jetzt klingelt's, danke. Aber da ich mit AJAX auf Kriegsfuß stehe, möge man mir die lange Leitung nachsehen :)

              Siechfred

              -- Ich bin strenggenommen auch nur interessierter Laie. (molily)
              Zitat des Tages || Falle Aufteilungsbescheid || RT 221 Erfurt-Altstadt i.V.
              1. Glück auf!

                Aber da ich mit AJAX auf Kriegsfuß stehe

                Mit welchem von beiden?
                Gruß,
                der Juve

                -- VfL Bochum - Rekordaufsteiger :)
    3. Hallo Jeena Paradies!

      Reiner hat es schon ähnlich angesprochen, wenn man sensible Daten hin und her schiebt, dann tauchen diese bei GET in den LogFiles des Servers auf. Die Verbindung an sich war dann zwar sicher und die Daten wurden sicher für Dritte unlesbar übertragen, wer aber Zugang zu den Logfiles hat, sieht alles frei lesbar. Gerade bei großen Webseiten gibt es ja oft Tools die diese Daten aufbereiten. Da muss man dann dran denken die Parameter nicht mit auswerten zu lassen.

      Schönen Gruß

      Afra

      -- Die PARTEI in RLP
  2. Hallo,

    Welche Datenübertragung ist besser?
    Get oder Post?

    Die reine Lehre nach dem HTTP Standard sagt, dass man nur POST (und das unbenutzbare PUT) für Datenübertragung nutzen soll. Dort gibt es den Gedanken von „sicheren Methoden“, d.h. HTTP Methoden, die keine verändernden Nebeneffekte auf Seiten des Servers haben sollen. Diese Methoden sind dann nur dafür da, Informationen abzuholen, nicht um Informationen abzuliefern. Der Vorteil dadurch ist dann, dass man größtenteils nur anhand der Methode bestimmen kann, ob der HTTP Request direkt bis zum Server und der Programmlogik durchgereicht werden soll, oder ob der Request schon vorher durch Proxy, Cache oder Conditional GET beantwortet werden kann. Caching ist dadurch ein HTTP eingebautes Feature.

    „Sicher“ heisst es auch, weil dadurch bei schlechten Bots und Prefetching-Massnahmen Requests dann keine störenden Nebeneffekte ausführen. Stell Dir mal eine Webseite vor, in der ein Link zum Löschen von etwas ist:

      /foo?deleteEntry=1234

    Ein schlechter Bot oder ein Prefetching-Algorithmus im Browser könnte dann versehentlich diesen Link aufrufen und die Löschung vollziehen, obwohl das gar nicht Absicht war. Der Google Web Accelerator litt meines Wissens in den Anfangstagen kurzzeitit unter so einer Kinderkrankheit.

    Aber ja, tatsächlich wird diese Unterscheidung seltens beachtet. In letzter Zeit hat sie durch den Webservices-Architekturstil REST wieder etwas Aufmerksamkeit bekommen. Und besonders dumm ist ist auch nicht, deswegen sollte man die von Jeena gegebene Faustregel vielleicht noch dadurch erweitern:

    • GET für Parameter, die sich auf die Darstellung der abzuholenden Informationen beziehen, nicht aber den Datenbestand auf Seiten des Servers verändern, erweitern oder gar löschen.

    • POST für Request, die den Datenbestand auf dem Server verändern, erweitern oder löschen.

    (Und PUT und DELETE nutzt man höchstens in REST-basierten Web-Services und mit Javascript, da die Formulare in HTML unter der dämlichen Einschränkung leiden.)

    Tim

    1. Hallo,

      „Sicher“ heisst es auch, weil dadurch bei schlechten Bots und Prefetching-Massnahmen Requests dann keine störenden Nebeneffekte ausführen.

      Außer diesem hypothetischen »es könnte ja völlig kaputte und hirnrissige Clients geben« spricht m.E. praktisch nichts gegen GET. Nur bei dynamischen, oft personalisierten, jedenfalls geschlossenen Webanwendungen gibt es überhaupt die »Nebeneffekte« auf dem Server. Wenn man auf solche Webanwendungen Robots loslässt, muss notwendigerweise etwas schiefgehen. Daher gibt es Authentifizierung, Identifizierung usw. und nicht jeder Robot bekommt URLs zu Gesicht, deren GET-Aufruf irgendwelche serverseitigen »Nebeneffekte« hat (wie z.B. das Löschen von Daten).

      Mathias

      1. Hallo Mathias,

        (Sorry, ist mir in den letzten Tagen etwas entflutscht, zu antworten)

        Außer diesem hypothetischen »es könnte ja völlig kaputte und hirnrissige Clients geben« spricht m.E. praktisch nichts gegen GET.

        Nun ja, es gibt ja Clients, die sich teilweise so verhalten, weswegen ich explizit nicht nur Bots, sondern Prefetch-Anwendungen erwähne, die schon Probleme gemacht haben.

        Nur bei dynamischen, oft personalisierten, jedenfalls geschlossenen Webanwendungen gibt es überhaupt die »Nebeneffekte« auf dem Server. Wenn man auf solche Webanwendungen Robots loslässt, muss notwendigerweise etwas schiefgehen. Daher gibt es Authentifizierung, Identifizierung usw. und nicht jeder Robot bekommt URLs zu Gesicht, deren GET-Aufruf irgendwelche serverseitigen »Nebeneffekte« hat (wie z.B. das Löschen von Daten).

        Und gerade Prefetch-Erweiterungen sind nunmal (durch den Nutzer) authentifiziert, weil diese für diesen selbst agieren. Firefox' eingebauter Algorithmus erwartet zwar ein explizites Auszeichnen des zu prefetchenden Links durch den Webmaster, andere Prefetching-Erweiterungen sind da nicht so brav sondern fetchen alles, was nicht bei drei auf den Bäumen ist. Hier ärgert sich der Anbieter populärer Web-Anwendungen sehr über den GWA, weil sein Web-Framework stark auf GET-Aktionen ausgerichtet ist.

        Zugegeben, die Anbieter von alles ladenden Prefetch-Erweiterungen machen teilweise Annahmen, was sie besser nicht laden sollten:

        • Der Google Web Accelerator lädt keine Verweise mit Parametern.
        • Fasterfox lädt nur „statische Seiten“, konkret orientiert es sich an der Dateiendung (*.html, *.jpg, *.etc)

        Und auch wenn das relativ intelligente Annahmen im derzeitigen Web sind, kann man als Seitenanbieter dagegen verstoßen. RoR (in früheren Versionen und im Default) nutzt z.B. Parameter wie delete nicht im Parameter-Anteil der URI sondern im Pfad-Anteil. Usw. Diese Erweiterungen machen bestimmte Annahmen auf der Basis von HTTP (Beim GWA schon direkt in der Webmasters FAQ); als Anbieter von Web-Anwendungen erwidert man nun diese Annahmen entweder mit extra Code auf Serverseite, sperrt die Erweiterungen mit robots.txt oder HTTP-Header-Analyse aus oder erfüllt einfach die Annahmen von HTTP bei der Entwicklung. Letzteres erscheint mir einfach am entspanntesten, denn ansonsten ist das Aussperren von Prefetching ein Rennen, immer wenn ein neues solches Tool erscheint oder ein bestehendes seine Regeln ändert.

        (Und wie schon woanders geschrieben: GET-Aktionen sind eine Basis für CSRF-Sicherheitslücken, weil man damit jemanden auf der Seite Berechtigtem das unbeabsichtigte Laden von verändernden Verweisen unterjubeln kann.)

        Tim

  3. Tag,

    Bitte um Meinungen, in jede Richtung (z.B. Sicherheit, Geschwindigkeit, Übertragbarkeit usw.)

    Ergänzend zu dem bereits gesagten:
    - POSTS sind nicht deswegen sicherer, nur weil man die Parameter
      in der URL nicht sieht und sie somit "schwerer" manipulieren
      kann.

      Wird etwas per POST übertragen, muss ich das nur mit-loggen, und
      dann nach eigenem Gusto manipuliert versenden -> fertig.
      In den meisten Fällen reicht bereits ein kurzer Blick in den
      HTML-Quelltext der Seite, um zu wissen, was der Server haben will.

      Echten Sicherheitsgewinn erzielt man nur durch Verschlüsselung
      der Verbindung (z.b. HTTPS), und Validierung der
      Parameter auf der Serverseite - das gilt aber für POST - und
      GET-Requests gleichermaßen.

    • Einen entscheidenden Vorteil hat POST jedoch: Meines Wissens haben
        URI's in vielen Browsern eine maximale Zeichenbegrenzung
        (1024, wenn ich mich nicht irre) - wenn man darauf nicht achtet,
        kanns schnell ins Auge gehen, weil dann ggf. ein paar Paramneter
        abgeschnitten oder weggelassen werden.
        Mit POST ist man da auf der sicheren Seite, so lang man nicht
        soviel schickt, dass Client oder Server irgendwann vor Langeweile
        einschlafen, will sagen, in einen Timeout laufen.

    -> Fazit: Wenn möglich POST, wenn nötig und vertretbar GET.

    Danke schon mal im Vorraus

    MfG ein Unwissender