Kommunikationsnetze 7.2 Das Hypertext Transfer Protocol
Gliederung 1. HTTP 1.0 vs. 1.1 2. 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
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 1.0 1. HTTP 1.0 vs. 1.1
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://www.w3.org/pub/www/theproject.html HTTP/1.1 Request-URI (Beispiel): GET /pub/www/theproject.html HTTP/1.1 Host: www.w3.org 1. HTTP 1.0 vs. 1.1
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
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
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
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
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
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 2617 3. HTTP-Methoden
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: www.bank.de HTTP/1.0 401 Authorization Required WWW-Authenticate: Basic realm="name" GET /root/secret.html HTTP/1.0 HST:www.bank.de Authorization: Basic QWRtaW46Zm9vYmFy HTTP/1.0 200 K secret.html 3. HTTP-Methoden
Digest Authentication RFC 2617 Challenge( opaque )-and-response( response )-Verfahren nonce gegen Denial-of-Service-Angriffe GET /root/secret.html HTTP/1.0 HST: www.bank.de HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm= mitarbeiter@bank.de", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Authorization: Digest username= Hans.Mueller", realm="mitarbeiter@bank.de", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri= /root/secret.html", response="e966c932a9242554e42c8ee200cec7f6", opaque="5ccc069c403ebaf9f0171e9517f40e41" HTTP/1.0 200 K secret.html 3. HTTP-Methoden
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;... 500 Internal Server Error; 501 Not Implemented;... 3. HTTP-Methoden
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
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 822 E-Mail-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
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
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
5. Ein Beispiel GET / HTTP/1.0 If-Modified-Since: Tue, 18 Mar 2003 15:37:03 GMT; length=2322 Connection: Keep-Alive User-Agent: Mozilla/4.77C-CCK-MCD Caldera Systems penlinux [en] (X11; U; Linux 2.4.13 i686) Host: www.daco.informatik.fh-nuernberg.de Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 5. Ein Beispiel
HTTP/1.1 304 Not Modified Date: Fri, 11 Apr 2003 07:32:19 GMT Server: Apache Connection: Keep-Alive Keep-Alive: timeout=15, max=100 ETag: "33403-912-3e773d1f" 5. Ein Beispiel
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-8859-1, utf-8, * Accept-Language: en, en_us Host: www.daco.informatik.fh-nuernberg.de 5. Ein Beispiel
HTTP/1.1 200 K Date: Fri, 11 Apr 2003 07:33:06 GMT Server: Apache Last-Modified: Tue, 18 Mar 2003 15:37:03 GMT ETag: "33403-912-3e773d1f" 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>... 5. Ein Beispiel
6. Performance Lösungen für das World Wide Wait : Caching Mehrfache Server Content Delivery Networks 6. Performance
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). www.cisco.com/ipj 6. Performance
Caching Lokaler Cache Cache-Proxy beim ISP Internet Internet Cache-Proxy im LAN Eigentlicher Webserver 6. Performance
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
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
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
Mehrfache Server Flash Crowds www.dos.state.fl.us 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
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
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
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= http://cdn-server.com/furry/bears.mpg > Bears Today </a> <a href= http://cdn-server.com/furry/mice.mpg > Nice Mice </a> </body> </html> 6. Performance
Content Delivery Networks: Grafik (aus Tanenenbaum) 6. Performance
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
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
Sitzungsebene: SSL
Sitzungsebene: SSL
SSL: Integration in Browser
HTTP(S) Change Chipher Alert Handshake Anwendung Record Layer TCP Aufbau von SSL/TLS
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
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
Master secret k = 0101... 110110 Client ClientHello Certificate ClientKeyExchange CertificateVerify [ChangeCipherSpec] Finished Server ServerHello (Session_ID) Certificate CertificateRequest ServerHelloDone [ChangeCipherSpec] Master secret Finished k = 0101... 110110 SSL/TLS: Handshake
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
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
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.11... 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
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
Markt ist zwischen großen Anbietern aufgeteilt. Wer nicht mitspielt erhält: SSL: PKI
TLS: www.ietf.org/html.charters/tls-charter.html SSL: home.netscape.com/security/techbriefs/ssl.html S-HTTP: www.ietf.org/rfc/rfc2660.txt Implementierungen: www.openssl.org, www.apache-ssl.org, www.modssl.org 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, 1998. www.belllabs.com/user/bleichen/bib.html SSL/TLS, S-HTTP: Links