Onderwerp: KPN blokkeert externe SMTP-servers zonder beveiligde verbinding

KPN heeft het sinds enkele dagen onmogelijk gemaakt om e-mail te versturen via externe SMTP-servers indien er geen sprake is van een beveiligde verbinding, dat meldt XXL Webhosting dat zijn klanten adviseert hoe hier mee om te gaan. Ook kom ik één klant tegen die op Twitter klaagt over het probleem dat het niet langer […]

Source: ispam.nl

Inmiddels heb ik een klacht bij ACM ingediend i.v.m. netneutraliteit. Immers maken ze het voor klanten onmogelijk om verbinding te maken met een onbeveiligde e-mailserver bij derden. Heb enkele klanten met embedded apparatuur in het KPN-netwerk, waarvan de client alleen e-mail over poort 25 en onbeveiligd ondersteund. In verband met spf is het wenselijk dat de e-mail via de e-mailserver die buiten het netwerk van KPN staat wordt verstuurd.

Ik raad een ieder aan om een klacht in te dienen bij de ACM.

Oorspronkelijk geplaatst door frajaweb

Inmiddels heb ik een klacht bij ACM ingediend i.v.m. netneutraliteit. Immers maken ze het voor klanten onmogelijk om verbinding te maken met een onbeveiligde e-mailserver bij derden. Heb enkele klanten met embedded apparatuur in het KPN-netwerk, waarvan de client alleen e-mail over poort 25 en onbeveiligd ondersteund. In verband met spf is het wenselijk dat de e-mail via de e-mailserver die buiten het netwerk van KPN staat wordt verstuurd.

Ik raad een ieder aan om een klacht in te dienen bij de ACM.

Wat een onzin. Dit is juist een goede actie van KPN en hopelijk gaan nu meer mensen nadenken over het veilig versturen van email om zo spam tegen te gaan. Dat apparatuur het niet ondersteund kan KPN niet worden verweten, die fabrikanten moeten gewoon stoppen met rotzooi produceren. Mijn 15 jaar oude HP printer kan zelfs SMTPS.

Ja inderdaad. Vervelend als oude spullen niet meer werken. Maar of dat nou zo slecht is? Ik mag bijvoorbeeld ook niet meer met mijn 16 jaar oude diesel bestelauto het centrum van de meeste grote steden in...

Versleuteling over publieke netwerken is vroeger en tegenwoordig gewoon nodig. En als je dat niet kunt, dan staat het je vrij om een andere poort te gebruiken. Het zou wel aardig zijn als ze het alleen bij consumenten producten zouden doen en zakelijke producten hierin vrij laten.

Helemaal mee eens CharlieRoot en t.bloo!
@frajaweb De tijd die je hebt gestoken in een klacht schrijven naar ACM had je beter kunnen gebruiken om een simpele oplossing te maken voor het probleem van die klant (andere poort gebruiken, hang een rPi op die je als relay gebruikt, whatever)

Netneutraliteit is een groot goed, maar niet bedoeld om legacy systemen die overlast mogelijk maken werkend te houden

Het punt is denk ik vooral dat de communicatie slecht is.
Dit wordt "zomaar" gedaan. Zonder aankondiging vooraf. Zonder waarschuwingen.
Beter was geweest om eerst te detecteren welke klanten dit nog gebruiken, dan een gericht bericht sturen met "je hebt nog x maanden om je brakke shit te fixen".
En daarna pas afsluiten.

Tuurlijk zijn er oplossingen voor legacy producten, maar daar ging mijn opmerking niet over. Het ging over het principe van netneutraliteit, voorzien van een voorbeeld waar het voor problemen zou kunnen zorgen. Voornamelijk in wat oudere embedded systemen kan je soms maar zeer moeilijk een poort aanpassen of mailserver adres aanpassen. Deze versturen vaak simpele statusberichten, die zonder gevaar over een onbeveiligde verbindingen kunnen worden verstuurd. Versleuteling is dan een overbodige en onnodige luxe. Kpn bepaalt in dit geval wat kan en niet kan. In mijn optiek is dat in strijd met de regelgeving, ook als is het veiliger voor hun en andersmans netwerk. Andere onveilige manieren van datauitwisseling ondersteunen ze nog wel steeds op hun netwerk. Kortom een klacht waard.

Oorspronkelijk geplaatst door frajaweb

Tuurlijk zijn er oplossingen voor legacy producten, maar daar ging mijn opmerking niet over. Het ging over het principe van netneutraliteit, voorzien van een voorbeeld waar het voor problemen zou kunnen zorgen. Voornamelijk in wat oudere embedded systemen kan je soms maar zeer moeilijk een poort aanpassen of mailserver adres aanpassen. Deze versturen vaak simpele statusberichten, die zonder gevaar over een onbeveiligde verbindingen kunnen worden verstuurd. Versleuteling is dan een overbodige en onnodige luxe.

Wat jij een "overbodige en onnodige" luxe vind kan een ander bestempelen als een (potentieel) gevaar. Juist deze oude apparatuur die maar een "simpel" signaal verstuurt kan worden misbruikt voor het versturen van spam en andere zaken. Kijk naar de effecten die "simpele" IOT apparaatjes hebben gehad in de DDoS een tijdje terug. Jouw klaagzang laat alleen maar zien dat je er geen fluit van begrijpt.

For example, a few years ago, a 75,000-strong botnet comprised of embedded devices – consumer broadband routers, in that instance – was found to be launching DDoS attacks. We routinely see IoT botnets comprised of webcams, DVRs, cable television set-top boxes, satellite set-top boxes, etc. used to launch DDoS attacks.

Bron: https://www.arbornetworks.com/blog/i...-ddos-attacks/

Beste,

Dat ik er niks van begrijp is klinkklare onzin. In dit land hebben we gezamenlijk afspraken gemaakt over netneutraliteit. Wie is KPN om te bepalen wat wel en niet kan. Tuurlijk ben ik voor beveliging en uitrangeren van oude zooi, maar dit mag KPN niet bepalen. Voorbeeld was ter illustratie, niet om aan te geven dat ik voor onbeveiligde verbindingen ben. In tegendeel zelfs.

Het erbij halen van IoT en ddos gaat in deze discussie te ver, en is off topic. Elk apparaat en e-mailaccount waar de gebruikersnaam en wachtwoord van buit zijn buitgemaakt kunnen misbruikt worden. Hiervoor maakt het niks uit of de e-mail via SSL/TLS of niet via SSL/TLS loopt. Tuurlijk zijn ze bij onbeveiligde verbindingen net iets makkelijker af te vangen, maar SSL/TLS is op de juiste plek in het netwerk net zo makkelijk te omzeilen door een man in the middle attack. Bij oudere certificaten kan het soms nog eenvoudiger.

In het artikel gaat het over IoT devices in zijn algemeenheid. Bij de meeste IoT devices staat een standaard gebruikersnaam en wachtwoord ingesteld waardoor ze onderdeel van een botnet kunnen worden gemaakt, heeft verder niks met e-mail te maken. Is zelfs al af te leiden uit het citaat.

Oorspronkelijk geplaatst door frajaweb

Beste,

Dat ik er niks van begrijp is klinkklare onzin. In dit land hebben we gezamenlijk afspraken gemaakt over netneutraliteit. Wie is KPN om te bepalen wat wel en niet kan. Tuurlijk ben ik voor beveliging en uitrangeren van oude zooi, maar dit mag KPN niet bepalen. Voorbeeld was ter illustratie, niet om aan te geven dat ik voor onbeveiligde verbindingen ben. In tegendeel zelfs.

Het erbij halen van IoT en ddos gaat in deze discussie te ver, en is off topic. Elk apparaat en e-mailaccount waar de gebruikersnaam en wachtwoord van buit zijn buitgemaakt kunnen misbruikt worden. Hiervoor maakt het niks uit of de e-mail via SSL/TLS of niet via SSL/TLS loopt. Tuurlijk zijn ze bij onbeveiligde verbindingen net iets makkelijker af te vangen, maar SSL/TLS is op de juiste plek in het netwerk net zo makkelijk te omzeilen door een man in the middle attack. Bij oudere certificaten kan het soms nog eenvoudiger.

In het artikel gaat het over IoT devices in zijn algemeenheid. Bij de meeste IoT devices staat een standaard gebruikersnaam en wachtwoord ingesteld waardoor ze onderdeel van een botnet kunnen worden gemaakt, heeft verder niks met e-mail te maken. Is zelfs al af te leiden uit het citaat.

Ik denk dat je als hoster heel goed zelf mag bepalen wat wel en niet kan. Als ik mijn klanten de veiligheid wil garanderen die zij van mij verwachten, dan moet en wil ik die bieden ook. Pluspuntje in het kader van Wet Datalekken en Wet bescherming persoonsgegevens.

Emailverkeer is niet geblokkeerd/afgknepen. Je moet enkel een versleutelde verbinding maken. Het staat zelfs in een RFC: https://tools.ietf.org/html/rfc3207

Het is natuurlijk niet netjes dat KPN dit plotseling doet. Ze hadden dit prima van te voren kunnen aangeven, maar om er nou zou lastig over te doen vind ik ook weer overdreven. STARTTLS aan op je SMTP server en klaar. Als we bij alles wachten tot de laatste gebruiker/server/hoster over is of klaar is, dan komt er nooit wat van.

@NibeP . In mijn optiek zit er nogal een verschil tussen een hoster of een ISP. Een ISP moet een neutrale verbinding beschikbaar stellen. Een hoster kan zelf bepalen, tot op bepaalde hoogte, hoe hij zijn services beschikbaar maakt naar de buitenwereld, het liefst beveiligd. Bij de blokkade van KPN, blokkeren zij in de rol van ISP, niet als hoster. Het zou wat zijn als mijn transit/netwerk-provider in het datacentrum een dergelijk besluit zou nemen.

Wat wordt er in de toekomst nog meer onmogelijk gemaakt door KPN? Onbeveiligd HTTP/POP3/IMAP is in de basis net zo onveilig. Immers weet je in de meeste gevallen bij het afvangen van een POP3/IMAP gebruikersnaam/wachtwoord ook de inloggegevens voor SMTP of het nu beveiligd is of niet. Kortom het is niet aan KPN als ISP om dit te bepalen, maar aan hosters/mailserverproviders. Als zij slim zijn, zijn ze al lang overgeschakeld.

Het verwijzen naar een protocol voorstel, waar al een errata op is, maakt voor deze discussie helemaal niets uit. KPN moet elk protocol neutraal doorgeven, of het nu gestandaardiseerd is of niet. Het gaat hier op het principe, niet of het wenselijk is of niet dat er onbeveiligde verbindingen worden opgebouwd.

Waarschijnlijk heb ik het hier verkeerd begrepen. Ik dacht dat KPN haar eigen mailservers had aangepast, maar het blijkt om de netwerktoegang zelf te gaan?

Dat maakt het lastiger vind ik en ik heb hier niet direct een vaste mening over. Aan de ene kant is het in conflict met netneutraliteit, maar tegelijkertijd moet je er ook iets aan doen om je netwerk veilig en schoon te houden.

Oorspronkelijk geplaatst door NibeP

Waarschijnlijk heb ik het hier verkeerd begrepen. Ik dacht dat KPN haar eigen mailservers had aangepast, maar het blijkt om de netwerktoegang zelf te gaan?

Dat maakt het lastiger vind ik en ik heb hier niet direct een vaste mening over. Aan de ene kant is het in conflict met netneutraliteit, maar tegelijkertijd moet je er ook iets aan doen om je netwerk veilig en schoon te houden.

Ik vind dit geen schending van de netneutraliteit. Ze bieden de mogelijkheid om te mailen, verbinding te maken etc - maar stellen de voorwaarde dat het versleuteld is. Lijkt mij positief en zou geen beperking moeten opleveren als iedereen een wat hogere mate van beveiliging tracht te hanteren. Als ze besluiten om heel HTTP te blokkeren en HTTPS open te laten heb ik er ook geen probleem mee, het hele internet is tegenwoordig op httpS beschikbaar (behalve webhostingtalk :P )

Oorspronkelijk geplaatst door CharlieRoot

Ik vind dit geen schending van de netneutraliteit. Ze bieden de mogelijkheid om te mailen, verbinding te maken etc - maar stellen de voorwaarde dat het versleuteld is. Lijkt mij positief en zou geen beperking moeten opleveren als iedereen een wat hogere mate van beveiliging tracht te hanteren. Als ze besluiten om heel HTTP te blokkeren en HTTPS open te laten heb ik er ook geen probleem mee, het hele internet is tegenwoordig op httpS beschikbaar (behalve webhostingtalk :P )

Hetgeen wat eigenlijk onduidelijk is, is wanneer is het schending van de netneutraliteit? Er is een beperking, je kan geen onversleutelde verbinding maken, maar wel een versleutelde. Je beperkt dus de toegang tot iets. De vraag is echter of het niet toestaan van onversleuteld verkeer een beperking is volgens netneutraliteit, wanneer je versleuteld verkeer WEL toe laat.

Wanneer je versleuteld verkeer toe laat, zie ik eigenlijk geen probleem. Dit is een leuke voor Arnoud Engelfriet .

Keihard feit is dat ze een poort dicht gezet hebben. Het is verdedigbaar dat wat je over die poorten doet, de access provider niet aan gaat. En dan zou het een schending kunnen zijn van de neutraliteit.

Maar aan de andere kant, je zou ook kunnen zeggen dat het voor iedereen geldt en er geen discriminatie is. Het is niet dat (ik zeg maar wat) verkeer naar Google er niet door komt maar Microsoft wel. Er wordt niet *direct* iemand bevoordeeld of benadeeld.