Unsicherer Transport und schwaches TLS

Ein Zertifikat einzurichten kostet heute Minuten, und trotzdem geht immer noch Datenverkehr unverschlüsselt über das Netz: eine vergessene Subdomain auf Port 80, eine API, die HTTP weiterhin annimmt, ein Cookie ohne Secure-Flag. Unsicherer Transport umgeht Ihre übrigen Maßnahmen, statt sie zu durchbrechen. Im Folgenden lesen Sie, wie das geschieht.

Was ist unsicherer Transport?

Unsicherer Transport ist die Schwachstelle, bei der Daten zwischen Client und Server unverschlüsselt oder mit veralteter Verschlüsselung über das Netz gehen, sodass jeder auf dem Netzwerkpfad mitlesen und mitschreiben kann. TLS, ausgeschrieben Transport Layer Security, ist das Protokoll, das diese Verbindung schützen soll; HTTPS ist nichts anderes als gewöhnliches HTTP innerhalb einer TLS-Verbindung.

Denken Sie an die Post. Eine Anfrage über Plain HTTP ist eine Postkarte: Jeder, der sie unterwegs in die Hand bekommt, vom WLAN-Zugangspunkt im Zug bis zum Provider dazwischen, liest mit und kann mit Bleistift etwas ergänzen. HTTPS ist derselbe Text in einem verschlossenen Umschlag.

In der Praxis tritt die Schwachstelle in wenigen festen Formen auf. Plain HTTP, das neben HTTPS weiter lauscht. Ein fehlender HSTS-Header, sodass der Browser beim ersten Besuch noch unverschlüsselt anklopft. Unterstützung für TLS 1.0 und TLS 1.1, Protokolle, die mit RFC 8996 formell abgekündigt wurden. Schwache Cipher Suites mit RC4 oder 3DES, oder Suites ohne Forward Secrecy. Mixed Content: eine HTTPS-Seite, die ein Skript über HTTP nachlädt. Und Cookies ohne Secure-Flag, die der Browser bereitwillig über Plain HTTP mitschickt.

Wie funktioniert ein Angriff auf unverschlüsselten Datenverkehr?

Der Angreifer benötigt eine Position auf dem Netzwerkpfad: einen Zugangspunkt im Café, einen gekaperten Heimrouter, einen infizierten Rechner im Firmennetz. Nehmen wir eine Anwendung, die neben HTTPS auf Port 80 lauscht und ihr Sitzungscookie ohne Secure-Flag setzt.

Verwundbar:

const express = require("express");
const app = express();

app.post("/login", (req, res) => {
  const token = createSession(req.body.user);

  // Kein Secure-Flag: Der Browser sendet dieses Cookie auch über Plain HTTP
  res.cookie("session", token, { httpOnly: true });
  res.redirect("/dashboard");
});

// Lauscht zusätzlich auf Port 80, und ohne HSTS bleibt das eine offene Tür
app.listen(80);

Ihr Benutzer tippt app.example.com ohne Schema in die Adressleiste, woraufhin der Browser http:// ergänzt und die erste Anfrage unverschlüsselt ins Netz schickt. Der Angreifer fängt sie ab, spricht selbst über HTTPS mit Ihrem Server und liefert dem Benutzer eine Kopie der Seite über einfaches HTTP aus, in der jeder Verweis auf https:// umgeschrieben ist. Diese Technik heißt SSL Stripping: Alles, was der Benutzer danach eingibt, passiert den Angreifer im Klartext.

Selbst ohne diese Umleitung genügt das Cookie ohne Secure-Flag: Eine einzige Anfrage an ein Bild oder ein altes Lesezeichen über HTTP reicht, und dann geht dies lesbar über die Leitung:

GET /dashboard HTTP/1.1
Host: app.example.com
Cookie: session=eyJhbGciOiJIUzI1NiJ9.9f3c2ae1

Wer das abfängt, fügt das Cookie in seinen eigenen Browser ein und ist als Ihr Benutzer angemeldet: ohne Passwort, ohne zweiten Faktor, ohne Spur in Ihrem Protokoll.

Die Lösung verbindet drei Dinge: eine dauerhafte Weiterleitung, einen HSTS-Header und das Secure-Flag.

Sicher:

const express = require("express");
const app = express();

const CANONICAL_HOST = "app.example.com";

app.use((req, res, next) => {
  // Hinter einem Reverse Proxy zeigt dieser Header, was der Client wirklich nutzte
  if (req.headers["x-forwarded-proto"] !== "https") {
    return res.redirect(308, "https://" + CANONICAL_HOST + req.originalUrl);
  }

  res.setHeader(
    "Strict-Transport-Security",
    "max-age=63072000; includeSubDomains; preload"
  );
  next();
});

app.post("/login", (req, res) => {
  const token = createSession(req.body.user);

  res.cookie("session", token, {
    httpOnly: true,
    secure: true,
    sameSite: "lax"
  });
  res.redirect("/dashboard");
});

Die Weiterleitung verwendet einen festen Hostnamen statt des Host-Headers aus der Anfrage, damit ein manipulierter Header Besucher nicht anderswohin lenkt. Der HSTS-Header sagt dem Browser zwei Jahre lang: Verwende für diesen Hostnamen und seine Subdomains ausschließlich HTTPS. Ab dem zweiten Besuch wird http:// im Browser selbst zu https://, noch bevor ein Paket abgeht; mit preload steht der Hostname zusätzlich in einer Liste, die mit dem Browser ausgeliefert wird, sodass auch der erste Besuch abgesichert ist. Die TLS-Einstellungen gehören auf die Schicht, die TLS terminiert, meist Ihr Reverse Proxy: nur TLS 1.2 und 1.3, mit Cipher Suites, die Forward Secrecy bieten.

Welche Auswirkungen hat unsicherer Transport?

Technisch ist der unmittelbare Gewinn die Übernahme von Sitzungen, dazu Zugangsdaten, API-Schlüssel und Tokens aus Authorization-Headern. Weil der Angreifer nicht nur liest, sondern auch schreibt, kann er zudem die Antwort verändern: ein Skript einschleusen, einen Download-Link austauschen. Unsicherer Transport hebelt damit Maßnahmen aus, die auf dem Papier tadellos wirken, denn Multi-Faktor-Authentifizierung nützt wenig, wenn das Sitzungscookie danach im Klartext über die Leitung geht.

Geschäftlich beginnt es bei der Pflicht, personenbezogene Daten während der Übertragung angemessen zu schützen; ein Abfluss auf diesem Weg ist meldepflichtig. Hinzu kommt, dass PCI DSS starke Kryptografie über offene Netze verlangt und Browser bei Plain HTTP eine Warnung anzeigen, die Besucher abschreckt.

Die Einstufung reicht von medium bis hoch, und dieser Unterschied ist real. Eine Informationsseite ohne Eingabefelder über HTTP schadet dem Vertrauen, richtet aber unmittelbar keinen Schaden an; ein Anmeldeformular, eine API mit Bearer-Tokens oder ein Verwaltungsbereich auf demselben Kanal sehr wohl. Gedämpft wird die Auswirkung dadurch, dass der Angreifer eine Position auf dem Netzwerkpfad braucht; verstärkt wird sie dadurch, wie oft Benutzer in fremden Netzen unterwegs sind.

Wie erkennen Sie unsicheren Transport und schwaches TLS?

Beginnen Sie bei der Bestandsaufnahme: Der Fehler sitzt selten auf der Hauptseite und fast immer im Umfeld, in Staging, alten Subdomains, Mailoberflächen, dem Backend einer mobilen App. Certificate-Transparency-Protokolle liefern eine recht vollständige Liste der Hostnamen. Rufen Sie jeden davon ausdrücklich über http:// auf und prüfen Sie, ob Sie eine dauerhafte Weiterleitung über HTTPS erhalten und nicht einfach eine funktionierende Seite.

Sehen Sie sich danach die Antwort-Header an. Fehlt Strict-Transport-Security, oder steht die max-age bei wenigen Minuten, existiert die Richtlinie formal, praktisch aber nicht. Prüfen Sie in den Entwicklerwerkzeugen die Flags Secure, HttpOnly und SameSite an jedem Cookie und achten Sie auf Konsolenmeldungen zu Mixed Content. Die TLS-Konfiguration prüfen Sie mit Standardwerkzeugen:

# Akzeptiert der Server noch TLS 1.0?
openssl s_client -connect app.example.com:443 -tls1

# Vollständige Übersicht von Protokollen, Cipher Suites und Zertifikat
nmap --script ssl-enum-ciphers -p 443 app.example.com

Scanner erkennen schwache Protokollversionen und abgelaufene Zertifikate zuverlässig. Was sie übersehen, ist die vergessene Subdomain außerhalb des Prüfumfangs, der interne Verkehr zwischen zwei Diensten ganz ohne TLS und der eine Endpunkt, der die Weiterleitung überspringt. AssistSec prüft die gesamte Transportschicht im Rahmen eines Penetrationstests, einschließlich der Hostnamen, die auf der ersten Liste fehlten.

Wie verhindern Sie unsicheren Transport?

• Erzwingen Sie HTTPS auf jedem Hostnamen. Beantworten Sie Port 80 ausschließlich mit einer dauerhaften Weiterleitung auf denselben Host über HTTPS, ohne Ausnahme für Health Checks oder alte Integrationen.
• Aktivieren Sie HSTS und wachsen Sie zu Preload. Starten Sie mit einer kurzen max-age, prüfen Sie alle Subdomains und erhöhen Sie danach auf ein Jahr oder mehr mit includeSubDomains.
• Beschränken Sie sich auf TLS 1.2 und TLS 1.3. Deaktivieren Sie SSL 3.0, TLS 1.0 und TLS 1.1 und wählen Sie Cipher Suites mit Forward Secrecy und AEAD, bevorzugt über den SSL Configuration Generator von Mozilla.
• Setzen Sie bei jedem Cookie das Secure-Flag. Kombinieren Sie es mit HttpOnly und einem passenden SameSite-Wert und nutzen Sie für Sitzungscookies nach Möglichkeit den Präfix __Host-.
• Räumen Sie Mixed Content auf. Laden Sie Skripte, Stylesheets, Bilder und Schriften nur über HTTPS; upgrade-insecure-requests ist bestenfalls ein vorübergehendes Auffangnetz.
• Verschlüsseln Sie auch den internen Verkehr. Zwischen Loadbalancer und Anwendung, zwischen den Diensten und zur Datenbank; auch dieses Netz ist keine vertrauenswürdige Zone.
• Automatisieren Sie Zertifikate und überwachen Sie das Ablaufdatum. Erneuern Sie über ACME und nehmen Sie die TLS-Konfiguration in Ihre wiederkehrenden Prüfungen auf.