SMTP Strict Transport Security
Sinds dit jaar heeft o.a. google een nieuwe ontwerp voor een standaard voor: SMTP Strict Transport Security. De beveiliging van SMTP is momenteel nog niet goed doordat bij het gebruikte STARTTLS het opzetten van een SMTP sessie tussen twee mailservers(MTA) en van een client(MUA) naar een mailserver(MTA) bijna altijd opportunistische encryptie(ongeldig of ongevalideerd certificaat) en/of onversleutelde verbindingen toelaat. Dit komt vooral vanwege de noodzakelijke compatibiliteit met andere mailservers(MTA) en misgeconfigreerde mail clienten(MUA). (Zorg ervoor dat je poort 587/submission met STARTTLS gebruikt en niet poort 25 voor e-mail verzending gebruikt). Wat betreft de communicatie tussen mailservers over poort 25 is de harde keuze is er alleen de keuze voor wel of geen e-mail uitwisselen als de verbinding alleen onveilig(bij geen STARTTLS ondersteuning) opgezet kan worden.
Er bestaat al enige jaren de HTTP Strict Transport Security header. Deze HTTP header wordt gezet na het opzetten van een veilige HTTPS connectie en zorgt ervoor de webbrowser voor een lange tijd onthoudt om alleen veilig verbindingen te maken met die website. Op die manier zal er bij terugkomst op de website nooit een downgrade van een veilige verbinding naar een onveilige verbinding kunnen plaatsvinden. De HTTP header wordt echter wel na een veilige HTTPS sessie gezet. Bij SMTP STARTTLS is dit niet mogelijk omdat de verbinding begint met een onveilige SMTP verbinding om te onderhandelen of dat encryptie gebruikt gaat worden. Nu maakt SMTP strict transport security gebruik van een TXT DNS record om het SMTP Strict Transport Security beleid te vinden op een subdomain _mta_sts.
Een mailserver die een e-mail naar een andere mailserver gaat versturen moet immer toch al via DNS het ip adres van de mailserver om mee te verbinden opzoeken. Maar omdat DNS onveilig is als er geen DNSsec gebruikt wordt moet dit DNS record weer gevalideerd worden met een JSON beleid over HTTPS. Want wanneer er geen DNSsec gebruikt op het domain moet nu het hele HTTPS protocol gebruikt gaan worden om de authenticiteit en integriteit van een SMTP Strict Transport Security DNS record te kunnen garenderen. Het SMTP Strict Transport Security lijkt me momenteel zonder DNSsec nog niet eenvoudig te implementeren wat het gebruik en de adoptie ervan voorlopig in de weg kan zitten. Wat jammer is want DNSsec en vooral DANE wordt nog steeds vaak niet ondersteund. Voorlopig blijft daarom e-mail verkeer tussen mail servers bijna altijd niet volledig veilig beveiligd.
D9ping