Smtp tls1.2 handshake failure code 40 bij mail versturen

Ik sluit de (waarde) discussie verder af. Ik ben inmiddels met mijn alertmails weer terug bij een oude (mail)provider die mij maar wat graag (smalend) zag terugkomen.

Wat mij vooral stoort/stoorde dat ik hier zelf ruim een week kwijt was die blokkade a) op te bemerken, b) te onderzoeken en c) nu dan op “te lossen”.

Of iemand wel of niet welke TLS dan wil gebruiken, moet wmb een keuze zijn dat verder niet zo heel moeilijk is te faciliteren.
Wanneer Freedom aka. Soverin meent dat vrijheid bestaat uit gebruikers verplicht laten voldoen aan haar TLS “normen”, ben daar wel klaar mee.

Ik ben met je eens dat de communicatie vooraf inderdaad duidelijker had gemoeten.

In een TLS sessie is de server in de lead om uiteindelijk te bepalen welke algoritmes er gebruikt worden. De client geeft aan wat die kan (zoals het voorbeeld aan het begin van dit topic), de server maakt op basis van de configuratie een keuze voor de sterkste combinatie die ook door de client ondersteund wordt. Als er geen overlap zit tussen wat de client aanbiedt en wat de server mag dan krijg je het effect wat jij nu hebt. Hoe strak die server configuratie staat heb je als klant nooit in de hand en is een afweging die de organisatie maakt die de server aanbiedt, vaak op basis van een risico profiel. Ik kan me zomaar voorstellen dat bijvoorbeeld een website als deze community meer oude ciphers toestaat dan bijvoorbeeld een online bankieren omgeving (ik heb het niet getest, het is maar een voorbeeld). Stel je browser maar eens in zodat die alleen de algoritmes kan gebruiken die jouw nas email client ondersteund en probeer dan nog eens normaal websites te bekijken, ik denk dat je schrikt van hoeveel er niet meer doet.

Thx4r. Er zit in het concept van “beveiliging” wel wat absurdistisch wanneer dat als doel wordt opgelegd waar dat niet nodig, gevraagd of laat staan, gewenst is.

Ik heb in andere hoedanigheden vaak gepleit dat techniek of veiligheid niet het doel moet zijn wanneer het gaat om functionaliteit.
Als iemand anders wil en dat verder geen probleem is, moet je die persoon niet daartoe gaan dwingen. Als je al je klanten wil helpen beveiligen moet je zorgen dat er een zelf instelbare firewall is zodat de voordeur op slot kan.

Zoals je zelf ook aangeeft, blijf ik ook opmerken dat de gebruikssituatie van een setting moet meewegen of en in welke mate een dienstverlener bij iemand een oplossing gaat afdwingen.
Mijn andere providers zeggen simpel, wat jij hier - zelf daarvan bewust - wil.
SSL/TLS is primair voor veiliger verbindingen die - als schijnveiligheid - beschermd zouden zijn tegen MIM attacks. Een risico dat hier en zo ja; wmb niet eens aan de orde is met een 1:1 connectie die naar Freedom en van daaruit bij Soverin uitkomt.

Dat afzien van SSL/TLS als keuze best zou kunnen; is die vooral hier niet willen bieden om zo het schip te laten blinken. En is verder niets moeilijk aan een vinkje (dat er trouwens al imo was in MijnFreedom) en/of een aparte poort/serveradres met mijn part andere restricties daarvoor neerzetten.

Dit doorgetrokken naar browsersmania voor websites is ook daar dit afdwingen pure onzin omdat iedereen het maar doet. Ik herhaal hier dat ik alleen uitgaand mail voor signalering.
Hier hou ik een paar browsers versies in ere omdat die tenminste niet bij mij gaan afdwingen dat ik whatever moet gaan doen.
Intern in mijn lab doe ik zo min mogelijk aan beveiliging omdat dit a) geld/moeite kost, b) vooral afleidt en c) volstrekt onnodig is voor een ontwikkeling.
Het eigen systeem, huis of middelen moet niet je keuze gaan beperken.

Jij maakt hier duidelijk andere keuzes en als dat voor jou werkt is dat prima. Anderen zullen blij zijn dat ze dat doen. Bij blijven met de huidige stand van zaken rondom crypto is iets wat er bij hoort als je een publieke dienst voorzien van TLS aan het internet hangt.

Het probleem is dat dat niet gaat. Om dat te kunnen doen moet je de gebruiker authenticeren om de gevraagde instelling erbij te kunnen pakken. Echter, voordat je gaat authenticeren wil je al een beveiligde verbinding hebben. Om dan de beveiliging van alle authenticatie naar die server te verlagen omdat er misschien enkelen zijn die oude software willen blijven gebruiken kan ook niet de bedoeling zijn.

Waar ik na het typen van mijn vorige bericht aan dacht: Misschien biedt Freedom/Soverin inderdaad een mailserver aan zonder TLS, waar je dus plain-text al je data heen stuurt. Daar zitten uiteraard ook risico’s aan, maar dat kan een bewuste keuze zijn.

“Omdat iedereen het maar doet” is ook niet de reden. De reden is dat het veilig moet zijn, zeker op sites waar (financiele) gevolgen aan zitten (denk webwinkels, belastingen, banken) ben ik als klant erg blij dat ze de beveiliging up-to-date houden. Sterker nog, als die onder de maat is loop ik door naar de concurrent waar dat mogelijk is.

1 like

Ik ben geen publiek, ik ben een betalende gebruiker die wil kunnen kiezen en heb niet gevraagd mij (daarin) te beleren.

We gaan hier niet goed uitkomen omdat we denken vanuit verschillende percepties. Ik wil de keuze hebben en kijk/duik niet weg in een zwart/wit situatie dat dat niet zou opgaan voor een Freedom, laat staan dat iets (on)veilig zou kunnen zijn.

De kern is dat dingen (ook hier) altijd een keuze moeten zijn. Daar worden jij en ik, beiden gelukkig van. Iemand kan dan kiezen voor die opgelegde “veiligheid” en ik heb daarin dan de keuze om in dit geval daar weloverwogen & bewust vanaf te zien.

En dan inzake die keuze, Freedom biedt een TLS vinkje in MijnFreedom die laat kiezen dat en mail adres uitgaand met/naar anderen kan mailen zonder TLS verplichtingen.


en dan je eigen betaalde gebruikers die uitgaande keuze van een eigen mailclient vervolgens niet willen bieden. Breek mij maar af want ik ben het kwijt.
Als je dan als provider ballen hebt, ga dan ook bepalen dat je gebruikers alleen met gelijkgestemden met TLSV1+ mogen mailen. Kijken hoe snel je eigen gebruikers wegshoppen omdat ze hun mail niet meer kwijt kunnen.

Je betaald voor een pakket, waarvan de provider denkt dat de klanten dit wensen.
Als ze het aanpassen, betalen we met ons allen voor jouw knopje.
Ik zie het huidige knopje, voor uitgaande mail van Freedom ook als een overgangsregeling.

Ik ben er van overtuigd, dat de meeste klanten het zo veilig mogelijk willen.
Dat het af en toe veranderd is logisch.
Als er staat bij internet.nl ‘uitfaseren’ dan ga er maar van uit, dat dit ook gebeurt.
Vaak duurt het jaren, tot het moment van de verandering.

Nogmaals, betonnen plaat, maak dingen tot een (bewuste) keuze ipv oreren of voor een ander “bedenken” dat het ‘veilig’ moet, laat staan drogredeneren dat iets geld kost want dan ken ik ook nog wel wat riedeltjes uit de eigen parochie.

Waar het op neer lijkt te komen dat Freedom zelf niets kan (cq wil veranderen ?), dat dan hier o.a. wordt gerechtvaardigd met opgediepte drogredeneringen. Triest om opnieuw te constateren dat Freedom, zo, niet veel meer lijkt te zijn (geworden) dan een doorgifte van “welgemeende” bedoelingen wier realisatie “nog jaren op zich zal laten wachten”.

Terzijde, ik heb mijn probleem elders opgelost en dat ik hier woorden aan besteed is omdat ik het niet eens ben dat mensen geen keuze wordt gelaten. Het is intrinsiek niet OK dat we een (internet)samenleving inrichten die zich richt op aannames vanuit meerderheden en daarmee andersdenkenden uitsluit.

Ik zeg ook niet dat jij publiek bent, ik zeg dat de server publiek is. Die hangt aan internet en is vanuit het hele internet bereikbaar met alle gevaren die daarbij horen en dus beveiligingsmaatregelen die daarvoor genomen moeten worden.
In de relevante wetgeving worden bedrijven zelfs gedwongen hun beveiliging goed op orde te hebben, volgens mij met termen als “goed huisvaderschap”.

We kijken er inderdaad verschillend naar. Het enige wat ik probeer uit te leggen zijn de keuzes waar een bedrijf als Freedom/Soverin voor staan. Ik snap best dat jij vanuit jouw kant voornamelijk de keerzijde van diezelfde medaille ziet. Als mede-Freedom klant, en daarmee mede belanghebbende voor de veilige dienstverlening, kan ik alleen maar blij worden dat dit soort stappen gezet worden. Niet omdat ik jou graag ongelukkig wil zien, maar omdat het betekend dat ze de beveiliging (in algemene zin) serieus nemen.

Het lastige is dat de keuze die jij wil technisch niet te realiseren is. Ik ken werkelijk geen enkel programma die de mogelijkheden biedt die jij omschrijft. Ik kan wel wat smerige netwerktruuks verzinnen die mogelijk kunnen functioneren in een thuissituatie, maar dat schaalt absoluut niet op naar de schaal waar een ISP mee te maken heeft.

Dat is wel een technisch wezenlijk heel andere keuze dan kunnen kiezen hoe de inhoud van TLS eruit moet zien. In geval van deze keuzes wordt de mogelijkheid geboden om wel of geen TLS te gebruiken, en de instelling zorgt ervoor dat voor jou de variant zonder TLS niet werkt.

Ik vind het wel ver gaan om best practices en wetgeving drogredenen te noemen.

tldr; maak veiligheid en inrichting daarvan een eigen keuze.

Nogmaals, we kijken hier anders naar het gebruik en hanteren daarin een verschillende benadering. Ik hecht niet zoveel waarde aan regels en ik prioriteer vooral de keuze te hebben om daar desgewenst vanaf te kunnen wijken. Dat is ook niet zo tegenstrijdig omdat die twee insteken prima samen kunnen gaan (leven). Men moet dat dan wel willen en niet op voorhand wegduiken dat iets niet zou kunnen.

Je hebt gelijk dat de mail(server) OOK aan het publieke netwerk hangt waarbij ik die serverplaats hier toch echt zie als betaald onderdeel en verlengde van MIJN aansluiting die ik heb afgenomen bij Freedom. Ook reden dat ik bereid ben om daarvoor wat meer dan elders te betalen (voor die fysieke aansluiting).

Een eenvoudige oplossing zou al een aparte server/poort of doorgeluste proxy zijn die dan naar keuze (bv op grond van bv IP adres of andere whitelist criteria) alleen intern door Freedom connecties is te gebruiken. Trucs, anders dan “if freedom connectie met vinkje” er geen TLS-xx onderhandeling vereist is. Ik zal verder maar niet ingaan dat je daarvoor ook iets in de sourcecode kunt herprogrammeren of opnemen.

Ook t.a.v. van “regels” en “gedrag”, staan we op andere hoogten te kijken naar de horizon. En dan neem ik als klant en investeerder, de vrijheid om rigide regelgeving ingezet als doel, te ridiculiseren.
Wat mij het meeste dwarszit dat dingen voldongen gebeuren zonder dat dit wordt doorgesproken en ik raak geïrriteerd wanneer iemand met vingertjes gaat wijzen dat ergens zou staan dat het zo zou moeten.

Nog even een toevoeging die iemand mij aan de hand deed. Bij Google kan je - zoals ik ook zie - naar keuze met ssl, tls en/of en zelfs over smtp-poort 25 mailen. → Send email from a printer, scanner, or app - Google Workspace Admin Help
Het nadeel is alleen dat ik liever mij data daar niet wil (ver)binden, hoewel dit voor mijn alarmmeldingen niet eens zo belangrijk is.
Update 25feb23: deze voorziening is onderdeel van het grotere Google Spaces - collaboration suite - dat als eendenfuik dan $6-12/mnd kost.

Ik ga even technisch door en laat de normen/waarden discussie voor elders.
tldr; ik regel nu mijn alerts mail via AmazonSES en jammer dat freedom/soverin dat niet meer wilde faciliteren.

Het TLS issue zit wmb dieper dan ik kon bedenken. Freedom/Soverin eigent zich sinds het mailonderhoud van 15feb23 een hogere standaard toe dan nu strikt noodzakelijk is. Dit door alleen nog de “goede” ciphers toe te staan en die met criteria “voldoende”; af te gaan wijzen. Dit ws in aanloop om alleen nog die van TLSV1.3 toe te (gaan) staan.

Maar goed, inmiddels bij Amazon ook de SMTP (SES) dienst ingeschakeld waar ik wel totaal vrij ben om (bijzonder veilig) te doen wat ik nodig heb. E.e.a. qua functie, vergelijkbaar met GoogleWorkspace.
Bij AmazonAWS kan ik zonder probleem mailen met -en naar zg geverifieerde mailadressen. Niet dat ik die zooi daar wilde aansteken maar helaas daartoe gedwongen en ik niets voor voelde om weer een eigen maildienst te moeten gaan draaien.
En voor wie dat roept: een zg embedded mailclient te updaten of “sendmail” variaties te hercompileren met alles wat daar bijzit, is voorlopig geen optie.

Wat in deze oplossing jammer is te bemerken dat Freedom/Soverin de aflevering van mail die namens mijzelf - zg inpersonated mail - verstuurd (op/in mijn eigen domein) weer ziet als spam en de aflevering daarvan dan botweg blokkeert; ipv mijn die keuze te laten. Maar goed, gelukkig zijn & heb ik flexibeler partijen waar ik wel gewoon mijn dingen weer kan doen.

Waarom Freedom/Soverin hierin zo stellig, bot en/of koppig in wil zijn, verbaast mij oprecht bij & van een technische club die zich voorstaat op ‘vrijheden’.