Smtp tls1.2 handshake failure code 40 bij mail versturen

E-MAIL
1

Sinds een paar dagen kan ik vanaf een bepaalde (oude qnap) client geen mail meer versturen via SMTP SSL/TLS server smtp.freedom.nl:465.
Het (b)lijkt dat de mailconnectie wordt afgebroken met een handshake failure vamuit Freedom.Heeft Herkent iemand dat en en wat te doen ?

Hieronder een verkorte tcp dump mt uitgelichte velden. Ik vermoed dat een paar ciphersniet meer worden geaccepteerd of mogelijk zijn.

15	2023-02-19 20:04:48,203485	192.168.x.x	185.233.34.142	TLSv1.2	187	✓	Client Hello
	Secure Sockets Layer
		TLSv1.2 Record Layer: Handshake Protocol: Client Hello
		    Content Type: Handshake (22)
		    Version: TLS 1.0 (0x0301)
		    Length: 116
		    Handshake Protocol: Client Hello
		        Handshake Type: Client Hello (1)
		        Length: 112
		        Version: TLS 1.2 (0x0303)
		        Random: xxxxxxxxxxx
		        Session ID Length: 0
		        Cipher Suites Length: 26
		        Cipher Suites (13 suites)
		            Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
		            Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
		            Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
		            Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
		            Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
		            Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
		            Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
		            Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
		            Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
		            Cipher Suite: TLS_RSA_WITH_IDEA_CBC_SHA (0x0007)
		            Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
		            Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
		            Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
		        Compression Methods Length: 1
		        Compression Methods (1 method)
		        Extensions Length: 45
		        Extension: SessionTicket TLS (len=0)
		        Extension: signature_algorithms (len=32)
		        Extension: heartbeat (len=1)

16	2023-02-19 20:04:48,205060	185.233.34.142	192.168.x.x	TCP	66	✓	465 → 47790 [ACK] Seq=1 Ack=122 Win=64640 Len=0 TSval=3606382938 TSecr=2998118891
17	2023-02-19 20:04:48,206182	185.233.34.142	192.168.x.x	TLSv1.2	73	✓	Alert (Level: Fatal, Description: Handshake Failure)
	Secure Sockets Layer
		TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
		    Content Type: Alert (21)
		    Version: TLS 1.2 (0x0303)
		    Length: 2
		    Alert Message
		        Level: Fatal (2)
		        Description: Handshake Failure (40)
2

Ik krijg net bericht van de helpdesk dat met het laatst uitgevoerde “onderhoud”, patsboem dus besloten dat sommige combinaties via/van/met TLSV1_2 niet meer veilig zijn. Jammer dat dit niet is/werd voorgelegd en//of vooraf aangekondigt.
Het advies is nu om de mailclient zo ver te krijgen dat deze alleen TLS v1.2 gebruikt.

Mooie gescripte-helpdesk oplossing van niet ons Freedom probleem dat vooral dan stuit op “zover zien te krijgen” omdat ik niet in controle ben over die mailclients die immers in zichzelf nu eenmaal zo zijn geconfigureerd. Ik kon al niet meer plat (poort 25) mailen, SSL (poort 587) is niet meer werkend en nu wordt dus geknaagd aan de TLS (poort 465) communicatie waarbij ik bij anderen prima via TLS kan mailen.

Het zou een betere optie zijn dat ik als klant de keuze krijg of ik al of niet vanuit MIJN client naar MIJN eogen mailbox op mijn eigen wijze kan mailen.
Ik word sws wat vermoeid :weary: van het constant navolgen van andermans veranderingen die impact hebben op mijn machinerie.

Hoe staan anderen daarin qua insteek en/of andere, cq alternatieve oplossing ?

Nog even gescheckt met nmap --script ssl-enum-ciphers -p 465 smtp.freedom.nl en idd, de mailserver van Freedom komt nu terug dat alleen nog de volgende - meer geavanceerdere TLS - ciphers mogelijk zijn:

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (rsa 4096) - A
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (rsa 4096) - A
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (rsa 4096) - A
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (rsa 4096) - A
  • TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 4096) - A

Sterker, as of date 20feb23 17u30 - worden op poort 465 worden op/vanuit betreffende systeemclient, alleen nog de volgende ciphers (in)geslikt:

  •   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

  •    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  •   TLS_RSA_WITH_AES_256_GCM_SHA384
  • Ciphers die mijn “ssmtp/sendmail” programma simpelweg niet heeft en dus ook niet kan uitvoeren.

Prima als keuze en optie maar ongewenst omdat dit defacto zegt dat alles wat dit niet kan, dan de vuilnisbak in kan. Was het voorheen dat poort/programma je blokkeerde, wordt het nu dus die daarin gebruikte certificeringssleutel. Je mag dus alleen mailen indien het op die opgelegde manier gaat.

3

Ben niet bekend met QNAP, maar wellicht kun je nieuwe certificaten aanmaken die wel voldoen?

Die nare vermoeidheid die je beschrijft, herken ik :wink:

4

Beter nog, dat hij TLS v1.2 en 1.3 ondersteunt.
Voor je het weet, gaat de lat weer hoger.

5

tldr; gefrustreerd en/of hoe is dit bespreekbaar te maken om te veranderen ?

Ik doe keurig TLV1_2 maar mijn software beschikt niet over de complexere ciphers die Freedom nu vereist.

Ik vrees ook voor die RAT-race en ook hier merk ik en irriteer ik mij aan het voortdurende (ongevraagd) “verbeteren”. Iets dat ik snap voor, met en naar communicatie van derden buiten Freedom.

Met een andere provider heb ik een andere ‘ruzie’ omdat Google de mail van onze domeinen is gaan afwijzen omdat we niet voldoen aan “de” cq. hun (gmail) SPF/DKIM eisen. Niet moeilijk maar het geeft heel veel gedoe, vooral omdat we ermee worden geconfronteerd en ineens mails krijgen van afnemers waarom wij niet meer antwoorden (en van Google we maa één mail - in de spammap - krijgt dat die zaken voortaan afkeurt).

In dit geval van Freedom gaat het om mijn eigen interne mailbox bestemd voor server alert-boodschappen en dus eigenste mail die volgens normern kennelijk zo veilig moet zijn dat het daarmee niet meer te gebruiken is.
Om nu weer een eigen mailserver te moeten gaan inrichten, lijkt mij ook weer niet echt de bedoeling van die opgelegde “vrijheid”. De meerwaarde van Freedom is dan serieus wel foetsie en ga ik wel mailen met Protons interface.

Vraag is òf en hoe dit beleid te veranderen en/of dat Freedom uitluitend freedom is met wat zij verstaan onder vrijheid als bepaalt door een ander ?

6

Certificaat staat hier los van. Freedom “zegt” simpel dat ze sinds de “verbetering”, alleen nog hun encryptie - 256bit of hoger - ondersteunen.

7

Onafhankelijk van hoe wij/ik over de gemaakte keuze denken lijkt het me op z’n minst wenselijk dat keuzes met dit soort gevolgen op z’n minst vooraf worden gecommuniceerd aangezien iets wat werkte ineens niet meer werkt (alsof de spec van de benzine wordt aangepast en jouw iets oudere auto daardoor niet meer functioneert). Ik ben benieuwd naar het echte antwoord/standpunt van Freedom, dus niet een “het is nu jouw probleem geworden” antwoord maar een duidelijke beleidskeuze met een communicatieplan. Ik heb namelijk wel eens eerder meegemaakt dat een door een enthousiaste techneut gemaakte aanpassing tijdens onderhoud terug werd gedraaid (tijdelijk, tot iedereen fatsoenlijk tijd had gehad om zich voor te bereiden) omdat er iets te enthousiast was gehandeld en de gevolgen voor de gebruikers niet goed waren ingeschat.

2 likes
8

De genoemde ciphers in de zijn nou niet bepaald the-latest-and-greatest, logisch dat die op een gegeven moment uitgefaseerd worden. Beetje jammer van de communicatie inderdaad, maar dat is wat mij betreft onderdeel van zo’n dienst elders afnemen. Daar ben je als klant niet mee geholpen natuurlijk, maar ja.

Wat je zou kunnen doen:

  1. Kijken of je je client kan updaten (of in ieder geval de openssl versie daarvan) zodat je nieuwere ciphers beschikbaar hebt
  2. Zelf een proxy opzetten die de (zwakkere) ciphers toestaat en aan de andere kant een sessie opzet met de mailserver met de daar ondersteunde ciphers.
9
  • Item 1: FF ivm alerts de - uitgaande, ja niet eens erg oude - client updaten is uiterst ingewikkeld omdat we expliciet niet de daarmee verbonden andere riedel - die niets te maken heeft met mail - willen gaan doorlopen.
  • Item 2: Ja, dus weer een eigen mailserver gaan draaien die dan externe mail moet gaan proxy’en. Iets dat we een paar jaar geleden juist de deur hadden uitgedaan. Dit kon ‘beter’ prima elders en voorkomt ook divers misbruik.

Ik ben het helemaal eens met veiligheid als uitgangspunt maar niet dit als doel ten koste van vrije keuzes. Wanneer ik thuis ongezien naak wil rondlopen moet ik dat zelf weten.
Voor mij begint het de contouren te krijgen van dat je als burger links- of rechtsom, in je eigen huis zal voldoen aan (andermans) gestelde eisen zonder dat wordt gekeken of die eisen zinnig/redelijk zijn.
Eerst hebben we dat poort25, SSL en TLSV1_x gedoe gehad en nu dat daarboven op gaat dit verder met specifieke ciphers.

Het is best mogelijk en doenbaar dat bepaalde ciphers niet kunnen worden gebruikt om naar/met anderen te mailen en hou het intern verder simpel. Wat het TLS vinkje bij MijnFreedom nog doet, ontgaat mij nu volledig.

10

Ik mijn beleving is vrijheid niet, dat ze eindeloos oude meuk blijven ondersteunen.
Wel is het handig, dat dit soort dingen duidelijk en op tijd aangekondigd zijn.
Wat heel erg vriendelijk zou zijn, dat er een knopje is in ‘mijn freedom’
Waar je alvast de lat hoger kunt leggen.
Dan kun je zelf bepalen, wanneer je over stapt. (binnen een tijdvak)
Je kunt dan ook even terug, als het nog niet lukt.

11

Nee, dat is niet wat ik bedoelde. Wat ik bedoelde is een simpel klein programma wat de sessie vanaf je qnap oppakt, aan de achterkant een nieuwe sessie richting freedom opzet en de data tussen die twee uitwisselt. Mogelijk bestaat er al wat voor en anders is het met een beperkte hoeveelheid python code wel te maken. Het zal ongetwijfeld wat geneuzel rondom certificaten geven enzo, maar dat is meestal wel oplosbaar. Het is uiteraard wel iets wat je zelf ergens moet hosten, maar eenmaal opgezet heb je er geen omkijken meer naar.

Overigens: Als de software zo oud is dat deze ciphers niet ondersteund worden kan je je ook afvragen hoe veilig je data op die qnap is.

12

ik voel een belerend vingertje met “Oude meuk” of dat een ontstane disfunctie (ineens) een eigen tekortkoming zou zijn.
Zo ja waar en volgens wiens maatstaven wordt dat weer door & voor wie dan wanneer bepaalt ?
Hierbij ook kijken naar het doel en het ondersteunen vooral hier bestaat uit gangbare ciphers - opzettelijk of bewust ? - wegmieteren.

En ja, het is kennelijk mijn probleem dat mijn leveranciers hun ooit vernieuwende meuk aan mij geboden, na een paar jaar niet (meer) willen/kunnen bijwerken en ik inmiddels zo wel in hun eendenfuik zit te zwermen. Iets dat we elders vaker zien waardoor prima zaken, stelselmatig waardeloos worden gemaakt zodat er nieuw spul in de dan ontstane - voorheen ondenkbare - kaders kan worden afgezet.

Ik weet nog niet of en hoe Freedom hier precies in staat. Ik hoop oprecht dat zij niet dat manipulatieve pad (wij “bepalen” wat …vul-in… is) gaan volgen. Juist haar onafhankelijkheid is voor mij primair reden was dat ik koos voor een partij anderen niet in die absolute autoriteit (na)volgt.

Ik kan anders dan net zo goed (weer) mijn eigen zooi gaan draaien en heb voldoende aan een whatever provider die mijn mail (aan/van anderen) ergens op/in het publieke internet kan kwakken.

Vrijheid is ook dat ook bieden met idd desnoods een “your-choice” knopje dat in mijn tijdsbeleving sws minimaal 6 maanden tot een jaar kan worden aangekondigd indien de partij ‘hautain’ bepaalt wat iemands keuze is.

13

Er iets tussen zetten, los van idd dat gehannes, is niet echt een optie op die zg aangemerkte onveilige qnap die - zelf geïnitieerd - uitsluitend een uitgaande alertmail stuurt. Een mail die elke dag zei: “OKidokie proces 123 is in orde”.

Dat er iets tussen zetten en zg geen omkijken naar hebben is juist het probleem omdat wij inmiddels afscheid hadden genomen van eigen mailservers, afhandeling en daarmee juist alle rotzooi die daartussen zat etc.etc.
Die QNAP authenticeert zich excpliciet op -en in het eigen mailadres als ondergebracht van/bij Freedom. Nogmaals, de (alert)mail daarvan is uitsluitend voor onszelf (intern) en gaat niet eens verder niet naar de boze buitenwereld. Freedom weigert simpelweg mijn eigen mail in te slikken en legt mij hun veranderende voorwaarden op.

Wat ik vooral ter discussie wil stellen de eenzijdige actie die er lijkt plaats te vinden en iets dus een eigen probleem wordt gemaakt omdat de Freedom dat - mogelijk zich van geen kwaad bewust - een valide gedachte vond:

  1. Ik zou willen dat dit soort veranderingen van werking - bvk ook technisch - kunnen worden doorgesproken
  2. Eventuele uitkomsten dan worden voorgesteld en aangekondigd
  3. Voldoende tijd is om op gestelde wijzigingen in te - kunnen - spelen.
14

Zo is het niet bedoelt.
Van Freedom wordt ook verwacht dat ze alles veilig houden.

15

Absoluut, ik verwacht daarbij ook dat ze uitleggen wat ze, en waarom, gaan uitschakelen/aanpassen en dat zoiets, behoudens emergency situaties, niet op zeer korte termijn of zelfs pas achteraf communiceren (of helemaal niet en zoals nu proefondervindelijk door iemand moet worden ervaren). Vandaar dat ik ook graag, bij voorkeur van het management, van Freedom internet een standpunt in zou wil lezen of hier inderdaad de normale en gewenste weg is bewandeld, of dat er hier iets heel erg mis is gegaan en hersteld gaat worden om later alsnog gecontroleerd, na een overgangsperiode, te worden doorgevoerd. Tot die tijd blijft het naar mijn idee enigszins speculatie over het waarom van de situatie en dat is jammer, want als er een fout is gemaakt en dit niet zo had moeten lopen speculeren we misschien voor niets de verkeerde kant op, als het zo bedoeld was dan kunen we alsnog losbarsten :smile:

2 likes
16

:+1: Goed genuanceerd dat (ondanks - mijn - frustratie) het niet goed is om te speculeren met hoe en waarom.

Ik ga ook zeker de helpdesk (be)vragen welke weg hier(in) is genomen want om nu hier op een koude kermis on-the-fly gaan proberen voor mijn QNAP en andere clients, een nieuwere sendmail te crosscompilen (als dat al kan), zijn een paar bruggen te ver. Geen idee ook nog hoe ik dat zou moeten moet fabrieken met/voor de benodigde TLS versie.
Op dit moment krijg ik niet veel meer dan een antwoord in orde van moet/had je maar nieuwe(re) spullen doen.

Dat Freedom alles veilig houdt is generiek een goed uitgangspunt maar niet omdat zij vooroplopend gaat bepalen wat die veiligheid dan is en ik als gebruiker dat maar moet inslikken. Wanneer het gaat om veiligheid en controle daarvan, heb ik nog wel een ander rijtje t.a.v. authenticatie, autorisatie, administratie en implementatie.

17

Gmail en outlook.com geven al heel lang problemen met dit TLS verhaal met mailen vanaf een MFP.
Bij steeds meer klanten is dit (vaak plotseling) absoluut niet meer weekend te krijgen en hebben we maar geadviseerd een goedkope NAS in het netwerk te hangen en te gaan scannen naar folder.

18

tldr; blokkeren van zwakkere mail-ciphers is een “Freedom” keuze. Prima voor externe mail en kolder dat op te gaan leggen voor intranet - gebruikte - mail.

Het TLS verhaal hier is dat bepaalde “zwakkere” coderingsmethoden (zg ciphers) ondanks dat die via TLSV1.2 worden verstuurd, plots niet meer worden geaccepteerd. Het is hier Freedom die dat oplegt aan haar gebruikers en zo mijn mail op/in/aan de eigen mailbox blokkeert.
Dit nog los dat ik ergens flabbergasted ben dat ik dus geen mail mag deponeren op/in mijn eigen mailbox die ik juist voor dat doel heb gemarkeerd dat die zonder TLS moet/mag werken.

Dat een mailprovider extern ontvangen mail blokkeert welk niet voldoet aan herkomsteisen (dkim/spf/dns) en coderingsafspraken (ciphers/ssl/tls) en/of laat staan spamlijsten of geolocatie; is wmb iets dat tussen providers speelt. Dat Google of Microsoft bv mail weigert van bv Freedom-IP’s is dan hun (bewuste) keuze. Providers doen dat met laat ik het “eufemistisch” zeggen om in hun eigenzinnigheid; hun ‘gebruikers te beschermen’.
Dat ‘beschermen’ is vooral de vermoorde onschuld dat mailproviders zelf geen geziek en gezeik t.a.v. hun ‘dienstbaarheid’ willen hebben.

Veiligheid als uitgangspunt nastreven is prima maar dat moet niet uitmonden op doordrijven door in de communicatie van de gebruiker ook overal controles en sloten te plaatsen op de binnendeuren. Prima wanneer een gebruiker dat zou willen maar dat moet dan een keuze zijn wanneer iemand in de eigen mailbox whatever mail wil plaatsen.

19

Zo te zien volgt Freedom (of eigenlijk Soverin denk ik?) de richtlijnen van het NCSC hierin:

Zowel de protocollen (TLS versies) als de gebruikte algoritmes (ciphers en hashes) zijn continu aan verandering onderhevig. Er komen nieuwe bij (met de aanname dat die veiliger zijn) en er vallen af (vaak naar aanleiding van theoretisch/praktisch bewijs dat ze niet meer veilig genoeg zijn). Voor oude apparaten houd het daardoor op een gegeven moment gewoon op. Ik heb hier ook nog een Nokia E90 Communicator en een Jolla 1 telefoon die om exact die reden bijna niets meer op het internet kunnen benaderen.

De Freedom mailservers als intranet beschouwen klopt denk ik ook niet helemaal. Ze hangen aan het grote boze internet en zullen op basis daarvan aan bepaalde beveiligingseisen moeten voldoen. Bedenk ook dat het toestaan van de oude ciphers (die voor jou nu nodig zouden zijn) ook betekend dat de beveiliging voor andere Freedom klanten wordt verlaagd. De balans tussen die twee is (in ieder geval op de plaatsen waar ik gewerkt heb) een continue afweging: Vanuit commercie wil je dat zo veel mogelijk apparaten van je diensten gebruik kunnen maken, en vanuit de techniek wil je dat wat je aanbiedt aan bepaalde veiligheidsstandaarden voldoet, welk bedrijf wil er immers op security.nl terecht komen met een artikel dat z’n (mail)servers slecht beveiligd zijn?
Oude ciphers gebruiken wordt daarbij dan vaak ook als schijnveiligheid gezien: Je denkt dat je veilig bent (je gebruikt immers cryptografie), maar feitelijk ben je niets veiliger dan een plain-text verbinding omdat de algoritmes achterhaald zijn.

2 likes
20

Mooi, algemeen, verhaal.
tldr; richlijnen (?) mogen niet maken dat anderswillenden daartoe worden gedwongen.

Ik snap dat Freedom ‘richtlijnen’ voor een veilig internet als haar moreel te hanteren doel ziet. Ik vermoed eerder dat er onvoldoende - wederom technisch als keuze - wordt bekeken wat zij (hier: Soverin) veroorzaakt.
Laat staan dat dit als keuze is (voorgelegd) aan gebruikers. Het is het helaas bekende: “U doet naar wat wij goed achten” en dan wegduiken achter een richtlijn.

Verder denk ik helemaal niets over (andermans veronderstelde) mail-veiligheid en zie MIJN mail-aansluiting toch echt als MIJN intranet.
Ook al dat ik op die mailbox expliciet TLS al had uitgeschakeld. Het is heel moeilijk om als organisatie een vinkje te laten gebruiken of iemand wel of niet; en dan met welke SSL standaard die een Freedom voorziening wil gaan gebruiken.

Ik had/heb met die mailboxen ook geen enkele behoefte om met anderen dan onszelf te kunnen/gaan mailen. Ik zou juist eerder willen dat ik zelf kan besluiten wie wel en niet vanuit dan welk IP adres daarop mail kan/mag aanbieden.
Dat afdekken met een ‘encryptie’-verhaal is idd vooral de schijnveiligheid ophouden. Sws kan een overheidsinstantie, desgevraagd, prima meekijken met mijn TLS/SSL verkeer.

Wanneer het gaat om veiligheid moet vooral de mogelijkheid bieden dat iemand zelf kan besluiten om een echt deur dichthouden. Hetzij fysiek, het zij op grond van identificatie of (gebrek aan) coderingsleutels. Wanneer ik mijn part wil mailen met RSA64 bit, zou ik dat als vrijheid echt zelf moeten weten. Net zoals ik zelf kan besluiten of ik de inhoud ga encrypten.

Freedom moet idd standaard uit de doos haar gebruikers de best mogelijk; veilige en betrouwbare mailvoorziening leveren. Hierbij niet vervallen in de situatie dat zij daarin bewust andersdenkende gebruikers, dit als haar maatstaf gaat opleggen en zo maar dingen (voor)beschikt. Het is best lullig te ontdekken dat er niet kan worden gemaild omdat iets/iemand dit zomaar besloten heeft.

Nogmaals: vrijheid is dat mensen binnen de vrijheden van anderen, zelf hun zaken - juist ook als het gaat om veiligheid - kunnen bepalen.

Terzijde, ik zie net een reactie van Freedom dat zij met Soverin in overleg gaat. Ook omdat haar verteld, volgens Soverin er geen accounts zouden (?) zijn die zouden mailen met de vervallen (“oude meuk”) ciphers.
Dit laatste - niet kunnen mailen - klopt formeel & technisch ook, want een mailsessie kan/komt idd niet eens meer tot stand. Dit nog even los dat imo een organisatie niet zou moeten mogen monitoren op wat gebruikers en dan hoe, doen.

Ik heb ook het :+1: document doorgenomen en lees daarin dat mijn “oude meuk” ciphers, zoals o.a. TLS_DHE_RSA_WITH_AES_128_CBC_SHA & TLS_DHE_RSA_WITH_AES_256_CBC_SHA volgens stelling, nog voldoende veilig zouden zijn. Waarom dat Freedom dan ook die ‘sleutels’ weigert is best een discussie waard.