Als je mij mail wil sturen op mijn eigen domein zonder STARTTLS zal dat niet gaan. Je hebt 20 jaar de tijd gehad om het te regelen. Als je nu nog niet STARTTLS gebruikt hoef ik je niet naar je te luisteren.

STARTTLS verplichten is eenvouding te doen in Exim:

Veel plezier in je bubble. ;-)

Het probleem is dat STARTTLS alleen niet voldoende is. Als dat het probleem was, dan hadden we het probleem eenvoudig kunnen oplossen: prik een 'flag day' waarna iedereen STARTTLS gebruikt of mails worden niet meer geaccepteerd. Helaas is er nergens vastgelegd wélk certificaat er gecontroleerd moet worden. Verwacht je de naam van de mailserver? Want dan ben je vatbaar voor DNS aanvallen. Verwacht je de domainnaam van het domein mailadres? Dan krijg je problemen met providers die op grote schaal certificaten moeten aanvragen voor klanten. In de configuratie die je voorstelt is dit niet opgelost, waardoor een MITM altijd mogelijk blijft. Uiteindelijk zijn het de DANE en MTA-STS standaard die wel vastleggen welk certificaat er verwacht moet worden, maar beiden zijn niet zonder problemen uit te rollen.

Volgens mij moeten we gewoon tot de conclusie komen dat email nooit zo veilig zal worden als het zou moeten zijn. Op termijn moeten we collectief overstappen op decentrale chat applicaties, waarin E2EE wel goed geregeld is.

Welke decentrale chat app denk jij aan waar wij kunnen gaan emailen?

Ik heb zelf postfix gecompileerd omdat de distro's een oude versie leveren zonder SNI.
Ook mekkert mijn rspamd dat sommige ontvangen berichten nog steeds geen TLS gebruiken bij ontvangst.
Het duurt dus nog wel even voordat de wereld functioneert...

Die bestaat niet, vooral omdat er geen algemene standaard is voor E2EE in chat applicaties. Er wordt wel gewerkt aan standaardisatie van MLS binnen de IETF, maar dat betekend niet dat de uiteindelijke systemen ook decentraal/federated kunnen werken, zoals email wel kan. Zelf heb ik de meeste hoop gevestigd op Riot/Matrix en/of Wire, maar het lijkt er op dat centrale oplossingen in de vorm van Microsoft Teams het 'nieuwe normaal' gaan worden. Dat terwijl het noch veilig (E2EE) noch decentraal is. Met daarbij gevaar voor een monocultuur, afhankelijkheid van en aftapbaarheid door niet-Europeese organisaties (hoewel je terecht ka beargumenteren dat dit nu al bij email ook speelt, kijkend naar Microsoft en Google).

Welke problemen zijn daar dan mee? Ik heb hier zonder problemen DANE en MTA-STS kunnen implementeren.

Ja dat kun je prima doen als autist op je zolderkamer maar bij normaal gebruik is dat toch niet zo'n succes.
Een snelle grep in mijn logs laat bijvoorbeeld zien dat KPN uitgaand nog geen STARTTLS doet (inkomend wordt
het wel geaccepteerd).
Nou zul jij vast niks missen aan mail van mensen die een account bij een van de KPN providers hebben, maar ik ga die
nog maar even niet afsluiten.

Received: from cpsmtpb-ews09.kpnxchange.com (cpsmtpb-ews09.kpnxchange.com [213.75.39.14]) by XXXXX with ESMTP id 1587585828-27165-1 for <XXXXXX>; Wed, 22 Apr 2020 22:03:52 CEST

Dat valt wel mee in de praktijk. De enige mail die hierdoor wordt geweigerd is spam en idiote AUTH aanvalspogingen terwijl AUTH niet geadverteerd is. De rest - de mail die je wel wilt - gebruikt STARTTLS. Als er iemand probeert mail te sturen zonder encryptie krijgt die de melding te zien dat TLS benodigd is.

De oude manier om mail te sturen vanaf de command line werkt nog wel, mits je daar openssl of iets dergelijks voor gebruikt.

@ Gisteren, 18:15 door iatomory
Het klopt dat STARTTLS op zich geen volledige oplossing is, maar het is wel een eerste stap. Ik gebruik natuurlijk ook DNSSEC, CAA en DANE. CAA pint de CA (Certificate Authority) vast, DANE pint het certifcaat zelf vast en DNSSEC zorgt voor de beveiliging van DNS. Dat is voldoende veilig.

DANE controles worden nog weinig gebruikt. Het aantal domeinen dat DANE ueberhaupt toepast is laag en het is niet erg makkelijk configureerbaar. Als Let's encrypt wordt gebruikt heb je ~4 keer per jaar kans dat DNS niet up to date is. Als DNS wel automatisch up to date is, dan verzwakt dat DANE zelf enigszins. Je kan een hash maken tegen een hoger liggend certificaat. Vandaar dat CAA niet overbodig is.

Partijen als Google en Microsoft hebben nog wat in te halen met DNSSEC. Al hun mail kan worden onderschept via MitM.

Daar zeg je nogal wat! Ja, ik was al een beetje op de hoede om deze vraag te stellen. Of de IETF het juiste antwoord is dat weet ik niet, vooral sinds het geklooi met HTTP/2. En natuurlijk gaan partijen zoals MS ermee vandoor. Trouwens, een monocultuur daar is volgens mij weinig mis mee, mits het geheel (F)OSS is, een goed testprogramma heeft en geschreven is in een fatsoenlijke taal.

(Ik ben iatomory, meer even niet ingelogd). Zoals Anoniem 04:32 schrijft is STARTTLS geen volledige oplossing. Laten we daarbij niet vergeten dat het passief afluisteren aan de orde van de dag is, in tegenstelling tot het uitvoeren van een MiTM aanval. Vanuit dat perspectief bied het gebruik van STARTTLS zonder validatie wel degelijk een meerwaarde, ik wil dus ook zeker niet stellen dat zonder validatie het helemaal geen nut heeft: het afdwingen van versleuteling alleen bied wel degelijk meer beveiliging dan zonder.

CAA speelt alleen een rol bij certificaat uitgifte, niet meer als een certificaat al in gebruik is. Een rogue CA aanval kan er dus niet mee voorkomen worden. Je kan daarom niet spreken van 'CA pinning' zoals dat bij DANE en het niet meer gebruikte HPKP wel kan.

Zoals je zelf schrijft is dit is de kern van het probleem: er zijn te weinig partijen die validatie (goed) uitvoeren op uitgaande mail. Je kunt zelf nog zoveel DANE records aanmaken, uiteindelijk moet de verzendende partij deze wel valideren. Er is nergens afgesproken dat we met zijn allen DANE gaan gebruiken, sterker nog Google en andere grote mail providers zijn hier op tegen en hebben daarom hun eigen MTA-STS standaard in het leven geroepen. Door de wildgroei aan standaarden is het verre van gemeengoed dat als je zelf DANE en/of MTA-STS insteld er ook gebruik van gemaakt wordt.

@Anoniem 20:46 Dat is mij ook wel gelukt voor de inkomende mails, uitgaande mails ligt bij mijn mailprovider (die daar DANE voor gebruiken). De problemen waar ik aan denk zijn:
0) Met betrekking tot inkomende mail is het noodzakelijk de DANE records op een juiste manier te vernieuwen, hiervoor is echter een handje vol tools beschikbaar en vaak vereisen deze veel toestemming tot de API van je DNS provider om hun werk te doen. Ik mis dus tools en goede API's om dit te doen (althans, de laatste keer dat ik hier naar keek)
1) Gebrek aan ondersteuning in mail software voor het ophalen van de MTA-STS policy bij uitgaande mails, in mijn logs komt alleen Google elke 12 uur langs
2) Gebrek aan validatie van DANE records in de mail software, alles hangt af van DNSSEC validatie door een DNS server. Certificaat validatie overlaten aan een willekeurige server in je netwerk, die vaak ook nog eens over een onbeveiligde verbinding wordt gecontacteerd, is NIET het juiste security model. Als je van DNSSEC afhankelijk bent moet je ook zelf deze valideren.
3) Geen security-by-default doordat alles afhangt van extra configuratie die je zelf moet instellen om gebruik te maken van MTA-STS en/of DANE op uitgaande mails, met de huidige opzet gaat het nooit lukken om iedereen over te krijgen naar 'veilige' email verbindingen

Graag een positieve bijdrage s.v.p. en geen rotzooi inzenden.

Kun je dat onderbouwen met hard bewijs of is dat alleen maar het bekende tendentieuze geleuter wat we zo goed kennen
van deze site?

Zowel Google als Microsoft hebben geen MTA-STS TXT records op hun domeinen google.com, gmail.com, microsoft.com, outlook.com.

Het is ESMTP, en STARTTLS is een ESMTP extensie. Deze server heeft geen open poort 25. Ontvang je dit op een KPN account?

Zijn er nog mensen die verzenders zien die geen STARTTLS ondersteunen? (exclusief spam)

Jawel hoor:
https://mta-sts.gmail.com/.well-known/mta-sts.txt
https://mta-sts.outlook.com/.well-known/mta-sts.txt
https://mta-sts.google.com/.well-known/mta-sts.txt
Voor Microsoft.com kon hem interdaad niet vinden.

Zie https://en.wikipedia.org/wiki/Global_surveillance en specifieke programmas zoals https://en.wikipedia.org/wiki/XKeyscore.

Dat zijn geen TXT records, maar je hebt verder wel gelijk, ik keek niet goed.

Wat betreft het eerder genoemde MTA-STS, dat stelt weinig voor en het vormt geen beveliging tegen geavanceerde MitM aanvallen. Het is zeker geen alternatief voor DNSSEC en ook niet voor DANE. Het lijkt meer op SPF met een web server component.

Als ze zoiets voorstellen lijkt mij dat een poging te zijn om waarschuwingen te verzamelen van de simpelere email gebaseerde aanvallen. Misschien omdat er iemand in een regenjas zegt dat ze geen DNSSEC en DANE mogen gebruiken? Nou zie ik wel meer domme dingen gebeuren bij de grote partijen waar zogenaamd de allerslimsten onder ons mogen werken, maar zo dom kan niemand zijn. Misschien ben ik te optimistisch.

@Anoniem 19:37
Afgezien van het Trust-on-First-Use probleem van MTA-STS, bied het - net als DANE - bescherming tegen MitM aanvallen. In tegenstelling tot DANE wordt er niet verwezen naar specifieke public keys, maar naar de servernaam die in het certificaat moet staan. Dat certificaat moet binnen het WebPKI uitgegeven zijn, waarmee de verbinding geauthenticeerd is. De beveiliging van TLS is daarmee niet meer gestoeld op die van DNS(SEC), los van de certificaat uitgifte, en daarmee een goed alternatief voor DANE.

De reden dat deze partijen niet aan DNSSEC, en daarmee DANE, willen beginnen is omdat er meer vertrouwen is in het WebPKI dan in DNSSEC waar DANE op bouwt. Dat lijkt wat tegenstrijdig als je bedenkt dat je afhankelijk bent van een honderd tal CA's, maar heeft vooral te maken met de hogere beveiligingseisen van de certificaten en Certificate Transparancy. DNSSEC staat al jaren bekend om de acceptatie van matig ondertekende sleutels, nog steeds, waar niemand iets aan wil doen. Het is dus niet zo zeer dat er domme beslissingen genomen worden, men heeft gewoon geen vertrouwen in DNSSEC.

Die server kun je als MitM ook onderscheppen, net als alle verkeer, inclusief DNS en webverkeer. Je kan als aanvaller certificaten aanvragen. Het is dus een complicatie, maar geen beveiliging.

DANE (en dus DNSSEC) kun je niet vergelijken met MTA-STS qua veiligheid.

Volgens Google ondersteunt 91% van de ontvangende mail servers in Europa (inclusief Rusland) STARTTLS:
https://transparencyreport.google.com/safer-email/overviewp

En 92% van de binnenkomende mail.

Aangezien veel van die mail waarschijnlijk niet-persoonlijke mail is zoals amateuristische massa mailings, denk ik dat je ondertussen wel plain text email kunt blokkeren. Als niemand daarmee begint wordt het niet beter.