Aufgabe 1 – HTTPS-Einrichtung für einen Webshop

Aufgaben – Verschlüsselung in der Praxis

Diese Aufgaben orientieren sich am Format und Anforderungsniveau der IHK-Abschlussprüfung für Fachinformatiker. Jede Aufgabe beschreibt eine realistische Arbeitssituation und enthält mehrere Teilaufgaben mit unterschiedlichen Aufgabentypen (Erklären, Auswählen, Planen, Bewerten).

Aufgabe 1 – HTTPS-Einrichtung für einen Webshop (18 Punkte)

Handlungssituation: Die Techwerk GmbH betreibt unter shop.techwerk.de einen öffentlich erreichbaren Online-Shop. Der bisherige Webserver läuft noch ohne TLS. Der Geschäftsführer hat euch als IT-Abteilung beauftragt, die HTTPS-Einrichtung zu planen und umzusetzen.

Teilaufgabe 1a (4 Punkte)

Nennt drei konkrete Risiken, die entstehen, wenn der Shop weiterhin nur über HTTP erreichbar ist. Bezieht euch dabei auf die Schutzziele der CIA-Triad.

Teilaufgabe 1b (2 Punkte)

Welcher Zertifikatstyp eignet sich für shop.techwerk.de? Begründet eure Wahl in einem Satz.

  • Self-Signed Certificate
  • DV-Zertifikat (Domain Validation)
  • OV-Zertifikat (Organization Validation)
  • EV-Zertifikat (Extended Validation)

Teilaufgabe 1c (4 Punkte)

Beschreibt in eigenen Worten die Rolle des TLS-Handshakes. Geht dabei auf folgende Punkte ein:

  1. Was wird im Handshake ausgehandelt?
  2. Warum kommen anschließend symmetrische Verfahren zum Einsatz, obwohl der Handshake asymmetrisch ist?

Teilaufgabe 1d (4 Punkte)

Die folgende Cipher Suite ist in der aktuellen Serverkonfiguration aktiv:

TLS_RSA_WITH_AES_128_CBC_SHA

a) Welches Problem hat diese Cipher Suite im Hinblick auf Perfect Forward Secrecy?

b) Welche Cipher Suite würdet ihr stattdessen empfehlen? Benennt eine konkrete Alternative und erklärt in einem Satz, warum diese besser ist.

Teilaufgabe 1e (4 Punkte)

Ein Kollege schlägt vor, den HSTS-Header erst nach einer „Testphase” zu setzen.

a) Erläutert, welchen Angriff HSTS verhindert.

b) Welches Risiko entsteht, wenn HSTS mit preload aktiviert wird und danach wieder deaktiviert werden soll?

Musterlösungen

Aufgabe 1a: Ohne HTTPS kann ein Angreifer im selben Netz (z. B. WLAN) den Datenverkehr im Klartext mitlesen (Vertraulichkeit verletzt). Bestelldaten oder Formulare könnten unbemerkt manipuliert werden (Integrität verletzt). Außerdem kann der Nutzer nicht sicher sein, ob er wirklich mit dem echten Shop kommuniziert (Authentizität – ergänzendes Schutzziel). Konkretes Beispiel: Login-Daten, Kreditkartennummern und Adressen sind für jeden im Netzwerk sichtbar.

Aufgabe 1b: OV- oder EV-Zertifikat. Ein DV-Zertifikat bestätigt nur den Domainnamen, aber nicht die Unternehmensidentität – für einen E-Commerce-Betrieb ist die Vertrauenswürdigkeit gegenüber Kunden entscheidend. (DV wäre technisch akzeptabel, aber nicht optimal.)

Aufgabe 1c: Im Handshake einigen sich Client und Server auf TLS-Version, Cipher Suite und tauschen Schlüsselmaterial aus, um einen gemeinsamen Sitzungsschlüssel zu berechnen. Asymmetrisch für den Handshake, weil kein gemeinsamer Schlüssel vorab existiert (Schlüsseltauschproblem). Für die eigentlichen Nutzdaten wird dann symmetrisch verschlüsselt (z. B. AES-256-GCM), weil symmetrische Verfahren 100–1000x schneller sind und große Datenmengen effizient verarbeiten.

Aufgabe 1d: TLS_RSA_WITH_AES_128_CBC_SHA nutzt statischen RSA-Schlüsselaustausch – kein Forward Secrecy. Wird der Private Key später kompromittiert, kann der gesamte aufgezeichnete Traffic entschlüsselt werden. Alternative: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 oder in TLS 1.3: TLS_AES_256_GCM_SHA384. ECDHE generiert ephemere Schlüssel pro Session – PFS ist gewährleistet.

Aufgabe 1e: a) HSTS verhindert SSL-Stripping-Angriffe: Ein Angreifer könnte beim ersten Seitenaufruf die HTTPS-Weiterleitung abfangen und den Client mit unverschlüsseltem HTTP kommunizieren lassen. Mit HSTS weigert sich der Browser, HTTP-Verbindungen zur Domain aufzubauen. b) Mit preload wird die Domain in eine fest im Browser eingebaute Liste aufgenommen. Selbst wenn der Server das Header entfernt, kennen Browser die Domain noch als HTTPS-only – für lange Zeit (oft Monate bis Jahre, bis Listen-Updates ausgerollt sind). Ein Rückwechsel auf HTTP ist praktisch nicht möglich.