Gmail-gebruikers krijgen waarschuwing bij e-mail via onversleutelde verbindingen

Google gaat gebruikers van zijn Gmail-dienst waarschuwen wanneer er e-mails binnenkomen die via onversleutelde verbindingen zijn verstuurd. Dat besluit is genomen naar aanleiding van een onderzoek waaruit bleek dat kwaadwillenden proberen e-mailverkeer te onderscheppen.

In de afgelopen jaren heeft Google in samenwerking met Amerikaanse wetenschappers onderzoek uitgevoerd naar e-mailencryptie. Dat meldt het bedrijf op zijn beveiligingsblog. Uit het onderzoek bleek onder andere dat er groeperingen actief zijn die met valse dns-servers proberen e-mailverkeer te onderscheppen om het naar onbeveiligde servers te laten lopen. Zo pogen zij om het versturen van berichten via versleutelde verbindingen te ondermijnen, om vervolgens de inhoud te kunnen onderscheppen. Op basis daarvan heeft Google besloten dat het waarschuwingen gaat geven als binnenkomende e-mail via servers met onversleutelde verbindingen is binnengekomen.

In de komende maanden moeten de waarschuwingen gaan verschijnen bij Gmail-gebruikers. De waarschuwingen, waarvan nog onduidelijk is hoe deze er precies uit komen te zien, gelden alleen bij e-mailverkeer met servers van andere e-mailproviders dan Gmail; verkeer tussen Googles mailservers is namelijk standaard van encryptie voorzien. Volgens de internetgigant is het aantal e-mails dat via onversleutelde verbindingen wordt verstuurd tussen Gmail- en niet-Gmail-gebruikers de afgelopen jaren aanzienlijk gedaald.

Het onderzoek waar Google naar verwijst is uitgevoerd door onderzoekers van de University of Michigan en de University of Illinois. Zij hebben hun bevindingen in een paper beschreven die online is gezet.

Reacties (56)

[sebasmac]

Het punt is dat systeembeheerders hier een beetje de dupe van zijn, want het is nu al redelijk lastig als startende website om niet in de spam te komen bij google en ja dan voldoe je aan het hele plan (SPF, DKIM etc.. etc..) Door dit ook te verplichten is er nog een stap bijgekomen. Opzich voor de eindgebruiker prima natuurlijk. Maar zo jammer dat er op websites standaard vermeld moet worden, oh en mocht je onze mails niet ontvangen, kijk dan even in je spam folder. Komt ook niet heel vertrouwd over

[Armin]

Door dit ook te verplichten is er nog een stap bijgekomen

Een self-signed certifciaat is genoeg. Voor email is immers non-authentciated ook geaccepteerd.

Overigens moeten kleine systeem beheerders gewoon ophouden zelf SMP servers te gaan opstarten. Net zoals je Cloud en web hosting uitbesteed, sluit je beter een contract af met een bestaande relay. Laat die mensen al het - inderdaad complexe - werk doen van registratie en reputatie opbouwen.

Juist het wilde westen waar iedereen mete en server-rack zijn eigen SMTP server het net op kon sturen, heeft geleid tot de huidige spam ellende. We zijn nu eindelijk terug op een 'slechts' 70% van-alle-emailverkeer-is-spam vs 90% een jaar of twee geleden.

Klinkt hard, maar mail-servers beheren een een specialisme geworden, dat niet meer voor de kleine man (of vrouw ) is weggelegd.

[MadEgg]

Niet mee eens. De distributed nature van SMTP / e-mail maakt het juist zo sterk. Zeker, de spam-problematiek is vervelend. Door in het begin het protocol anders ontworpen te hebben had veel daarvan voorkomen kunnen worden. DIngen als DKIM of PGP hadden direct al in het protocol verweven en verplicht gesteld kunnen worden om grotere veiligheid te bieden en spam te minimaliseren.

Alles maar centraliseren naar een paar grote bedrijven maakt de hele wereld afhankelijk van deze paar grote bedrijven en maakt het toepassen van censuur etc ook veel laagdrempeliger. Hierdoor neemt de grootste kracht van e-mail flink af.

Een e-mailserver goed configureren voor een systeembeheerder is echt niet zo moeilijk, met een dagje inlezen in de materie kom je daar echt wel uit. Waar het fout gaat is dat te veel mensen dat niet doen. Mailservers mogen dus best hogere eisen stellen aan mail die ze accepteren. Ik zal het niet snel zeggen over Google, maar in dit geval vind ik het een zeer goede actie van ze. Als grote mail-provider als gmail en outlook dergelijke mail simpelweg niet meer accepteren kunnen kleinere partijen eenvoudig ook volgen. Op dit moment is dat niet haalbaar aangezien je te weinig leverage hebt.

[Armin]

Niet mee eens

Dat kan, maar die strijd is al lang beslecht. Alle grote providers op aarde hebben jaren geleden al een convenant gesloten server-SMTP poorten te blokkeren voor clients, en de grote jongens accepteren gewoon geen nieuwe servers meer zonder dat ze en allerlei registraties ondergaan, en reputatie opbouwen.

Alles maar centraliseren naar een paar grote bedrijven maakt de hele wereld afhankelijk van deze paar grote bedrijven en maakt het toepassen van censuur etc ook veel laagdrempeliger. Hierdoor neemt de grootste kracht van e-mail flink af.

Er zijn tienduizenden SMTP dienstverlenende bedrijven alleen al in het westen. Het huidge strengere model veranderde (let wel verleden tijd, want het is nu dus zo) niets aan het decentrale karakter. Het zorgt er enkel voor dat niet elke beunhaas met een server-rack een SMTP server kan runnen.

En in feite zijn we het eens, want dat zeg je zelf ook ...

Een e-mailserver goed configureren voor een systeembeheerder is echt niet zo moeilijk, met een dagje inlezen in de materie kom je daar echt wel uit. Waar het fout gaat is dat te veel mensen dat niet doen..

Precies! Dus er is geen echte drempel voor serieuze vaklieden. Wel voor spammers en beunhazen. Met die laatste heb ik geen medelijden want worden vaak misbruikt door spammers, en die eerste zijn een inmens probleem.

[Dorank]

Dat kan, maar die strijd is al lang beslecht. Alle grote providers op aarde hebben jaren geleden al een convenant gesloten server-SMTP poorten te blokkeren voor clients, en de grote jongens accepteren gewoon geen nieuwe servers meer zonder dat ze en allerlei registraties ondergaan, en reputatie opbouwen.

Onzin, immers als ze je mail niet accepteren kan je ook geen reputatie opbouwen.
Je kan met een schoon/gloedje nieuw IP adres gewoon mail afleveren bij de grote jongens, wellicht dat ze je throttelen als je een te groot volume aflevert in een korte tijd. Maar als het geen spam is komt uiteindelijk alles gewoon aan met een paar uur vertraging.

[Armin]

Je kan met een schoon/gloedje nieuw IP adres gewoon mail afleveren bij de grote jongens, wellicht dat ze je throttelen als je een te groot volume aflevert in een korte tijd. Maar als het geen spam is komt uiteindelijk alles gewoon aan met een paar uur vertraging.

Mits je je domain registratie etc op orde hebt etc. En dat is zoals je aan de 'klachten' op het internet kunt vinden iets wat vaak fout gaat.

Maar al het enkel kleine volumes zijn, waarom dan je eigen server opzetten? Of beter gezegd, waarom dan een eigen server opzetten zonder relay met je ISP?

De realiteit is dat het gewoon vaak fout gaat en de grote jongens je wel degelijk filteren omdat je oprechte nieuwsletter, je webblog forum registratie etc als spam aangezien wordt.

Wat gelukkig helpt is als je een betrouwbare hosting partner als ISP neemt. Een deel van de reputatie krijg je dan 'gratis', waardoor het lijkt alsof het 'zomaar' kon.

[Anoniem: 668730]

Dit valt echt tegen. Met een schoon maar ongebruikt IP is je reputatie in eerste instantie laag en heb je direct afleveringsproblemen bij diverse providers. De mail komt dan wel aan, maar staat netjes in de SPAM folder.

Wij zijn vrijwel altijd genoodzaakt om een nieuwe SMTP server voor bepaalde domeinen terug te laten vallen op een reeds bestaande SMTP server met een betere reputatie. Pas na het opbouwen van een reputatie zetten we dat weer uit.

Bovendien hebben de meeste grote providers nu feedback systemen waardoor je bericht krijgt als iemand een e-mail van jouw server als SPAM markeert. Dit is bijzonder nuttig, maar niet altijd even eenvoudig om aan mee te doen.

[RobinF]

Volgensmij is KPN juist van plan om de poorten niet meer te blokkeren. Mede omdat de SMTP Relay er uit gaat

[Armin]

Lijkt me sterk dat ze dat op non-zakelijke abbonementen gaan doen.

Immers elke Tweaker die express of per ongeluk (Linux bak) een SMTP server aan laat staan, wordt niet alleen het doelwit van hackende spammers, maar zorgt er ook voor dat deze KPN IP's blacklisted worden. KPN's eigen reputatie gaat dan naar de knoppen.

Misschien dat bij bepaalde zakelijke abbonementen men het gaat toestaan, maar zeker niet bij Peter de Tweaker thuis.

[MadEgg]

Dat kan, maar die strijd is al lang beslecht. Alle grote providers op aarde hebben jaren geleden al een convenant gesloten server-SMTP poorten te blokkeren voor clients, en de grote jongens accepteren gewoon geen nieuwe servers meer zonder dat ze en allerlei registraties ondergaan, en reputatie opbouwen.

Dat klopt niet. Providers blokkeren inderdaad SMTP-poorten van consumentenlijnen. Datacentra gelukkig niet. En je hoeft ook echt niet gewhitelist te worden. Het is vooral zaak om een IP-adres te hebben dat niet geblacklist is. Vrijwel alle IP-adressen die gebruikt worden voor consumenten-lijsten staan overigens wél op blacklists, dus die spam wordt van twee kanten ingeperkt.

Neem je een zakelijke verbinding met een statisch IP-adres is de kans klein dat je geblacklist bent, en dat is eenvoudig te controleren. Het zou kunnen dat een vorige gebruiker zich misdragen heeft. In dat geval zul je wat werk moeten verzetten om van de blacklists af te komen.

Staat je IP-adres niet op dergelijke blacklists dan heb je niets te vrezen. Ja, ik spreek uit ervaring. Heb al diverse mailservers geconfigureerd op verschillende nieuw-verkregen IP-adressen en domeinnamen en nooit problemen gehad met automatische spam-blokkeringen door de grote provider.

Precies! Dus er is geen echte drempel voor serieuze vaklieden. Wel voor spammers en beunhazen. Met die laatste heb ik geen medelijden want worden vaak misbruikt door spammers, en die eerste zijn een inmens probleem.

Daar ben ik het helemaal mee eens. Er mogen best strenge richtlijnen zijn waar je aan moet voldoen om je mailserver serieus te laten nemen. Deze richtlijnen moeten echter niet organisatorisch van aard zijn maar technisch. Ik juich deze stap van Google dan ook van harte toe. Zij hebben de macht om dergelijke richtlijnen door te drukken, en zolang het openbare technologie is en niet iets wat GMail op een oneerlijke manier bevoordeeld is dat alleen maar goed.

[MadEgg]

Dat zei ik dan ook niet. Wel precies citeren Ik zei dat je reputatie moet opbouwen, en dat moet zeker. Als je niet registreerd en gewoonweg met een nieuwe verse server email verstuurt zul je ontdekken dat het gros van de grote providers je botweg zal filteren. Immers dat is wat spammers doen/deden.

Ik citeerde je toch ook inclusief 'reputatie opbouwen'? Dat is wat mij betreft een vorm van 'whitelisten': als je als nieuwkomer / onbekende partij binnenkomt zou dat betekenen dat je dus niet geaccepteerd wordt. Je moet dan namelijk eerst (positieve) reputatie opbouwen voordat je op deze whitelist terecht komt / aan de criteria voldoet.

Mijn ervaring is compleet anders. Mits je je mailserver en DNS juist configureert wordt er niets geblokkeerd en komen e-mails direct door. Zowel bij Microsoft/Outlook.com als bij Google/GMail. Ook als dit een nieuwe mailserver is met een (voor jou) nieuw IP adres en een pas geregistreerde domeinnaam.

[AMS76]

Toch vreemd. Wij hebben aardig wat klanten die hun eigen SMTP-mail versturen. Zolang je bijv. de reverse DNS e.d. maar goed hebt staan, is/was er eigenlijk geen probleem met het afleveren van deze mail... Ook niet op nieuwe IP-addressen/reeksen.

[Armin]

EDIT: Jammer weer dat 'oneens' modden ...

[Anoniem: 310408]

Alles maar centraliseren naar een paar grote bedrijven maakt de hele wereld afhankelijk van deze paar grote bedrijven en maakt het toepassen van censuur etc ook veel laagdrempeliger. Hierdoor neemt de grootste kracht van e-mail flink af.

Armin heeft het niet over alles bij een handjevol mailserver plaatsen maar over het feit dat je als tweemans bedrijf beter geen eigen mail server kan hosten. Dat kan je beter overlaten aan de tienduizenden bedrijven die dat goed kunnen, niet alleen bij een handjevol. Gezien het feit dat ik dagelijks bounces zie van belangrijke mailen zie hoe mail servers worden gebruikt door spammer lijkt me dat een standpunt dat te verdedigen is.

Ik heb geen enkele angst dat Gmail or Hotmail mijn mails zouden censureren. Als ze dat doen zijn ze binnen een week de helft van hun gebruikers kwijt. Ze zouden ook tientallen Amerikaanse wetten (*waaronder de grondwet) moeten negeren. Die kans lijkt me klein. We kunnen niet bij elk bericht bang worden.

[MadEgg]

Armin heeft het niet over alles bij een handjevol mailserver plaatsen maar over het feit dat je als tweemans bedrijf beter geen eigen mail server kan hosten.

Nouja, als dat tweemans-bedrijf de bakker of het klusbedrijf is heb je gelijk. Als dat tweemans-bedrijf een ICT-bedrijf is zie ik geen reden om dat niet te doen. Ja, je zult kennis van zaken moeten hebben. Dat verwacht je dan ook van een ICT-bedrijf natuurlijk, en dat geldt net zo goed voor dat klusbedrijf als ze ergens een badkamer gaan betegelen, om maar eens wat te noemen.

Ik heb geen enkele angst dat Gmail or Hotmail mijn mails zouden censureren. Als ze dat doen zijn ze binnen een week de helft van hun gebruikers kwijt. Ze zouden ook tientallen Amerikaanse wetten (*waaronder de grondwet) moeten negeren. Die kans lijkt me klein. We kunnen niet bij elk bericht bang worden.

Ik bedoel daar voornamelijk censuur door overheden mee. Als al je gebruikers op Gmail zitten hoef je alleen maar (gerechtelijk) aan te kloppen bij Google om bepaalde censuur door te laten voeren. Werken ze niet mee? Prima, dan wordt gmail in dat land geblokkeerd. Deze tactiek is in het verleden al meerdere malen succesvol toegepast als pressiemiddel. Als een groot deel van de gebruikers verspreid is over vele mailservers dan is dat niet zo eenvoudig te realiseren.

[R4gnax]

Als dat tweemans-bedrijf een ICT-bedrijf is zie ik geen reden om dat niet te doen. Ja, je zult kennis van zaken moeten hebben. Dat verwacht je dan ook van een ICT-bedrijf natuurlijk, en dat geldt net zo goed voor dat klusbedrijf als ze ergens een badkamer gaan betegelen, om maar eens wat te noemen.

Het is lichtelijk ironisch dat je als tegenvoorbeeld juist een tak van bedrijf naar voren schuift waar het bovenmatig voorkomt dat er beun-kwaliteit gehanteerd wordt. Ook door meer-persoonsbedrijven die te boek staan als echte professionals en de tarieven daar naar rekenen.

[Reactie gewijzigd door R4gnax op 25 juli 2024 19:36]

[MadEgg]

Ja, net als op elk vakgebied. Vandaar dat technische eisen aan een server om serieus genomen te worden door andere servers een zeer goede zaak zijn.

Het is natuurlijk ook aan de klant om enig vooronderzoek te doen naar de partij waarmee hij in zee gaat.

Dat ik mij in plaats daarvan zou wenden tot groot bedrijf geeft mij niet op eens de zekerheid van hogere kwaliteit. Er zijn genoeg voorbeelden van grote partijen die de meest waardeloze mailservers aanbieden.

[3raser]

Overigens moeten kleine systeem beheerders gewoon ophouden zelf SMP servers te gaan opstarten. Net zoals je Cloud en web hosting uitbesteed, sluit je beter een contract af met een bestaande relay.

En hoe verstuur je je mail dan naar die relay? Juist ja, via een onversleutelde verbinding. Dat is nu juist het probleem waar dit artikel over gaat. De berichten kunnen dus worden onderschept nog voordat ze bij de relay aankomen. En als je als systeembeheerder wel zelf die versleutelde verbinding kan opzetten heb je die relay dus ook niet meer nodig.

[Armin]

En hoe verstuur je je mail dan naar die relay? Juist ja, via een onversleutelde verbinding.

Nee, via een versleutelde verbinding, liefst met een echt maar desnoods self-signed certifciaat.

De OP stelde namelijk dat "het is nu al redelijk lastig [is] als startende website om niet in de spam te komen", en dit het nog moeilijker te maken.

Een kleine beheerder moet gewoon een relay doen, zodat je van het in de spam box komen, geen last hebt. Een certificaat installeren echter zou geen drempel moeten zijn. Zo ja, kun je hard gezegd beter geheel geen email servers configuren anno 2015 ...

[MadEgg]

Hoezo lastig? Ik heb daar nog nooit problemen mee gehad. Zolang het IP-adres van de server niet blacklisted is en je netjes aan het standaard-lijstje voldoet (in aanvulling op wat jij noemt een hele belangrijke: correcte netwerkconfiguratie / (reverse) hostname-resolutie) heb ik nog nooit meegemaakt dat mail geweigerd wordt door gmail of hotmail.

Natuurlijk kun je met de content van de mail hier nog wel weer invloed op uitoefenen, als je mails over viagra of bankrekeningen stuurt zul je het wel wat lastiger krijgen.

[williamvdh]

Alles wat je noemt (SPF, DKIM, etc) is heel makkelijk in te stellen in een control panel coals cPanel, evenals het beveiligen van je mailserver. Je kunt zelfs een gratis SSL certificaat krijgen op verschillende manieren. Dus ook voor kleine websites is er geen enkel excuus om niet aan beveiliging te doen.

[xleeuwx]

En nu in een SBS server van MS ?

Of een Postfix installatie op Linux die al 4 jaar draait.

Het gaat er om dat een server met een goede reputatie nu ineens "spam" verstuurd.

[Olaf van der Spek]

Het punt is dat systeembeheerders hier een beetje de dupe van zijn,

Het is toch niet Google's schuld dat het opzetten van een SMTP server blijkbaar zo lastig is?
Vraag de 'vendor' van je SMTP server software eens of dat niet wat makkelijker kan.

[runelaenen]

Je kan echt veel beter iets als mailgun gebruiken, geen gedoe met regeltjes en certificaten en tot 10000 mails per maand gratis. Sinds ik het ken gebruik ik het in al mijn projecten waar er gemailt moet worden.

[Olaf van der Spek]

Op basis daarvan heeft Google besloten dat het waarschuwingen gaat geven als binnenkomende e-mail via servers met onversleutelde verbindingen is binnengekomen.

Dit begrijp ik niet. Een man-in-the-middle kan de onderschepte email toch gewoon via een versleutelde verbinding afgeven bij Google?
Of betekent dit dat self-signed certs niet meer voldoende zijn?

[Armin]

Een man-in-the-middle kan de onderschepte email toch gewoon via een versleutelde verbinding afgeven bij Google?

Klopt, maar een MITM aanval is nog behoorlijk lastig uit te voeren, al je écht in het midden wil gaan zitten als actieve deelnemer.

Wat veel vaker gebeurd is de encryptie-stap verstoren. Immers die gaat onversleuteld. Men voorkomt dus dat tijdens de handshake de plain-text verbinding geupgrade wordt naar TLS. Men verstoord de STARTTLS handshake. Dat is makkelijk want die gebeurd in plain-text.

Gevolg is dat men geen actieve rol hoeft te spelen, maar gewoon passief kan meeluisteren.

Bij een echte actieve MITM inderdaad heb je gelijk en betekent het onvermijdelijk dat self-signed of verlopen certs niet meer voldoende zijn.

[Arietje]

Er is een kans dat het wel de kant op gaat van valid certificaten. Exim heeft enkele maanden geleden een stap gezet door het certificaat te verifiëren en te loggen als dit niet goed uit de test komt.

Uit changelog:

Verification of the server certificate for a TLS connection is now tried (but not required) by default. The verification status is now logged by default, for both outbound TLS and client-certificate supplying inbound TLS connections

Ik geloof overigens dat het volgens de richtlijnen van de RFC niet toegestaan is om SSL te eisen, dus gmail trekt hierin op zich wel zijn eigen weg. Dit kan op zich ook best legitiem zijn vind ik.

Daarnaast vind ik valid certificaten ook geen gek idee, anders houd je de onveilige deur alsnog half open.

[Reactie gewijzigd door Arietje op 25 juli 2024 19:36]

[MadEgg]

Daarnaast vind ik valid certificaten ook geen gek idee, anders houd je de onveilige deur alsnog half open.

Mwa. In principe heb je daar de MX-records al voor in DNS. Een betere aanpak zou zijn (wat ook al wordt gecontroleerd, maar niet doorslaggevend is) om te kijken of de mailserver die mail namens een bepaald domein aanlevert als MX-server geregistreerd is voor het betreffende domein in DNS. Dit, aangevuld met DNSSEC wat de integriteit van de DNS-data zou moeten garanderen, geeft je de zekerheid dat een e-mail in ieder geval van de juiste mailserver afkomstig is. Net als DKIM, overigens.

[Reactie gewijzigd door MadEgg op 25 juli 2024 19:36]

[Arietje]

Maar nu leg je de focus bij de ontvangende partij, of het aankomende mailtje al dan niet van de juiste afzender komt. Het gaat hier meer om of er afgeluisterd kan worden denk ik. Dan zal dat met een geldig certificaat geëncrypt moeten worden.

[MadEgg]

Certificaten hebben niets met afluisteren te maken. Met een SSL of TLS verbinding weet je zeker dat alleen de twee endpoints van de verbinding de gegevens kunnen lezen. Als client weet je echter niet of de andere endpoint wel de juiste server is. Dat laatste is de zekerheid dat een certificaat geeft. Mits je de Certificate Authority vertrouwt zou je er dan vanuit moeten kunnen gaan dat dat certificaat alleen is verstrekt aan de juiste server.

DKIM verifieert inderdaad alleen de afzender. De andere kant op hoeft ook niet als je DNS kunt vertrouwen (bijvoorbeeld met behulp van DNSSEC), omdat je juist de MX-records gebruikt om de ontvangende server te bepalen.

Dan zou je al IP-adressen moeten rerouten wat het een stuk lastiger maakt. Alsnog zou dezelfde DKIM public key welke in DNS gepubliceerd wordt gebruikt kunnen worden om te verifieren dat de ontvangende mailserver is wie wij zegt te zijn, maar daarvoor zou wel een wijziging / aanvulling aan het SMTP-protocol nodig zijn, of in ieder geval aan de TLS handshake. Alsnog is dat wmb een wenselijkere situatie dan een systeem gebaseerd op CA's.

[Arietje]

Certificaten hebben niets met afluisteren te maken.

Dat is wel een hele mooie. Certificaten hebben alles met afluisteren te maken. Ik heb het nu de hele tijd over MITM aanvallen. DNSSEC heeft daar helemaal niets mee te maken. Een aangepast DKIM variant zou kunnen, maar nu verzin je gewoon een heel nieuw protocol ter plaatse.

Het punt is dat vertrouwde certificaten een best solide oplossing is tegen MITM. Dus ook al heb je de juiste DNS en route te pakken, dan kan iemand die op je lijn zit rustig een eigen self signed certificaat sturen want je smtp server neemt die klakkeloos aan. Dan is alles netjes gevalideerd met DNSSEC en DKIM, maar ondertussen weet de NSA of wie dan ook wat er in de mail gezegd is.

Wat ik zeg is ook vrij simpel te implementeren: er wordt al lang met TLS gewerkt. Het enige nieuwe zou zijn 1. verplicht tls (daar gaat het nu al naar toe), en 2. werk met vertrouwde CAs.

[MadEgg]

DNSSEC heeft daar in zoverre mee te maken dat het de integriteit van de DNS-gegevens bevestigd. Dit voorkomt dus DNS-hijacking omdat dit mbv DNSSEC voorkomen wordt.

Als de remote server het juiste IP-adres en de juiste route heeft, en bovendien de juiste challenge stuurt aan de hand van de DKIM-sleutel, waarom zou je hem dan niet vertrouwen?

Ik noem inderdaad een wijziging in het protocol, maar jij stelt ook een ingrijpende wijziging voor: self-signed certificaten niet langer accepteren.

Het hele probleem met CA's is dat je er een partij bij betrekt die er verder vrij weinig mee te maken heeft. Het is in mijn optiek veel idealer als je niet van diverse partijen afhankelijk bent. DNS-registratie is per ontwerp al distributed / hierarchisch en leent zich dus perfect voor dit soort zaken. Bovendien, als je je domein probeert te beveiligen héb je al een domein, waardoor je dus maar met één partij zaken hoeft te doen: je registrar.

CA's brengen een hele meuk aan extra certificaten, controles en netwerkverkeer met zich mee die totaal niet nodig zijn. Bovendien is al diverse malen aangetoond dat het niet onfeilbaar is of net zo goed gehackt kan worden. Bovendien vereisen ze vertrouwen van de consument in partijen waar zij helemaal geen kennis van hebben en ook niet willen hebben.

Het moge duidelijk zijn dat ik ook voor HTTPS het SSL/TLS systeem met CA's verre van ideaal vindt, ook dat zou met een dergelijke techniek beter op te lossen zijn.

[Olaf van der Spek]

Gevolg is dat men geen actieve rol hoeft te spelen, maar gewoon passief kan meeluisteren.

Iets verstoren lukt toch niet passief?

[Armin]

Je hebt gelijk en ik ging dan ook kort door de bocht. Maar enkel de plain-text handsmake via een MITM aanval onderscheppen is makkelijker dan een volledige STARTTLS zelf ondersteunen aan beide kanten.

Na de handshake te onderscheppen, en wijzigen, kan men weer passief in de achtergrond wegvallen.

[Timo002]

Hoe zit dat dan met email die via php mail() functie verstuurd wordt vanaf een website met SSL certificaat?

Want op die manier versturen wel ontzettend veel webshop emails naar klanten over hun bestelling.

[MadEgg]

PHP's mail-functie is een wrapper om Sendmail op *nix en een SMTP-server op Windows. Dat hangt dus af van de configuratie van de betreffende mail relay.

Sendmail is een de facto standaard interface op Unices waar je een flinke keuze hebt aan software wat dat accepteert. Als de betreffende software goed geconfigureerd is zal de mail dus met behulp van SSL verstuurd worden.

Op Windows gaat het puur via SMTP. Zonder SSL, bij mijn weten. Dat betekent dus dat dit alleen veilig is als de SMTP-server op localhost is ingesteld, of een andere SMTP-server op een intern netwerk. De betreffende SMTP-server kan dan de versleuting voor zijn rekening nemen en de mail alsnog encrypted verzenden.

[Timo002]

Betekend dit dat het in de PHP versie zelf geregeld moet zijn? Of moet je zelf via ssh aan de gang om je is server goed te krijgen?

[MadEgg]

PHP vertrouwt volledig op de relay-server, zowel op Linux als op Windows. Het hangt dus af van de configuratie van die relay, zij het Postfix, Exim of een Windows SMTP-server.

Als je zeker wilt zijn dat je mail via SSL verstuurd wordt zul je dat zelf zeker moeten stellen door een mail-library te gebruiken die wel SSL ondersteund, zoals PHPMailer. Dan nog moet je zorgen dat je de beschikking hebt over een SMTPS-server, natuurlijk.

[Timo002]

Dat gaat dus erg veel problemen opleveren. Veel CMS systemen zoals Wordpress, Magento, OpenCart, ExpressionEngine, Bolt etc sturen in de basis gewoon email via php mail, zonder gebruik te maken van SMTP. Ben benieuwd hoe dit uitpakt!

[MadEgg]

Ik denk dat dat wel meevalt. Zoals ik al zei: het hangt op Linux-server 100% af van de configuratie van de SMTP-relay en op Windows, indien een lokale SMTP-relay gebruikt wordt ook voor 100% van de configuratie van die relay.

En zal in de meeste gevallen al wel een SSL verbinding gebruiken, en zo niet, dan is daar een kleine wijziging in de configuratie voor nodig.

Aan Magento, WordPress, etc hoeft feitelijk niets veranderd te worden.Bovendien geloof ik niet dat die PHP's mail gebruiken. In ieder geval niet allemaal. WordPress gebruikt ook PHPMailer, met een wrapper daaromheen genaamd wp_mail. Magento gebruik Zend_Mail, welke ook SSL ondersteund. OpenCart gebruikt bij gebrek aan andere configuratie, inderdaad PHP's mail(), maar kan bij gebruik van SMTP ook TLS gebruiken middels een eigen SMTP-client implementatie.

Ongetwijfeld geldt dat net zo goed voor de andere dingen die je noemt.

Als je serieuze webshop runt mag ik sowieso hopen dat je niet vertrouwt op de standaard-configuratie van PHP want die is puur voor development. Altijd al zo geweest. Voor enige zekerheid dat je mails goed aankomen moet je de juiste mailserver gebruiken en DKIM toepassen. Daarvoor ben je sowieso al aangewezen op mailconfiguratie. Als je dat niet doet heb je op dit moment ook al een vrij grote kans dat je e-mails in de spamfolder van de ontvanger terecht komen, dus daar verandert ook niet zo veel aan.

[Reactie gewijzigd door MadEgg op 25 juli 2024 19:36]

[Timo002]

PHPmailer is toch alleen maar een class om PHP mail heen? Of heb ik dat altijd verkeerd begrepen?

Als je met PHPmailer de e-mail goed op zet kun je zonder smtp ook gewoon goede mail versturen die niet in de SPAM terecht komt. Maar dan moet je wel voor goede spf records zorgen en de juiste email opbouw. Via mail-tester.com kom ik daarmee op een 9. Alleen DKIM mist dan nog.

[MadEgg]

PHPMailer is een PHP bibliotheek die mai kan versturen, met aanzienlijk meer mogelijkheden dan dat PHP's mail() functie biedt. Onder andere biedt het meerdere mail-transports, zoals SMTP, Sendmail en PHP's eigen mail() functie.

Het punt met het gebruik van alternatieven over PHP's mail() is dat ze configuratie nodig hebben. Daarom dat veel PHP mail libraries out-of-the-box terugvallen op PHP's interne mail() functie, om in ieder geval een basisfunctionaliteit te bieden. Vanuit een gebruikersoogpunt is het echter eenvoudiger om een SMTP-server te configureren in Zend_Mail, PHPMailer of een andere implementatie dan om de PHP mail-configuratie, ofwel die van de geconfigureerde relay.

Overigens ondersteunt PHPMailer ook DKIM, dus een hogere score is best te realiseren.

Default configuratie van mail gebruiken is vrijwel altijd onvoldoende om kwalitatieve mailtjes te versturen, dus daar veranderd deze maatregel van Google weinig aan.

[hjvg]

heb dit gisteren al gezien bij een e-mail. als je de e-mail opent staat er een gele waarschuwing boven.

Gmail couldn't verify that this message was sent by planet.nl. Learn more

veder komt de mail nog gewoon normaal in de inbox en niet in de spam

[jaapzb]

Volgens mij komt dat bericht er te staan als iemand een mail stuurt met een From header die niet overeen komt met de server waarvan het bericht afkomstig is.

[MadEgg]

Lijkt me niet, dat gebeurt zeer grootschalig. Amazon SES bijvoorbeeld, stuurt ook e-mail met een From-header van de afzender, maar de e-mail wordt door Amazon-servers verstuurd. De return-path header wijst dan wel naar Amazon SES, zoals de specificatie voorschrijft. Overigens beveiligd SPF daartegen ook al, maar doordat dat niet grootschalig toegepast wordt werkt dat matig. In aanvulling daarop werkt het ook nog eens slecht met redirects in het geval van mailservers die uitvallen waarna spares het overnemen.

DKIM werkt daar allemaal wél netjes omheen en is een veel betere oplossing, wmb. Dat zouden ze ook best verplicht mogen stellen zodat de motivatie om dat te gebruiken bij veel mailservers ook eens wat hoger wordt.

[Phoenix_the_II]

Ja want emails tussen servers worden ook encrypted op het internet verstuurd natuurlijk .....

Right...

..?

[Reactie gewijzigd door Phoenix_the_II op 25 juli 2024 19:36]

[MadEgg]

Als beide mailservers dat ondersteunen wel ja.

[Armin]

want emails tussen servers worden ook encrypted op het internet verstuurd natuurlijk ......

Ja, de meerderheid inmiddels wel. Sijpelweg omdat o.a. Google Hotmail en Google dat doen en dan heb je al de drie grootste spelers.

Probleem is echter dat SMTP verkeer oorspronkelijk niet encrypted was. Je kunt dus niet encryptie verplichten, want dan zou veel email niet aankomen. Ik denk aan 'onze' KPN die anno 2015 gewoon nog géén encryptie heeft op al haar inter-SMTP verkeer inclusief alle zakelijke relays. Dus encryptie is optioneel, en bovendien wordt ook non-authentciated (verlopen, selfsigned, etc certificaat) geaccepteerd onder het motto, beter encrypted dan plain text.

Nu blijkt in bepaalde landen (vooral buiten het westen gelukkig) er expliciete aanvallen gedaan worden om de onderhandeling betreft encryptie te verstoren of verkeer geheel om te leiden. De servers vallen dan terug op plain-text.

Google begint nu met een naming en shaming. Ik betwijfel of het effectief is, maar ik hoop dat ik ongelijk heb.

[Dorank]

Kijk in de headers en je weet het antwoord op je vraag...

Received: from [a.b.c.d] (helo=foo)
by smtp.example.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256)
...

Maar bedenk wel dat versleuteling van de verbinding tussen MTAs Opportunistic Encryption is. Er zijn voor zover ik weet geen MTAs die de welbekende CAs gebruiken om de identiteit te controleren, het is wachten op acceptatie en implementatie van DANE en TLSA (afhankelijk van DNSSEC).

Maar dan zelfs als de MTAs de verbinding versleutelen, in de geschetste attak vector is het gewoon mogelijk om de versleuteling tussen de hops te spoofen (als de attacker maar zelf met STARTTLS de boel aflevert).

[Fuzzillogic]

En ondertussen weigeren ze om SSL te gebruiken voor hun XMPP/Jabber chat sessies. Google lijkt vooral voor de bühne te handelen.

[Dorank]

Huh, wat? Ik gebruik al jaren de "legacy xmpp over ssl" poort 5223.

[Fuzzillogic]

Als ik vanaf mijn server S2S-communicatie verplicht over SSL laat lopen (en ik heb een certificaat van startssl, een algemeen geaccepteerde ca) dan kan krijg ik geen verbinding met het gmail.com domein. C2S is wellicht anders, maar ik gebruik geen Google-services.

[z1rconium]

Google wil graag de data voor zichzelf houden.