Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

EFF-initiatief wil adoptie van e-mailbeveiliging via starttls vergroten

De Amerikaanse burgerrechtenorganisatie Electronic Frontier Foundation heeft het project Starttls Everywhere aangekondigd. Dat is gericht op beheerders van e-mailservers, die met behulp van bijbehorende tools starttls kunnen configureren, zodat e-mails tussen servers zijn versleuteld.

In een aankondiging van het initiatief stelt de EFF voorop dat de adoptie van starttls inmiddels op 89 procent zit, vergeleken met 39 procent vijf jaar geleden. Dat zou niet wegnemen dat er problemen zijn met de techniek, die verkeer tussen mailservers over een versleutelde verbinding laat verlopen. Er is dus geen sprake van end-to-endencryptie. Het eerste probleem is volgens de organisatie dat vrijwel niemand certificaten controleert, wat er weer toe leidt dat weinig certificaten worden aangeboden. Daardoor kan een actieve aanvaller bijvoorbeeld nog steeds verkeer onderscheppen.

Het tweede probleem is dat zelfs als gebruik wordt gemaakt van een geldig certificaat, het nog steeds mogelijk is om een downgrade-aanval uit te voeren. Starttls zorgt er namelijk voor dat twee servers overeenkomen een beveiligde tls-verbinding te gebruiken, maar die eerste 'afspraak' verloopt onversleuteld, aldus de EFF. Daardoor kan een aanvaller het doen voorkomen dat geen van beide servers ondersteuning biedt voor starttls. De organisatie bespreekt de technieken DANE en MTA-STS, die hiervoor een oplossing moeten bieden, maar komt tot de conclusie dat die niet toereikend zijn. Zo kan DANE worden gebruikt om aan te geven dat een bepaald domein versleutelde verbindingen ondersteunt, maar dat is afhankelijk van dnssec, dat weer een laag adoptiepercentage kent.

De EFF wil deze problemen aanpakken met zijn Starttls Everywhere-project. Een eerste stap is dat Postfix-beheerders gebruik kunnen maken van een Certbot-plug-in om geldige certificaten voor hun mailserver te genereren. Sommigen zullen Certbot kennen van Let's Encrypt, waar de EFF eveneens bij is betrokken. Plug-ins voor Dovecot en Sendmail zijn nog in ontwikkeling. Vervolgens wil de organisatie downgrade-aanvallen aanpakken door een zogenaamde policy list te hosten, waar mailservers op staan die starttls gebruiken. Beheerders kunnen hun server aan de lijst toevoegen via de site van het project; organisaties als Gmail en Outlook staan er al op. Op de site kunnen gebruikers ook hun e-maildomein op veiligheid controleren.

Door Sander van Voorst

Nieuwsredacteur

26-06-2018 • 10:32

30 Linkedin Google+

Reacties (30)

Wijzig sortering
Dit is een goed begin. Maar het zou beter zijn moesten alle Mail User Agents standaard een PGP configuratie aanbieden aan de gebruiker en standaard alle E-mails encrypteren met PGP.

Daarna zouden alle Mail User Agents standaard, net zoals browsers voor HTTPS zijn beginnen doen de laatste jaren, moeten tonen dat een E-mail niet betrouwbaar is omdat hij niet met PGP geencrypteerd is.

Het is te eenvoudig om een SMTPS te downgraden naar SMTP: vrijwel alle SMTP servers zullen in plain-text communiceren van zodra de STARTLS capability verdwijnt. M.a.w. moet een MiTM tussen twee SMTP servers (wat je toch al moet zijn om E-mails te onderscheppen) op SMTP protocol enkel maar CAPA onderscheppen (wat moet gebeuren voor de STARTLS uitgevoerd wordt) en die TLS capability token uit het resultaat knippen. De andere kant zal niet beter weten en de connectie downgraden naar plain text.

Er zijn te veel SMTP servers die niet meer zouden functioneren moest niemand nog plain-text accepteren. Dus niemand zal zijn SMTP server zo instellen dat hij enkel nog TLS connecties aangaat.

M.a.w. moet de Mail User Agent voor de beveiliging zorgen. Dat doen we met PGP.

Moesten alle Mail User Agents vijandig gaan doen voor niet met PGP ondertekende en/of geŽncrypteerde E-mails, dan zou vrijwel alle spam ook meteen daar onder vallen. Want iedere E-mail die gestuurd moet worden, moet met de public key van de tegenpartij geŽncrypteerd worden en/of met de private key van de verstuurder ondertekend worden. Een spammer zijn signature zou dus meteen geblokkeerd kunnen worden. En de spammer moet jouw public key gaan bijhouden. Krijg je te veel spam? Dan verander je je private/public key en publiceer je naar je E-mail vriendjes je nieuwe public key.

Daarna kan de spammer geen E-mails meer naar je versturen (die niet vijandig zouden behandeld worden door je Mail User Agent).

Eigenlijk is PGP dus het antwoord op E-mail beveiliging. Het zou bv. door overheden en instellingen kunnen gebruikt worden om bv. ook aangetekende zendingen te versturen.

PGP is een MUA to MUA probleem. Moest het IETF gewoon zeggen dat vanaf nu in de nieuwe versie van MIME het gebruik van PGP verplicht is en dat een MUA verplicht is om fout opgestelde E-mails te negeren of zeer vijandig te behandelen (dikke vette waarschuwingen, offline openen, geen HTML rendering, en zo verder) .. dan is het probleem over een paar jaar opgelost.

Maarja. Outlook he. Eigenlijk zou Outlook gewoon door bv. de EU en/of het IETF moeten verplicht worden het zo te implementeren (met dus PGP, en die dikke vette waarschuwingen, e.d.). Een paar maanden na die nieuwe versie van Outlook zou het E-mail landschap er totaal anders uit zien.

Disclaimer: ik heb aan een Mail user Agent voor een handvol Nokia smartphones gewerkt (de generatie voor Lumia).
Nee, PGP is een overblijfsel uit de jaren negentig, en tegenwoordig niet meer serieus te nemen als oplossing. Zo ontbreekt bijvoorbeeld forward secrecy volledig. Daarnaast is de implementatie in mail clients abominabel te noemen, en is het nog steeds extreem ingewikkeld voor de gebruiker.

Mocht je me niet geloven, Matthew Green legt op zijn blog een groot aantal bezwaren beter uit dan ik het zou kunnen.

[Reactie gewijzigd door terrapin op 27 juni 2018 15:27]

idd, vooral voor de eindgebruiker is het zo ontzettend ingewikkeld, dat gaat m echt niet worden.
Als je je wachtwoord kwijt bent, dan ben je je mail kwijt.
Je kan niet naar een site gaan en op "wachtwoord vergeten?" klikken, het is gewoon afgelopen.
No way dat ik bijv mijn moeder zoiets vrijwillig zie gebruiken, die heeft liever onveilige mail met evt rode knipperende waarschuwingen (wat dan vast ook gebruikelijk zou zijn, als je mensen zou proberen te pushen het te gebruiken). Of gebruikt net als nu Facebook Messenger, die zeurt tenminste niet.

Je zou het nog zo kunnen implementeren, dat je PGP wachtwoord in de cloud staat, waarvan de account een apart wachtwoord heeft dat je _wel_ op een digibeet-proof manier kan herstellen.
Doet de beveiliging wel flink teniet, als de cloud dienst omvalt/wordt gehackt kan je alsnog je mail kwijt zijn, ondanks dat je zelf alles tiptop netjes hebt geregeld.
Al heb je datzelfde probleem bij starttls (CA's), daarbij betreft het alleen transport en niet opslag, en die hebben wat hogere standaarden dan het wel en wee van "wachtwoord vergeten" linkjes.

Maar goed, als je wilt dat de gemiddelde persoon niet gillend wegrent, is t niet anders.
PGP beveiliging is wel goed zat hoor, iig een stuk beter dan niks, maarja als niemand t gebruikt/beheert zoals t hoort dan is dat niet relevant.

[Reactie gewijzigd door N8w8 op 27 juni 2018 11:55]

Dat PFS ontbreekt is meer een functie die er gewoon bij hoort: Oude mails kan je later altijd nog met de betreffende sleutel lezen. Hierdoor kan je ze met PGP opgeslagen laten staan en ontsleutelen wanneer je het nodig hebt.

PFS is iets voor online end to end diensten. Niet voor iets als emails die eigenlijk statische content zijn, waarbij je het transport niet mee in beschouwing wil nemen. PGP is namelijk geen dienst waarbij de eindgebruikers direct met elkaar hoeven te communiceren en bij iets als email wil je dat ook helemaal niet. Bij PFS is dat wel nodig, voor elke communicatie wordt een sleutel onderhandeld via het Diffie-Hellman protocol en dat is interactief.

[Reactie gewijzigd door GekkePrutser op 26 juni 2018 16:57]

En de headers van de email dan, die blijven dan fijn plain-text? Nee dankje ;) Versleuteling kan prima op transport niveau (zie https met TLS en http/2).

De eeuwige backward compatibiliteit zit de vooruitgang in de weg en iemand moet een keer harde maatregelen nemen om te stoppen met onversleutelde transport van mail.
De headers zijn nodig voor de adressering. Op een envelope staat ook jouw naam en de naam van de verzender.

En inderdaad, de S van SMTPS dient er voor om ook die zogenaamde headers te beveiligen.

Voorts is SMTPS een gedistribueerd protocol. M.a.w. is het niet eenvoudig voor ťťn partij om alle metadata van alle E-mails wereldwijd te verzamelen (zoals bij social media momenteel nu wel het geval is, gezien Facebook de monopolist is). Wanneer natuurlijk iedereen GMail gebruikt, maak je het Google wel erg makkelijk natuurlijk. Niet doen dus he.

Maar dus om een graph van alle E-mail verkeer te maken, zou je alle SMTP servers moeten MiTM attacken. Dat is haalbaar voor een organisatie als de NSA. En daarom doen we SMTPS en niet SMTP.

Maar SMTPS is dus eenvoudig te downgraden (maar moest de NSA dat bij alle verbindingen gaan doen, dan zou dat gewoon kei hard opvallen). Daarom moet er ook PGP tussen de MUAs zijn. SMTPS en PGP zou ongeveer veilig genoeg moeten zijn.
PGP is veel meer dan alleen beveiliging. Het is natuurlijk leuk dat jij meent de mailhost van jouw domain te kunnen vertrouwen en tevens ook de host van de ontvanger, de werkelijkheid is natuurlijk een beetje anders.
Bij pgp heb je daarentegen niet alleen de zekerheid dat alleen de beoogde ontvanger het bericht kan ontsleutelen ook kun je ermee vaststellen dat jij de werkelijke verzender bent een degelijke en publieke keyserv infrastructuur zou daarmee aanzienlijk beter werken dan velerlei alternatieven waaronder de verschillende digiD diensten
Je legt me nu wat woorden in de mond hoor..

Bij het opzetten van een veilige verbinding gaat het niet alleen om versleuteling maar juist ook om verificatie. Tevens zijn dan alle headers ook versleuteld.

Met pgp over een open netwerkje kan alsnog iedereen zien dat ik naar jan en alleman mail stuur, samen met alle andere headers en onderwerp. Dankje de koekoek ;)

Begrijp me niet verkeerd. Ik gebruik zelf ook GPG, genoeg om te weten dat het geen wonder middel is. Er wordt hier met de term gegooid alsof het een blockchain is, nog zo'n gedoodverfd "wondermiddel".
Het probleem van onversleutelde email is eigenlijk veel groter dan dat van MITM aanvallen op websites, waar wel hele campagnes voor gevoerd worden.
Ofwel is de gebruiker er zich niet eens van bewust dat email meestal onversleuteld is of wel bedrijven zijn er zich wel van bewust en leggen portalen aan. En dan krijg je de situatie dat een persioenverzekeraar met een besparing van hun portokosten een webportaal aanlegt (waarvan je het beveiligingsniveau in twijfel kunt trekken) en je een brief stuurt dat er informatie in hun webportaal klaar staat. Veel klantonvriendelijker kan eigenlijk niet. Tijd voor mail 2.0 dus, E2E versleuteld en met de mogelijkheid om spammers te weren.
En die E-mail 2.0 is dan dus MIME met verplichting voor PGP, SMTP met verplichting voor TLS en POP en IMAP beiden ook met verplichting voor TLS.

Het beste zou zijn moesten MUA's hťťl duidelijk aanduiden dat een E-mail die waar dan ook uit de veilige chain is geweest, onbetrouwbaar is. M.a.w. liefst zelfs negeren of bv. automatisch in de spam folder droppen.

Maar gradueel daar naar toe gaan kan door te beginnen met PGP te introduceren als verplichting voor MIME: je MIME message moet met PGP geŽncrypteerd zijn, of de E-mail is in zijn geheel spam en/of onveilig en/of onbetrouwbaar.

Hťt probleem dat je hebt is dan Outlook. Als Microsoft hun Outlook daar niet op aanpast, zal niemand in de wereld zich iets van dat E-mail 2.0 of MIME-met-verplicht PGP aantrekken. M.a.w. zouden we op EU niveau Microsoft moeten verplichten dit juist te implementeren in de EU variant van Outlook. Daarna een update naar iedere Outlook gebruiker uitrollen. En precies hetzelfde voor Hotmail en GMail (als web E-mail platformen). M.a.w. Outlook en Hotmail: Microsoft heeft de sleutel in handen.

Merk op dat bv. Google helemaal geen end-to-end encryptie wil. Omdat ze dan ook niet meer de inhoud van de E-mails kunnen analyseren voor marketing doeleinden. End-to-end wil nl. zeggen dat de mail user agent de decryptie doet (m.a.w. is dat bv. de JavaScript in je browser in geval van GMail, zoals bv. mailvelope doet. Niet de GMail server).

[Reactie gewijzigd door freaxje op 26 juni 2018 13:26]

Zie daar oplossingen zoals ZIVVER, waarbij er wel een boodschap klaar wordt gezet dat er een mail / bericht voor je klaar staat, echter zo gebruiksvriendelijk als mogelijk (met 2FA). Echt veilige mail waarmee datalekken actief worden voorkomen/teruggedrongen.
Voor e-mailversleuteling heeft S/MIME toch een veel bredere ondersteuning dan PGP? Veel clients ondersteunen dat al out-of-the-box en het gebruiksgemak is daardoor ook wat beter dan het huidige PGP ecosysteem. Helaas is ook bij S/MIME het marktaandeel bij eindgebruikers minimaal.

Zo'n "uw e-mail is onveilig" zou wel een positief effect hebben ja.
S/MIME zou ook goed zijn. Alleen moet je bij S/MIME een certificaat autoriteit hebben, geloof ik. M.a.w. moest bv. de EU (of overheden) dit gaan verplichten voor gewone burgers, dan moet het ook gratis certificaten uitdelen en hiervoor het beheer op zich nemen (is geen slecht idee, denk ik).

Bij PGP kan je zelf die private/public keys aanmaken en de public key aan je contacten geven en/of registreren.

Eigenlijk is de moeilijkheid bij beiden om dat sleutelbeheer gebruiksvriendelijk te krijgen. Maar ook hier kan de Mail User Agent behulpzamer worden.

ps. Momenteel is PGP iets populairder onder de techneuten. Met PGP geŽncrypteerde E-mails krijg ik wel eens aan als techneut. Ik heb aan E-mail clients gewerkt voor Nokia, dus je kan je wel voorstellen dat andere E-mail ontwikkelaars (en IETF mensen van de IMAP groep) me wel eens een paar van die 'leukere' E-mails stuurden: gewoon om te testen of de E-mail client die ik aan het ontwikkelen was wel alles juist ondersteunt ;-). Ik heb toen dus m.a.w. allerlei rariteiten die perfect volgens de specificatie juist zijn, maar waar veel MUA's niet mee omkunnen, ontvangen. PGP was typisch, S/MIME zelden of nooit.
Heel erg goed innitiatief! En lets-encrypt technologie inzetten om dit onderwater probleem voor velen op te lossen. Ik ben een groot voorstander hiervan. (Naast dat we al jaren tls op de smtp hebben aanstaan en dat de meeste ligitieme email zo wordt delivered)
Het probleem is dat stel dat ik tussen jouw SMTP server en de andere SMTP server kan gaan zitten (een traditionele MiTM), dan kan ik de reply van het capability command wijzigen zodat het geen TLS capability meer geeft aan uw tegenpartij.

Uw tegenpartij zal toch niet zo geconfigureerd zijn dat hij daarna de connectie afsluit.

Naar jouw kant kan ik trouwens blijven nabootsen alsof er wel sprake is van TLS encryptie.

M.a.w. aan jouw kant zou je er niets van merken.

E-mail moet met end-to-end encryptie beveiligd worden. Niet (enkel) door het kanaal. De content moet end-to-end encrypted zijn.

Daarvoor gebruiken we PGP. PGP is een probleem van de Mail User Agent.

ps. Net zoals hoe berichten op bv. Telegram en Whatsapp end-to-end door de client geŽncrypteerd worden en het niet voldoende is om het XMPP kanaal te encrypteren.
Hoe wil je aan het certificaat voor dat domein komen? Nog een MITM tussen de server en CA?

Kortom het laten geloven dat de ander nog gewoon een SSL verbinding heeft wordt lastig daar deze ook het certificaat hoort te checken.
Dus ideaal is dit (ik het het protocol niet meer van buiten, maar hier lijkt het op). Connectie van SMTP1 naar SMTP2:
SMTP1 -> CAPA
SMTP2 <- TLS A B
SMTP1 -> STARTLS
SMTP2 & SMTP1 <-> key-exchange
<Alle trafiek is nu geŽncrypteerd>
SMTP1 -> Commando's (geŽncrypteerd)
SMTP2 <- Replies (geŽncrypteerd)
Hoe het bij een MiTM die de connectie downgrade zou gaan (SMTP1 naar SMTP2 met MiTM er tussen zonder dat SMTP1 en SMTP2 dit doorhebben):
SMTP1 -> CAPA
MiTM -> CAPA
SMTP2 <- TLS A B
MiTM <- A B
SMTP2 & MiTM <-> key-exchange
<Alle trafiek tussen SMTP2 en MiTM is nu geŽncrypteerd>
SMTP1 -> Commando's in plain text (want er is geen TLS denk SMTP1)
MiTM -> Commando's maar dan geŽncrypteerd
SMTP2 <- Encrypted replies
MiTM <- Repies maar niet meer geŽncrypteerd
M.a.w. SMTP2 heeft een valid certificaat van MiTM gekregen, en weet niet beter. SMTP1 denkt dat SMTP2 geen TLS ondersteuning heeft. MiTM doet alsof alles in orde is voor iedereen.

Merk op dat bij een MiTM er iemand tussen U en de andere partij zit.

Een meer geavanceerd voorbeeld zou inderdaad zelfs de TLS sessie opzetten, maar dan telkens de sleutels veranderen. Je kan die meer geavanceerde versies wel ergens schematisch vinden. Er zijn ook kant en klare softwares die dit gewoon doen voor je. Dit is dus zelfs geen NSA-level kennis of technologie.
Maar nogmaals, hoe komt the MITM aan een geldig certificaat voor een van beide domeinen? Dat gaat je dus nooit lukken tenzij je een CA hacked.
De SMTP1 denkt dat er geen certificaat nodig is omdat de MiTM de connectie heeft gedowngrade naar plain text. De SMTP2 geeft gewoon haar eigen certificaat en de MiTM gebruikt dat.

Wanneer je met een meer geavanceerde manier de hele TLS sessie nabootst dan moet je telkens decrypteren en terug encrypteren als MiTM. In dit geval heb je wel een hacked CA nodig.

Maar bij de overgrote meerderheid van SMTP1 servers is dat niet nodig. De MiTM zorgt er voor dat SMTP1 denkt dat SMTP2 geen TLS heeft. Dus SMTP1 doet geen certificaat check en de check tussen MiTM en SMTP2 zal MiTM wel goedkeuren natuurlijk (de MiTM heeft toch al slechte bedoelingen).

Komt de MiTM aanvaller een SMTP1 tegen die niet doorgaat tenzij er TLS is, dan pas gebruik je de meer geavanceerde methode. Maarja. 98% van de SMTP servers zullen gewoon doorgaan bij een downgrade van de connectie.
Een eerste stap is dat Postfix-beheerders gebruik kunnen maken van een Certbot-plug-in om geldige certificaten voor hun mailserver te genereren.
Dit is toch allang mogelijk?
Ik gebruik Let's Encrypt voor veel zaken die officieel niet ondersteund worden. Maar daar ben je beheerder voor, om het werkend te krijgen.
Daarom kan het wel gebruiksvriendelijker, dat zal er allicht toe leiden dat het meer gebruikt wordt.
Dus een plugin er bij voor certbot.
Als ik de stappen voor postfix bekijk, is het al vrij gemakkelijk.
https://www.upcloud.com/s...stfix-using-lets-encrypt/

Als het nog gebruiksvriendelijker moet, moeten die mensen misschien geen mail server beheren.
Bij IPv6 zou het goed zijn moest ieder huishouden haar eigen SMTP server draaien, i.p.v. dat er SMTP servers zijn en dat providers voor je E-mail moeten zorgen (en ook haar eigen social media service, en haar eigen XMPP service, en haar eigen whatever service).

Wanneer alles en iedereen adresseerbaar is. Waarom zouden we dan niet gewoon overal zelf zulke servers draaien? Uiteraard zonder dat er beheer van de niet technische gebruiker moet zijn. Dat moet gewoon onmiddellijk goed staan allemaal.

In dat geval kan het handig zijn om certificaat infrastructuur te hebben die dit eenvoudig maakt voor moms en pops.

De enige reden waarom Internet providers dit soort taken op zich nemen, is omdat IP adressen niet voor altijd assigned blijven voor de meeste Internet consumenten. Dat zal bij IPv6 nu net veranderen. Dus wordt iedereen adresseerbaar. Dus kunnen bv. die thuis-routertjes zelf oa. SMTP gaan doen (dat kunnen velen nu al, trouwens).
Nee, dat is niet de reden. De meeste mensen weten helemaal niks van e-mail en hoe het getransporteerd wordt en willen dat ook niet. IPv6 gaat daar helemaal geen verandering in brengen. Daarnaast stellen ze eisen aan mail die meer dan alleen SMTP en IMAP zijn. Men wil een goede Web-UI, goede spamfilters, agenda en adresboek functies, etc.

Hobbyisten kunnen al decennia-lang hun eigen mailserver draaien (bij veel providers kon je een statisch IP krijgen als je wilde) maar velen die ik ken (incl. mezelf) zijn daarmee gestopt omdat het beheren van een maildienst een dagtaak geworden is. De hoeveelheid spam en malware die via e-mail verzonden wordt en bovenstaande eisen aan webmail en andere functies maken dat het veel werk kost en je in je eentje het nooit zo goed kunt doen als een dedicated maildienst. Voor mij voldoende redenen om naar hosted Exchange te gaan. Anderen naar GSuite of hun providers dienst.

Ik ben professioneel systeembeheerder en heb wel de kennis maar niet meer de tijd of zin om dit in mijn vrije tijd te doen. Voor velen is dat niet anders.
Dat "beheer" zou dus de ontwikkelaar van het routertje op zich kunnen nemen: een router heeft dan een eenvoudige standaard configuratie die voor iedereen hetzelfde is en die gewoon werkt. Anti-spam is ook outsourcebaar. Mollum bijvoorbeeld. M.a.w. dan is het kwestie van op de web UI van de router een combobox te zetten met een paar mogelijkheden in: 'ik wil dat Mollum mijn E-mails nakijkt op spam', 'ik wil niet dat er nagekeken wordt op spam' of 'ik wil een lokale spamassassin dit laten nakijken'.

Er is eigenlijk helemaal niets moeilijk aan om dit consumer-grade te krijgen.

Alleen is "het Internet" in het algemeen de verkeerde richting op gegaan door gecentraliseerd te willen zijn. Dat is het omgekeerde van wat een goed idee is.

Dat iedereen alle E-mail zaken op GMail is beginnen zetten, is een zťťr slechte zaak voor de onafhankelijkheid van het Internet. Er is niets waarom we SMTP niet gewoon thuis op de router van het gezin kunnen laten draaien. Zťker niet configuratie of beheer-moeilijkheden. Dat is immers extreem eenvoudig en een reeks defaults zou voor 99,9999% van de gezinnen meteen werken. Ze hebben enkel geen vast IP adres en geen automatisch domain voor hun gezin (waar de MX van ingesteld staat).

Die laatste twee kan de overheid en/of de EU automatisch en gestandarizeerd aan alle gezinnen uitdelen en/of kan het Internet Providers verplichten dat te doen op een gestandarizeerde manier. Problem solved, and routers will be made.
Het is een prima begin, maar startTLS clients (mailprogramma's) schakelen nog vrolijk over op plain uitwisseling van user/wachtwoord + verdere communicatie. En het is beperkt tussen het verkeer tussen client en mailserver. Communicatie tussen mailservers onderling, voordat de eindbestemming mail server is bereikt, is iets waar we als eindgebruiker geen invloed op hebben. Hoe secure is het daar al?

Een volgende stap zou dan zijn om TLS/SSL verplicht te stellen. Zonder versleuteling geen contact met mailserver. En daarnaast zouden alle stappen in het proces veilig moeten.

Houd je alleen over dat mail op mailservers altijd stilzwijgend een kopie getrokken kan worden, zonder dat iemand dat merkt. Dat los je alleen maar op door de hele inhoud van je mail te versleutelen. Het is eigenlijk schande dat daar niet eens werk van gemaakt wordt om dit makkelijker te doen (PGP, S/MIME of whatever). Dit is voor de gemiddelde eindgebruiker allemaal veel te ingewikkeld.
Dit wordt pas opgelost als er standaarden komen voor bedrijven zodat die zonder starttls niet meer mogen connecten. Bijv. door het in PCI DSS op te nemen. En als de standaard MTA's (postfix, qmail, exim en sendmail) ook overgaan op starttls by default.

We zitten nu op 89% adaptatie. Ik denk dat dit niet gaat gebeuren voordat er 95% adaptatie is.

Misschien is het voldoende als de Google's and Microsofts van deze wereld geen mail meer aannemen van servers die starttls niet vereisen.
Hopelijk zorgen ze nu ook dat je niet meer poort 80 en 443 open hoeft te zetten om certbot te kunnen gebruiken. Dat vind ik nog een groot nadeel van het huidige proces (ik wil op mijn mailserver geen webservices draaien). Het bewijzen dat je het domein hebt, zou je net zo goed via poort 25 kunnen doen.

[Reactie gewijzigd door GekkePrutser op 26 juni 2018 16:55]

Hoe je het iig met postfix kan opzetten heb ik een tijdje geleden eens een blog over geschreven

https://blog.kruyt.org/postfix-and-tls-encryption/

Dit gaat ook in op wat hardening, niet alleen he ls aan ze met een certificate.
Ben ik de enige waarbij deze site aangeeft dat EFF.org geen bekende certificerings authoriteit is?
Does not present a valid certificate
Failure: Name in cert doesn't match any MX hostnames.

Failure: Certificate root is not trusted: x509: certificate signed by unknown authority

On the internet, even if you think you’re talking to a service named “eff.org”, it could be an impersonator pretending to be “eff.org”. Checking a mail server’s certificate helps ensure that you really are talking to the actual service.
Heel vreemd. Ik heb met een andere TLS check geverifiŽerd dat het wel degelijk allemaal werkt, alleen op nota bene deze site wordt dus aangegeven dat het niet klopt :?

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True