Versleuteling en versleuteld verkeer
40 vragen over Versleuteling en versleuteld verkeer, in gewone taal: wat u controleert, wat NetSenX laat zien en wat een sensor niet ziet.
Ja, op basis van metadata: versleuteld verkeer wordt nooit ontsleuteld. NetSenX kijkt naar flow-metadata en enkele protocolvelden — timing, volume, bestemmingen en de TLS-handshake — zodat beaconing en ongebruikelijke gegevensoverdrachten zichtbaar blijven zonder de versleuteling te breken of inhoud te lezen.
Ja, op basis van metadata. Timing, volume, bestemmingen en de TLS-handshake blijven zichtbaar wanneer de inhoud versleuteld is, zodat beaconing naar een C2-server en ongebruikelijke gegevensoverdrachten te detecteren zijn zonder de versleuteling te breken. Wat onzichtbaar blijft, is de inhoud van de sessie.
Flow-metadata (wie met wie verbindt, wanneer, hoe vaak en hoeveel data er wordt verplaatst) en enkele protocolvelden: de servernaam en de parameters uit de TLS-handshake, en de antwoorden op DNS-query's. NetSenX ontsleutelt de sessie nooit en leest de versleutelde inhoud niet.
Voor veel ervan niet. Wie met wie praat, wanneer, hoe vaak en hoeveel, samen met de onversleutelde TLS-handshake en DNS-antwoorden, blijft zichtbaar zonder ontsleuteling. Dat is genoeg om beaconing naar een command-and-controlserver, scans, laterale beweging tussen interne hosts en ongewone uploads te zien, stappen die de meeste inbraken zetten voordat ze schade aanrichten. Ontsleuteling is nodig om inhoud te zien, zoals een kwaadaardig bestand in een download of de tekst van een opdracht, en ze heeft een prijs: een onderscheppende proxy die sleutels en ontsleutelde gegevens bewaart, een bedrijfscertificaat op elk beheerd apparaat, apps die niet meer werken, vragen over privacy en de ondernemingsraad, en blinde vlekken bij onbeheerde apparaten. Veel bedrijven halen meer uit endpointbeveiliging voor bestanden en processen op elke machine, plus netwerkdetectie voor het gedrag van alle apparaten. NetSenX ontsleutelt nooit verkeer: de kerndetecties werken op elk abonnement, TLS-fingerprints vanaf het Starter-abonnement waar de agent pakketten vastlegt.
Ontsleuteling maakt inhoud zichtbaar, maar betekent een onderscheppingspunt dat sleutels bewaart, een onderscheppingscertificaat op elk apparaat en het verwerken van ontsleutelde inhoud die persoonsgegevens kan bevatten. Sinds TLS 1.3 kan een passieve sensor sessies niet meer ontsleutelen met een kopie van de privésleutel van de server.
Meer dan men verwacht. Om HTTPS te inspecteren beëindigt de firewall of proxy elke verbinding, ontsleutelt en inspecteert die en opent een nieuwe versleutelde verbinding met de echte server, waarbij hij een eigen certificaat toont, ondertekend door een bedrijfsroot die op elk beheerd apparaat staat. De bijwerkingen: apps met certificate pinning, veel updaters, sommige bank- en zorgapps en delen van clouddiensten weigeren het vervangende certificaat, dus uitzonderingslijsten groeien steeds; onbeheerde apparaten, gasten en machines zijn helemaal niet te inspecteren; de proxy wordt één plek met ontsleuteld verkeer, inclusief persoonsgegevens, wat vragen oproept over de AVG en de ondernemingsraad; oudere proxy's ondersteunen recente TLS-functies of de nieuwe hybride post-kwantumgroepen mogelijk niet en verzwakken verbindingen ongemerkt; en inspectie kost prestaties. Ze heeft nog steeds haar plek, bijvoorbeeld om downloads op beheerde laptops te scannen. Maar veel dreigingen zijn ook zonder zichtbaar. Dat is de aanpak van NetSenX: het ontsleutelt nooit en werkt met metadata en de onversleutelde handshake.
Alleen op de delen die niet versleuteld zijn, tenzij u ontsleutelt. Deep packet inspection (DPI) betekent voorbij de pakketheaders in de inhoud lezen. Bij TLS is de inhoud versleuteld, dus klassieke signaturen die zoeken naar een kwaadaardig bestand of commando in de stroom matchen niet meer. Leesbaar blijven de onversleutelde handshakeberichten, met de TLS-versie, de keuze voor cijfersuite en sleuteluitwisseling, een clientfingerprint en meestal de servernaam, en de DNS-antwoorden die aan de verbinding voorafgingen. Samen met flowmetadata, dus wie, wanneer, hoe vaak en hoeveel, is dat genoeg voor veel detecties: beaconing naar een command-and-controlserver, scans, laterale beweging en ongewone uploads. Om inhoud te zien hebt u een onderscheppende proxy nodig die verkeer ontsleutelt en opnieuw versleutelt, met eigen kosten en risico's. NetSenX leest de handshakevelden waar zijn agent pakketten vastlegt, op Linux of als SPAN/TAP-sensor, niet in de basismodus op macOS, en ontsleutelt nooit verkeer.
Vaak wel, omdat malware zich op bepaalde manieren moet gedragen om bruikbaar te zijn, en dat gedrag is in de flows te zien. Flowrecords beschrijven elke verbinding: bron en bestemming, poorten, starttijd, duur, en bytes en pakketten in elke richting. Een gecompromitteerd apparaat dat op vaste tijden contact opneemt met zijn besturingsserver, geeft een herkenbaar ritme, beaconing; een apparaat dat het netwerk verkent, raakt in korte tijd veel interne hosts en poorten, wat scannen en laterale beweging is; een apparaat dat gegevens steelt, verstuurt veel meer dan normaal, vaak 's nachts. Niets hiervan vraagt ontsleuteling, en onderzoek naar de analyse van versleuteld verkeer laat al jaren zien dat patronen in tijd en omvang veel informatie bevatten. De grenzen: één verbinding met een bekende clouddienst kan onschuldig lijken, en geduldige aanvallers proberen op te gaan in de massa. Daarom werkt flowanalyse het best tegen een basislijn van wat normaal is voor elk apparaat. NetSenX detecteert beaconing, scans, laterale beweging en ongewoon uitgaand datavolume op elk abonnement, ook Free.
De inhoud niet, maar wel meer erover dan men vaak denkt. Versleuteling verbergt woorden, bestanden en toetsaanslagen, maar omvang, timing en richting van pakketten lekken patronen: een videogesprek, een grote upload, een remote-desktopsessie en een software-update hebben elk een herkenbare vorm. Onderzoekers laten al jaren zien dat zulke verkeersanalyse, met wisselende nauwkeurigheid, bezochte websites of gebruikte applicaties kan herkennen, zelfs via een VPN. Voor verdediging is dat nuttig: zo kan een netwerksensor een interactieve sessie onderscheiden van een automatische check-in, of een server opmerken die plotseling gigabytes verstuurt, zonder iets te ontsleutelen. Voor privacy is het een herinnering dat versleuteling geen onzichtbaarheid is. Wat verkeersanalyse niet kan: een bericht lezen, zien welk bestand is geüpload of weten wat iemand in een AI-chatbot heeft getypt. NetSenX gebruikt flowmetadata en de onversleutelde handshake, ontsleutelt nooit sessies en reconstrueert geen inhoud.
Dat kan. Het Hof van Justitie van de EU oordeelde in de zaak-Breyer (C-582/14, 19 oktober 2016) dat een dynamisch IP-adres een persoonsgegeven kan zijn. NetSenX publiceert een verwerkersovereenkomst volgens artikel 28 AVG en bewaart klantgegevens in de EU.
Ja. HTTPS betekent dat de verbinding versleuteld is en dat de server een geldig certificaat heeft voor de naam in de adresbalk; het zegt niets over de vraag of de site of de downloads veilig zijn. Aanvallers gebruiken HTTPS net zo gewoon als iedereen, omdat certificaten gratis en geautomatiseerd zijn, en veel phishing en verspreiding van malware loopt erover. Het slotje beschermt u tegen iemand die onderweg verkeer leest of verandert, niet tegen de inhoud aan de andere kant. Bescherming tegen kwaadaardige downloads komt van endpointbeveiliging op het apparaat, filtering in browser en e-mail, actuele software en beperken wie programma's mag installeren. Aan de netwerkkant verbergt versleuteling het bestand, maar niet het gedrag dat meestal op een infectie volgt: een apparaat dat plotseling op vaste tijden een nieuwe bestemming benadert, interne hosts scant of ongewone hoeveelheden data verstuurt. NetSenX detecteert die patronen op elk abonnement, uit flowmetadata en zonder verkeer te ontsleutelen.
Alleen als de client ertoe kan worden gebracht de onderschepper te vertrouwen. Een man-in-the-middle-aanval op HTTPS vraagt om een certificaat dat de client accepteert voor de doelnaam, een gebruiker die de waarschuwing wegklikt of een applicatie die certificaten niet goed controleert. Bedrijven doen het bewust met TLS-inspectieproxy's, door een eigen rootcertificaat op beheerde apparaten te installeren. Aanvallers proberen hetzelfde door via malware een vals rootcertificaat te plaatsen, gebruikers waarschuwingen te laten accepteren of apps met gebrekkige certificaatcontrole te misbruiken. Verdediging: leer medewerkers nooit certificaatwaarschuwingen weg te klikken, beheer welke rootcertificaten op bedrijfsapparaten staan, houd apps bijgewerkt en gebruik HTTP Strict Transport Security (HSTS) op uw eigen websites, zodat browsers onversleutelde verbindingen weigeren. Certificate pinning in sommige apps weigert elke onderschepper, ook uw eigen proxy. In TLS 1.3 is het servercertificaat versleuteld, dus een passieve netwerksensor kan niet controleren wie het heeft uitgegeven; die controle hoort op het apparaat of in proxylogs.
Als een programma een TLS-verbinding opent, noemt zijn eerste bericht de ondersteunde versies, ciphers en extensies, in een kenmerkende volgorde. Een vingerafdruk zoals JA4 vat dat bericht samen in een korte tekenreeks, zodat dezelfde clientsoftware over verbindingen heen herkend kan worden zonder iets te ontsleutelen. Dat helpt ongebruikelijke clients te zien, zoals een script dat zich als browser voordoet. NetSenX berekent TLS-vingerafdrukken uit de handshake vanaf het Starter-abonnement, met een eigen implementatie. De handshake is alleen zichtbaar waar de agent pakketten vastlegt: op Linux of als sensor op een SPAN- of TAP-poort, niet in de basismodus op macOS.
Beide maken een fingerprint van de clientkant van een TLS-handshake, maar JA4 kan omgaan met het gedrag van moderne browsers. JA3, gepubliceerd in 2017, hasht de velden van de ClientHello in de volgorde waarin ze verschijnen. Sinds begin 2023 schudt Chrome bij elke verbinding de volgorde van de TLS-extensies door elkaar, waardoor de JA3-waarde elke keer verandert en veel minder bruikbaar wordt om browsers te herkennen. JA4, gepubliceerd in 2023, sorteert de velden vóór het hashen, voegt de TLS-versie, het transport (TCP of QUIC) en het eerst aangeboden applicatieprotocol toe en levert een leesbare tekenreeks waarvan de delen afzonderlijk te vergelijken zijn. Geen van beide bewijst op zichzelf kwade opzet: veel programma's delen een fingerprint en malware kan een browser nadoen. Ze zijn nuttig om een client te zien die niet bij het apparaat past, zoals een script op een server dat zich als browser voordoet. NetSenX berekent TLS-fingerprints vanaf het Starter-abonnement, met een eigen implementatie, waar zijn agent pakketten vastlegt: op Linux of als SPAN/TAP-sensor, niet in de basismodus op macOS.
Server Name Indication (SNI) is een veld in de TLS-ClientHello waarin de client de gewenste site noemt, zoals login.example.com, omdat veel sites één IP-adres delen en de server moet weten welk certificaat hij moet tonen. Het wordt verstuurd voordat de versleuteling begint, dus iedereen op de route kan het lezen. Voor monitoring is het een van de nuttigste velden in versleuteld verkeer: het noemt de dienst achter een IP-adres, wat helpt om een AI-assistent, een site voor bestandsdeling of een bekende bedrijfsapplicatie te onderscheiden van een onbekende server, zonder inhoud te lezen. De meeste webfilters en veel firewalls steunen er ook op. Twee dingen verminderen de waarde: verbindingen rechtstreeks naar een IP-adres dragen geen zinvolle naam, en Encrypted Client Hello (ECH) verbergt de echte naam achter een publieke voornaam. Dan worden DNS-antwoorden en de geschiedenis van elke bestemming belangrijker. NetSenX leest de servernaam uit de handshake waar zijn agent pakketten vastlegt, op Linux of als SPAN/TAP-sensor.
ECH is een TLS-extensie die het gevoelige deel van de ClientHello versleutelt, inclusief de echte servernaam, met een publieke sleutel die de site in DNS publiceert. Op de lijn ziet een waarnemer alleen een buitenste ClientHello met een gedeelde publieke naam, meestal die van het contentdeliverynetwerk dat de site host, in plaats van de echte site. Het is ontworpen voor privacy: niemand op de route, van café-wifi tot internetprovider, mag te weten komen welke site u bezoekt. Grote browsers ondersteunen het en sommige grote contentdeliverynetwerken bieden het aan, dus een deel van het webverkeer gebruikt het al, terwijl de meeste bedrijfs- en interne servers dat niet doen. ECH gaat meestal samen met versleutelde DNS, omdat de naam anders alsnog via de DNS-query zou uitlekken. Certificaat en sessie-inhoud waren onder TLS 1.3 al versleuteld; ECH sluit een van de laatste leesbare velden. Voor securityteams betekent het minder namen en meer leunen op gedrag.
Gedeeltelijk. Met ECH ziet een sensor de echte servernaam in de handshake niet meer, dus regels op basis van namen, webfilters en eenvoudige lijsten voor schaduw-IT verliezen precisie bij sites die het gebruiken. Er blijft veel over: het IP-adres van de bestemming en wie dat beheert, de buitenste publieke naam, meestal die van een groot contentdeliverynetwerk, DNS-antwoorden als DNS niet van begin tot eind versleuteld is, de timing, het volume en de richting van elke flow en de clientfingerprint. Gedragsdetecties zoals beaconing, scans, laterale beweging en ongewone uploads hangen niet af van de servernaam en blijven werken. Intern verkeer wordt zelden geraakt, omdat interne servers zelden ECH-sleutels publiceren. Op beheerde apparaten hebt u invloed: laat ze uw eigen DNS-resolver gebruiken en zet de bedrijfsbeleidsregels van de browser in, waarmee ECH en versleutelde DNS te sturen zijn. Zicht op AI- of bestandsdelingsdiensten op naam wordt voor sites achter ECH minder volledig, voor elke netwerksensor, NetSenX inbegrepen.
Ze beperken wat oudere firewalls zien, maar maken verkeer niet onzichtbaar. QUIC (RFC 9000, 2021) is het transport onder HTTP/3. Het draait over UDP-poort 443 en versleutelt bijna alles, ook veel van wat TCP leesbaar liet, zoals pakketnummers en bevestigingen. De eerste pakketten bevatten een TLS 1.3-ClientHello die alleen is beschermd met sleutels die iedereen kan afleiden, dus een sensor die QUIC begrijpt, kan nog steeds de servernaam en de handshakeparameters lezen. Firewalls en proxy's die voor TCP zijn gebouwd, kunnen QUIC vaak helemaal niet inspecteren. Gangbaar bij bedrijven die op TLS-inspectie of webfiltering vertrouwen, is UDP-poort 443 te blokkeren, waardoor browsers ongemerkt terugvallen op HTTP/2 over TCP. Zonder zo'n regel verschijnt QUIC gewoon als UDP-flows met timing en volume zoals elk ander verkeer, en flowgebaseerde detecties zoals beaconing en ongewoon uploadvolume blijven gelden. Controleer of uw firewall QUIC rapporteert voordat u aanneemt dat het is gedekt.
Het kan de DNS-opvragingen verbergen, niet de verbindingen die erop volgen. DNS over HTTPS (DoH, RFC 8484) en DNS over TLS (DoT, RFC 7858) versleutelen de vragen die een apparaat aan zijn resolver stelt. Gebruiken browsers of apps een externe DoH-resolver, dan zien uw bedrijfs-DNS-server en de logs niet meer welke namen worden opgezocht, wat DNS-filtering en onderzoek verzwakt. Malware kan DoH om dezelfde reden gebruiken. De verbindingen met de echte bestemmingen gaan nog steeds over het netwerk, met IP-adressen, timing en volume, en vaak met de servernaam in de TLS-handshake. Praktische stappen: draai een eigen resolver, of gebruik die van een aanbieder, die versleutelde DNS ondersteunt en laat beheerde apparaten die gebruiken; voorkom met beleid voor browser en besturingssysteem dat ze andere resolvers gebruiken; en let op apparaten die rechtstreeks met publieke DoH-diensten praten. DoT is makkelijk te herkennen omdat het poort 853 gebruikt; DoH ziet eruit als gewoon HTTPS. NetSenX waarschuwt bij DNS-tunneling; het filtert of blokkeert geen DNS.
Op een machine die u beheert, is de eenvoudigste manier de client zijn sessiesleutels naar een bestand te laten schrijven en dat bestand in Wireshark te laden. Browsers en veel commandoregeltools op basis van OpenSSL of NSS respecteren de omgevingsvariabele SSLKEYLOGFILE: stel die in, reproduceer het probleem terwijl u met Wireshark of tcpdump vastlegt, en wijs in de TLS-instellingen van Wireshark het sleutellog aan. Dat werkt ook bij TLS 1.3, waar de privésleutel van de server niet meer volstaat. Op een eigen server kunnen sommige webservers en proxy's ook sleutels loggen, of u test tegen een testkopie met logging aan. Behandel sleutellogs als wachtwoorden: wie het bestand en de opname heeft, kan het verkeer lezen, dus verwijder beide na afloop en verzamel ze nooit van andermans apparaten zonder duidelijke grondslag en zonder dat zij het weten. Voor dagelijkse monitoring is ontsleuteling zelden nodig: flowmetadata en de onversleutelde handshake beantwoorden de meeste vragen over wie met wie praat en hoe.
Bij TLS 1.3 kost het één heen-en-terugreis voordat er data stroomt. De client stuurt een ClientHello met de TLS-versies, cijfersuites en groepen voor sleuteluitwisseling die hij ondersteunt, een sleutelaandeel voor zijn voorkeursgroep en meestal de naam van de gewenste server (SNI). De server antwoordt met een ServerHello die versie, cijfersuite en groep kiest, plus een eigen sleutelaandeel. Uit de twee aandelen leiden beide kanten hetzelfde geheim af, en vanaf dat moment is alles versleuteld, ook het servercertificaat en het bewijs dat de server de bijbehorende privésleutel heeft. De client controleert het certificaat tegen de autoriteiten die hij vertrouwt, en de applicatiedata begint. ClientHello en ServerHello gaan onversleuteld over de lijn, en daarom kan een passieve sensor de TLS-versie, de gekozen groep voor sleuteluitwisseling, bijvoorbeeld klassiek X25519 of hybride X25519MLKEM768, en een clientfingerprint zien zonder iets te ontsleutelen. Met Encrypted Client Hello wordt ook een deel van de ClientHello, inclusief de servernaam, verborgen.
TLS 1.3 (RFC 8446, 2018) is sneller en schrapt de zwakke opties achter de meeste eerdere TLS-aanvallen. De handshake is klaar na één heen-en-terugreis in plaats van twee. Alleen sleuteluitwisselingen met forward secrecy blijven over, dus verkeer opnemen en later de privésleutel van de server stelen ontsleutelt eerdere sessies niet meer. Oude cijfers en modi zoals RC4, 3DES, CBC-suites en statische RSA-sleuteluitwisseling verdwijnen, en er blijft een korte lijst moderne geauthenticeerde cijfers over. En een groter deel van de handshake wordt versleuteld, ook het servercertificaat. Voor monitoring heeft dat twee gevolgen. Een passief apparaat kan sessies niet meer ontsleutelen met een kopie van de privésleutel van de server, dus inspectie vraagt nu een actieve onderscheppende proxy. En er is minder in leesbare vorm te zien: het certificaat is verborgen, terwijl de hello-berichten, de gekozen groep en de servernaam, tenzij Encrypted Client Hello wordt gebruikt, zichtbaar blijven. Geef overal de voorkeur aan TLS 1.3 en houd TLS 1.2 alleen met sterke cijfersuites aan voor oudere clients.
Ja. Beide zijn sinds RFC 8996 (maart 2021) formeel afgekeurd door de IETF, grote browsers accepteren ze niet meer, en ze steunen op oude hashfuncties en cijferconstructies met bekende zwakheden. Staan ze op een server nog aan, dan is het risico minder een directe aanval dan een downgradepad, en een teken van verwaarlozing dat auditors, verzekeraars en scanners zullen opmerken. Zoek vóór het uitschakelen uit wie ze nog gebruikt: oude printers, scanners, industriële apparaten, verouderde applicaties en embedded clients zijn de gebruikelijke verdachten, en uitschakelen zonder controle kan een productielijn of betaalterminal stilleggen. Kijk in serverlogs die de TLS-versie vastleggen, laat een externe scanner los op publieke diensten en kijk binnen het netwerk naar de TLS-versies in de handshakes. Schakel ze dan uit, of isoleer wat niet bij te werken is in een eigen segment, met een plan voor vervanging. Dezelfde inventaris komt later goed van pas bij het post-kwantumwerk.
Alles zonder forward secrecy of geauthenticeerde versleuteling, en alles van de oude lijsten. Concreet: schakel RC4 uit, dat RFC 7465 in TLS verbiedt, plus 3DES en andere 64-bits blokcijfers, export- en NULL-cijfers, statische RSA-sleuteluitwisseling en CBC-suites met SHA-1 waar uw clients het toelaten. Houd de TLS 1.3-suites AES-GCM en ChaCha20-Poly1305 aan, en gebruik voor TLS 1.2 ECDHE-sleuteluitwisseling met AES-GCM of ChaCha20-Poly1305. Gebruik gepubliceerde configuratiegidsen in plaats van zelf iets te verzinnen: de server-side TLS-aanbevelingen van Mozilla en de ICT-beveiligingsrichtlijnen voor TLS van het NCSC geven geteste profielen voor moderne en oudere clients. Controleer voordat u een productieserver aanpast welke clients verbinden en wat ze aanbieden, uit serverlogs of een overzicht van de handshakes, zodat u geen oud apparaat buitensluit. Test daarna opnieuw van buitenaf met een TLS-scanner en schakel de hybride groep X25519MLKEM768 in waar uw software die ondersteunt.
Forward secrecy betekent dat elke sessie een verse, tijdelijke sleutel gebruikt die daarna wordt weggegooid, zodat wie later de langlopende privésleutel van een server steelt, eerder opgenomen sessies niet kan ontsleutelen. Het komt van kortstondige sleuteluitwisselingen zoals ECDHE of X25519: de langlopende sleutel bewijst alleen de identiteit van de server, terwijl de sessiesleutel ontstaat uit wegwerpwaarden die beide kanten kiezen. Oudere TLS-configuraties met statische RSA-sleuteluitwisseling hadden het niet, zodat één gestolen sleutel jaren aan opgenomen verkeer kon openen. TLS 1.3 maakt forward secrecy verplicht, en goed ingestelde TLS 1.2-servers bieden het ook. Het verklaart ook waarom harvest now, decrypt later over de sleuteluitwisseling gaat: forward secrecy beschermt tegen een toekomstige diefstal van de sleutel, niet tegen een toekomstige kwantumcomputer die de kortstondige uitwisseling op elliptische curven zelf breekt. Hybride post-kwantumsleuteluitwisseling behoudt forward secrecy en voegt de ontbrekende bescherming toe. Controleer uw servers met een TLS-scanner: elke aangeboden suite zou het moeten hebben.
Versleuteling maakt van leesbare gegevens door elkaar gehusselde gegevens die alleen iemand met de juiste sleutel kan terugzetten. De methode, het algoritme, is openbaar; het geheim is de sleutel. Goede versleuteling betekent dat zelfs een krachtige computer de gegevens zonder sleutel niet binnen bruikbare tijd terugkrijgt. U gebruikt het elke dag: HTTPS op websites, de VPN naar kantoor, berichtenapps, schijfversleuteling op laptops en telefoons, en back-ups. Het beschermt gegevens onderweg tegen iedereen die het netwerk kan afluisteren, en opgeslagen gegevens tegen iedereen die de schijf steelt. Het beschermt gegevens niet tegen iemand die de sleutel al heeft of een apparaat beheert waarop de gegevens worden ontsleuteld, zoals malware op een ingelogde laptop. Daarom staat versleuteling naast toegangsbeheer, patchen en monitoring in plaats van die te vervangen. Een netwerksensor ziet dat versleutelde verbindingen plaatsvinden, met hun metadata, maar niet de inhoud.
Symmetrische versleuteling gebruikt één gedeelde sleutel om af te sluiten en te openen; asymmetrische of publieke-sleutelversleuteling gebruikt een paar: een publieke sleutel die iedereen mag kennen en een privésleutel die alleen de eigenaar heeft. Symmetrische algoritmen zoals AES zijn snel en versleutelen bijna alle echte gegevens. Hun zwakke punt is het veilig delen van de sleutel. Publieke-sleutelmethoden zoals RSA, Diffie-Hellman op elliptische curven en hun post-kwantumopvolgers lossen dat op: twee partijen die elkaar nooit hebben ontmoet, kunnen over een open netwerk een verse symmetrische sleutel afspreken, en met een privésleutel kun je gegevens zo ondertekenen dat iedereen met de publieke sleutel het kan controleren. Echte protocollen combineren beide. Een TLS-verbinding gebruikt in de handshake publieke-sleutelcryptografie om een sleutel af te spreken en de identiteit van de server te bewijzen, en schakelt daarna voor de gegevens over op AES of ChaCha20. Die verdeling verklaart ook het kwantumverhaal: het algoritme van Shor bedreigt het publieke-sleuteldeel, terwijl symmetrische versleuteling met 256-bitssleutels sterk blijft.
Dat hangt af van het soort algoritme, want lengtes zijn tussen soorten niet vergelijkbaar. Bij symmetrische versleuteling geldt AES-128 nog steeds als sterk en geeft AES-256 extra marge, ook tegen toekomstige kwantumcomputers; gebruik 256 bits voor gegevens die vele jaren geheim moeten blijven. Bij RSA is 2048 bits nu het gangbare minimum, en instanties zoals het Duitse BSI raden voor langere bescherming minstens 3000 bits aan. Sleutels op elliptische curven zijn bij dezelfde sterkte veel korter: een 256-bitscurve zoals P-256 of X25519 komt ongeveer overeen met RSA van zo'n 3000 bits. Gebruik voor hashing SHA-256 of sterker. Twee kanttekeningen tellen zwaarder dan de getallen. Sleutellengte helpt niet als de sleutel slecht is gegenereerd, in een script staat of nooit wordt gewisseld. En RSA en elliptische curven van elke lengte vallen tegen een grote kwantumcomputer, daarom zijn post-kwantumalgoritmen hun vervanging op lange termijn, geen langere sleutels. Volg voor exacte waarden de actuele richtlijnen van uw nationale instantie.
Een hashfunctie maakt van elke hoeveelheid gegevens een korte vingerafdruk van vaste lengte, zoals de 256-bitsuitvoer van SHA-256. Dezelfde invoer geeft altijd dezelfde hash, een kleine wijziging geeft een totaal andere, en niemand kan uit de hash de invoer terugrekenen of twee invoeren met dezelfde hash vinden. Daardoor zijn hashes nuttig om te controleren of een download of back-up niet is veranderd, voor digitale handtekeningen, die de hash van een document ondertekenen, voor het veilig opslaan van wachtwoorden en voor de integriteitscontroles binnen TLS. Oude functies zijn gesneuveld: MD5 en SHA-1 zijn voor beveiligingsdoeleinden gebroken, en in 2017 werd publiekelijk een SHA-1-botsing aangetoond, dus behandel ze als verouderd waar ze nog opduiken, bijvoorbeeld in oude certificaten of bestandscontroles. SHA-256, SHA-384 en SHA-3 zijn de huidige keuzes. Een hash is geen versleuteling: er is geen sleutel en niets te ontsleutelen. Kwantumcomputers verzwakken hashfuncties maar beperkt.
Nee, en voor wachtwoorden is hashen de juiste keuze. Versleuteling is met een sleutel omkeerbaar, dus wie de versleutelde wachtwoorden en de sleutel steelt, heeft alle wachtwoorden terug. Een hash is niet om te keren, dus het systeem bewaart alleen de hash en vergelijkt die bij het inloggen. Gewone snelle hashes zoals SHA-256 zijn voor wachtwoorden toch een slechte keuze, omdat aanvallers met een gestolen database op grafische kaarten enorme aantallen gissingen per seconde kunnen proberen. Gebruik een functie die voor wachtwoorden is gemaakt, bewust traag en met een willekeurige salt per gebruiker: Argon2id, scrypt of bcrypt, zoals de OWASP-richtlijn voor wachtwoordopslag aanraadt. Bewaart een leverancier of een oude applicatie wachtwoorden versleuteld, of gehasht met alleen MD5 of SHA-1, behandel dat dan als een bevinding om op te lossen. Voor uw eigen medewerkers ligt de grotere winst elders: meerfactorauthenticatie (MFA), een wachtwoordmanager en het blokkeren van hergebruikte wachtwoorden. Een netwerksensor ziet niet hoe een server wachtwoorden opslaat; dat hoort in een applicatiereview.
Een digitale handtekening is een waarde die met een privésleutel uit gegevens wordt berekend en die iedereen met de bijbehorende publieke sleutel kan controleren. Slaagt de controle, dan zijn twee dingen bewezen: de gegevens komen van de houder van die privésleutel, en ze zijn sinds het ondertekenen niet veranderd. Handtekeningen beschermen veel waar u zonder het te merken op vertrouwt: software-updates en drivers, de TLS-certificaten die de identiteit van een website bewijzen, ondertekende pdf's en e-facturen, met S/MIME ondertekende e-mail en de code die uw ontwikkelaars uitbrengen. In de EU hebben gekwalificeerde elektronische handtekeningen volgens de eIDAS-verordening bovendien juridische kracht. Een handtekening is maar zo betrouwbaar als haar privésleutel: wordt die gestolen, dan kan een aanvaller malware ondertekenen die echt lijkt, daarom horen ondertekeningssleutels in hardware security modules of vergelijkbaar beschermde opslag, bruikbaar voor weinig mensen. De huidige handtekeningen gebruiken RSA of elliptische curven, die een grote kwantumcomputer zou breken; hun post-kwantumopvolgers zijn ML-DSA en SLH-DSA.
Een TLS-certificaat is een ondertekend document dat een publieke sleutel aan een naam koppelt, zoals www.example.com, zodat een browser of client kan controleren dat hij met de echte server praat en niet met een bedrieger. De handtekening komt van een certificaatautoriteit (CA) die de client al vertrouwt, meestal via een keten: een root-CA, een tussenliggende CA en dan het certificaat van de server zelf. Tijdens de handshake toont de server zijn certificaat en bewijst hij dat hij de bijbehorende privésleutel heeft. Certificaten hebben een vervaldatum en kunnen worden ingetrokken. Wat een certificaat niet bewijst, is dat de site veilig of eerlijk is: een phishingsite kan een volkomen geldig certificaat hebben, omdat CA's vooral de controle over het domein nagaan, niet het bedrijf erachter. Binnen bedrijven geeft vaak een interne CA certificaten uit voor servers, VPN's en apparaten. Houd een inventaris bij van alle certificaten met eigenaren en vervaldata; vergeten certificaten veroorzaken storingen en verbergen zwakke sleutels.
Clients vertrouwen de server niet meer: browsers tonen een waarschuwing over de hele pagina, en apps, API's, VPN-clients en apparaten weigeren meestal helemaal te verbinden. Voor gebruikers lijkt het een storing, en in de praktijk is het dat ook: betaalpagina's, klantportalen, mailservers en verbindingen tussen machines kunnen op het moment van verlopen stoppen, vaak 's nachts of in het weekend. Verlopen certificaten leren medewerkers ook waarschuwingen weg te klikken, precies wat een aanvaller die verkeer onderschept wil. De oplossing is een proces, geen heldendaad: een inventaris van elk certificaat met eigenaar en vervaldatum, ruim vooraf waarschuwingen en automatische vernieuwing via het ACME-protocol (RFC 8555) waar het platform dat ondersteunt. Vergeet de certificaten in appliances, printers, interne diensten en codeondertekening niet, die externe scanners nooit zien. Zicht op TLS-handshakes in het interne netwerk helpt servers te vinden die niemand had genoteerd, al is bij TLS 1.3 het certificaat zelf versleuteld en moet het op de server worden gecontroleerd.
Omdat een kortere geldigheid de schade van een gestolen sleutel of een ten onrechte uitgegeven certificaat beperkt, en iedereen dwingt het vernieuwen te automatiseren. In april 2025 nam het CA/Browser Forum, het orgaan van certificaatautoriteiten en browsermakers dat de regels voor publieke TLS-certificaten vaststelt, stemming SC-081 aan: de maximale geldigheid daalt van 398 naar 200 dagen vanaf 15 maart 2026, naar 100 dagen vanaf 15 maart 2027 en naar 47 dagen vanaf 15 maart 2029. De regels gelden voor publiek vertrouwde certificaten, niet voor certificaten van uw eigen interne CA. Voor een bedrijf dat certificaten nog eens per jaar met de hand vernieuwt, verandert de werklast: vernieuwingen worden frequent en handmatige processen zullen falen. Het antwoord is automatisering via ACME (RFC 8555) of de tools van uw aanbieder, een inventaris van elk publiek certificaat en waar het is geïnstalleerd, inclusief loadbalancers en appliances, en bewaking van de vervaldata. Zie het als oefening in crypto-agility: dezelfde discipline helpt bij de post-kwantumovergang.
Niet omdat ze zelfondertekend zijn, maar door wat er meestal bij hoort. Een zelfondertekend certificaat versleutelt even goed als elk ander; het probleem is vertrouwen. Clients kunnen het niet controleren tegen een bekende autoriteit, dus gebruikers en beheerders leren waarschuwingen weg te klikken of verificatie in scripts uit te zetten, en diezelfde gewoonte laat een echte onderschepping onopgemerkt. Zelfondertekende certificaten op appliances hebben vaak zwakke of standaardsleutels, geen bewaking van de vervaldatum en geen eigenaar. Beter is een interne certificaatautoriteit die waar mogelijk geautomatiseerd uitgeeft, waarvan de root naar beheerde apparaten is verspreid, met een inventaris van elk certificaat en de vervaldatum. Bij apparaten die alleen met zelfondertekende certificaten komen, zoals printers of besturingen, vervangt u het certificaat waar het apparaat dat toestaat en houdt u het apparaat in een segment met beperkte toegang. Zelfondertekende certificaten horen ook in uw post-kwantuminventaris: elk heeft een sleuteltype en -lengte die ooit moeten veranderen.
Mutual TLS betekent dat beide kanten van een verbinding certificaten tonen: de server bewijst zijn identiteit aan de client en de client aan de server. Bij gewoon HTTPS heeft alleen de server een certificaat en bewijst de gebruiker pas later wie hij is, met een wachtwoord of token. Bij mTLS heeft de client een privésleutel nodig en een certificaat van een autoriteit die de server vertrouwt, wat moeilijk te phishen en makkelijk in te trekken is. Het is gangbaar tussen diensten in een microservicesarchitectuur, voor API's tussen bedrijven, voor apparaatidentiteit in IoT en OT en in sommige zero-trustproducten voor toegang op afstand. De kosten zijn certificaatbeheer op schaal, dus clientcertificaten uitgeven, roteren en intrekken, en problemen oplossen als er iets verloopt. Op het netwerk ziet mTLS eruit als gewoon TLS. In TLS 1.3 is het clientcertificaat versleuteld, dus een passieve sensor ziet dat de verbinding bestaat en de handshakeparameters, niet welk clientcertificaat is gebruikt.
Het versleutelt het verkeer tussen uw apparaat en de VPN-gateway, niet de hele weg naar de bestemming. Achter de gateway gaat het verkeer verder naar het kantoornetwerk of internet, alleen beschermd door wat de applicatie zelf gebruikt, zoals HTTPS. Een bedrijfs-VPN beschermt medewerkers op hotel- of café-wifi dus tegen lokaal afluisteren en geeft toegang tot interne systemen; het maakt een onversleutelde interne applicatie niet veilig en verbergt niets voor het bedrijfsnetwerk dat het verkeer ontvangt. Split tunneling stuurt maar een deel van het verkeer door de VPN en de rest rechtstreeks, wat de prestaties helpt maar betekent dat de monitoring van het bedrijf slechts een deel ziet. Een commerciële VPN-dienst verplaatst uw vertrouwen van de internetprovider naar de VPN-aanbieder. VPN-gateways zelf zijn vaak doelwit en hebben snelle patches en meerfactorauthenticatie (MFA) nodig. Op het netwerk zijn VPN-tunnels zichtbaar als verbindingen met de gateway, met timing en volume, niet met hun inhoud.
Combineer een actieve scan met passieve observatie, want elk vindt wat de ander mist. Een geautoriseerde scan van uw adresbereiken op poort 22 en andere gangbare SSH-poorten, met een tool als Nmap, toont elke host die antwoordt en de softwareversie die hij meldt. Controleer uw cloudconsoles en DNS-records op servers buiten de kantoorbereiken. Passieve observatie voegt toe wat scans missen: SSH op ongebruikelijke poorten, servers die alleen vanuit bepaalde segmenten bereikbaar zijn, en hoe SSH echt wordt gebruikt, dus welke clients wanneer met welke servers verbinden. Loop de lijst daarna door met de eigenaren: elke server heeft een benoemde persoon, een reden van bestaan en een patchschema nodig, en wat niemand opeist, gaat na een aankondigingstermijn uit. Beperk SSH tot beheernetwerken of een jumphost en gebruik sleutels in plaats van wachtwoorden. NetSenX waarschuwt op elk abonnement wanneer een host veel interne hosts begint te benaderen op beheerpoorten zoals SSH, want zo zien scans en laterale beweging eruit.
Begin met de versie die elke server meldt en bevestig die daarna met de patchstatus van de leverancier, want de melding alleen kan misleiden. Elke SSH-server stuurt vóór alles een identificatietekenreeks zoals SSH-2.0-OpenSSH_9.6p1, die een scanner of een eenvoudige verbinding laat zien. Vergelijk die versie met het bereik in het advies. Voor regreSSHion (CVE-2024-6387) noemde het advies dat Qualys op 1 juli 2024 publiceerde bijvoorbeeld OpenSSH vanaf 8.5p1 tot, maar niet met, 9.8p1 op Linux op basis van glibc. Controleer daarna de pakketversie op elke server: Linux-distributies zetten beveiligingsfixes vaak terug in een ouder versienummer, dus een server die een geraakte versie meldt, kan al gepatcht zijn, en de securitytracker van de distributie is leidend. Patch via de pakketbeheerder, herstart de dienst en controleer opnieuw. Houd een lijst van SSH-servers bij in uw inventaris, zodat het volgende advies minuten kost in plaats van dagen.