TLS VPN versus IPsec: de vijf velden die het bekijken waard zijn

TLS VPN's tegen IPsec VPN's afzetten op protocolfamilie beantwoordt een vraag die niemand stelde, en het verwijst meestal naar een constructie die beide families jaren geleden al lieten vallen. Wat een beoordelaar werkelijk kan vaststellen, is de onderhandelde bescherming, de peer-identiteit, het clientmodel en de blootgestelde dienst. Die vier dingen zijn zichtbaar in een implementatie, en geen ervan volgt uit het productlabel. Vraag naar vijf velden en het gesprek wordt concreet.

Vijf velden, en het label is er daar geen van

Het eerste veld is de ondersteunde software-release, want een protocolbeschrijving zonder versie is een folder. Het tweede is de onderhandelde protocolversie, die bepaalt welke constructies überhaupt beschikbaar zijn. Het derde is de beschermingssuite, het vierde de authenticatiemethode voor zowel peer als gebruiker, en het vijfde de toegangsreikwijdte die het product na toelating verleent.

Een SSL VPN-label dekt minstens drie verschillende producten: een volledige netwerkclient, een applicatieproxy en een ouderwets browsergebaseerd portaal. Ze stellen andere diensten bloot en falen anders, dus het label kan het veld reikwijdte niet vervangen.

Wat geauthenticeerde versleuteling werkelijk verandert

TLS 1.3 vereist geauthenticeerde versleuteling, waarmee de oudere MAC-then-encrypt-constructie uit het protocol verdwijnt in plaats van optioneel te blijven. IPsec ESP heeft net zo lang geauthenticeerde-encryptiesuites, met AES-GCM in een eigen RFC. In beide families komt de garantie uit de onderhandelde suite en niet uit de familienaam, en daarom begint de veldenlijst met een versie. Een beoordelaar die de suite niet kan noemen, heeft niets te beoordelen.

Daarom is de historische vergelijking misleidend. Een implementatie die vastzit op een oude TLS-versie met een CBC-suite en een die TLS 1.3 met een AEAD-suite draait, zijn niet dezelfde beveiligingshouding, ook al zijn het beide TLS VPN's. Dezelfde tweedeling bestaat aan de IPsec-kant tussen een moderne ESP-suite en een ouderwetse combinatie.

Lees de onderhandelde waarden in plaats van de configuratie die je bedoelde. De opdrachten hieronder laten zien waar een live endpoint en een live tunnel werkelijk op uitkwamen.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

Als het endpoint geen TLS 1.3 wil onderhandelen, is dat een bevinding en geen voorkeur. Als de tunnel een suite vermeldt die je niet verwachtte, is de configuratie die telt degene die de peers kozen, niet degene in de sjabloon.

Peer-identiteit is een aparte vraag

Versleuteling zonder geverifieerde peer beschermt het verkeer tegen waarnemers en geeft het aan wie de verbinding ook maar beantwoordde. Peer-authenticatie vraagt welke identiteit wordt verwacht, welk vertrouwensmateriaal die valideert, en hoe de client zich gedraagt als het antwoord niet klopt. Een certificaatketen, een vastgezette sleutel en een vooraf gedeeld geheim zijn drie verschillende antwoorden met drie verschillende operationele kosten.

Stel dan dezelfde vragen over de gebruiker of het apparaat. Een gateway die de machine authenticeert en elke gebruiker toelaat, of omgekeerd, heeft een specifieke houding die opgeschreven moet worden in plaats van aangenomen. Resourcemachtigingen die na toelating worden toegepast horen bij hetzelfde veld, want authenticatie is geen autorisatie.

Het behouden van hostnaam- en certificaatcontroles is belangrijker dan de vertrouwdheid van het inlogvenster. Een client die is geconfigureerd om verificatie te negeren, heeft de enige stap verwijderd die je gateway onderscheidt van een overtuigende imitatie.

De grens die het product blootstelt

Een clientloos portaal proxy't geselecteerde applicatiebewerkingen via de gateway, zodat de gebruiker een interface bereikt in plaats van een netwerk. Een full-tunnelclient draagt wat zijn routes en filterbeleid selecteren, wat een veel groter oppervlak is. De twee vergelijken op protocolsterkte mist het verschil in wat een aanvaller erdoor kan bereiken. De ene stelt een applicatie-interface bloot, de andere een gerouteerd netwerk, en de twee vragen om verschillende beoordelingen.

Vraag welke dienst wordt blootgesteld, welke bewerkingen zijn geautoriseerd en waarop de gateway zelf luistert. Een beheerinterface die bereikbaar is vanaf hetzelfde adres als het gebruikersportaal is een implementatiebevinding, en geen protocolkeuze vergoedt dat.

Reikwijdte per applicatie vernauwt het oppervlak verder, en verandert ook het faalgedrag wanneer de tunnel wegvalt. Een ontwerp dat volledige tunnelbereik aanneemt, breekt op manieren waarop een per-app-ontwerp dat niet doet, en de supportlast volgt.

Bepaal de faaluitkomst en de levenscyclus

Wat er gebeurt wanneer authenticatie of bescherming niet beschikbaar is, is een beleidsbeslissing die in de beoordeling thuishoort. Een geblokkeerde uitkomst en een onaangekondigde directe terugval hebben verschillende gevolgen, en het verschil is onzichtbaar in een functielijst. Vermeld het bedoelde gedrag naast de resource die het beschermt.

Neem de patch- en supportlevenscyclus van de gateway op, de ingeschakelde externe functies en het updatepad voor clients. Een juiste protocolkeuze maakt een slecht uitgerolde dienst niet veilig, en de meeste incidenten zitten in dat gat en niet in de suite.

Schrijf de vijf velden, het faalbeleid en de eigenaar van de levenscyclus op één pagina. Die pagina is een beoordeling; een vergelijking van protocolfamilies is een mening.