(Fortsetzung von hier.)

8. TLS

Aufgabe: Schalte den Client auf den Modus „Verschlüsselt“, und probiere die Beispiele aus.
Auf dem Verbindungsbutton steht jetzt „Verbindung herstellen! (TLS)“, das heißt, dass die Verbindung verschlüsselt wird. Auf der HTTP-Ebene bleibt alles gleich. Damit erhältst auf Port 443 Antworten von den meisten Webservern. Probiere auch andere Adressen aus, auf Port 443 und mit TLS sollten die meisten funktionieren.

Das Problem ist: TCP-Verbindungen sind nicht verschlüsselt. Alle Anfragen an den Server können mitgelesen werden. Das betrifft die die Anfragen, die auf Port 80 geschickt werden, und deren URL mit „http://“ beginnt. Auf „http://“ reagieren aber fast alle Webseiten zwar mit einer Webseite, aber in der steht nur, dass man nach „https“ umgezogen ist. Das heißt: da gibt es nicht mehr viel zu sehen. Eine Ausnahme sind unsere eigenen Web-Adressen zum Experimentieren und ein paar andere, etwa httpforever.com.

Dieses „https“ heißt eigentlich „HTTP über TLS“; die HTTP-Anfragen sind exakt die gleichen.

Wie TLS funktioniert (optional)

Aber auf der Ebene darunter geschieht etwas, einem bestimmten Protokoll folgend, das TLS (Transport Layer Security) heißt. Zuerst wird eine TCP-Verbindung erzeugt; dann lässt man sich den öffentlichen Teil des Public-Private-Schlüsselpaars des Servers schicken. In der einfachsten Fassung denkt sich der Client einen Schlüssel für eine symmetrische Verschlüsselung aus, verschlüsselt diesen mit dem öffentlichen Schlüssel des Servers, und schickt diesem das Ergebnis. Der Server ist dann ja auch der einzige, der diese Nachricht mit seinem privaten Schlüssel entschlüsseln kann, womit sowohl Client als auch Server und sonst niemand im Besitz des Schlüssels für die symmetrische Verschlüsselung sind und demnach alles weitere nach Herzenslust verschlüsseln können.

Einziger Schwachpunkt: Wenn sich der Client am Anfang den öffentlichen Schlüssel des Servers holt, verpackt in einem Zertifikat, dann muss der ich darauf verlassen, dass dieser öffentliche Schlüssel wirklich zum Server gehört. Es könnte sich ja auch ein Man-in-the-Middle dazwischengeschaltet haben und seinen eigenen Schlüssel für den des Servers ausgeben, die Nachrichten des Clients dadurch entschlüsseln, und danach neu verschlüsselt an den Server schicken. Deshalb gibt es Institutionen, die solche Zertifikate verwalten und bestätigen. Oder man klickt einfach im Browser auf „Unsigniertes Zertifikat trotzdem akzeptieren“ oder so ähnlich.

Die Zertifikate

In allen Beispielen sind die Zertifikate für Host-Namen ausgestellt, also etwa herr-rau.deund nicht für IP-Adressen. Bei dem Erstellen der Verbindung über TLS kannst du also keine IP-Adresse mehr eingeben, sondern musst den Host-Namen benutzen.

9. Content mitschicken: HTTP GET (eigene Server)

Man kann in einer HTTP-GET-Anfrage auch Parameter mitschicken. Das sieht dann etwa so aus:

GET /gedicht.php?autor=droste HTTP/1.1
Host: dailyimage.php

Dabei hängt man an die angefordertere Ressource mit einem Fragezeichen Paare von Parametern und Werten an. Das mit diesem ? sieht man so bei vielen Seiten im Browser in der Adresszeile.

Was die Ressource, hier gedicht.php, mit dem übergebenen Parameter macht, das hängt von ihr ab. Es ist sehr leicht, eine HTML- oder Text-Datei mit Code de Programmiersprache PHP anzureichern, die auf vielen Servern zur Verfügung steht. Damit kann man eine Datei erzeugen, die je nach übergebenem Wert (hier: droste) des Parameters (hier: autor) unterschiedliche Ergebnisse erzeugt, die dann zurückgeschickt werden.

Aufgabe: Schalte auf den Modus „TCP mit Parametern“ und probiere die Beispiele aus. Teste das mit „droste“, „goethe“ und „schiller“ als Autor.

10. Content mitschicken: HTTP-GET (fremde Server)

Nachdem fremde Server meist nur über TCP erreichbar sind, findest du alle Beispiele dafür im Modus „TCP GET mit Parametern“.

11. Content mitschicken: HTTP-POST (eigene Server)

Man könnte auf die Idee kommen, auf diese Art Benutzer und Passwort mitzuschicken:

GET /anmeldung1.php?user=millie&passwort=1234 HTTP/1.1

Das funktioniert auch, allerdings sind diese so angereicherten Adressen öffentlich sichtbar, etwa in der Browser-Geschichte. Wenn es geheimer bleiben soll, bietet das Hypertext Transfer Protocol eine andere Möglichkeit, Information als Inhalt mitzuschicken, nämlich POST statt GET.

(Im Beispiel geht es nur um kurze Texte, aber HTTP ermöglicht auch, ganze und größere Dateien der Server-Request beizufügen. Was der Server dann damit macht, hängt natürlich von diesem ab.)

Eine POST-Anfrage sieht so aus:

POST /anmeldung2.php HTTP/1.1
Host: dailyimage.php
Content-Type: application/x-www-form-urlencoded
Connection: disconnect
Content-Length: 25

user=millie&passwort=1234

Allerdings muss man dabei angeben, wie groß die Nachricht ist, etwa durch Content-Length, in diesem Fall: 25 Zeichen. (Es gibt noch andere Möglichkeiten, das zu tun, die besonders für sehr langen Content verwendet werden. Aber ausrechnen muss man immer etwas.)
Deshalb gibt es die Möglichkeit, die Parameter und Werte in eine Extrazeile zu schreiben, deren Inhalt dann mit „Lade HTTP-Post“ in der korrekten Form übernommen wird. Wenn du eigene Beispiele willst, musst du die Ressource von Hand nachtragen.

Der Content ist hier die letzte Zeile, also das mit den beiden Parameter/Wert-Paaren. Der Content-Type ist der gleiche wie bei dem GET-Beispiel; es gibt auch noch weitere.

Aufgabe: Schalte in den Modus „Einfach mit POST“. Probiere die POST-Anfrage im Beispiel mit verschiedenen Werten für die Parameter aus, oder lass einen oder beide Parameter weg oder füge neue hinzu.

Projektidee: Einkaufsliste

Man könnte eine Adresse anlegen, die folgende Parameter akzeptiert, hier mit Beispielwerten:

• zeige=unerledigtzeigt alle unerledigten Punkte auf der Einkaufsliste
• neu=Milch setzt Milch auf die Liste der unerledigten Punkte
• erledigt=Kaffee entfernt Kaffee von der Liste

Man müsste sich jetzt nur noch die Authentifizierung überlegen und dem Server ermöglichen, die Liste irgendwo zu speichern, entweder in einer Datei oder in einer SQL-Datenbank. Das ist dann aber eine Aufgabe, mit der der Client nichts zu tun hat.

Außerdem müsste man sich überlegen, in welchem Format die Liste heruntergeladen wird. Das kann eine Reihe von Textzeilen sein oder etwas in einem standardisierten Format wie JSON

12. Content mitschicken: HTTP-POST (fremde Server)

Dazu gibt es noch keine Beispiele.

13. DoS und DDoS

Jede Verbindung und jede Anfrage beschäftigt den Server und kostet ihn Rechenzeit. Wenn man so viele Anfragen sendet, dass der Server überlastet ist, heißt das Denial-of-Service-Angriff (DoS).
Wenn dieser Angriff nicht nur von einem Rechner ausgeht, sondern von vielen gleichzeitig, heißt der Angriff Distributed Denial of Servicer (DDoS). Diese Rechner gehören dann meist zu einem Botnet, das heißt, sie sind alle mit Schadsoftware infiziert, die es ermöglicht, sie zentral und auf einmal fernzusteuern. Das merkt man als Besitzer dieser Rechner nicht unbedingt, zumal zu solchen für Botnets anfälligen Rechnern alle möglichen Geräte im Internet of Things (IoT) gehören: Kühlschränke, Überwachungskameras, Temperatursensoren, alles, was irgendwie im Internet ist.

Viele Server werden misstrauisch, wenn fehlerhafte oder nicht standardisierte Anfragen an den Server geschickt werden. Du darfst also experimentieren, solltest dich aber zurückhalten, damit der Server nicht verdächtiges Verhalten von deiner IP-Adresse aus vermutet.

Das bewusste Suchen nach Lücken zur Vorbereitung des Ausspähens von Daten ist in Deutschland strafbar.

(Letzter Teil hier.)