Onveilig transport en zwakke TLS

Een certificaat installeren kost tegenwoordig minuten, en toch reist er nog altijd verkeer onversleuteld over het net: een vergeten subdomein op poort 80, een API die HTTP blijft accepteren, een cookie zonder de Secure-vlag. Onveilig transport omzeilt uw overige maatregelen in plaats van ze te doorbreken. Hieronder leest u hoe dat werkt.

Wat is onveilig transport?

Onveilig transport is de kwetsbaarheid waarbij gegevens tussen client en server onversleuteld of met verouderde versleuteling over het netwerk gaan, waardoor iemand op het netwerkpad kan meelezen en meeschrijven. TLS, voluit Transport Layer Security, is het protocol dat die verbinding hoort te beschermen; HTTPS is niets anders dan gewoon HTTP binnen een TLS-verbinding.

Vergelijk het met post. Een verzoek over plain HTTP is een briefkaart: iedereen die hem onderweg in handen krijgt, van het wifi-punt in de trein tot een tussenliggende provider, leest mee en kan er met potlood iets bij schrijven. HTTPS is dezelfde tekst in een dichte envelop.

In de praktijk komt de kwetsbaarheid in een handvol vaste gedaanten voor. Plain HTTP dat naast HTTPS blijft luisteren. Een ontbrekende HSTS-header, waardoor de browser bij het eerste bezoek nog onversleuteld aanklopt. Ondersteuning voor TLS 1.0 en TLS 1.1, protocollen die met RFC 8996 formeel zijn afgeschaft. Zwakke cipher suites met RC4 of 3DES, of suites zonder forward secrecy. Mixed content: een HTTPS-pagina die een script of een afbeelding via HTTP ophaalt. En cookies zonder de Secure-vlag, die de browser bereidwillig over een onversleutelde verbinding meestuurt.

Hoe werkt een aanval op onversleuteld verkeer?

De aanvaller heeft een positie op het netwerkpad nodig: een eigen toegangspunt in een café, een gekaapte thuisrouter, een besmet werkstation in het kantoornetwerk. Neem een applicatie die naast HTTPS op poort 80 luistert en haar sessiecookie zonder Secure-vlag zet.

Kwetsbaar:

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

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

  // Geen Secure-vlag: de browser stuurt deze cookie ook over plain HTTP mee
  res.cookie("session", token, { httpOnly: true });
  res.redirect("/dashboard");
});

// Luistert ook op poort 80, en zonder HSTS blijft dat een open deur
app.listen(80);

Uw gebruiker typt app.example.com in de adresbalk, zonder schema, waarna de browser http:// invult en het eerste verzoek onversleuteld het netwerk op stuurt. De aanvaller vangt dat af, praat zelf over HTTPS met uw server en serveert de gebruiker een kopie van de site over gewoon HTTP, waarin elke link naar https:// is herschreven. Deze techniek heet SSL stripping: alles wat de gebruiker daarna intikt, passeert de aanvaller in leesbare vorm.

Zelfs zonder die volledige omleiding volstaat de cookie zonder Secure-vlag: één verzoek naar een afbeelding of een oude bookmark op HTTP is genoeg, en dit gaat leesbaar over de lijn:

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

Wie dat onderschept, plakt de sessiecookie in zijn eigen browser en is ingelogd als uw gebruiker: zonder wachtwoord, zonder tweede factor en zonder spoor in uw logboek.

De oplossing combineert drie dingen: een permanente redirect, een HSTS-header en de Secure-vlag.

Veilig:

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

const CANONICAL_HOST = "app.example.com";

app.use((req, res, next) => {
  // Achter een reverse proxy verraadt deze header wat de client echt gebruikte
  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");
});

De redirect gebruikt een vaste hostnaam en niet de Host-header uit het verzoek, zodat een gemanipuleerde header bezoekers niet elders naartoe stuurt. De HSTS-header zegt de browser twee jaar lang: gebruik voor deze hostnaam en al zijn subdomeinen uitsluitend HTTPS. Vanaf het tweede bezoek wordt http:// binnen de browser al omgezet naar https://, nog voordat er een pakket vertrekt; met preload staat de hostnaam in een lijst die met de browser meekomt, waardoor ook het allereerste bezoek beschermd is. De TLS-instellingen horen op de laag die TLS afsluit, meestal uw reverse proxy: alleen TLS 1.2 en 1.3, met cipher suites die forward secrecy bieden.

Wat is de impact van onveilig transport?

Technisch is de directe winst het overnemen van sessies, plus inloggegevens, API-sleutels en tokens uit Authorization-headers. Omdat de aanvaller niet alleen leest maar ook schrijft, kan hij ook de respons aanpassen: een script injecteren, een downloadlink vervangen, een bedrag in een formulier veranderen. Onveilig transport neutraliseert daarmee maatregelen die er prima uitzien, want multifactorauthenticatie helpt weinig als de cookie na het inloggen leesbaar over de lijn gaat.

Zakelijk begint het bij de plicht om persoonsgegevens tijdens verzending passend te beschermen; een lek langs deze weg is meldingsplichtig. Daarnaast eist PCI DSS sterke cryptografie over open netwerken en tonen browsers bij plain HTTP een waarschuwing die bezoekers afschrikt.

De classificatie loopt van medium tot hoog, en dat verschil is echt. Een brochurepagina zonder invoervelden over HTTP is slecht voor het vertrouwen maar niet direct schadelijk; een inlogformulier, een API met bearer-tokens of een beheerpaneel op hetzelfde kanaal wel. Wat de impact tempert, is dat de aanvaller een positie op het netwerkpad moet hebben; wat hem versterkt, is hoe vaak gebruikers op onbetrouwbare netwerken zitten.

Hoe spoort u onveilig transport en zwakke TLS op?

Begin bij de inventaris, want de fout zit zelden op de hoofdwebsite en bijna altijd op wat eromheen hangt: staging, oude subdomeinen, mailinterfaces, de backend van een mobiele app. Certificate Transparency-logboeken geven een complete lijst van hostnamen. Probeer per hostnaam expliciet http:// en controleer of u een permanente redirect naar dezelfde host over HTTPS krijgt, en niet gewoon een werkende pagina.

Kijk daarna naar de responsheaders. Ontbreekt Strict-Transport-Security, of staat de max-age op enkele minuten, dan bestaat het beleid formeel wel maar praktisch niet. Controleer in de ontwikkelaarstools of elke cookie de vlaggen Secure, HttpOnly en SameSite draagt en of de console mixed content meldt. De TLS-configuratie zelf toetst u met standaardgereedschap:

# Accepteert de server nog TLS 1.0?
openssl s_client -connect app.example.com:443 -tls1

# Volledig overzicht van protocollen, cipher suites en certificaat
nmap --script ssl-enum-ciphers -p 443 app.example.com

Scanners vinden zwakke protocolversies en verlopen certificaten prima. Wat zij missen, is het vergeten subdomein dat nooit in de scope stond, het interne verkeer tussen twee services zonder TLS, en de ene endpoint die de redirect overslaat. AssistSec neemt de volledige transportlaag mee in een penetratietest, inclusief de hostnamen die niet op de eerste lijst stonden.

Hoe voorkomt u onveilig transport?

• Dwing HTTPS af op elke hostnaam. Beantwoord poort 80 uitsluitend met een permanente redirect naar dezelfde host over HTTPS, zonder uitzondering voor health checks of oude integraties.
• Zet HSTS aan en groei naar preload. Begin met een korte max-age, controleer al uw subdomeinen en verhoog daarna naar minimaal een jaar met includeSubDomains.
• Beperk uzelf tot TLS 1.2 en TLS 1.3. Schakel SSL 3.0, TLS 1.0 en TLS 1.1 uit en kies cipher suites met forward secrecy en AEAD, bij voorkeur via de SSL Configuration Generator van Mozilla.
• Markeer elke cookie als Secure. Combineer dat met HttpOnly en een passende SameSite-waarde, en gebruik voor sessiecookies waar mogelijk de prefix __Host-.
• Ruim mixed content op. Laad scripts, stylesheets, afbeeldingen en fonts uitsluitend over HTTPS; upgrade-insecure-requests is hooguit een tijdelijk vangnet.
• Versleutel ook het interne verkeer. Tussen loadbalancer en applicatie, tussen services en naar de database; ook dat netwerk is geen vertrouwde zone.
• Automatiseer certificaten en bewaak de vervaldatum. Vernieuw via ACME en neem de TLS-configuratie op in uw periodieke controles.