Wat u moet weten over het gebruik van SSL/TLS om verbindingen van uw e-mailservers te versleutelen

Toen ik
werd benaderd met het onderwerp voor deze blogpost, stemde ik van harte toe. Hier volgt een parafrasering
van hoe het ging:

“Zou je een
post kunnen schrijven over het belang van TLS in e-mailservers?” vroeg Patrick.

“Tuurlijk,” zei ik.

Whew, dat was een waanzinnige
conversatie om te herbeleven! Als een wervelwind!

Toen begon ik er een beetje over na te denken. Zijn er echt email servers die geen encryptie gebruiken voor transit? Ik heb het niet over end-to-end encryptie zoals we die in het verleden hebben gebruikt (S/MIME, PGP, enz.). Ik heb het over versleuteling van server tot server of alles daartussenin om de gegevens langs de route te beschermen.

Zeker, in deze tijd zou niemand zijn inkomende/uitgaande post in klare tekst laten rondgaan en God weet welke route laten afleggen om te worden onderschept en er voordeel uit te halen. Veel mensen gebruiken e-maildiensten en het kan niet zo zijn dat zij doorvoersleuteling van hun dienst zouden uitsluiten. Datalekken kosten hen miljoenen aan
rechtszaken en verlies van zaken en schande…..

Ik ging terug naar Patrick
met een vraag.

“Hebben we statistieken
of informatie over e-mailservers die geen encryptie gebruiken? Ik denk dat het aantal laag zal
zijn. Met andere woorden, wat heeft u ertoe gebracht mij naar dit artikel te vragen?

Patrick antwoordde: “Eigenlijk weet ik dat niet. Ik dacht dat het een goed onderwerp zou zijn gezien het belang
van e-mail en alle aspecten die nodig zijn voor beveiliging.”

OK. Dat klinkt logisch. Er zijn waarschijnlijk e-mailservers die er helemaal geen gebruik van maken, hoewel ongetwijfeld een veel groter percentage verouderde protocollen of verlopen certificaten gebruikt en gewoon een opfrisbeurt nodig heeft.

Dit artikel gaat
over waar we zijn met de e-mail en transit encryptie om ervoor te zorgen dat u
werkt op een optimaal veiligheidsniveau dat beschikbaar is.

Encryptie in Email Servers

Op dit punt hebben we waarschijnlijk een algemeen begrip van hoe TLS werkt, maar laten we het even samenvatten voor het geval u hier nieuw in bent.

Persoon A wil
veilige communicatie verzenden naar Mens B. Persoon A en Mens B hebben een vooraf vastgesteld
certificaat. Persoon A gebruikt het certificaat om de informatie te versleutelen en
stuurt de versleutelde informatie naar Mens B. De informatie is onleesbaar totdat Mens
B het certificaat gebruikt om de versleutelde informatie te ontsleutelen.

Als Mens B met versleutelde informatie
terug wil antwoorden aan Persoon A, dan zou Mens B het
certificaat gebruiken om de gegevens te versleutelen en Persoon A zou het certificaat gebruiken om het bericht
te ontsleutelen.

Dit is in het algemeen hoe
versleutelen/ontsleutelen werkt. Vervang nu de in dit voorbeeld genoemde personen door
servers en andere dergelijke verbindingen. Hetzelfde concept.

Nu als Mens B terug wil antwoorden aan Persoon A met versleutelde informatie, dan gebruikt Mens B de symmetrische sleutel die zojuist is gegenereerd en kunnen zij nu zowel gegevens naar elkaar versleutelen en verzenden, als ontvangen en ontsleutelen.

Dit is in het algemeen hoe versleutelen/decoderen met SSL/TLS werkt. Vervang nu de genoemde personen in dit voorbeeld door servers en andere dergelijke verbindingen. Hetzelfde concept. Dit is hoe TLS werkt met e-mail, wat een beetje anders is dan hoe het een HTTPS verbinding vergemakkelijkt, vanwege het feit dat e-mail andere protocollen gebruikt. Maar er zijn toch een aantal duidelijke overeenkomsten:

• Er vindt een handshake plaats
• Authenticatie vindt plaats (hoewel beide partijen zich in deze context authentiseren)
• Session keys worden gebruikt om de stroom emails over te brengen.

Ebb and (Mail) Flow

De volgende stap in dit
“begrijpen waarom” artikel is het “begrijpen hoe” gedeelte.

In het kort: een e-mail client stuurt een e-mail naar de uitgaande server. De uitgaande server doet een DNS look up, op basis van de bestemming e-maildomein, en dat DNS MX record zal bepalen welke server om de e-mail te sturen naar en, eventueel, die server zal bepalen of moet worden doorgestuurd op totdat het de bestemming inbox Mail Delivery Agent (MDA).

Het is niet genoeg om DNS MX records te
vertrouwen, dat is een heel andere vertrouwenskwestie, maar de SMTP
(mail die uitgaat, MTA, etc) server en de mail die binnenkomt (via POP3, IMAP,
Exchange) moeten elkaar kunnen identificeren en de juiste sleutels hebben om met elkaar te
communiceren. En, afhankelijk van de route, kan er meer
dan slechts één-ishop email server communicatie zijn. Mail Exchangers, proxy
servers en andere zouden op hun plaats kunnen zijn langs de route. Elke hop (zou moeten) vragen om een
versleutelde link. Vaak is dat ook zo. Soms ook niet. Gebruikers zouden
het liefst zien dat gevoelige informatie onderweg wordt versleuteld. End-to-End encryptie
helpt ervoor te zorgen dat er een soort van encryptie is over de hele weg, maar
lagen van veiligheid zijn altijd, uh, beter.

Respect Thy Securi-Tie

Voor de goede orde,
Securi-Tie is geen echt woord. Ik heb dat woord alleen verzonnen omdat het rijmde. Het is een afleiding van het woord veiligheid.

Om een soort springplank
van de vorige sectie te maken, moeten we het hebben over beveiligingsopties die, hoewel
ze van de client kant worden ingesteld, eigenlijk een aantal instructies
aan de mail server kant geven voor beveiligingsgerelateerde doeleinden.

Bij het configureren van een
email client (Outlook, Thunderbird, etc), is de standaard
configuratie onversleuteld. Maar, zoals het punt is van dit artikel, willen we meestal
voor de versleutelde optie gaan. In zekere zin is het niet helemaal aan de client: het
hangt af van wat de server kan ondersteunen. Ervan uitgaande dat uw inkomende
en uitgaande servers encryptie kunnen ondersteunen, waarom zou u dat niet doen? Als u in een restaurant biefstuk
bestelt en ze bieden u voor dezelfde prijs sirloin of Kobe(wagyu) ribeye
aan, waarom zou u dan niet het vlees van de betere kwaliteit bestellen?

Dus, als u
TLS/SSL op uw e-mail wilt gebruiken (dit is voor het transit gedeelte en niet het end-to-end,
S/MIME gedeelte dat in andere blog posts wordt besproken), zet het aan. Gebruik poorten 465
of 587 voor SMTP (‘member, outbound mail) en 993 (IMAP) of 995 (POP3) voor
inkomend verkeer.

Er is een
interessant encryptieprotocol dat nog steeds onder e-mailservers wordt gebruikt. Het
heeft zijn goede en slechte kanten zoals dat met de meeste dingen het geval is. Uiteindelijk zou ik zeggen dat
de bedoelingen goed zijn, maar dat de toepassing in de praktijk niet zo ideaal is als
zou kunnen. Dames en heren, dat protocol is STARTTLS.

STARTTLS is een beveiligings
protocol dat in feite SSL/TLS is. Simpel gezegd neemt STARTTLS een
bestaande onversleutelde en dus onveilige verbinding, en probeert
deze om te zetten in een veilige verbinding met behulp van TLS (of SSL). Dus, het veiligheidsniveau van
STARTTLS vs SSL/TLS is eigenlijk niet verschillend. Als alles goed is ingesteld, zullen ze
allebei informatie met TLS (of SSL) versleutelen.

Het belangrijkste verschil is
gebaseerd op de toestand van een verbinding en/of het initiëren van communicatie. STARTTLS
garandeert geen versleutelde communicatie. Het betekent in feite, “als de
verbinding onversleuteld is en je bent in staat om, maak er een veilige
verbinding van. Als het verbindingsknooppunt (waarschijnlijk een server) niet in staat is om de
verbinding in een versleutelde verbinding om te zetten, kan het aan de client-end zijn om
te beslissen hoe het vanaf dat punt moet worden afgehandeld.

Hoewel ik de
kwalificatie van STARTTLS als “nuttig” gebruikte, zou het als minder veilig kunnen worden beschouwd
dan het selecteren van SSL/TLS. Standaard SSL/TLS selectie is in feite, “Gebruik
encryptie of ga failliet.” STARTTLS zegt, “Eh, als u het zou kunnen, doe het dan alstublieft. Zo niet, kunnen we verder gaan op basis van andere instructies.”

Hier zijn wat concluderende verklaringen

Vaak moet het voor de hand liggende worden gezegd en misschien
overdreven worden. Dus hier is het, ahem: Gebruik encryptie. Vooral voor iets dat
zo belangrijk is, zo cruciaal en geïntegreerd in schijnbaar de overgrote meerderheid van
elke organisatiestructuur die informatie kan dragen die maakt of breekt. Er hoeft niet veel moeite in gestoken te worden. Gebruik zowel end-to-end als in-transit
encryptie. Twee is beter dan één.

Als iemand vindt dat de extra moeite om een e-mail
server versleuteld versus onversleuteld in te stellen het niet waard is, dan is die
iemand het niet waard. Dit is gewoon een overdrijving van het voor de hand liggende. End-to-end encryptie, zoals S/MIME, vergt een
meer ingewikkelde aanpak, maar het is ook de moeite waard als je lagen en lagen
beveiliging toevoegt. Maar er is geen excuus om niet de tijd te nemen om
veilige verbindingen op te zetten en te onderhouden.

Wanneer het zicht het toelaat, moet elk e-mailpad dat niet veilig of gecompromitteerd lijkt, onder de loep worden genomen. En daarmee, wees blij met je onderzoek naar een veiliger internet. Proost!

*** Dit is een Security Bloggers Network syndicated blog van Hashed Out door The SSL Store™ geschreven door Ross Thomas. Lees de originele post op: https://www.thesslstore.com/blog/encryption-and-email-servers/