Wat is mTLS? Wederzijdse authenticatie tussen computers uitgelegd
Als je met je browser een beveiligde website bezoekt, zie je meestal een slotje in de adresbalk. Dat slotje betekent dat de verbinding is versleuteld met TLS (Transport Layer Security), en dat de website zich heeft geïdentificeerd met een certificaat, een soort digitaal paspoort dat bewijst dat de site is wie hij zegt te zijn. Wat de website echter niet doet, is vragen wie jíj bent. Jij hoeft geen paspoort te tonen om de deur binnen te lopen.
mTLS, kort voor mutual TLS ofwel wederzijdse TLS, verandert dat principe: bij mTLS moeten beide kanten van een verbinding zich identificeren met een certificaat, niet alleen de server. Vergelijk het met een besloten kantoorgebouw waar niet alleen de receptionist een naamplaatje draagt, maar waar ook elke bezoeker verplicht een pasje moet laten scannen voordat de deur opengaat. Beide partijen controleren elkaar, en pas als dat gelukt is, mag het gesprek beginnen. Deze techniek wordt vooral gebruikt tussen computersystemen onderling, bijvoorbeeld tussen de duizenden kleine softwareonderdelen waaruit een moderne app is opgebouwd, en steeds vaker ook om apparaten en gebruikers te beveiligen in bedrijfsnetwerken.
Wat is het precies?
Om mTLS te begrijpen, helpt het om eerst gewone TLS te begrijpen. Wanneer je browser verbinding maakt met een website, stuurt de server een certificaat op. Dat certificaat is digitaal ondertekend door een vertrouwde partij, een zogeheten certificaatautoriteit (CA), en bevat een publieke sleutel. Je browser controleert of de handtekening klopt en of het certificaat bij het juiste domein hoort. Zo ja, dan wordt een versleutelde verbinding opgezet. De server bewijst zijn identiteit; de bezoeker blijft anoniem voor het protocol zelf (al kan een website je later via een wachtwoord laten inloggen).
Bij mTLS komt daar een stap bij. Ook de client, dus bijvoorbeeld jouw apparaat, een app, of een ander computersysteem, heeft een eigen certificaat met een eigen publieke en private sleutel. Tijdens het opzetten van de verbinding stuurt niet alleen de server, maar ook de client dit certificaat op. Beide partijen verifiëren elkaars certificaat bij een vertrouwde CA voordat er data wordt uitgewisseld. Pas als die dubbele controle slaagt, is de verbinding tot stand gekomen.
Belangrijk is dat certificaten hier de rol overnemen van wachtwoorden. Een certificaat kun je niet raden of onderscheppen zoals een wachtwoord dat via phishing kan uitlekken; het bewijs van identiteit steunt op cryptografische sleutels die (in theorie) alleen de rechtmatige eigenaar bezit. Dat maakt mTLS geschikt voor situaties waarin je niet wilt vertrouwen op simpele inlogcodes, zoals communicatie tussen servers die geen mens achter een toetsenbord hebben om een wachtwoord in te typen.
Wat wil men ermee bereiken?
De kern van mTLS is het wegnemen van impliciet vertrouwen. In klassieke netwerken ging men er lang van uit dat alles binnen de firewall van een bedrijf veilig was: eenmaal binnen, vrij verkeer. Die aanname is de afgelopen vijftien jaar steeds meer losgelaten, mede door grote inbraken waarbij aanvallers eenmaal binnen het netwerk zich vrij konden bewegen. Dit denken heeft geleid tot het zogeheten zero trust-model: vertrouw nooit automatisch, verifieer altijd, ook al bevindt een systeem zich al binnen het netwerk.
mTLS is een van de bouwstenen om zero trust in de praktijk te brengen. In een moderne applicatie bestaat de achterkant vaak niet uit één groot programma, maar uit tientallen of honderden kleine onderdelen (microservices) die voortdurend met elkaar praten, bijvoorbeeld een betaalservice, een inlogservice en een voorraadservice. Zonder mTLS zou elk onderdeel elk ander onderdeel zomaar moeten vertrouwen. Met mTLS bewijst elke service bij elk contact opnieuw wie hij is, wat het voor een aanvaller die één onderdeel weet te compromitteren veel lastiger maakt om zich verder door het systeem te bewegen.
Daarnaast biedt mTLS versleuteling: net als bij gewone TLS wordt het verkeer onderweg afgeschermd tegen afluisteren. De combinatie van encryptie én wederzijdse identiteitscontrole maakt het een aantrekkelijke bouwsteen voor omgevingen waar zowel vertrouwelijkheid als sterke authenticatie nodig zijn, denk aan financiële systemen, overheidsinfrastructuur en zorgnetwerken.
Voorbeelden uit de praktijk
mTLS is geen toekomstbeeld maar wordt al op grote schaal toegepast, vaak onzichtbaar voor eindgebruikers, diep in de infrastructuur van technologiebedrijven.
Istio, een open source-project dat in 2017 werd gelanceerd door Google, IBM en het taxi-achtige bedrijf Lyft, is een zogeheten service mesh: een laag software die het verkeer tussen microservices beheert. Istio kan mTLS automatisch afdwingen tussen alle onderdelen van een applicatie, zonder dat programmeurs daar zelf code voor hoeven te schrijven. Het project draait inmiddels onder de paraplu van de Cloud Native Computing Foundation (CNCF).
Linkerd, oorspronkelijk ontwikkeld door het bedrijf Buoyant, is een vergelijkbaar service mesh-project en eveneens ondergebracht bij de CNCF. Ook Linkerd versleutelt en authenticeert het verkeer tussen microservices standaard met mTLS, met als expliciete belofte dat dit weinig extra configuratie vergt.
SPIFFE (Secure Production Identity Framework For Everyone) en de bijbehorende software SPIRE vormen een ander CNCF-project dat specifiek is gericht op het uitgeven en beheren van korte-levensduur-identiteiten voor workloads in de cloud, waarna die identiteiten gebruikt kunnen worden om mTLS-verbindingen op te zetten. Het idee is ontstaan uit ervaringen bij bedrijven als Google en Netflix met het beheren van identiteit op zeer grote schaal.
Google BeyondCorp is het interne zero trust-model dat Google vanaf ongeveer 2011 begon te bouwen, deels als reactie op de aanval die bekendstaat als Operation Aurora (2009). Google publiceerde de architectuur vanaf 2014 in een reeks technische artikelen. Certificaatgebaseerde, wederzijdse authenticatie tussen apparaten en diensten is daarin een centraal element, en het model heeft veel andere bedrijven geïnspireerd om vergelijkbare zero trust-architecturen te bouwen.
Cloudflare biedt mTLS als product aan bedrijven aan, onder meer via zijn Zero Trust- en API-beveiligingsdiensten, zodat organisaties mTLS kunnen inzetten om te controleren welke apparaten of systemen toegang krijgen tot hun API's, zonder dat ze zelf de onderliggende certificaatinfrastructuur hoeven te bouwen.
Hoe ver is de techniek?
mTLS zelf is geen nieuwe uitvinding; het bouwt voort op TLS, een protocol dat al sinds de jaren negentig bestaat (destijds nog SSL geheten) en dat door de Internet Engineering Task Force (IETF) wordt onderhouden. De meest recente versie, TLS 1.3, is vastgelegd in RFC 8446 uit 2018 en wordt inmiddels breed ondersteund. mTLS gebruikt dezelfde onderliggende cryptografie, maar dan met verificatie in twee richtingen.
Wat wél volop in ontwikkeling is, is de infrastructuur eromheen: hoe geef je op grote schaal certificaten uit aan duizenden kortlevende softwareonderdelen, hoe vervang je die certificaten automatisch voordat ze verlopen, en hoe doe je dat zonder dat een storing in dat systeem meteen de hele applicatie platlegt? Projecten als Istio, Linkerd en SPIFFE/SPIRE zijn precies bedoeld om die praktische complexiteit te beheersen, en ze zijn de afgelopen jaren volwassener geworden: verschillende ervan hebben de status 'graduated' bereikt binnen de CNCF, wat betekent dat ze door onafhankelijke beoordelaars als stabiel en breed toegepast worden gezien.
De belangrijkste obstakels zijn niet zozeer cryptografisch van aard, maar operationeel. Certificaatbeheer op schaal is foutgevoelig: een verlopen certificaat kan een dienst onbereikbaar maken, en verkeerd geconfigureerde vertrouwensrelaties kunnen onbedoeld toegang blokkeren of juist te veel toestaan. Ook buiten grote cloudomgevingen, bijvoorbeeld bij kleinere bedrijven of in IoT-apparaten met beperkte rekenkracht, is het opzetten van een betrouwbare certificaatketen niet triviaal. mTLS is dus technisch volwassen, maar de mate waarin organisaties het daadwerkelijk correct en consistent toepassen, verschilt sterk.
Wie werken eraan?
De onderliggende TLS-standaard wordt beheerd door de IETF, een internationale, open gemeenschap van ingenieurs die internetstandaarden ontwikkelt. Op het gebied van praktische toepassingen van mTLS spelen vooral grote clouddienstverleners en de open source-gemeenschap eromheen een sleutelrol: Google, IBM en Lyft rond Istio; Buoyant rond Linkerd; en een bredere groep bedrijven, waaronder ook HashiCorp (bekend van identiteits- en infrastructuursoftware als Vault en Consul, die eveneens mTLS gebruiken voor communicatie tussen diensten) rond SPIFFE/SPIRE.
Veel van deze projecten worden gecoördineerd via de Cloud Native Computing Foundation, een non-profitorganisatie die onderdeel is van de grotere Linux Foundation en die open source-projecten voor cloud-infrastructuur host en standaardiseert. Daarnaast bieden commerciële partijen als Cloudflare, Amazon (AWS) en Microsoft (Azure) mTLS-functionaliteit aan als onderdeel van hun cloud- en beveiligingsdiensten, gericht op bedrijven die deze technologie willen gebruiken zonder zelf de volledige onderliggende infrastructuur te bouwen.