Alles over man-in-the-middle (MITM)-aanvallen

Een man-in-the-middle-aanval (MITM-aanval) vindt plaats wanneer een aanvaller zich heimelijk tussen twee communicerende partijen positioneert en berichten leest of wijzigt die beide partijen als privé beschouwen. MITM-aanvallen kunnen elk protocol of elke poort op interne of externe netwerken treffen. Ze zijn gevaarlijk omdat de communicatie tijdens de aanval voor beide partijen normaal lijkt. De aanbevolen maatregelen zijn: TLS 1.3 met wederzijdse authenticatie afdwingen voor alle gevoelige verbindingen, HSTS met preloading implementeren om SSL-stripping te voorkomen, Certificate Transparency-logboeken controleren op ongeautoriseerde certificaatuitgiften en certificaatpinning gebruiken voor toepassingen met hoge beveiligingseisen.

Kort antwoord: Wat is een man-in-the-middle (MITM) aanval?

Een MITM-aanval is een cyberaanval waarbij een aanvaller heimelijk de communicatie onderschept tussen twee partijen, A en B, die beiden denken rechtstreeks met elkaar te communiceren. De aanvaller kan alle berichten lezen, deze wijzigen voordat ze worden doorgestuurd, nieuwe berichten toevoegen of zich voordoen als een of beide partijen. De aanval is bijzonder effectief omdat deze onzichtbaar is: tenzij de communicerende partijen cryptografische mechanismen hebben om elkaars identiteit en de integriteit van de berichten te verifiëren, kunnen ze de onderschepping niet detecteren. Versleuteling alleen is niet voldoende als de aanvaller de sleuteluitwisseling zelf kan onderscheppen. Daarom zijn geauthenticeerde sleuteluitwisselingsprotocollen en certificaatvalidatie essentiële verdedigingsmechanismen.

Hoe MITM-aanvallen werken: het mechanisme

Een MITM-aanval verloopt in twee fasen: interceptie (het verkrijgen van een positie tussen de twee partijen) en uitvoering (het misbruiken van die positie om gegevens te lezen, te wijzigen of te injecteren).

Laten we een concreet scenario bekijken: gebruiker A wil een gevoelig bericht naar gebruiker B sturen. Aanvaller Z heeft zich op het netwerkpad tussen A en B gepositioneerd.

1. A initieert communicatie en denkt dat hij verbonden is met B. Z heeft de verbinding onderschept en stuurt het verkeer van A door naar B, terwijl hij zich voordoet als B voor A en als A voor B.
2. A stuurt een bericht bestemd voor B. Z ontvangt het als eerste, leest de onversleutelde inhoud en wijzigt deze eventueel voordat hij het naar B doorstuurt.
3. B ontvangt het (mogelijk gewijzigde) bericht in de veronderstelling dat het rechtstreeks van A afkomstig is. B stuurt een antwoord naar A. Z onderschept dit antwoord, leest het en wijzigt het eventueel voordat het naar A wordt doorgestuurd.
4. Tijdens de hele uitwisseling weten noch A noch B dat Z zich ertussen bevindt. Als de communicatie niet versleuteld is, heeft Z volledige toegang tot alle gegevens. Als de communicatie wel versleuteld is, maar Z de sleuteluitwisseling heeft gecompromitteerd, kan Z nog steeds al het verkeer lezen en wijzigen.

MITM-aanvallen zijn moeilijk te detecteren omdat ze de communicatiestroom niet verstoren. Vanuit het perspectief van A en B verloopt het gesprek normaal. De enige betrouwbare manier om een ​​MITM-aanval te detecteren of te voorkomen, is door middel van cryptografische authenticatie: het verifiëren dat de entiteit waarmee je communiceert daadwerkelijk is wie ze beweert te zijn, met behulp van een mechanisme dat een aanvaller niet kan vervalsen.

Soorten MITM-aanvallen

Aanvalstype	Hoe werkt onze technologie?	Hoofddoel	Belangrijkste verdediging
ARP-spoofing (ARP-vergiftiging)	De aanvaller verstuurt vervalste ARP-berichten waarin zijn MAC-adres wordt gekoppeld aan een legitiem IP-adres (zoals de standaardgateway), waardoor de computers van de slachtoffers in plaats daarvan verkeer naar de aanvaller sturen.	Lokale netwerken; gedeelde netwerksegmenten	Dynamische ARP-inspectie (DAI) op beheerde switches; netwerksegmentatie
DNS-spoofing (DNS-cachevergiftiging)	Een aanvaller manipuleert de cache van een DNS-resolver met frauduleuze records, waardoor slachtoffers die die resolver raadplegen IP-adressen ontvangen die door de aanvaller worden beheerd voor legitieme domeinnamen.	DNS-infrastructuur; elk systeem dat gebruikmaakt van de vergiftigde resolver.	DNSSEC; versleutelde DNS (DoH/DoT); gevalideerde resolverconfiguratie
SSL-strippen	De aanvaller onderschept een HTTP-naar-HTTPS-omleiding en behoudt een HTTP-verbinding met het slachtoffer, terwijl de HTTPS-verbinding met de server behouden blijft, waardoor onderschepping in platte tekst mogelijk wordt.	Websessies waarbij gebruikers URL's typen zonder HTTPS.	HSTS met preloading; alle HTTP-verkeer wordt op de server omgeleid naar HTTPS.
Wi-Fi-afluistering / malafide toegangspunt	Een aanvaller creëert een kwaadaardig toegangspunt met een naam die lijkt op die van een legitiem openbaar netwerk; apparaten die automatisch verbinding maken, sturen al hun verkeer via het toegangspunt van de aanvaller.	Gebruikers op openbare wifi-netwerken	Vermijd automatisch verbinden met onbetrouwbare netwerken; gebruik een VPN op alle openbare wifi-netwerken; gebruik 802.1X-authenticatie voor wifi-netwerken binnen bedrijven.
Sessie kaping	De aanvaller steelt of voorspelt een geldig sessietoken (cookie) en gebruikt dit om zich bij de server voor te doen als het slachtoffer, zonder de inloggegevens van het slachtoffer nodig te hebben.	Webapplicatiesessies; browsergebaseerde applicaties	Secure- en HttpOnly-cookievlaggen; korte sessietokenlevensduur; tokenbinding; MFA voor herauthenticatie bij gevoelige acties.
HTTPS-spoofing (homograafaanval)	De aanvaller registreert een domein met geïnternationaliseerde tekens die identiek lijken aan een legitiem domein (bijvoorbeeld met Cyrillische tekens die visueel identiek zijn aan Latijnse tekens); het HTTPS-slotje lijkt geldig voor het domein van de aanvaller.	Gebruikers die HTTPS verifiëren maar het volledige certificaat niet controleren.	Certificaattransparantiemonitoring; gebruikersbewustzijn; afhandeling van geïnternationaliseerde domeinnamen door browsers
BGP-kaping	De aanvaller kondigt specifiekere of valse BGP-routes aan, waardoor internetrouters verkeer dat bestemd is voor een legitiem netwerk omleiden via infrastructuur die door de aanvaller wordt beheerd.	Verkeer op internetschaal; aanvallen op ISP-niveau.	BGP-routevalidatie (RPKI); monitoring op onverwachte wijzigingen in de routebron

Waarschuwingssignalen dat u mogelijk slachtoffer bent van een MITM-aanval

• Onverwachte certificaatwaarschuwingen: Uw browser geeft een certificaatfout weer, een waarschuwing voor een niet-vertrouwde certificeringsinstantie (CA), of het certificaat van een bekende website is onverwacht gewijzigd. Dit kan erop wijzen dat een aanvaller zijn eigen certificaat gebruikt om verbinding te maken.
• URL-afwijkingen: Het domein in de adresbalk vertoont subtiele verschillen met het verwachte domein, zoals tekenvervangingen (https://spooFing.com in plaats van https://spoofing.com), extra subdomeinen of geïnternationaliseerde tekens die lijken op Latijnse letters.
• Onverwachte HTTP-verbindingen: Uw browser of applicatie maakt verbinding via HTTP terwijl u HTTPS verwachtte, wat kan duiden op een SSL-strippingaanval.
• Herhaalde onderbrekingen van de verbinding: Je verbinding wordt verbroken en je wordt herhaaldelijk gevraagd om opnieuw in te loggen. Dit kan een teken zijn dat een aanvaller inloggegevens onderschept tijdens het opnieuw inloggen.
• Onverwachte vertraging: De netwerklatentie is aanzienlijk hoger dan normaal voor verbindingen met bekende diensten, wat erop kan wijzen dat het verkeer via een extra tussenstap wordt geleid.
• ARP-tabelafwijkingen: Op een beheerd netwerk toont de ARP-tabel één MAC-adres dat is gekoppeld aan meerdere IP-adressen, of het MAC-adres van de standaardgateway is gewijzigd, wat kan duiden op ARP-spoofing.

Hoe TLS en encryptie MITM-aanvallen voorkomen

De meest effectieve technische verdediging tegen MITM-aanvallen is geauthenticeerde encryptie, die vertrouwelijkheid (een aanvaller kan de gegevens niet lezen) combineert met authenticatie (beide partijen kunnen de identiteit van de entiteit waarmee ze communiceren verifiëren). TLS (Transport Layer Security) biedt beide eigenschappen voor netwerkcommunicatie.

De TLS-handshake werkt als volgt: de server presenteert een digitaal certificaat dat is uitgegeven en ondertekend door een vertrouwde certificeringsinstantie (CA). De client (browser of applicatie) verifieert de certificaatketen: het certificaat moet verwijzen naar een root-CA in de vertrouwensopslag van de client, het certificaat moet geldig zijn voor het domein waartoe toegang wordt verkregen en het certificaat mag niet zijn ingetrokken. Als de validatie slaagt, is de client cryptografisch verzekerd dat deze communiceert met de entiteit die de privésleutel bezit die bij het certificaat hoort. Een aanvaller die de verbinding onderschept, kan geen geldig certificaat voor het legitieme domein presenteren zonder de privésleutel of een vertrouwde CA te hebben gecompromitteerd.

Na authenticatie gebruikt TLS een tijdelijke sleuteluitwisseling (ECDHE in TLS 1.3; ECDHE of DHE in TLS 1.2) om sessiesleutels vast te stellen die niet via het netwerk zijn verzonden, waardoor forward secrecy wordt gewaarborgd. Zelfs als een aanvaller versleuteld verkeer onderschept en later een permanente privésleutel bemachtigt, kan hij eerdere sessies niet decoderen omdat de sessiesleutels tijdelijk waren en nooit zijn opgeslagen.

Protocol- en algoritmeselectie voor MITM-preventie

Controleer:	Aanbevolen configuratie	Wat te vermijden	Waarom dit belangrijk is voor MITM
TLS-versie	TLS 1.3 (voorkeur); minimaal TLS 1.2	TLS 1.0, TLS 1.1, SSL 3.0, SSL 2.0	Oudere versies hebben bekende zwakke punten die aanvallers misbruiken om verbindingen te verzwakken of verkeer te decoderen.
Sleuteluitwisseling	ECDHE (TLS 1.3 verplicht); DHE met 2048+ bitgroepen voor TLS 1.2	RSA-sleuteluitwisseling (geen forward secrecy); statische DH	Bij de uitwisseling van tijdelijke sleutels wordt forward secrecy gegarandeerd; bij de uitwisseling van RSA-sleutels worden bij een compromittering van de privésleutel alle eerder opgenomen sessies gedecodeerd.
Certificaatsleuteltype	ECDSA P-256 of RSA-3072+	RSA-1024, DSA, MD5-ondertekende certificaten	Zwakke certificaatsleutels kunnen worden vervalst, waardoor een aanvaller een geldig ogend certificaat kan presenteren voor een man-in-the-middle-aanval.
HTTP-beveiligingsheaders	HSTS met max-age 31536000 en includeSubDomains; HSTS Preload List-inzending voor publieke domeinen	Geen HSTS; korte HSTS maximale leeftijd; geen voorladen	Zonder HSTS kunnen SSL-stripping-aanvallen HTTPS-verbindingen degraderen naar HTTPS.
Certificaatvalidatie	Volledige ketenvalidatie + OCSP-stapling + monitoring van certificaattransparantie	Zelfondertekende certificaten zonder pinning; certificaatvalidatie uitgeschakeld in apps	Uitgeschakelde of zwakke validatie is de belangrijkste reden waarom MITM-aanvallen slagen tegen versleutelde verbindingen.
DNS-beveiliging	DNSSEC voor gezaghebbende zones; DNS-over-HTTPS (DoH) of DNS-over-TLS (DoT) voor resolvers.	Niet-gevalideerde DNS via UDP/53	DNS-spoofing is een veelgebruikt toegangspunt voor MITM-aanvallen; DNSSEC biedt integriteitsvalidatie van DNS-reacties.
Mutual TLS (mTLS)	mTLS voor API-communicatie tussen diensten en zero-trust-architecturen.	Server-only TLS voor gevoelige interne API's	mTLS vereist dat beide partijen certificaten presenteren en valideren, waardoor het voor een aanvaller aanzienlijk moeilijker wordt om zich in een verbinding te mengen.

SSL-stripping: een specifieke MITM-techniek

SSL-stripping is een van de meest effectieve MITM-technieken tegen webgebruikers, omdat het misbruik maakt van de overgang tussen HTTP en HTTPS. Wanneer een gebruiker een URL typt zonder HTTPS te specificeren (bijvoorbeeld door een domeinnaam rechtstreeks in de adresbalk te typen), maakt de browser doorgaans eerst een HTTP-verbinding die doorverwijst naar HTTPS. Een aanvaller die deze initiële HTTP-verbinding onderschept, kan:

1. Onderschep het eerste HTTP-verzoek van het slachtoffer vóór de HTTPS-omleiding.
2. Stuur het verzoek door naar de rechtmatige server via HTTPS (waarbij een geldige, versleutelde sessie met de server tot stand wordt gebracht).
3. Ontvang het HTTPS-antwoord van de server, verwijder de HTTPS-redirect en lever de inhoud via HTTP aan het slachtoffer.
4. De browser van het slachtoffer toont HTTP (zonder hangslotje), en alle gegevens die het slachtoffer verzendt, inclusief inloggegevens en sessietokens, zijn in platte tekst zichtbaar voor de aanvaller.

De verdediging is HTTP Strict Transport Security (HSTS) . HSTS instrueert browsers die een site eerder hebben bezocht om gedurende de max-age-periode alleen via HTTPS verbinding te maken, zelfs als de gebruiker de URL zonder HTTPS invoert. HSTS Preloading gaat nog een stap verder: het domein wordt opgenomen in een lijst die in browserreleases wordt verwerkt, zodat zelfs nieuwe bezoekers via HTTPS verbinding maken zonder dat een eerder bezoek nodig is om de HSTS-header te ontvangen.

Belangrijke managementafhankelijkheden voor MITM-preventie

De effectiviteit van TLS-gebaseerde MITM-preventie hangt volledig af van de integriteit van de certificaat- en privésleutelinfrastructuur. Als een aanvaller een geldig certificaat voor een doeldomein kan verkrijgen of vervalsen, kan hij dit tijdens een MITM-aanval presenteren en de standaard certificaatvalidatie doorstaan.

• Bescherming van privésleutels: Als de privésleutel van een server voor TLS-certificaten wordt gecompromitteerd, kan een aanvaller zich voordoen als de server tegenover elke client en zo de TLS-authenticatie volledig omzeilen. Privésleutels voor TLS-certificaten moeten met dezelfde zorgvuldigheid worden opgeslagen als elke andere gevoelige cryptografische sleutel, inclusief het beperken van de toegang tot alleen geautoriseerde processen. HSM-opslag voor certificaten met een hoge waarde en roulerende certificaten volgens een vast schema.
• Levenscyclusbeheer van certificaten: Verlopen, ingetrokken of verkeerd geconfigureerde certificaten genereren waarschuwingsmeldingen die gebruikers kunnen negeren of die applicaties kunnen omzeilen door certificaatvalidatie uit te schakelen. CertSecure Manager Het automatiseert het beheer van de levenscyclus van certificaten, waardoor wordt gegarandeerd dat certificaten worden vernieuwd vóór de vervaldatum en dat intrekking snel wordt afgehandeld wanneer er een vermoeden bestaat dat een sleutel is gecompromitteerd.
• Vertrouwen in de certificeringsinstantie: De veiligheid van TLS-authenticatie hangt af van de betrouwbaarheid van de certificeringsinstanties (CA's) in de rootcertificaatarchief van de client. Certificate Transparency (CT)-logboeken bieden een openbaar, alleen-toevoegend overzicht van alle door CA's uitgegeven certificaten, waardoor domeineigenaren kunnen controleren op ongeautoriseerde certificaatuitgiften voor hun domeinen.

Organisatorische beheersmaatregelen voor MITM-preventie

1. Dwing TLS overal af: Alle webpagina's, API's en interne services moeten minimaal via TLS 1.2 communiceren, bij voorkeur via TLS 1.3. Interne communicatie tussen services blijft met name vaak onversleuteld, waardoor deze kwetsbaar is voor laterale aanvallen die gebruikmaken van MITM-technieken.
2. HSTS implementeren met voorladen: Dien alle publiekelijk toegankelijke domeinen in bij de HSTS Preload List. Stel de maximale geldigheidsduur in op minimaal één jaar en voeg alle subdomeinen toe.
3. Gebruik wederzijdse TLS (mTLS) voor API's: Interne API's en communicatie tussen microservices vereisen dat zowel de client als de server geldige certificaten presenteren, waardoor het voor een aanvaller onmogelijk wordt om een ​​ongeautoriseerde service in een communicatiekanaal te plaatsen.
4. Transparantie van certificaten monitoren: Abonneer u op CT-logbewakingsservices die u waarschuwen wanneer er nieuwe certificaten voor uw domeinen worden uitgegeven. Dit maakt snelle detectie mogelijk van ongeautoriseerde certificaatuitgifte die een MITM-aanval mogelijk zou kunnen maken.
5. Bescherm de netwerklaag: Implementeer Dynamic ARP Inspection (DAI) op beheerde switches om ARP-spoofing op lokale netwerken te voorkomen. Gebruik 802.1X-authenticatie voor bedrijfs-Wi-Fi om aanvallen van malafide access points te voorkomen. Segmenteer netwerken om het broadcastdomein te beperken waarin ARP-aanvallen kunnen plaatsvinden.
6. Train gebruikers in het herkennen van waarschuwingssignalen: Gebruikers die certificaatfouten, HTTP-verbindingen waar HTTPS wordt verwacht en verdachte URL-afwijkingen herkennen, kunnen de social engineering-componenten van MITM-aanvallen voorkomen die afhankelijk zijn van de acceptatie van beveiligingswaarschuwingen door de gebruiker.

Beperkingen van technische MITM-verdedigingen

• Bedrijfs-TLS-inspectie creëert een gesanctioneerde MITM-aanval: Veel organisaties zetten TLS-inspectieproxy's in die TLS-verbindingen beëindigen en opnieuw versleutelen om het verkeer te controleren op malware en dataverlies. Vanuit het perspectief van het eindpunt voert de proxy een man-in-the-middle-aanval uit. Dit creëert een spanningsveld tussen beveiligingsmonitoring en end-to-end-versleuteling, en vereist dat gebruikers het proxycertificaat van de organisatie vertrouwen, dat doorgaans via groepsbeleid wordt geïmplementeerd.
• Certificaatpinning creëert operationele kwetsbaarheid: Certificaatpinning voorkomt MITM-aanvallen met frauduleus uitgegeven certificaten, maar verstoort ook de legitieme certificaatrotatie, tenzij de applicatie wordt bijgewerkt met de nieuwe gepinde waarde voordat het oude certificaat verloopt. Slecht beheer van pinrotatie heeft al tot grote applicatiestoringen geleid.
• HSTS biedt geen bescherming bij de eerste aansluiting zonder voorbelasting: Zonder preloading wordt HSTS pas geactiveerd nadat een gebruiker de site eerder via HTTPS heeft bezocht en de HSTS-header heeft ontvangen. Nieuwe bezoekers blijven daardoor kwetsbaar voor SSL-stripping.
• Versleutelde kanalen beschermen de doorvoer, maar niet de eindpunten: TLS beschermt gegevens tijdens de overdracht tussen client en server. Als de client of de server gecompromitteerd raakt, kan een aanvaller op dat eindpunt de onversleutelde gegevens lezen, ongeacht welke versleuteling het netwerkpad tussen hen beschermt.

Hoe encryptieconsultancy kan helpen

• CertSecure Manager: CertSecure Manager Beheert de levenscyclus van TLS-certificaten in uw omgeving, inclusief automatische verlenging om verlopen te voorkomen, intrekkingsbeheer en inzicht in alle certificaten die uw verbindingen beschermen. Verlopen of verkeerd geconfigureerde certificaten zijn een belangrijke factor bij MITM-aanvallen.
• HSM als een service: HSM als een service Beschermt de privésleutels achter uw TLS-certificaten in FIPS 140-3 gevalideerde hardware, waardoor het extraheren van sleutels wordt voorkomen, zelfs in geval van een servercompromis.
• Adviesdiensten op het gebied van encryptie: Encryptie Adviesdiensten Evalueer de TLS-configuratie van uw webpagina's en API's en identificeer zwakke cipher suites, ontbrekende HSTS-headers, certificaatfouten en onversleutelde interne servicecommunicatie die een risico op man-in-the-middle-aanvallen met zich meebrengt.
• PKI als een service: PKI als een service Biedt de infrastructuur voor het uitgeven en beheren van certificaten voor interne mTLS-implementaties, waardoor zero-trust netwerkarchitecturen mogelijk worden waarbij elke serviceverbinding wederzijds wordt geverifieerd.

Conclusie

MITM-aanvallen blijven een van de gevaarlijkste aanvalscategorieën omdat ze onzichtbaar werken: beide partijen denken dat hun communicatie privé is, terwijl dat niet het geval is. De technische verdedigingsmechanismen zijn goed ingeburgerd en effectief wanneer ze correct worden toegepast: TLS 1.3 met geauthenticeerde sleuteluitwisseling, HSTS met preloading, mTLS voor service-to-service-communicatie, Dynamic ARP Inspection voor lokale netwerken en Certificate Transparency-monitoring. De meest voorkomende oorzaak van het falen is niet dat de beveiligingsmaatregelen ontbreken, maar dat ze verkeerd geconfigureerd, onvolledig of afwezig zijn in delen van de netwerk- of applicatiestack die als veilig worden beschouwd. Een grondige beoordeling van uw TLS-configuratie, certificaatbeheer en interne netwerkbeveiligingsmaatregelen biedt het inzicht dat nodig is om deze lacunes te dichten.

Veelgestelde Vragen / FAQ

Wat is een Man-in-the-Middle (MITM) aanval?

Een MITM-aanval is een cyberaanval waarbij een aanvaller in het geheim de communicatie tussen twee partijen onderschept en berichten leest of wijzigt die volgens beide partijen rechtstreeks naar de andere partij worden verzonden. De aanval is onzichtbaar voor beide partijen, tenzij er cryptografische authenticatiemechanismen aanwezig zijn om de onderschepping te detecteren of te voorkomen.

Hoe voorkomt TLS MITM-aanvallen?

TLS voorkomt MITM-aanvallen door middel van authenticatie met servercertificaten (de server moet bewijzen dat hij de privésleutel bezit voor een certificaat dat is uitgegeven door een vertrouwde CA voor het juiste domein) en versleutelde sleuteluitwisseling (sessiesleutels worden vastgesteld via ECDHE, waardoor een onderschepper de sessiesleutels niet kan achterhalen, zelfs niet als hij de handshake onderschept). TLS 1.3 maakt forward secrecy verplicht voor alle verbindingen.

Wat is SSL-stripping en hoe werkt het?

SSL-stripping onderschept de eerste HTTP-verbinding van een slachtoffer voordat deze kan worden doorgestuurd naar HTTPS. Hierdoor blijft de HTTP-verbinding met het slachtoffer behouden, terwijl de verbinding met de server via HTTPS verloopt. Het slachtoffer stuurt onbewust onversleutelde gegevens naar de aanvaller. HSTS met preloading voorkomt dit door HTTPS af te dwingen, zelfs vóór de eerste verbinding tot stand komt.

Wat is ARP-spoofing en waarom is het gevaarlijk?

ARP-spoofing verstuurt vervalste ARP-berichten die het MAC-adres van de aanvaller koppelen aan een legitiem IP-adres op het lokale netwerk, waardoor verkeer via de aanvaller wordt omgeleid. Dit maakt MITM-aanvallen op netwerkniveau mogelijk, nog voordat er encryptie op applicatieniveau is toegepast. Dynamische ARP-inspectie op beheerde switches is de belangrijkste technische verdediging.

Wat is certificate pinning en wanneer zouden organisaties het moeten gebruiken?

Certificate pinning configureert een applicatie zodanig dat deze alleen specifieke certificaten of publieke sleutels voor een bepaalde server accepteert, en zelfs legitiem uitgegeven certificaten die niet overeenkomen, weigert. Het is geschikt voor mobiele applicaties met hoge beveiligingseisen en bedrijfs-API's waarbij beide eindpunten onder organisatiebeheer vallen. Het brengt echter operationele complexiteit met zich mee rondom certificaatrotatie en wordt niet aanbevolen voor standaard webapplicaties.

Hoe kan een organisatie een MITM-aanval detecteren?

Signalen zijn onder andere onverwachte certificaatwijzigingen of -fouten, afwijkingen in de ARP-tabel (één MAC-adres voor meerdere IP-adressen), onverwachte HTTP-verbindingen waar HTTPS wordt verwacht, herhaalde verbindingen die opnieuw authenticatie vereisen, ongebruikelijke latentie en DNS-resolutieresultaten die afwijken van de verwachte waarden. De logboekbewaking van Certificate Transparency waarschuwt voor ongeautoriseerde certificaatuitgiften voor uw domeinen.