Eerst maar even een algemene opmerking die waarschijnlijk bij de vragensteller bekend is maar mogelijk bij andere niet.

TLS 1.0 en TLS 1.1 worden ook niet aangeraden door de NCSC. ALs er vanwege connectiviteits redenen toch vastgehouden moet worden aan TLS 1.0 en bepaalde oude cyphersuites, dan moeten die versies / cyphersuites aangezet worden op de server.
Dus kan de NCSC richtlijn niet gevolgd worden en we hebben te maken met twee niet geheel te verenigen eisen.

Wat kan dan wel helpen om de risico's te verminderen :

1) Een speciale mailserver of een andere TCP poort voor zelf beheerde oude apparaten (bijvoorbeeld multifunction printers) die nog mail met TLS 1.0 of oude cyphersuites gebruiken. Met behulp van firewall rules worden deze port / server alleen beschikbaar gesteld aan de oude apparaten, dus een whitelist van IP addressen die de oude versie mogen gebruiken.

2) Het gedurende langere periode loggen van de gebruikte cyphersuites en dan beoordelen van niet of weinig gebruikte cyphersuites. (ook nodig voor punt 1 om deze apparaten te ontdekken). Dan kunnen na een log periode alle niet gebruikte cyphers uitgezet worden.

3) Het disablen van cyphersuites met bekende problemen. Natuurlijke de NULL cypher maar ook

4) Het instellen van de prioriteitslijst, dat was de bovenstaande vraag. Een directe lijst voor exim / GNUTLS heb ik niet gevonden.
De beste referentie vind ik:
https://wiki.surfnet.nl/pages/viewpage.action?pageId=10125388

Individuele cyphersuites met hun status worden aan gegeven bij https://ciphersuite.info/
Ik hoop dat hiermee je verder geholpen te hebben.
Niet met een prioriteits lijst maar wel wat handvatten om die te maken.

Let zowie zo met exim op CVE-2019-15846.

Wat zegt vraag@internet.nl erover (ja, dat is echt hun mailadres)?

TS hier

@willem Dekker
Omdat wel versleuteling beter is dan geen versleuteling blijft TLS 1.0 nog even nodig. Als je mail niet aanneemt zonder STARTTLS, dan is het van belang dat mail kan worden bezorgd via een oude versleuting.

@17-04-2020, 23:06 door Anoniem
Niet gevraagd.

De NCSC volgorde is volgens internet.nl:

@allen
De NCSC documentatie legt uit wat de volgorde van ciphersuites zou moeten zijn. De vraag is welke oplossingen jullie hebben gekozen. GNUTLS heeft een enkele prioriteitstring die allerlei onderdelen opknipt. Je kan dus helaas niet zoiets als TLS_AES256_GCM_SHA384 (TLSv1.3) invullen. GNUTLS knipt het op in algoritme, HMAC, key exchange, signing, etc.

De prioriteitstring in begint met opzet met een leeg blad: NONE betekent dat alles naar niets gereset wordt. %SERVER_PRECEDENCE geeft aan dat de server de volgorde aangeeft. Het interessante deel is natuurlijk wat er tussenin staat.

De volgende onderdelen lijken mij van belang:

Nu moeten ze nog worden samengevoegd tot een geheel dat zowel voldoet aan de NCSC richtlijnen als aan een praktische ondersteuning voor zoveel mogelijk nog veel in gebruik zijnde of belangrijke legacysystemen.

Let op: deze string is geen aanbeveling voor productiesystemen!
gnutls-cli -l --priority NONE:PFS:%SERVER_PRECEDENCE:\
+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+ECDHE-ECDSA:+ECDHE-RSA:+RSA:-DHE-RSA:\
+AES-256-GCM:+CHACHA20-POLY1305:+AES-128-GCM:+AES-256-CBC:-AES-128-CBC:-AES-256-CCM:-AES-128-CCM:\
+AEAD:+SHA384:+SHA256:+SHA1:\
+GROUP-SECP384R1:+GROUP-SECP256R1:+GROUP-X25519:+GROUP-FFDHE4096:+GROUP-FFDHE3072:+GROUP-FFDHE2048

Specifiek uitgeschakeld zijn DHE-RSA, AES-128-CBC, AES-256-CCM, AES-128-CCM. Die zijn hopelijk niet nodig voor legacy systemen. Voor TLS 1.0 is AES-256-CBC aanwezig. TLS1.0:RSA_AES_256_CBC_SHA1:256 wordt daarmee ondersteund. De signing heb ik niet apart opgegeven in de string.

Met GNUTLS 3.6.7 levert het dit op:

Je kan zo al zien dat dit niet een heel aantrekkelijke volgorde in GCM/CBC en in hashes oplevert - als we mogen aannemen dat de volgorde correct is weergegeven. Daarnaast is het een mix van TLS versies, wat ook een mix van volgordes kan opleveren. Een complicerende factor is dat bepaalde suites ok zijn in TLS 1.3, maar een stuk minder in een lagere TLS versie. Zo is de TLS 1.3 suite incompleet en is DHE er helemaal niet meer.

Het kan beter, dus proberen we dit: Let op: deze string is geen aanbeveling voor productiesystemen!

Door -GROUP-FFDHE2048 voor +DHE-RSA en +RSA te zetten wordt DH-2048 voor die algoritmes uitgeschakeld.

Ondanks de opgegeven volgorde staat SHA1 soms toch hoger dan SHA256. Er zijn ook nog tal van complicaties/combinaties die niet aan de orde zijn geweest maar wel van belang zijn.

internet.nl geeft nu een 100% score, met de opmerking over het uitfaseren van TLS 1.0 en TLS 1.1. Nu gaat het niet per se om een 100% score, maar om het zoveel mogelijk voldoen aan de NCSC richtlijnen en tegelijkertijd ook compatible blijven met oude mail servers die mail naar onze MX sturen. Wie ziet er nog mogelijkheden met een andere priority string voor verbetering?

Probleem moet je anders benaderen: waarom zou jij je mail servers vatbaar maken voor aanvallen op kwetsbaarheden?
Google, Microsoft en nog vele andere mta bouwers ondersteunen TLS 1.0 niet meer dus dwing de mail zenders om hun mail platformen te updaten/voorzien van juiste crypto.

Daarnaast ben ik van mening dat platformen die nog steeds mail sturen en TLS1.0 gebruiken aan de schandpaal mogen, helaas dat de AVG daar dan weer een stokje voor heeft gestoken :(

@RaceAap
TS hier

gmail.com en outlook.com ondersteunen TLS 1.0 op de MX server. Voor uitgaande mail weet ik het niet.

Misschien dacht je aan browsers? Voor die categorie heeft het weinig nut nog TLS 1.0 te ondersteunen, want er is geen up-to-date browser meer die dat vereist. Voor web servers zou ik gerust TLS 1.2 en 1.3 ondersteunen en de rest uitschakelen.

Test sites zoals https://www.immuniweb.com/ssl/ functioneren als schandpaal.

Waarom NIET? Transport encryptie van e-mail is toch alleen maar een "nice to have" functie. Leuk als het werkt, pech
als het toch mis gaat. Als encryptie of authenticiteit belangrijk is moet het end-to-end zijn en dat is dit niet.

Het uitschakelen van TLS 1.0 en 1.1 heeft de hoeveelheid ongewenste e-mail doen dalen hier. Dus ja, sommige verzenders kunnen hun mail niet meer bij je afleveren, maar dat is wellicht niet zo erg als het lijkt :-).

Zet gewoon heel die mailserver uit, dan ontvang je helemaal geen ongewenste e-mail meer!

Nee dat is heden ten dage geen nice to have, maar eerder een noodzaak. Aangezien niet iedereen met mail encryptie werkt ( of kan werken ) zoals GPG of andere varianten, is beveiligde transport noodzakelijk geworden.

Voor zeer vertrouwelijke zaken gebruik ik de e-mail niet, tenzij de overkant GPG begrijpt. Maar de rest hoeft ook niet leesbaar voor iedereen over het Internet.