Kommunikationsnetze. 7. Das World Wide Web 7.2 Das Hypertext Transfer Protocol. Kommunikationsnetze 7. Das World Wide Web 7.3 HTTP

Transkript

1 Kommunikationsnetze 7.2 Das Hypertext Transfer Protocol

2 Gliederung 1. HTTP 1.0 vs Verbindungen 3. HTTP-Methoden 4. Header 5. Ein Beispiel 6. Performance 7. SSL Literatur: A. S. Tanenbaum, Computer Networks, 4th. Ed., Pearson Education Int., 2003 Gliederung

3 1. HTTP 1.0 vs. 1.1 Erste Version (HTTP 0.9) holte nur Raw data vom Server Zweite Version HTTP 1.0 RFC 1945 (Mai 1996) MIME-ähnliche Beschreibung der Inhalte Metadaten, Modifier Probleme mit Version 1.0 hierarchischen Proxies Caching Persistente Verbindungen Virtuelle Hosts Fehlerhafte Implementierungen von HTTP HTTP 1.0 vs. 1.1

4 Erweiterungen in HTTP 1.1 Persistenz ist Default-Wert Multi-Homed Web Server: Ältere HTTP 1.0-Implemetierungen nehmen an, es gäbe eine 1-zu-1 Zuordnung zwischen DNS-Hostname und IP-Adresse Da dies heute nicht mehr so ist, MUSS ein HTTP/1.1-Client den host-request-header mit senden, der den DNS-Namen noch einmal angibt. Unterstützung absoluter URI (für Proxies). Beispiel: GET HTTP/1.1 Request-URI (Beispiel): GET /pub/www/theproject.html HTTP/1.1 Host: 1. HTTP 1.0 vs. 1.1

5 2. Verbindungen HTTP 1.0 Für jede GET-Anfrage wurde eine TCP-Verbindung aufgebaut, und nach Erhalt der Datei wieder abgebaut (auch für eingefügte Bilder!) Kosten: 2,5 RTT (5 Nachrichten), ggf. noch Wartezeit für Timeout, Netwerküberlastung, und CPU-Zeit bei Client, Server und Proxies Implementierung persistenter Verbindungen mit dem Keep-Alive-Headerfeld waren fehlerhaft HTTP 1.1: Persistente Verbindungen Spart o.g. Kosten Pipelining von HTTP-Requests wird möglich Versteht ein Server ein neues Feature nicht, so kann er eine Fehlermeldung zurück senden (anstatt die TCP-Verbindung zu beenden) 2. Verbindungen

6 HTTP 1.1: Persistente Verbindungen Sind jetzt Default-Wert! Abbau einer TCP-Verbindung muss mit dem connection-headerfeld signalisiert werden: connection: close Pipelining: Requests werden nicht nummeriert Server muss Antworten in der Reihefolge zurücksenden, in der die Requests eingegangen sind 2. Verbindungen

7 3. HTTP-Methoden Methoden wurden mit Hinblick auf spätere objektorientierte Erweiterbarkeit spezifiziert ( SAP: Simple bject Access Protokoll wurde so möglich) Sichere Methoden GET, HEAD sind sicher, da sie nur Daten abrufen (Buffer verflow-angriffe ausgenommen) PST, PUT, DELETE sind unsicher Idempotente Methoden Auch mehrmaliger Aufruf dieser Methoden mit der gleichen URI bewirkt das Gleiche wie einmaliger Aufruf mit dieser URI 3. HTTP-Methoden

8 GET filename HTTP/1.1 Veranlasst den Server, das spezifizierte File an den Client zu senden. Bei einer Request-URI MUSS noch der host-header mit angegeben sein, um die Angabe eindeuitig zu machen. HEAD filename HTTP/1.1 Nur der Header für das genannte File wird angefordert, ohne die Datei selbst. Mit diesem Befehl kann man z.b. feststellen, wann die Datei zuletzt verändert wurde. PTINS hne URI: Abfrage der Fähigkeiten des Servers Mit URI: Abfrage der Eigenschaften der Datei TRACE Debugging Anfrage wird im Body der Antwort zurückgesendet CNNECT (reserviert für zukünftige Nutzung mit einem Proxy.) 3. HTTP-Methoden

9 PST Request-URI HTTP/1.1 Server soll den Body des PUT-Requests an die in Request-URI genannte Ressource anfügen Beispiele für anfügen sind: Annotation von existierenden Ressourcen Senden einer Nachricht an ein bulletin board, eine newsgroup, eine Mailingliste, oder Ähnliches Übergabe eines Datenblocks, z.b. einer Eingabe aus einem Formular, an einen datenverarbeitenden Prozess Erweiterung einer Datenbank durch eine Anfüge-peration Die genaue Bedeutung von anfügen wird vom Server meist anhand der Request- URI ermittelt. PUT Request-URI HTTP/1.1 Gegenteil von GET Angefügte Datei wird unter der genannten URI gespeichert, alte Version überschrieben. 3. HTTP-Methoden

10 DELETE Request-URI HTTP/1.1 Daten unter der genannten URI sollen gelöscht werden. PUT, PST und DELETE verlangen ggf. nach einer Autorisierung des Clients Basic Authentication RFC 2617 Digest Authentication RFC HTTP-Methoden

11 Basic Authentication RFC 2617 Einfaches Username/Passwort-Verfahren Pop-Up-Fenster im Browser erscheint Passwort ist NICHT verschlüsselt, sondern nur BASE64-codiert GET /root/secret.html HTTP/1.0 HST: HTTP/ Authorization Required WWW-Authenticate: Basic realm="name" GET /root/secret.html HTTP/1.0 HST: Authorization: Basic QWRtaW46Zm9vYmFy HTTP/ K secret.html 3. HTTP-Methoden

12 Digest Authentication RFC 2617 Challenge( opaque )-and-response( response )-Verfahren nonce gegen Denial-of-Service-Angriffe GET /root/secret.html HTTP/1.0 HST: HTTP/ Unauthorized WWW-Authenticate: Digest realm= nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Authorization: Digest username= Hans.Mueller", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri= /root/secret.html", response="e966c932a e42c8ee200cec7f6", opaque="5ccc069c403ebaf9f0171e9517f40e41" HTTP/ K secret.html 3. HTTP-Methoden

13 Status-Codes in der Server-Antwort Code 1xx 2xx 3xx 4xx 5xx Bedeutung Informationen; kann Header-Zeilen enthalten, aber keinen Body Erfolg; Anfrage wurde empfangen, verstanden und akzeptiert Umleitung; Anfrage kann nur erfüllt werden, wenn der Client weitere Aktionen tätigt (der Nutzer muss darüber aber nicht informiert werden) Client-Fehler; der Server liefert eine mögliche Erklärung des Fehlers Server-Fehler Beispiel 100 Continue (Server ist bereit, die Anfrage zu bearbeiten) 200 K (Folgezeilen sind abhängig von der Methode; bei GET wird z.b. das gewünschte File im Body gesendet.) 303 See ther (gesuchter Content kann unter einer anderen URI mit GET abgefragt werden) 400 Bad Request; 401 Unauthorized; 403 Forbidden; 404 Not Found; 405 Method Not Allowed; Internal Server Error; 501 Not Implemented; HTTP-Methoden

14 4. Header HTTP-Methoden sind bewusst einfach gehalten Zusatzinformationen werden in ergänzenden Message-Headern übermittelt Client Server: Request-Header Server Client : Response-Header Komplexe Syntax. Beispiel: Präferenz 1.0 für text/html und text/x-c, Präferenz 0.8 für text/x-dvi, und Präferenz 0.5 für text/plain (1 beste, 0 schlechteste Präferenz) Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c 4. Header

15 Header Richtung R/ Inhalt Accept Request Angabe über bevorzugte Datenformate Accept: image/jpeg Accept-Charset Request Zeichensätze, die der Browser versteht Accept-Encoding Request Unterstützte Codierungsverfahren (gzip, compress, deflate, identity) Accept-Language Request Präferierte Sprachen Accept-Language: da, en-gb;q=0.8, en;q=0.7 Authorization Request /R Wird normalerweise nach einer 401-Antwort gesendet (dann R); siehe Beispiele zu Basic und Digest- Authentication. From Request RFC Adresse Host Request R Angabe des DNS-Hostnamens für multihomed Hosts User-Agent Request Infos zum Browser und seinem S Cookie Request Sendet ein ggf. vorhandenes Cookie zurück zum Server 4. Header

16 Header Richtung R/ Inhalt If-Modified-Since Request Datei nur senden, wenn sie seit dem angegebenen Zeitpunkt modifiziert wurde Cache-Control beide Verschiedene Direktiven zur Kontrolle des Caching; wird unter Performance besprochen. Connection beide Aushandlung von Parametern für eine bestimmte Verbindung; spezielle Verwendung: Connection: close Date beide R/ Datum und Uhrzeit im RFC 1123-Format Keep-Alive beide Wenn Connect: Keep-Alive gesendet wurde, kann dieser Header mit hinzugefügt werden. Er ist allerdings nur in RFC 2068 etwas beschrieben. Upgrade beide Möglichkeit, eine neuere Protokollversion auszuhandeln 4. Header

17 Header Richtung R/ Inhalt Accept-Ranges Response Der Param. bytes sagt, dass Bytes angef. Werden dürf. Content-Encoding Response Verwendetes Codierungsverfahren (gzip, compress, deflate, identity) Content-Language Response Die Sprache, in der die Webseite abgefasst ist Content-Length Response Die Länge der Datei in Bytes Content-Type Response Der MIME-ähnliche Typ der Datei Content-Location Response Redirection (Umleitung) auf eine andere URI, von der der Content geladen werden kann. ETag Response Entity Tag Last-Modified Response Angabe, wann das Dokument zum letzten Mal verändert wurde; wichtig für das Caching Location Response Redirection Server Response Informationen zum WWW-Server und seinem S Set-Cookie Response Setzen eines Cookies im Browser 4. Header

18 5. Ein Beispiel GET / HTTP/1.0 If-Modified-Since: Tue, 18 Mar :37:03 GMT; length=2322 Connection: Keep-Alive User-Agent: Mozilla/4.77C-CCK-MCD Caldera Systems penlinux [en] (X11; U; Linux i686) Host: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso ,*,utf-8 5. Ein Beispiel

19 HTTP/ Not Modified Date: Fri, 11 Apr :32:19 GMT Server: Apache Connection: Keep-Alive Keep-Alive: timeout=15, max=100 ETag: " e773d1f" 5. Ein Beispiel

20 GET / HTTP/1.1 Connection: Keep-Alive User-Agent: Mozilla/5.0 (compatible; Konqueror/2.2.1; Linux) Accept: text/*, image/jpeg, image/png, image/*, */* Accept-Encoding: x-gzip, gzip, identity Accept-Charset: iso , utf-8, * Accept-Language: en, en_us Host: 5. Ein Beispiel

21 HTTP/ K Date: Fri, 11 Apr :33:06 GMT Server: Apache Last-Modified: Tue, 18 Mar :37:03 GMT ETag: " e773d1f" Accept-Ranges: bytes Content-Length: 2322 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html <!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html> Ein Beispiel

22 6. Performance Lösungen für das World Wide Wait : Caching Mehrfache Server Content Delivery Networks 6. Performance

23 Caching Fragen zum Caching Wer soll cachen? Wie lange soll eine Webseite gecachet werden? Hierarchisches Caching: 1. Cache im Client-Host selbst (bei Netscape: rdner cache im Filesystem) 2. Cache auf dediziertem Rechner im Client-LAN 3. Cache beim ISP Literatur: The Internet Protocol Journal, Volume 2, Number 3 (September 1999) Performance

24 Caching Lokaler Cache Cache-Proxy beim ISP Internet Internet Cache-Proxy im LAN Eigentlicher Webserver 6. Performance

25 Caching Wie lange soll eine Webseite gecachet werden? Beispiel: Webseite mit Börsenkurse: Solange mit Aktien gehandelt wird, ändern sich die Kurse jede Sekunde Wenn die Börse geschlossen hat, kann die Seite mehrere Stunden oder das ganze Wochenende gecachet werden. Beispiel: Suchanfrage bei Google nach abelschen Quasigruppen Sollte nicht gecachet werden, da eine zweite Anfrage mit dem gleichen Query- String äußerst unwahrscheinlich ist. 6. Performance

26 Methoden zur Ermittlung der Speicherzeit im Cache Last-Modified-Header (Heuristik): Wenn das Datum der letzten Modifikation lange zurück liegt, kann man davon ausgehen, dass die Seite noch lange unverändert bleiben wird. If-Modified-Since-Header: Proxy leitet die Anfrage des Client, um den genannten Header erweitert, an den Webserver weiter. Wurde die Seite nicht modifiziert, antwortet der Server mit 304 Not Modified, und der Proxy entnimmt die Seite aus seinem Cache. Wurde die Seite modifiziert, so leitet der Proxy die neue Seite des Servers weiter und speichert sie ins einem Cache. Kombination der beiden Verfahren ist möglich. 6. Performance

27 Caching Cache-Control-Mechanismen 15 Seiten zum Thema Caching im Allegemeinen in RFC 2616 Cache-Control mit 17 verschiedenen Direktiven Wichtig: no-cache-direktive für dynamisch generierte Webseiten Header Richtung R/ Inhalt Cache-Control Response Verschiedenste Direktiven, z.b. no-cache Expires Response Gibt an, wann der Inhalt spätestens stale, d.h. veraltet sein wird Proaktives Caching Zusammen mit der Webseite werden auch alle Links von dieser Webseite gecachet. Beim Anklicken eines dieser Links kann der Kunde sehr viel schneller bedient werden. 6. Performance

28 Mehrfache Server Flash Crowds war die unbedeutende Webseite des Bundesstaates Florida Im Endspurt des letzten US-Wahlkampf brach der Server zusammen Gesucht: Replizierbarkeit von WWW-Servern on Demand, möglichst an verschiedenen Standorten 6. Performance

29 Content Delivery Networks Webseiten werden gegen Bezahlung auf möglichst vielen Servern repliziert Marktführer: Akamai 1. Firma bezahlt das CDN dafür, dass ihre Webseite weltweit gut verfügbar sind. 2. CDN spricht mit ISPs, um Proxy-Server in ihren Netzwerken aufzustellen. Die Kunden der ISPs erhalten dadurch eine verbesserte Performance. 3. Anfragen an die Webseite der Firma werden durch spezielle HTTP-Techniken auf einen der Proxy-Server umgeleitet. Dazu wird die Startseite der Firma modifiziert. 6. Performance

30 Content Delivery Networks: Beispiel (aus Tanenenbaum) riginal-webseite von Furry Video <html> <head><title> Furry Video </title></head> <body> <h1> Furry Video s Product List </h1> <p> Click below for free samples </p> <a href= bears.mpg > Bears Today </a> <a href= mice.mpg > Nice Mice </a> </body> </html> 6. Performance

31 Content Delivery Networks: Beispiel (aus Tanenenbaum) Modifizierte Webseite von Furry Video <html> <head><title> Furry Video </title></head> <body> <h1> Furry Video s Product List </h1> <p> Click below for free samples </p> <a href= > Bears Today </a> <a href= > Nice Mice </a> </body> </html> 6. Performance

32 Content Delivery Networks: Grafik (aus Tanenenbaum) 6. Performance

33 Content Delivery Networks: Grafik (aus Tanenenbaum) Problem in Schritt 8: Wohin soll cdn-server.com den Request umleiten? cdn-server.com muss die IP-Adresse des Clients in einer Datenbank suchen, um zu bestimmen wo (d.h. z.b. bei welchem ISP) er sich aufhält. 6. Performance

34 7. SSL De facto Standard für Client-Server-Sicherheit IETF RFC: The TLS Protocol Version 1.0 (RFC 2246) In allen gängigen Browsern integriert Freie Programmbibliotheken, z.b. SSLRef, SSLPlus, SSLava, SSLeay, openssl 7. SSL

35 Sitzungsebene: SSL

36 Sitzungsebene: SSL

37 SSL: Integration in Browser

38 HTTP(S) Change Chipher Alert Handshake Anwendung Record Layer TCP Aufbau von SSL/TLS

39 HTTP-Daten Fragmentierung http 3.1 Länge Kompression http 3.1 Länge Verschlüsselung http 3.1 Länge MAC Padd. P. Länge SSL/TLS Record Layer

40 SSL/TLS arbeitet immer in einem aktuellen Verbindungsstatus (connection state): Ausgewählte Algorithmen Ausgewählte Schlüssel Start-Status ist NULL Das Handshake-Protokoll handelt einen pending state aus Durch [ChangeCipherSpec] wird der pending state in actual state kopiert. SSL/TLS Verbindungsstatus

41 Master secret k = Client ClientHello Certificate ClientKeyExchange CertificateVerify [ChangeCipherSpec] Finished Server ServerHello (Session_ID) Certificate CertificateRequest ServerHelloDone [ChangeCipherSpec] Master secret Finished k = SSL/TLS: Handshake

42 Client ClientHello (Session_ID) [ChangeCipherSpec] Finished Server ServerHello (Session_ID) [ChangeCipherSpec] Finished Vorteil: Einsparung der aufwendigen Public-Key-perationen beim Weitersurfen auf dem gleichen Server. SSL/TLS: Verkürzter Handshake

43 Erzeugung von Schlüsselmaterial: Prinzip P_hash(secret, seed) = HMAC_hash(secret, A(1) seed) HMAC_hash(secret, A(2) seed)... A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) PRF(secret, label, seed) = P_MD5(S1, label seed) XR P_SHA-1(S2, label seed) TLS: Generierung der Schlüssel

44 master secret key expansion Client random Server random PRF Key block 1 Key block 2 Key block 3 Key block 4 Key block 5 Key block 6 Key block 7 Key block 8 Key block 9 Key bl.10 Key bl MAC write Client MAC write Serve r ENC write Client ENC write Serve r IV write Client IV write Client TLS: Generierung der Schlüssel

45 Der Eine Million Fragen -Angriff SSL verwendet PKCS#1 zur Codierung von RSA-Kryptogrammen: PKCS#1- Klartext beginnt immer mit den Bytes 00 und 02 Angreifer wählt einen Chiffretext und sendet ihn an Server beginnt Klartext nicht mit 00 02, dann Fehler_1 beginnt Klartext mit 00 02, dann Fehler_2 Jedesmal, wenn Fehler_2 auftritt, kann der Angreifer den Schlüsselraum halbieren. SSL: Angriffe

46 Markt ist zwischen großen Anbietern aufgeteilt. Wer nicht mitspielt erhält: SSL: PKI

47 TLS: SSL: home.netscape.com/security/techbriefs/ssl.html S-HTTP: Implementierungen: Million-Fragen-Angriff: D. Bleichenbacher "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1" in Advances in Cryptology -- CRYPT'98, LNCS vol. 1462, pages: 1--12, SSL/TLS, S-HTTP: Links