Waarom TLS Mogelijk Niet Voldoende Is Voor Uw E-mail Encryptiestrategie

Het digitale tijdperk heeft niet alleen ons dagelijks leven, maar ook de manier waarop bedrijven opereren, ingrijpend veranderd. Bedrijven hebben tegenwoordig veel meer interactie met hun klanten en cliënten. Deze organisaties beschikken ook over veel meer data om hun bedrijf beter te begrijpen. Deze data stelt bedrijven in staat om inefficiënties te dichten, groeikansen te identificeren en hun klanten beter van dienst te zijn.

Deze data is, niet verrassend, ontzettend waardevol. Het beschermen ervan is daarom cruciaal geworden voor het voortbestaan van een bedrijf in een zeer competitieve markt. Wanneer organisaties hun persoonlijk identificeerbare informatie (PII), beschermde gezondheidsinformatie (PHI), intellectueel eigendom (IP) of andere vertrouwelijke informatie beschermen, waarborgen ze de continuïteit van hun bedrijf, tonen ze aan te voldoen aan wetgeving rondom gegevensbescherming en behouden ze hun reputatie.

Bedrijven moeten hun gevoelige informatie beschermen, of deze nu is opgeslagen op servers of wordt gedeeld via e-mail of een ander communicatiekanaal. Transportlaagbeveiliging (TLS) is een belangrijk onderdeel geworden van de e-mailbeveiligingsstrategie van elke organisatie, zeker nu zij moeten voldoen aan regelgeving zoals de Payment Card Industry Data Security Standard (PCI DSS), de Health Insurance Portability and Accountability Act (HIPAA) en de Algemene Verordening Gegevensbescherming (GDPR) van de Europese Unie.

Het inschakelen van TLS garandeert echter niet dat je e-mails veilig zijn voor nieuwsgierige ogen. Sterker nog, veel organisaties gebruiken TLS nog steeds op de verkeerde manier, waardoor hun e-mails kwetsbaar blijven voor ongeautoriseerde toegang en datalekken.

Hoe werkt TLS?

Om een website of applicatie TLS te laten gebruiken, moet er een TLS-certificaat zijn geïnstalleerd. Een TLS-certificaat wordt uitgegeven aan de persoon of het bedrijf dat eigenaar is van een domein. Het certificaat bevat belangrijke informatie over wie het domein bezit en de publieke sleutel van de server, die beide essentieel zijn voor het valideren van de identiteit van de server.

Een TLS-verbinding wordt gestart via een proces dat de TLS-handshake wordt genoemd. Telkens wanneer iemand een website bezoekt die TLS gebruikt, begint de TLS-handshake tussen het apparaat van de gebruiker (ook wel het clientapparaat genoemd) en de webserver.

Tijdens de TLS-handshake doen het apparaat van de gebruiker en de webserver het volgende:

• Specifiëren welke versie van TLS (TLS 1.0, 1.2, 1.3, enz.) wordt gebruikt,
• Bepalen welke cipher suites worden gebruikt,
• De identiteit van de server verifiëren met behulp van het TLS-certificaat van de server, en
• Sessiesleutels genereren voor het versleutelen van berichten tussen het apparaat van de gebruiker en de webserver nadat de handshake is voltooid.

Wat is een Certificate Authority (CA)?

Een Certificate Authority (CA) is een organisatie die de identiteit van entiteiten (zoals websites, e-mailadressen, bedrijven of individuen) valideert en deze koppelt aan cryptografische sleutels door elektronische documenten, digitale certificaten genoemd, uit te geven.

Een digitaal certificaat biedt het volgende:

• Authenticatie—dient als bewijs om de identiteit te valideren van de entiteit aan wie het is uitgegeven.
• Encryptie—voor veilige communicatie over onveilige netwerken.
• De integriteit van documenten die met het certificaat zijn ondertekend, zodat een derde partij deze onderweg niet kan wijzigen.

Wat is het verschil tussen TLS en SSL?

TLS is voortgekomen uit een eerder encryptieprotocol genaamd secure sockets layer (SSL), ontwikkeld door Netscape. TLS versie 1.0 begon als de ontwikkeling van SSL versie 3.1, maar de naam van het protocol werd vóór publicatie gewijzigd om aan te geven dat het niet langer aan Netscape was verbonden. Hierdoor worden TLS en SSL soms door elkaar gebruikt.

Mogelijke kwetsbaarheden van TLS

Hoewel TLS en SSL ongetwijfeld een essentiële basis vormen voor de aanpak van gegevensbeveiliging binnen een bedrijf, bevatten ze toch kwetsbaarheden.

De belangrijkste zwakte ontstaat door het gebrek aan kennis bij bedrijven over e-mailencryptie; velen denken dat het transportkanaal, en dus de e-mail, volledig beveiligd is zodra TLS wordt gebruikt.

Bedrijven moeten zich echter realiseren dat e-mailberichten tussen de e-mailservers van de verzender en ontvanger reizen, via een kanaal dat ook buiten hun netwerk loopt. Een e-mail is slechts beschermd tot de volgende mail-hop, en er is geen controle over wat er gebeurt zodra het bericht het volgende Simple Mail Transfer Protocol (SMTP) punt bereikt.

Een vertrouwelijk bericht kan dus binnen het netwerk van het bedrijf worden blootgesteld, omdat TLS geen end-to-end encryptie biedt. TLS beveiligt alleen het kanaal van het apparaat van de verzender tot de zakelijke mailserver. Maar e-mails worden vaak via extra servers doorgestuurd, waar encryptie niet gegarandeerd kan worden.

Bijvoorbeeld, bij antiviruscontroles en inhoudscans kunnen gegevens onderweg worden blootgesteld aan nieuwsgierige beheerders of andere medewerkers.

Een ander beveiligingsrisico schuilt in de gebruikte X.509-certificaten. Veel bedrijven valideren hun certificaten niet, waardoor al hun gevoelige data wordt blootgesteld.

Bedrijven moeten ervoor zorgen dat certificaten zijn uitgegeven door een betrouwbare en gerenommeerde Certificate Authority (CA). Dit is allesbehalve triviaal, want veel bedrijven ondertekenen hun certificaten zelf.

Bedrijven moeten ook controleren of certificaten geldig zijn en of encryptie-algoritmen en sleutellengtes actueel zijn (lees: state-of-the-art).

Veel bedrijven, vooral die OpenSSL gebruiken, maken hun eigen certificaten aan, omdat dit handig en goedkoper is dan certificaten van een officiële CA. Ja, certificaten kosten geld. Ze moeten worden aangeschaft en vernieuwd. Als bedrijven vergeten te verlengen, wordt het certificaat uiteindelijk ingetrokken en moeten ze opnieuw betalen aan de CA voor een nieuw certificaat.

Bedrijven zijn zich er vaak ook niet van bewust dat als ze een verkeerde TLS-versie gebruiken die geen “perfect forward secrecy” biedt, berichten kunnen worden ontsleuteld door onbevoegde personen die de sleutels weten te achterhalen.

Een andere bekende beperking van TLS is de “optionele TLS”-systeemconfiguratie. Bij “verplichte TLS” zal het verzendende systeem een e-mailbericht alleen overdragen als het volgende systeem in de keten TLS ondersteunt; het bericht wordt niet overgedragen als dat systeem geen TLS ondersteunt. Als een systeem echter “optionele TLS” gebruikt, wordt het bericht toch verzonden, waardoor het kanaal niet is versleuteld en het bericht wordt blootgesteld.

Hier zijn nog enkele extra redenen waarom TLS mogelijk onvoldoende is om je e-mailcommunicatie te beveiligen.

TLS beschermt e-mails tegen sommige, maar niet alle, soorten aanvallen

TLS alleen is niet voldoende voor e-mailbeveiliging, omdat het slechts tegen bepaalde vormen van e-mailaanvallen beschermt. TLS is met name effectief tegen man-in-the-middle- en afluisteraanvallen die plaatsvinden terwijl data onderweg is. Als je gevoelige informatie op je servers of databases hebt opgeslagen, moet je een extra encryptieprotocol gebruiken zoals Pretty Good Privacy (PGP) of Secure/Multipurpose Internet Mail Extensions (S/MIME).

Deze encryptieprotocollen zorgen ervoor dat als een hacker toegang krijgt tot de server, hij de versleutelde data niet kan lezen. En omdat deze protocollen niet afhankelijk zijn van het verzenden van platte tekst via het netwerk, zijn ze minder gevoelig voor verkeersanalyse en andere side-channel aanvallen die versleutelde communicatie monitoren.

TLS kan kwetsbaar zijn voor downgrade-aanvallen

TLS wordt meestal gebruikt om verbindingen tussen je computer en een server te beveiligen, bijvoorbeeld wanneer je via een browser inlogt op je e-mail. Maar het kan ook worden gebruikt voor andere verbindingen, zoals het versturen van e-mails van de ene server naar de andere.

Het probleem met deze aanpak is dat de volledige verbinding niet is versleuteld. Alleen de data tussen de verzendende en ontvangende servers is versleuteld—en die servers hebben mogelijk geen sterke beveiliging. Een downgrade-aanval kan het verkeer op een niet-versleutelde verbinding onderscheppen en berichten lezen terwijl ze worden verzonden. Tenzij je end-to-end-encryptie gebruikt, loop je het risico dat je data en je organisatie gevaar lopen.

TLS heeft een sterkere handshake nodig

TLS is het meest gebruikte encryptieprotocol van dit moment, maar het heeft nog steeds beperkingen. Om te zorgen dat de e-mail van je bedrijf vanaf het begin veilig en versleuteld is, gebruik je STARTTLS met encryptie-algoritmen zoals PGP of S/MIME.

Op deze manier, zelfs als iemand je e-mails onderweg onderschept, kunnen ze deze niet lezen zonder je privésleutel. Het maakt het ook moeilijker voor een man-in-the-middle-aanval om plaats te vinden, doordat er een extra encryptielaag bovenop de initiële TLS-handshake zit.

Als je vertrouwelijke informatie veilig moet versturen, overweeg dan een extra beschermingslaag toe te voegen door je e-mail te versleutelen via een externe dienstverlener.

Kiteworks voor end-to-end beveiliging en encryptie

Kiteworks is meer dan alleen een beveiligde e-mailprovider. Het fungeert als een Private Content Network (PCN) voor governance, compliance en beveiliging rond het verzenden en ontvangen van gevoelige content binnen, door en buiten een organisatie.

Kiteworks biedt encryptie op ondernemingsniveau en uniforme beveiligingscontroles via een e-mail encryptiegateway en een Microsoft Outlook-plugin, webapplicatie, plugin voor bedrijfsapplicaties of mobiele applicatie. Daarnaast levert het geautomatiseerde beleidsregels op basis van rollen om de beveiliging en compliance van de meest gevoelige informatie van een organisatie te waarborgen.

Plan een gepersonaliseerde demo om te ontdekken hoe Kiteworks het verzenden en ontvangen van e-mails met vertrouwelijke informatie automatiseert, ongeacht de gebruikte encryptiestandaard.