Fort Lox

Firewall & Deep Packet Inspection - Superman-in-the-Middle

Zoals we weten biedt HTTPS voor surfverkeer twee belangrijke beveiligingstroeven ten opzichte van HTTP. Het communicatieprotocol zorgt enerzijds voor versleuteling, van client tot server, met TLS. Anderzijds wordt de identiteit van de webserver bevestigd, door certificaten uitgegeven door vertrouwde certificeringsinstanties. HTTPS is ondertussen al een hele tijd een basisbegrip, en meer dan 90% van het webverkeer gebeurt over HTTPS. De keerzijde is dat firewalls met next-gen-firewallingtechnieken standaard ook geen inkijk hebben in dit versleuteld verkeer, en beperkter zijn in hun beschermingsmethodieken. Gelukkig biedt Deep Packet Inspection (DPI) een oplossing.

Met behulp van Deep Packet Inspection (DPI) kan een firewall of netwerktoestel HTTPS-verkeer onderscheppen, inkijken, scannen, aanpassen,… en opnieuw doorsturen. Op die manier kan versleuteld netwerkverkeer dus even diep verwerkt worden als niet-versleuteld verkeer. Hierbij dient de firewall als een soort proxy, die zelf het verkeer ontsleutelt en opnieuw versleutelt.

Certificaten en identiteitsverificatie

In principe kan elke node waar het HTTPS-verkeer passeert, het verkeer tussen een client en een server onderscheppen, inlezen, aanpassen, en opnieuw doorsturen. Wanneer dit gebeurt voor malafide doeleinden, spreken we van een Man-in-the-middle-aanval (MitM). Dit kan ook met HTTPS, alleen ontsleutelt een onderschepper dan het verkeer, en wordt het opnieuw versleuteld door de onderschepper bij het doorsturen naar de client.

Eén van de voordelen van HTTPS, is de identiteitsverificatie aan de hand van certificaten. De private sleutel, voor het versleutelen van verkeer met het certificaat, is [SV1] [KM2] enkel gekend door de legitieme doelserver. De onderschepper kan zonder de private sleutel het verkeer dus niet correct ondertekenen met hetzelfde certificaat.

Voorbeeld:

We surfen met ons toestel naar linkedin.com, en krijgen een antwoord terug, versleuteld door de webserver van linkedin.com. Deze webserver kan bewijzen dat het de webserver is die linkedin.com mag representeren, omdat de webserver een certificaat heeft dat uitgegeven werd door een vertrouwde derde partij (Certificate Authority), en de private sleutel van dit certificaat. De webserver heeft dus al kunnen bewijzen aan de Certificate Authority (CA) dat het een server is die legitiem gebruik kan maken van het domein linkedin.com.

Bij een MitM-aanval surfen we naar linkedin.com, en antwoordt de server. Tussen deze communicatie zit er echter een onderschepper, die het verkeer tussen de partijen ontsleutelt en opnieuw versleutelt. Door het ontbreken van de private sleutel van het certificaat, kan de onderschepper het verkeer echter niet ondertekenen met hetzelfde certificaat. De onderschepper kan ook geen certificaat van een vertrouwde instantie voorleggen, omdat de onderschepper geen eigenaar/legitieme server van linkedin.com is. De software op de clientcomputer (browser, toepassing) ziet dat het certificaat niet correct is, en geeft een waarschuwing weer of blokkeert het verkeer. We kunnen dus zeggen dat een webserver met een geldig certificaat geauthenticeerd is als een webserver van de hostname/het domein in het certificaat.

De Firewall, of ‘Superman-in-the-Middle’

In het vorige onderdeel werd even toegelicht hoe HTTPS beschermt tegen MitM-aanvallen door de webserver te authenticeren. Zoals eerder aangehaald, is de DPI op een firewall echter ook een vorm van MitM. Een clienttoestel maakt geen onderscheid tussen kwaadwillige en goedwillige onderschepping van het netwerkverkeer.

Dit kan verholpen worden, door de firewall netwerktraffic opnieuw te laten versleutelen met een certificaat dat door het clienttoestel wordt vertrouwd. Dit kan dus met een ondertekeningscertificaat uitgegeven door de Certificate Authority van een domein, of door het zelfondertekend certificaat van de firewall te gaan installeren in de vertrouwde certificaatopslag van een clienttoestel. Wanneer we dit dan toepassen op het scenario in het vorig voorbeeld, zal de browser wel zien dat het certificaat waarmee de website linkedin.com ondertekend werd, niet uitgegeven werd door een vertrouwde basiscertificeringsinstantie. Het zal toch vertrouwd worden, door aanwezigheid van het certificaat of de interne instantie in de certificaatopslag.

Beveiligingsvoordelen

Door in het versleuteld verkeer te gaan kijken, kan er veel uitgebreider aan security profiling gedaan worden. Onder andere volgende zaken komen (beter) tot hun recht met DPI bij versleuteld verkeer:

  • Antivirusscanning
  • Identificatie van (cloud)applicatieverkeer
  • Afdwingen parameters in hogere lagen OSI-model (leeftijdsrestricties binnen webpagina’s, afdwingen safe search in zoekmachines,…)
  • Exploit- en intrusieverkeer

In dit artikel werd voornamelijk over HTTPS gesproken, maar Deep Packet Inspection beperkt zich niet enkel tot dat protocol. De methodiek kan gebruikt worden voor elk protocol dat gebruik maakt van TLS-versleuteld verkeer en de PKI met certificaten.

(Door Kyentl Mortier)