NWT HTTP(S) 3CHIT HTTP und HTTPS HTTP steht für Hyper Text Transfer Protocol ist ein Protokoll welches sich im OSI/ISO-Modell auf der 7. Ebene, der Anwendungsschicht, befindet. Als Transport benutzt es TCP über Port 80 und wird zur Übertragung von Daten verwendet. Es ist ein zustandsloses Protokoll, welches für die Übertragung von HTML-Dokumenten von Tim-Berners Lee entwickelt wurde. Ab HTTP/3 (Version 3) wird TCP durch das Netzwerkprotokolle namens QUIC ersetzt und kann eine deutlich höhere Geschwindigkeit erzielt werden. URI URI steht für Uniform Ressource Identifier und besteht aus dem Protokoll, Domain, Port und Pfad. Die Syntax einer URI sieht folgendermaßen aus: schema „:“ hier-part [„?“ query][„#“ fragment] Diese kompliziert aussehende Syntax kommt jeden Tag uns unterbewusst unter die Augen. Ein paar Beispiele für eine URI (URL): • • https://www.google.com/search?q=YouTube https://datatracker.ietf.org/doc/html/rfc2616#page-36 HTTP-Request Eine HTTP-Request (Anfrage) wird vom Client, der meist ein Webbrowser ist, an den Webserver versendet. Da HTTP ein staatenloses und verbindungsloses Protokoll ist muss für jede Anfrage (einer Ressource) eine neue Verbindung aufgebaut werden. HTTP/2 (Version 2) führte Multiplexing ein, welches den Browser erlaubt mehrere Anfragen pro Verbindung zu senden. Wenn ein Webbrowser eine Ressource (HTML-Datei) von Webserver abruft holt er sich zuerst das HTML-Dokument. Darin erkennt er, dass das HTML-Dokument noch weitere Dateien wie CSS, JavaScript, Bilder, etc. benötigt. Multiplexing erlaubt hier mehrere Anfragen auf derselben Verbindung wo egal ist in welcher Reihenfolge die angefragten Ressourcen wieder ankommen. Anfragemethoden Anfragemethoden teilen den Server mit, welche Aktion der Client ausführen möchte. Insgesamt gibt es aktuell 9 Anfragemethoden: • • • • • • • • • GET: Anfrage von einer Ressource HEAD: Anfrage von einer Ressource, nur ohne Body (Anfrage der Metadaten) POST: erstellt eine neue Ressource ohne Identifier (nicht idempotent) PUT: erstellt eine neue Ressource mit einen bekannten Identifier (idempotent) DELETE: Ressource am Webserver löschen CONNECT: Benutzt bei Proxyservern, damit diese die Anfrage nicht verstehen (verschlüsselt) OPTIONS: Liefert eine Liste vom Server mit seinen Unterstützen Methoden TRACE: Liefert Anfrage so zurück wie erhalten, um zu überprüfen, ob sie verändert, wurde PATCH: Änderung des Inhaltes einer Ressource S.R. und J.R. 1 NWT HTTP(S) 3CHIT Aufbau eines HTTP-Requests Eine HTTP-Request beginnt zuerst mit der Anfragemethode, der URI, der HTTP-Version und zusätzlichen Request-Headers. Der Einsatz des Bodys (Nachrichtenrumpf) ist je Anfragemethode unterschiedlich. Im nebenstehenden Beispiel wird der Body logischerweise nicht verwendet. Bei Einsatz der Methode „POST“, die in der Lage ist, Formulardaten in Key-Value-Pairs („key=value“) zu versenden, werden die Daten im Body angegeben. „GET“ ist ebenfalls in der Lag Formulardaten zu übertragen, indem es die Key-Value-Pairs an die URI dranhängt. Der Beginn wird durch das „?“ gekennzeichnet und jedes Key-Value-Pair wird durch ein „&“ getrennt. (https://www.google.com/search?q=YouTube) Am Server kann dann durch z.B. PHP die übertragenen Daten weiterverarbeitet werden. (Datenbank Eintrag, …). Nachteil ist dabei, dass die Eingabe in der Browser-Historie gespeichert bleibt, was bei Passwörtern nicht erwünscht ist. HTTP-Headers Die HTTP-Headers befinden sich in jeder Nachricht und übertragen zusätzliche Informationen. Ein Header beginnt mit seinen Case-Insensitiven Namen und endet mit dem Wert des Headers welcher mit einen „:“ vom Namen getrennt wird. Beispiele für Header sind: • • • Host o Ermöglicht mehrerer Webserver mit unterschiedlichen Namen auf gleicher IP Accept o Gibt an, welchen Dateityp der Client versteht (MIME-Types) Content-Length o Die Größe des Bodys HTTP-Statuscodes Statuscodes sind ein Teil der HTTP-Response, um den Client über den Stand seiner HTTP-Request zu informieren. Sie werden in 5 Hauptgruppen unterteilt (darunter 1 Beispiel davon): • • • • • 1xx: Informational ➢ Anfrage erhalten ▪ 100 Continue; Anfrage soweit korrekt und vom Server nicht abgelehnt 2xx: Success ➢ Anfrage erhalten, akzeptiert und verstanden ▪ 200 OK; Anfrage erfolgreich 3xx: Redirection ➢ Weiter Aktion nötig, um Anfrage abzuschließen ▪ 301 Moved Permanently; Die Ressource wurde auf eine neue URI verschoben welche im Header mit übertragen wird 4xx: Client Error ➢ Anfrage enthält falsche Syntax oder kann nicht verstanden werden ▪ 404 Not found; Die Ressource wurde unter der URI nicht gefunden 5xx: Server Error ➢ Der Server konnte eine gültige Anfrage nicht verarbeiten ▪ 501 Not Implemented; Der Server unterstützt die Anfragemethode nicht S.R. und J.R. 2 NWT HTTP(S) 3CHIT Aufbau einer HTTP-Response Nach Absenden einer HTTP-Request, sendet der Webserver eine HTTP-Response zurück. Diese enthält: • • • • Die angeforderte Ressource im Body (falls vorhanden) Statuscode und Statustext HTTP-Version HTTP-Headers des Servers Im Folgenden ein Beispiel für eine Response. Man sieht also den Header mit verschiedenen Informationen wie den Zeitstempel, Content-Type, den verwendeten Webserver, etc. Als Status Line wird die HTTP-Version inklusive des Status-Codes, in diesem Fall 200 OK (erfolgreiche Anfrage) gesendet. Im Body befindet sich dann die angeforderte Ressource, was in diesem Fall ein HTML-Dokument ist. HTTPS HTTPS steht für Hyper Text Transfer Protocol Secure und ist sozusagen der Bruder von HTTP. Das Protokoll funktioniert im Grunde genau exakt wie HTTP, mit dem Unterschied das hierbei die Übertragung verschlüsselt und nicht wie bei HTTP in Textform stattfindet. Somit ist HTTPS rein eine Erweiterung, um einen höheren Sicherheitsfaktor zu gewährleisten, was vor allem in der heutigen Welt bei der weiten Verwendung von Online-Banking und anderen sensiblen Datenübertragungen sehr wichtig ist. HTTPS arbeitet ebenfalls mit TCP auf Port 443. Zur Verschlüsselung wird aktuell TLS verwendet, welches der Nachfolger von SSL ist. TLS steht für Transport Layer Security, wo TLS v1.0 der verbesserten Version von SSL 3.0 entspricht. Alles unter TLS v1.3 wird als Sicherheitslücke angesehen. TLS TLS verwendet die asymmetrische Verschlüsselung, wo ein Gerät einen öffentlichen und privaten Schlüssel besitzt. Dabei kann eine Nachricht, die mit dem öffentlichen Schlüssel einer Maschine verschlüsselt wurde, nur wieder mit dem privaten Schlüssel entschlüsselt werden. TLS verschlüsselt jede gesendete Nachricht mithilfe zwei Schlüsseln, die vom Master-Secret abgeleitet werden. Das S.R. und J.R. 3 NWT HTTP(S) 3CHIT Master-Secret wird durch Zufallswerten generiert. Um das Master-Secret bzw. die benötigten Werte zur Generierung sicher zwischen beiden Geräten auszutauschen, gibt es verschiedene Verfahren wie RSA oder den Diffie-Hellman-Schlüsselaustausch. Zertifikat Ein Zertifikat ist eine Datei, welche mehrere Informationen enthalten. Darunter den Namen des Ausstellers und der Besitzer des Zertifikates, des Weiteren auch die Gültigkeitsdauer und die Fingerabdrücke für die Verschlüsselung. Zertifikate werden von Zertifizierungsstellen ausgegeben welche oft Gebühren dafür verlangen. Mit dem Zertifikat wird der Domain ein einzigartiger Public Key zugeschrieben, welcher dann vom aufrufenden Browser überprüft wird. Ein gültiges Zertifikat garantiert die Identität des Servers, und verhindert Man In The Middle – Angriffe. Das Zertifikat wird dann für die asymmetrische Verschlüsselung verwendet. Ob eine Website ein gültiges Zertifikat besitzt, kann an dem Schlüsselsymbol in der Suchleiste erkannt werden. Das Zertifikat kann mit einem Klick auf das Schloss eingesehen werden. Darin stehen alle Details über die Gültigkeit, den Austeller, den Besitzer, Fingerabrücke, etc. S.R. und J.R. 4
