Security Professionals - ipfw add deny all from eindgebruikers to any

GNUTLS en NCSC TLS richtlijnen

15-04-2020, 00:01 door Anoniem, 9 reacties
De NCSC heeft een jaar geleden de "ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS)" gepubliceerd:
https://www.ncsc.nl/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-transport-layer-security-tls

GNUTLS Priority strings documentatie: https://gnutls.org/manual/html_node/Priority-Strings.html
GNUTLS ciphers documentatie: https://gnutls.org/manual/html_node/Encryption-algorithms-used-in-the-record-layer.html

De standaard lijst voldoet niet aan NCSC volgens https://internet.nl, die o.a. gebruikt wordt in Debian 10 met Exim en
tls_require_ciphers

Ik ben benieuwd wat jullie gebruiken als zo compleet mogelijke GNUTLS priority list voor TLS ciphers van GNUTLS en of die voldoet aan NCSC's richtlijnen en TLS 1.0 t/m 1.3 ondersteunt. De ondersteuning voor TLS 1.0 is mogelijk nog nodig om mail aan te nemen van oudere systemen die mail sturen naar MX servers.

Het is makkelijk om een compliant lijst te maken door veel weg te laten, maar dat is een beetje vals spelen, want het moet wel werken in de praktijk, ook met oudere servers. Daarom graag alleen real world suggesties.

De prioriteit kan worden getest op de command line met
gnutls-cli -l --priority 'NONE:[..]:[..]'

NONE zorgt ervoor dat alles uitstaat, zodat je specifieke alles wat nodig is aan moet zetten.
Reacties (9)
16-04-2020, 23:36 door willem Dekker
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.
17-04-2020, 23:06 door Anoniem
Wat zegt vraag@internet.nl erover (ja, dat is echt hun mailadres)?
19-04-2020, 18:05 door Anoniem
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:
Good:
ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:
ECDHE-ECDSA-AES256-SHA384 [1.2]
ECDHE-ECDSA-AES256-SHA [1.0]
ECDHE-ECDSA-AES128-SHA256 [1.2]
ECDHE-ECDSA-AES128-SHA [1.0]
ECDHE-RSA-AES256-SHA384 [1.2]
ECDHE-RSA-AES256-SHA [1.0]
ECDHE-RSA-AES128-SHA256 [1.2]
ECDHE-RSA-AES128-SHA [1.0]
DHE-RSA-AES256-GCM-SHA384 [1.2]
DHE-RSA-CHACHA20-POLY1305 [1.2]
DHE-RSA-AES128-GCM-SHA256 [1.2]
DHE-RSA-AES256-SHA256 [1.2]
DHE-RSA-AES256-SHA [1.0]
DHE-RSA-AES128-SHA256 [1.2]
DHE-RSA-AES128-SHA [1.0]

Phase out:
ECDHE-ECDSA-DES-CBC3-SHA [1.0]
ECDHE-RSA-DES-CBC3-SHA [1.0]
DHE-RSA-DES-CBC3-SHA [1.0]
AES256-GCM-SHA384 [1.2]
AES128-GCM-SHA256 [1.2]
AES256-SHA256 [1.2]
AES256-SHA [1.0]
AES128-SHA256 [1.2]
AES128-SHA [1.0]
DES-CBC3-SHA [1.0]

@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
gnutls-cli -l --priority 'NONE:[..]:[..]:%SERVER_PRECEDENCE
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:

NONE:PFS:%SERVER_PRECEDENCE
+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0
+ECDHE-ECDSA:+ECDHE-RSA:+RSA
+AES-256-GCM:+CHACHA20-POLY1305:+AES-128-GCM:+AES-256-CBC
+AEAD:+SHA384:+SHA256:+SHA1
+GROUP-SECP384R1:+GROUP-SECP256R1:+GROUP-X25519:+GROUP-FFDHE4096:+GROUP-FFDHE3072:+GROUP-FFDHE2048

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:

Cipher suites for 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
TLS_AES_256_GCM_SHA384 0x13, 0x02 TLS1.3
TLS_CHACHA20_POLY1305_SHA256 0x13, 0x03 TLS1.3
TLS_AES_128_GCM_SHA256 0x13, 0x01 TLS1.3
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 0xc0, 0x2c TLS1.2
TLS_ECDHE_ECDSA_CHACHA20_POLY1305 0xcc, 0xa9 TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA1 0xc0, 0x0a TLS1.0
TLS_ECDHE_ECDSA_AES_256_CBC_SHA384 0xc0, 0x24 TLS1.2
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256 0xc0, 0x2b TLS1.2
TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2
TLS_ECDHE_RSA_CHACHA20_POLY1305 0xcc, 0xa8 TLS1.2
TLS_ECDHE_RSA_AES_256_CBC_SHA1 0xc0, 0x14 TLS1.0
TLS_ECDHE_RSA_AES_256_CBC_SHA384 0xc0, 0x28 TLS1.2
TLS_ECDHE_RSA_AES_128_GCM_SHA256 0xc0, 0x2f TLS1.2
TLS_RSA_AES_256_GCM_SHA384 0x00, 0x9d TLS1.2
TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 TLS1.0
TLS_RSA_AES_256_CBC_SHA256 0x00, 0x3d TLS1.2
TLS_RSA_AES_128_GCM_SHA256 0x00, 0x9c TLS1.2

Protocols: VERS-TLS1.3, VERS-TLS1.2, VERS-TLS1.1, VERS-TLS1.0
Ciphers: AES-256-GCM, CHACHA20-POLY1305, AES-256-CBC, AES-128-GCM
MACs: SHA1, AEAD, SHA384, SHA256
Key Exchange Algorithms: ECDHE-ECDSA, ECDHE-RSA, RSA
Groups: GROUP-SECP256R1, GROUP-SECP384R1, GROUP-SECP521R1, GROUP-X25519, GROUP-FFDHE2048, GROUP-FFDHE3072, GROUP-FFDHE4096, GROUP-FFDHE6144, GROUP-FFDHE8192
PK-signatures: SIGN-RSA-SHA256, SIGN-RSA-PSS-SHA256, SIGN-RSA-PSS-RSAE-SHA256, SIGN-ECDSA-SHA256, SIGN-ECDSA-SECP256R1-SHA256, SIGN-EdDSA-Ed25519, SIGN-RSA-SHA384, SIGN-RSA-PSS-SHA384, SIGN-RSA-PSS-RSAE-SHA384, SIGN-ECDSA-SHA384, SIGN-ECDSA-SECP384R1-SHA384, SIGN-RSA-SHA512, SIGN-RSA-PSS-SHA512, SIGN-RSA-PSS-RSAE-SHA512, SIGN-ECDSA-SHA512, SIGN-ECDSA-SECP521R1-SHA512, SIGN-RSA-SHA1, SIGN-ECDSA-SHA1

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!
gnutls-cli -l --priority NONE:PFS:%SERVER_PRECEDENCE:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+ECDHE-ECDSA:+ECDHE-RSA:-GROUP-FFDHE2048:+DHE-RSA:+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

TLS_AES_256_GCM_SHA384 0x13, 0x02 TLS1.3
TLS_CHACHA20_POLY1305_SHA256 0x13, 0x03 TLS1.3
TLS_AES_128_GCM_SHA256 0x13, 0x01 TLS1.3
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 0xc0, 0x2c TLS1.2
TLS_ECDHE_ECDSA_CHACHA20_POLY1305 0xcc, 0xa9 TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA1 0xc0, 0x0a TLS1.0
TLS_ECDHE_ECDSA_AES_256_CBC_SHA384 0xc0, 0x24 TLS1.2
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256 0xc0, 0x2b TLS1.2
TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2
TLS_ECDHE_RSA_CHACHA20_POLY1305 0xcc, 0xa8 TLS1.2
TLS_ECDHE_RSA_AES_256_CBC_SHA1 0xc0, 0x14 TLS1.0
TLS_ECDHE_RSA_AES_256_CBC_SHA384 0xc0, 0x28 TLS1.2
TLS_ECDHE_RSA_AES_128_GCM_SHA256 0xc0, 0x2f TLS1.2
TLS_DHE_RSA_AES_256_GCM_SHA384 0x00, 0x9f TLS1.2
TLS_DHE_RSA_CHACHA20_POLY1305 0xcc, 0xaa TLS1.2
TLS_DHE_RSA_AES_256_CBC_SHA1 0x00, 0x39 TLS1.0
TLS_DHE_RSA_AES_256_CBC_SHA256 0x00, 0x6b TLS1.2
TLS_DHE_RSA_AES_128_GCM_SHA256 0x00, 0x9e TLS1.2
TLS_RSA_AES_256_GCM_SHA384 0x00, 0x9d TLS1.2
TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 TLS1.0
TLS_RSA_AES_256_CBC_SHA256 0x00, 0x3d TLS1.2
TLS_RSA_AES_128_GCM_SHA256 0x00, 0x9c TLS1.2

Protocols: VERS-TLS1.3, VERS-TLS1.2, VERS-TLS1.1, VERS-TLS1.0
Ciphers: AES-256-GCM, CHACHA20-POLY1305, AES-256-CBC, AES-128-GCM
MACs: SHA1, AEAD, SHA384, SHA256
Key Exchange Algorithms: ECDHE-ECDSA, ECDHE-RSA, DHE-RSA, RSA
Groups: GROUP-SECP256R1, GROUP-SECP384R1, GROUP-SECP521R1, GROUP-X25519, GROUP-FFDHE3072, GROUP-FFDHE4096, GROUP-FFDHE6144, GROUP-FFDHE8192, GROUP-FFDHE2048
PK-signatures: SIGN-RSA-SHA256, SIGN-RSA-PSS-SHA256, SIGN-RSA-PSS-RSAE-SHA256, SIGN-ECDSA-SHA256, SIGN-ECDSA-SECP256R1-SHA256, SIGN-EdDSA-Ed25519, SIGN-RSA-SHA384, SIGN-RSA-PSS-SHA384, SIGN-RSA-PSS-RSAE-SHA384, SIGN-ECDSA-SHA384, SIGN-ECDSA-SECP384R1-SHA384, SIGN-RSA-SHA512, SIGN-RSA-PSS-SHA512, SIGN-RSA-PSS-RSAE-SHA512, SIGN-ECDSA-SHA512, SIGN-ECDSA-SECP521R1-SHA512, SIGN-RSA-SHA1, SIGN-ECDSA-SHA1

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?
20-04-2020, 10:16 door RaceAap
Door Anoniem: TS hier

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 :(
20-04-2020, 10:53 door Anoniem
@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.
20-04-2020, 11:10 door Anoniem
Door RaceAap:
Probleem moet je anders benaderen: waarom zou jij je mail servers vatbaar maken voor aanvallen op kwetsbaarheden?

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.
20-04-2020, 11:16 door Anoniem
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 :-).
20-04-2020, 11:58 door Anoniem
Door Anoniem: 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!
20-04-2020, 11:59 door RaceAap
Door Anoniem:
Door RaceAap:
Probleem moet je anders benaderen: waarom zou jij je mail servers vatbaar maken voor aanvallen op kwetsbaarheden?

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.

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.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.