AlexBa16/htl-reverse-proxy-tls-lab
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Verbessere Challenge-Angaben, TLS-Fixes und Windows-Tauglichkeit

Browse Source 
Fachliche Fixes:
- Easy-RSA: explizites --subject-alt-name (SAN) ergaenzt, sonst
  scheitert curl trotz CA-Import
- HSTS: max-age auf 3600 reduziert, includeSubDomains erklaert,
  Warnung zur host-weiten Browser-Falle + Reset-Weg
- Challenge 9: Backup-/Restore-Schritte fuer nginx.conf
- Compose-Portwechsel: redeploy statt proxy-reload klargestellt
- log_format-Platzierung (http-Block) dokumentiert
- add_header-Vererbungsfalle erklaert (Ch. 4 + Abgrenzung Ch. 8)

Angabe-Struktur (alle 13 Challenges):
- Einheitliches Schema: Ausgangszustand, Schritte (Muss),
  Zielzustand/Akzeptanz, erwartete Done-Check-Ausgaben
- Arbeitsweise global geklaert (additiv, Ausnahme Ch. 9, Reset)

Robustheit/Kosmetik:
- Load-Balancing: eindeutiger INSTANCE-Marker statt fragilem grep
- Challenge-3-Titel auf "Alias-Route" korrigiert
- HTTPS_PORT in .env.example parametrisiert
- Umlaut-Konsistenz (ASCII)

Windows-Tauglichkeit:
- Klargestellt: Test-Kommandos laufen in WSL bash, nicht PowerShell
  (curl-Alias-Falle), Stack-Steuerung per Wrapper oder WSL
- Wireshark: empfohlener Capture-Weg in WSL (tshark), npcap-Hinweis
- CA-Import: Linux-Trust-Store (WSL) vs Windows-Browser (certutil)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
hkoeck
2026-05-31 22:08:41 +02:00
parent 1739810044
commit 79a13f0919
12 changed files with 294 additions and 96 deletions
Download Patch File Download Diff File Expand all files Collapse all files
challenges/README.md
+186 -61
View File
@@ -8,13 +8,29 @@ Diese Aufgaben sind bewusst auf **manuelle Proxy-Konfiguration** ausgelegt.
- Done-Check Command live ausfuehren
- 2-3 Saetze erklaeren: was geaendert, warum, welche Wirkung
## Wo laufen die Kommandos? (besonders Windows)
Die meisten Teilnehmer arbeiten unter **Windows mit Docker Desktop + WSL**. Wichtig:
- **Stack steuern** (`make ...` oder der PowerShell-Wrapper `scripts/workshop.ps1`): geht aus PowerShell **oder** aus dem WSL-Terminal.
- **Alle Challenge-Kommandos** (`curl`, `openssl`, `grep`, `wget`, `for`-Schleifen, `./scripts/compose.sh ...`): laufen im **WSL-Terminal (bash)**, nicht in PowerShell.
- **Warnung:** In PowerShell ist `curl` ein Alias fuer `Invoke-WebRequest` und versteht die hier genutzten Flags (`-I`, `-k`, `--cacert`) **nicht**. Immer im WSL-Terminal testen.
- Das Repo liegt im WSL-Dateisystem oder unter `/mnt/c/...`; arbeite am besten aus dem WSL-Terminal im Projektordner.
## Arbeitsmodus
1. Dateien anpassen (`proxy/nginx.conf`, `docker-compose.yml`).
2. Deployen mit `make redeploy` oder `make proxy-reload`.
2. Deployen: nach reinen `nginx.conf`-Aenderungen reicht `make proxy-reload`; nach Aenderungen an `docker-compose.yml` (z. B. neue Ports oder Services) immer `make redeploy`, da der Container neu erstellt werden muss.
3. Testen mit `curl` / `openssl` / Wireshark.
4. Bei Problemen: `./scripts/compose.sh logs reverse-proxy`.
## Arbeitsweise (wichtig)
- Es wird **additiv in einer einzigen `proxy/nginx.conf`** gearbeitet: jede Challenge erweitert den Stand der vorherigen. Loesungen nicht wieder loeschen - die TLS-Challenges (10-12) bauen direkt aufeinander auf.
- **Ausnahme Challenge 9** (Debugging): Diese ueberschreibt die `nginx.conf` bewusst. Vorher sichern (`cp proxy/nginx.conf proxy/nginx.conf.bak`), danach wiederherstellen.
- Jede Angabe nennt einen **Ausgangszustand** (worauf baue ich auf) und einen **Zielzustand / Akzeptanz** (woran erkenne ich "fertig"). Der Done-Check ist die pruefbare Form des Zielzustands.
- Komplett zuruecksetzen geht jederzeit mit `make reset` (Container/Volumes) bzw. `make reset-hard` (zusaetzlich lokale Datei-Aenderungen verwerfen).
---
## Easy
@@ -24,45 +40,59 @@ Diese Aufgaben sind bewusst auf **manuelle Proxy-Konfiguration** ausgelegt.
**Ziel**
- Verstehen, wie Nginx Requests per Pfad an unterschiedliche Upstreams schickt.
**Muss**
**Datei**
- `proxy/nginx.conf` (nur lesen)
**Schritte (Muss)**
- Vor dem Test in `proxy/nginx.conf` nachsehen, welche `location` auf welchen `upstream` zeigt.
- Dann erst Requests ausfuehren.
- In eigenen Worten erklaeren, warum die Antworten unterschiedlich sind.
**Warum wichtig**
- Das ist die Kernkompetenz bei Reverse Proxys: Request-Fluss lesen und korrekt begruenden.
**Zielzustand / Akzeptanz**
- Du kannst fuer `/service/a` und `/service/b` jeweils Location -> Upstream -> Backend benennen und begruenden, warum die Antworten unterschiedlich sind.
**Done-Check**
```bash
curl http://localhost:8080/service/a
curl http://localhost:8080/service/b
curl http://localhost:8080/service/a # -> "Reverse Proxy Target A"
curl http://localhost:8080/service/b # -> "Reverse Proxy Target B"
```
**Warum wichtig**
- Das ist die Kernkompetenz bei Reverse Proxys: Request-Fluss lesen und korrekt begruenden.
### 2) Drittes Backend manuell hinzufuegen
**Ziel**
- Setup sicher erweitern, ohne bestehende Routen kaputt zu machen.
**Ausgangszustand**
- Stack laeuft, `/service/a` und `/service/b` antworten.
- `backends/c/index.html` liegt bereits im Repo (Starterseite).
**Dateien**
- `docker-compose.yml`
- `proxy/nginx.conf`
- `backends/c/index.html` (vorhanden, darf angepasst werden)
**Muss**
**Schritte (Muss)**
- Service `backend-c` in Compose einbauen.
- Upstream + Route `/service/c` in Nginx anlegen.
- A/B muessen weiterhin funktionieren.
- Deployen mit `make redeploy` (Compose-Aenderung -> Container-Neustart noetig).
**Warum wichtig**
- In realen Umgebungen kommen neue Services laufend dazu. Saubere Erweiterung ohne Regression ist entscheidend.
**Zielzustand / Akzeptanz**
- `/service/c` liefert Backend C.
- `/service/a` und `/service/b` funktionieren unveraendert weiter (keine Regression).
**Done-Check**
```bash
curl http://localhost:8080/service/c
curl http://localhost:8080/service/a
curl http://localhost:8080/service/b
curl http://localhost:8080/service/c # -> enthaelt "Reverse Proxy Target C"
curl http://localhost:8080/service/a # -> weiterhin "Reverse Proxy Target A"
curl http://localhost:8080/service/b # -> weiterhin "Reverse Proxy Target B"
```
**Warum wichtig**
- In realen Umgebungen kommen neue Services laufend dazu. Saubere Erweiterung ohne Regression ist entscheidend.
### 3) Eigene Route mit Rewrite oder Alias-Route
**Ziel**
@@ -71,18 +101,22 @@ curl http://localhost:8080/service/b
**Datei**
- `proxy/nginx.conf`
**Muss**
**Schritte (Muss)**
- Route `/demo/a` anbieten, die auf Backend A fuehrt.
- Entweder per rewrite oder per eigener proxy-Route loesen.
- Deployen mit `make proxy-reload`.
**Warum wichtig**
- Der Proxy entkoppelt externe API-Pfade von internen Service-Pfaden und ermoeglicht saubere Migrationen.
**Zielzustand / Akzeptanz**
- `/demo/a` liefert dieselbe Antwort wie `/service/a` (Backend A), obwohl der externe Pfad ein anderer ist.
**Done-Check**
```bash
curl http://localhost:8080/demo/a
curl http://localhost:8080/demo/a # -> "Reverse Proxy Target A"
```
**Warum wichtig**
- Der Proxy entkoppelt externe API-Pfade von internen Service-Pfaden und ermoeglicht saubere Migrationen.
---
## Medium
@@ -95,7 +129,7 @@ curl http://localhost:8080/demo/a
**Datei**
- `proxy/nginx.conf`
**Muss**
**Schritte (Muss)**
- Mindestens setzen:
- `X-Content-Type-Options: nosniff`
- `X-Frame-Options: DENY`
@@ -104,15 +138,24 @@ curl http://localhost:8080/demo/a
- `Cross-Origin-Opener-Policy: same-origin`
- `Cross-Origin-Resource-Policy: same-origin`
- Optional (Bonus): `Content-Security-Policy` fuer statische Seiten (mit Inline-Styles bewusst beruecksichtigen)
- Deployen mit `make proxy-reload`.
**Warum wichtig**
- Diese Header reduzieren typische Browser-Angriffsvektoren und gehoeren zu Security-Baselines.
**Fallstrick (`add_header`-Vererbung)**
- Header am besten **einmal im `server {}`-Block** setzen, dann gelten sie fuer alle Locations.
- Achtung: Sobald in einem `location {}`-Block **ein** `add_header` steht, verwirft Nginx in dieser Location **alle** `add_header` aus dem `server`-Block. Dann muessen sie dort wiederholt werden. Pruefen mit `curl -I` direkt auf der jeweiligen Route.
**Zielzustand / Akzeptanz**
- `curl -I http://localhost:8080/` zeigt alle geforderten Security-Header in der Antwort.
**Done-Check**
```bash
curl -I http://localhost:8080/
# -> zeigt X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP, CORP
```
**Warum wichtig**
- Diese Header reduzieren typische Browser-Angriffsvektoren und gehoeren zu Security-Baselines.
### 5) Interne Route absichern
**Ziel**
@@ -121,25 +164,29 @@ curl -I http://localhost:8080/
**Datei**
- `proxy/nginx.conf`
**Muss**
**Schritte (Muss)**
- Route `/internal/status` bauen.
- Nur `127.0.0.1` erlauben, alle anderen verbieten.
**Warum wichtig**
- Nicht jeder Endpoint soll oeffentlich sein; Zugriffskontrolle direkt am Proxy ist oft die erste Schutzschicht.
- Deployen mit `make proxy-reload`.
**Wichtiger Hinweis**
- Host-Request ueber `localhost:8080` kommt aus Docker-Sicht oft **nicht** von `127.0.0.1`.
**Zielzustand / Akzeptanz**
- Aufruf vom Host liefert `403`; Aufruf von innerhalb des Proxy-Containers (`127.0.0.1`) liefert die Antwort.
**Done-Check**
```bash
# Erwartet typischerweise 403 vom Host (by design)
curl -i http://localhost:8080/internal/status
# -> Erwartet typischerweise 403 vom Host (by design)
# Muss innerhalb des Proxy-Containers funktionieren
./scripts/compose.sh exec -T reverse-proxy sh -lc "wget -qO- http://127.0.0.1/internal/status"
# -> "internal ok" (funktioniert nur container-intern)
```
**Warum wichtig**
- Nicht jeder Endpoint soll oeffentlich sein; Zugriffskontrolle direkt am Proxy ist oft die erste Schutzschicht.
### 6) Logging verbessern
**Ziel**
@@ -148,19 +195,27 @@ curl -i http://localhost:8080/internal/status
**Datei**
- `proxy/nginx.conf`
**Muss**
**Schritte (Muss)**
- Eigenes `log_format` mit Upstream-Infos anlegen.
- Access-Log auf das neue Format umstellen.
- Deployen mit `make proxy-reload`.
**Warum wichtig**
- Gute Logs verkuerzen Incident- und Debug-Zeit drastisch und sind zentral fuer Betrieb/Security.
**Hinweis**
- `log_format` gehoert in den `http {}`-Block (nicht in `server {}` oder `location {}`), sonst startet Nginx mit `"log_format" directive is not allowed here` nicht. `access_log` darf in `http`, `server` oder `location` stehen.
**Zielzustand / Akzeptanz**
- Nach einem Request erscheint im Log eine Zeile im neuen Format inklusive Upstream-Infos (`upstream=...`, `urt=...`).
**Done-Check**
```bash
curl http://localhost:8080/service/a
./scripts/compose.sh logs reverse-proxy
# -> neue Log-Zeile mit upstream=... und urt=...
```
**Warum wichtig**
- Gute Logs verkuerzen Incident- und Debug-Zeit drastisch und sind zentral fuer Betrieb/Security.
### 7) Load Balancing konfigurieren
**Ziel**
@@ -170,20 +225,29 @@ curl http://localhost:8080/service/a
- `docker-compose.yml`
- `proxy/nginx.conf`
**Muss**
**Ausgangszustand**
- `/service/a` zeigt aktuell nur eine Instanz (Backend A). `backends/a2/index.html` liegt bereits im Repo.
**Schritte (Muss)**
- Zweite Instanz von Backend A (`backend-a2`) anlegen.
- `upstream backend_a` auf beide Instanzen erweitern.
- Mehrfach-Requests zeigen, dass beide Instanzen antworten.
- Deployen mit `make redeploy` (Compose-Aenderung).
**Warum wichtig**
- Lastverteilung ist eine der wichtigsten Funktionen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.
**Zielzustand / Akzeptanz**
- Bei mehreren Aufrufen von `/service/a` antworten **beide** Instanzen (Round-Robin), also sowohl `Target A` als auch `Target A2`.
**Done-Check (Beispiel)**
```bash
for i in $(seq 1 8); do
curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
curl -s http://localhost:8080/service/a | grep -o "INSTANCE=[A-Za-z0-9]*"
done
# -> Mischung aus "INSTANCE=A" und "INSTANCE=A2" ueber die 8 Requests
```
- Der unsichtbare Marker `<!-- INSTANCE=A -->` bzw. `INSTANCE=A2` steckt im HTML der Backends. `[A-Za-z0-9]*` matched das ganze Token eindeutig (kein Prefix-Problem wie bei `A` vs. `A2`).
**Warum wichtig**
- Lastverteilung ist eine der wichtigsten Funktionen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.
### 8) Response Header Minimization
@@ -193,51 +257,64 @@ done
**Datei**
- `proxy/nginx.conf`
**Muss**
**Schritte (Muss)**
- Mit `proxy_hide_header` mindestens einen durchgereichten Backend-Header ausblenden
(z. B. `ETag`, `Last-Modified`).
- Kurz erklaeren, warum weniger Fingerprinting-Infos hilfreich sind.
- Deployen mit `make proxy-reload`.
**Abgrenzung zu Challenge 4**
- Challenge 4 setzt aktive Schutz-Header.
- Challenge 8 entfernt unnoetige Header aus Upstream-Responses.
**Warum wichtig**
- Weniger Response-Metadaten bedeuten weniger Angriffsoberflaeche fuer Fingerprinting und Reconnaissance.
**Zielzustand / Akzeptanz**
- Der gewaehlte Header (z. B. `ETag`) taucht in `curl -I http://localhost:8080/service/a` **nicht mehr** auf, vorher war er sichtbar.
**Done-Check**
```bash
curl -I http://localhost:8080/service/a
# -> der ausgeblendete Header (z. B. ETag) fehlt jetzt in der Antwort
```
**Warum wichtig**
- Weniger Response-Metadaten bedeuten weniger Angriffsoberflaeche fuer Fingerprinting und Reconnaissance.
### 9) Debugging Challenge (kaputte Config reparieren)
**Ziel**
- Fehlerdiagnose in Nginx ueben.
**Ausgangszustand**
- Eigene `proxy/nginx.conf` ist in Betrieb. `proxy/nginx.broken.conf` enthaelt absichtlich mehrere Fehler.
**Datei**
- `proxy/nginx.broken.conf`
**Muss**
**Schritte (Muss)**
- Zuerst die eigene `proxy/nginx.conf` sichern (z. B. `cp proxy/nginx.conf proxy/nginx.conf.bak`) - diese Challenge ueberschreibt sie.
- Defekte Config testweise als aktive Config verwenden.
- Mindestens 2-3 Fehler finden und fixen.
- Symptome und Diagnoseweg erklaeren.
- Am Ende die eigene Config wiederherstellen (`cp proxy/nginx.conf.bak proxy/nginx.conf`).
**Erwartete Fehlerarten (Beispiel aus `nginx.broken.conf`)**
- Upstream-Name passt nicht zum referenzierten Namen in `proxy_pass`.
- Falscher Upstream-Port (`8080` statt `80`).
- Fehlender Trailing Slash in `proxy_pass` bei Prefix-Location.
**Warum wichtig**
- Debugging unter Druck ist Praxisalltag; diese Aufgabe trainiert systematisches Vorgehen mit Logs und Config-Tests.
**Zielzustand / Akzeptanz**
- Nach den Fixes liefern `/service/a` und `/service/b` wieder ihre Backends; Nginx startet ohne Config-Fehler.
**Done-Check**
```bash
curl http://localhost:8080/service/a
curl http://localhost:8080/service/b
curl http://localhost:8080/service/a # -> "Reverse Proxy Target A"
curl http://localhost:8080/service/b # -> "Reverse Proxy Target B"
./scripts/compose.sh logs reverse-proxy
```
**Warum wichtig**
- Debugging unter Druck ist Praxisalltag; diese Aufgabe trainiert systematisches Vorgehen mit Logs und Config-Tests.
---
## Hard (TLS)
@@ -247,23 +324,40 @@ curl http://localhost:8080/service/b
**Ziel**
- Eigene CA + Server-Zertifikat fuer `localhost` erstellen.
**Ausgangszustand**
- Stack laeuft auf HTTP (`8080`). Noch kein TLS, kein Port `8443`.
- `easy-rsa` und `openssl` sind installiert (siehe `challenges/easyrsa-hints.md`).
**Dateien**
- `docker-compose.yml`
- `proxy/nginx.conf`
- `docker-compose.yml` (Port `8443:443` + Cert-Volume)
- `proxy/nginx.conf` (TLS-Serverblock)
- `certs/easyrsa/*` (PKI), `certs/live/*` (Runtime-Cert + Key)
**Muss**
- Zertifikat fuer `localhost` erstellen.
- Proxy auf `443` erweitern (z. B. `8443:443`).
- Root-CA importieren und ohne `-k` testen.
**Schritte (Muss)**
- CA + Server-Zertifikat fuer `localhost` mit SAN erstellen (`--subject-alt-name="DNS:localhost,IP:127.0.0.1"`).
- Nur Runtime-Cert + Key bereitstellen (nicht die ganze PKI mounten).
- Proxy auf `443` erweitern (Mapping `8443:443`) und TLS in Nginx aktivieren.
- Mit `make redeploy` deployen (Compose-Aenderung -> Container-Neustart noetig).
- Root-CA in den System-Trust-Store importieren.
**Warum wichtig**
- TLS korrekt einzurichten ist Basis fuer Vertraulichkeit, Integritaet und Vertrauensaufbau im Netzwerk.
**Zielzustand / Akzeptanz**
- `curl https://localhost:8443/service/a` liefert Backend A **ohne** `-k` (CA wird vertraut).
- Kein SAN-/Hostname-Fehler.
**Done-Check**
```bash
curl https://localhost:8443/service/a
# Erwartet: HTML von Backend A, KEIN "SSL certificate problem"
# Falls CA noch nicht global importiert:
curl --cacert certs/easyrsa/pki/ca.crt https://localhost:8443/service/a
```
**Warum wichtig**
- TLS korrekt einzurichten ist Basis fuer Vertraulichkeit, Integritaet und Vertrauensaufbau im Netzwerk.
**Haeufigster Blocker**
- Ohne SAN scheitert curl mit `no alternative certificate subject name matches target host name` -> beim Signieren `--subject-alt-name` setzen (Details in `challenges/easyrsa-hints.md`).
### 11) HTTP -> HTTPS Redirect
**Voraussetzung**
@@ -273,21 +367,29 @@ curl https://localhost:8443/service/a
**Ziel**
- HTTP sauber auf HTTPS umlenken.
**Ausgangszustand**
- Aus Challenge 10: HTTPS laeuft auf `8443`, HTTP auf `8080` liefert noch direkt Inhalte.
**Datei**
- `proxy/nginx.conf`
**Muss**
- HTTP Requests auf HTTPS redirecten.
**Schritte (Muss)**
- HTTP Requests auf HTTPS redirecten (`return 301 https://$host:8443$request_uri;`).
- `/healthz` darf optional auf HTTP bleiben.
- Deployen mit `make proxy-reload` (reine `nginx.conf`-Aenderung).
**Warum wichtig**
- Redirect erzwingt verschluesselten Zugriff und verhindert versehentliche Nutzung unsicherer HTTP-Endpunkte.
**Zielzustand / Akzeptanz**
- HTTP-Aufrufe auf `8080` antworten mit `301` und `Location: https://localhost:8443/...`.
**Done-Check**
```bash
curl -I http://localhost:8080/service/a
# Erwartet: HTTP/1.1 301 ... und Location: https://localhost:8443/service/a
```
**Warum wichtig**
- Redirect erzwingt verschluesselten Zugriff und verhindert versehentliche Nutzung unsicherer HTTP-Endpunkte.
### 12) TLS Haertung + Chain Check + HSTS
**Voraussetzung**
@@ -300,23 +402,39 @@ curl -I http://localhost:8080/service/a
**Datei**
- `proxy/nginx.conf`
**Muss**
- TLS auf 1.2/1.3 beschraenken.
**Ausgangszustand**
- Aus Challenge 10+11: HTTPS auf `8443` laeuft, HTTP wird umgeleitet. TLS ist aber noch ungehaertet (keine Protokoll-Beschraenkung, kein HSTS).
**Schritte (Muss)**
- TLS auf 1.2/1.3 beschraenken (`ssl_protocols TLSv1.2 TLSv1.3;`).
- HSTS setzen (`Strict-Transport-Security`).
- Zertifikatskette pruefen und kurz erklaeren.
**Warum wichtig**
- Reines "HTTPS an" reicht nicht: erst Haertung + HSTS reduzieren Downgrade- und Fehlkonfigurationsrisiken.
- Deployen mit `make proxy-reload`.
**Hinweis**
- Im HTTP-Basissetup ist HSTS absichtlich **noch nicht** aktiv. Das ist Teil der Aufgabe.
**Warnung (HSTS-Falle im Browser)**
- HSTS merkt sich der Browser **host-weit** (`localhost`), nicht pro Port. Nach einem Besuch von `https://localhost:8443` erzwingt der Browser `https` auch fuer `http://localhost:8080` -> das HTTP-Lab scheint dann "kaputt".
- Zum Pruefen daher `curl` nutzen (curl speichert HSTS nicht).
- Falls der Browser haengt: HSTS fuer `localhost` zuruecksetzen (Chrome: `chrome://net-internals/#hsts` -> "Delete domain security policies" -> `localhost`).
- `max-age` ist im Lab bewusst kurz (1h), damit der Effekt von selbst verfaellt.
**Zielzustand / Akzeptanz**
- `curl -I` zeigt den `Strict-Transport-Security`-Header.
- `openssl s_client` verhandelt TLSv1.2 oder TLSv1.3 und endet mit `Verify return code: 0 (ok)`.
**Done-Check**
```bash
curl -I https://localhost:8443/service/a
# -> enthaelt: Strict-Transport-Security: max-age=3600; includeSubDomains
openssl s_client -connect localhost:8443 -servername localhost
# -> Protocol: TLSv1.3 (oder 1.2), Verify return code: 0 (ok)
```
**Warum wichtig**
- Reines "HTTPS an" reicht nicht: erst Haertung + HSTS reduzieren Downgrade- und Fehlkonfigurationsrisiken.
---
## Bonus Expert
@@ -326,14 +444,18 @@ openssl s_client -connect localhost:8443 -servername localhost
**Ziel**
- Nachweisbar zeigen, was im Klartext sichtbar ist und was durch TLS geschuetzt wird.
**Muss**
**Ausgangszustand**
- HTTPS laeuft (Challenge 10), `8080` und `8443` sind erreichbar. Wireshark/tshark ist installiert (siehe `challenges/wireshark-hints.md`).
**Schritte (Muss)**
- HTTP auf `8080` mitschneiden.
- HTTPS auf `8443` mitschneiden.
- `ClientHello`, `ServerHello`, `Certificate` markieren.
- Technisch erklaeren, warum HTTP lesbar ist und HTTPS ohne Keys nicht.
**Warum wichtig**
- Wer den Unterschied auf Paketebene gesehen hat, versteht TLS nicht nur theoretisch, sondern praktisch.
**Zielzustand / Akzeptanz**
- HTTP-Mitschnitt: Pfad und Header sind im Klartext lesbar (Follow Stream).
- HTTPS-Mitschnitt: nur der TLS-Handshake ist sichtbar, die Nutzdaten sind ohne Key nicht lesbar.
**Vorgehen (empfohlen)**
1. Capture auf passendem Interface starten (lokal meist `lo`).
@@ -347,6 +469,9 @@ openssl s_client -connect localhost:8443 -servername localhost
**Done-Check**
- 3-4 Screenshots + 3-5 Bulletpoints Auswertung.
**Warum wichtig**
- Wer den Unterschied auf Paketebene gesehen hat, versteht TLS nicht nur theoretisch, sondern praktisch.
**Typische Fehler**
- falsches Interface gewaehlt
- HTTPS noch nicht korrekt aktiv