HTTP/2 (RFC 7540)

Transcript

1. 1/44 HTTP/2 RFC 7540 Johannes Mittendorfer Sicherheit in Applikationsprotokollen 05.11.2015
2. 2/44 Inhalt 1 Einf¨ uhrung Geschichte Gr¨ unde f¨ ur neues Protokoll 2 Entwicklung SPDY HTTP/2 3 Protokoll Verbindungsaufbau Streams Frames Fehler 4 Sicherheit 5 Verbreitung Browser Server
3. 3/44 Inhalt 1 Einf¨ uhrung Geschichte Gr¨ unde f¨ ur neues Protokoll 2 Entwicklung SPDY HTTP/2 3 Protokoll Verbindungsaufbau Streams Frames Fehler 4 Sicherheit 5 Verbreitung Browser Server
4. 4/44 HTTP/0.9 & HTTP/1.0 • Tim Berners-Lee • CERN in Genf • Beginn des WWW • Standardisiert erstmals als HTTP/1.0 • RFC 1945 (Mai 1996) • L¨ adt Resourcen nacheinander • Jedes Mal neue Verbindung Abbildung : Erster HTTP Server
5. 5/44 HTTP/0.9 & HTTP/1.0 Server Client Zeit Abbildung : Mwhitlock/Wikimedia Commons
6. 6/44 HTTP/1.1 • RFC 2616 (1999) • Keepalive Header • M¨ oglichkeit Verbindung erneut zu nutzen • Mehrere Anfragen gleichzeitig
7. 7/44 HTTP/1.1 Server Client Zeit Abbildung : Mwhitlock/Wikimedia Commons
8. 8/44 Gr¨ unde f¨ ur ein neues Protokoll The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the way HTTP/1.1 uses the underlying transport [...] has several characteristics that have a negative overall effect on application performance today. (RFC 7540) Langsamer als System und ¨ Ubertragungsweg zulassen w¨ urden
9. 9/44 Head of line blocking • Erstes Packet blockiert die Verarbeitung der folgenden • Grund: Packete werden in HTTP/1.1 in gleicher Reihenfolge beantwortet
10. 10/44 Textuelle Befehle • Wenig effizient • Befehle meist gleich • Parsen aufw¨ andig GET /impressum HTTP/1.1 Connection: keep-alive Host: example.org\newline HTTP/1.1 200 OK Connection: close Content-Type: text/html
11. 11/44 Inhalt 1 Einf¨ uhrung Geschichte Gr¨ unde f¨ ur neues Protokoll 2 Entwicklung SPDY HTTP/2 3 Protokoll Verbindungsaufbau Streams Frames Fehler 4 Sicherheit 5 Verbreitung Browser Server
12. 12/44 Vorg¨ anger SPDY ( ” speedy“) • Internes Google Projekt • Vorgestellt im November 2009 • Ziel: Beschleunigung des Internets • Bin¨ arformat • SSL erforderlich • Header gzip komprimiert
13. 13/44 Vorg¨ anger SPDY ( ” speedy“) • HTTP/1.1 in SPDY und zur¨ uck konvertierbar • Verpackt und komprimiert Grundlage von HTTP/2
14. 14/44 HTTP/2 HTTP Working Group (Original: HTTP/2.0) 3/2012 Call for proposals 9/2012 Erster Entwurf 7/2013 Erste Implementierung des Entwurfes 4/2014 Last call 11/2014 Bei IESG als Standard vorgeschlagen
15. 15/44 Inhalt 1 Einf¨ uhrung Geschichte Gr¨ unde f¨ ur neues Protokoll 2 Entwicklung SPDY HTTP/2 3 Protokoll Verbindungsaufbau Streams Frames Fehler 4 Sicherheit 5 Verbreitung Browser Server
16. 16/44 Verbindungsaufbau (Klartext) GET / HTTP/1.1 Connection: Upgrade, HTTP2-Settings Upgrade: h2c HTTP2-Settings: <HTTP/2 SETTINGS payload> HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: h2c Abbildung : RFC 7540 • HTTP Upgrade Mechanismus • Kein Support → ignorieren • “h2c” f¨ ur HTTP/2 in cleartext • Kann ¨ ubersprungen werden, wenn Unterst¨ utzung bekannt
17. 17/44 Verbindungsaufbau (SSL) • Application-layer protocol negotiation (ALPN) → RFC 7301 • Bei TLS-Verbindungsaufbau mitgesendet • Wird auf den Wert “h2” gesetzt
18. 18/44 Preface • Als finale Best¨ atigung • Wird von Server und Client gesendet “PRI * HTTP/2.0 \r\n\r\nSM\r\n\r\n” + SETTINGS-Frame
19. 19/44 Streams Abbildung : Ilya Grigorik/Google • Mehrere unabh¨ angige Streams in einer Verbindung • Reihenfolge der Frames innerhalb eines Streams ist wichtig • Integer als Stream identifier • Anzahl kann von einem der Endpunkte begrenzt werden • Priorit¨ at optional
20. 20/44 Server push Abbildung : Ilya Grigorik/Google • Zus¨ atzliche Antwort ohne Anfrage • F¨ ur Dateien, die meist zusammen abgerufen werden • Beispiel: CSS und JavaScript zu einer HTML Datei • Client kann Annahme nach Ank¨ undigung verweigern
21. 21/44 Frames Abbildung : Grigorik et al. 9 Byte Header + n Byte Payload
22. 22/44 Frames (Beispiel) 00 00 ad 00 01 00 00 00 02 3c 68 74 6d 6c 3e 0d 0a 3c 68 65 L¨ ange: 173 • 24 bit Integer • Darf nicht gr¨ oßer als 214 sein • Ausnahme: SETTINGS MAX FRAME SIZE gr¨ oßer
23. 23/44 Frames (Beispiel) 00 00 ad 00 01 00 00 00 02 3c 68 74 6d 6c 3e 0d 0a 3c 68 65 Frame-Typ: DATA
24. 24/44 Frame-Typ • 8 bit groß • Beschreibt Inhalt des Payloads • Unbekannte Werte werden ignoriert Aktuell definiert DATA, HEADERS, PRIORITY, RST STREAM, SETTINGS, PUSH PROMISE, PING, GOAWAY, WINDOW UPDATE, CONTINUATION
25. 25/44 Frames (Beispiel) 00 00 ad 00 01 00 00 00 02 3c 68 74 6d 6c 3e 0d 0a 3c 68 65 Flags: 00000001 (Padding = false, End stream = true) • 8 bit groß • F¨ ur Frametypen spezifisch
26. 26/44 Frames (Beispiel) 00 00 ad 00 01 00 00 00 02 3c 68 74 6d 6c 3e 0d 0a 3c 68 65 Stream identifer: 2 • 31 bit groß (1. Bit ist reserviert) • Gibt Zugeh¨ origkeit zu einem Stream an • Wert 0 → betrifft ganze Verbindung
27. 27/44 Frames (Beispiel) 00 00 ad 00 01 00 00 00 02 3c 68 74 6d 6c 3e 0d 0a 3c 68 65 Payload: <html>\r\n<he...
28. 28/44 Header Frame • Enth¨ alt ¨ ahnliche Felder wie HTTP/1.1 Header • Methode (GET, POST, ...) • Pfad • User-Agent • Referrer • ... • Komprimiert ¨ ubertragen • Sehr effizient • RFC 7541 (HPACK: Header Compression for HTTP/2)
29. 29/44 HPACK Abbildung : Grigorik et al. • SPDY verwendet deflate Komprimierung → Sicherheitsl¨ ucke • Statische und dynamische Header Tabelle • Eintr¨ age im Frame verweisen auf Tabelleneintrag
30. 30/44 Fehler • Werden in RST STREAM und GOAWAY Frames verwendet • Unterscheiden sich stark von HTTP/1.1 • 32 Bit Felder
31. 31/44 Fehler 0x0 NO ERROR 0x1 PROTOCOL ERROR 0x2 INTERNAL ERROR 0x3 FLOW CONTROL ERROR 0x4 SETTINGS TIMEOUT 0x5 STREAM CLOSED 0x6 FRAME SIZE ERROR 0x7 REFUSED STREAM 0x8 CANCEL 0x9 COMPRESSION ERROR 0xa CONNECT ERROR 0xb ENHANCE YOUR CALM 0xc INADEQUATE SECURITY 0xd HTTP 1 1 REQUIRED
32. 32/44 Inhalt 1 Einf¨ uhrung Geschichte Gr¨ unde f¨ ur neues Protokoll 2 Entwicklung SPDY HTTP/2 3 Protokoll Verbindungsaufbau Streams Frames Fehler 4 Sicherheit 5 Verbreitung Browser Server
33. 33/44 Cross-Protocol Attack • Client erstellt Anfrage in einem Protokoll, die vom Server als ein anderes Protokoll verstanden wird • Erscheint m¨ olicherweise als “korrekte” Anfrage • Angriffe auf schlecht gesicherte lokale Server • Bei TLS durch ALPN identifier gesch¨ utzt • Ohne TLS nur minimal durch “h2c” Header gesch¨ utzt
34. 34/44 Intermediary Encapsulation Attack • Header encoding erlaubt ung¨ ultige* Header Felder und Werte • \n, \r, 0x0 als Angriff (C-String, etc...) • Werden als nicht wohlgeformt behandelt *Internet Message Syntax (RFC 2822)
35. 35/44 Push Frames • Ohne Anfrage von Client • Caching auf Grund von “Cache-control” Header • Mehrere Benutzer am Server (gleicher URL-Raum) • Push-Frame f¨ ur anderen Benutzer • Muss vom Server verhindert werden
36. 36/44 Denial of Service • Ziel: ¨ Uberlastung • HTTP/2 Verbindung Ressourcen-intensiv • Clients begrenzen Annahme von Push-Frames • H¨ aufiges ¨ Andern von Parameter in SETTINGS-Frame • Viele kleine oder leere Frames L¨ osung ¨ Uberwachung der Aktivit¨ at → ENHANCE YOUR CALM Fehler
37. 37/44 Header caching • Header f¨ ur Routing am Ende von Header-Frame → Frame wird gecached • Großer Header f¨ ullt Speicher • Durch SETTINGS MAX HEADER LIST SIZE begrenzt • Gr¨ oßere Frames werden verworfen
38. 38/44 Verschl¨ usselung • SSL (TLS) in SPDY erforderlich • In HTTP/2 optional • Jedoch: Unverschl¨ usselt derzeit von keinem Browser unterst¨ utzt • Kritik am Standard
39. 39/44 Inhalt 1 Einf¨ uhrung Geschichte Gr¨ unde f¨ ur neues Protokoll 2 Entwicklung SPDY HTTP/2 3 Protokoll Verbindungsaufbau Streams Frames Fehler 4 Sicherheit 5 Verbreitung Browser Server
40. 40/44 Browser • Aktuelle Version aller gr¨ oßer Browser • Chrome 41 • Opera 28 • Firefox 36 • Internet Explorer 11 (nur Windows 10)
41. 41/44 Server • Keine Unterst¨ utzung • amazon.com • SPDY draft 3.1 • twitter.com • wikipedia.org • baidu.cn • HTTP/2 draft 14 • facebook.com • HTTP/2 draft 15 • google.com • youtube.com Stand: 10. Oktober 2015
42. 42/44 Zusammenfassung • Effizient • Websites laden schneller • Komplex • Schwer zu lesen • Relaliv sicher • Zurzeit nur bei wenigen Seiten
43. 43/44 Weitere Informationen • RFC 7540 Hypertext Transfer Protocol Version 2 • Making the Web faster with HTTP 2.0 (Ilya Grigorik, erschienen in: Communications of the ACM) • Vortrag von Ilya Grigorik (http://youtu.be/SWQdSEferz8)
44. 44/44 Vielen Dank! Johannes Mittendorfer http://johannes-mittendorfer.com kontakt@johannes-mittendorfer.com