Security Professionals
- ipfw add deny all from eindgebruikers to any
GNUTLS en NCSC TLS richtlijnen 2021
15-05-2021, 01:37 door Anoniem, 33 reacties
NCSC heeft eerder dit jaar nieuwe TLS richtlijnen uitgegeven.
Nederlands: https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1
Engels: https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1
In GNUTLS kun je een cipher string instellen waarmee je cipher suites kunt bepalen.
Alleen TLS 1.3 is nu nog "good" en TLS 1.2 wordt als "sufficient" gezien.
Dit is een voorbeeld van een strikte cipher string voor GNUTLS (gnutls-cli 3.6.7):
CCM en CBC en FFHDE2048 moeten worden uitgeschakeld om gebruik te voorkomen.
Output sslscan 2.0.10 (openssl 1.1.11dev) van een Exim server met bovenstaande string:
Tests zijn gedaan met Debian 10.
Zichtbaar is dat CBC en CCM zijn uitgeschakeld. TLS 1.3 is groen en alle suites voor TLS 1.2 zijn groen.
Specifiek voor mail servers is alles behalve TLS 1.2 en 1.3 afwijzen vaak niet een haalbare kaart. Web servers kun je praktisch wel beperken tot alleen die versies.
Zie je nog verbeteringen in de string qua volgorde, inhoud of compactheid?
Nederlands: https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1
Engels: https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1
In GNUTLS kun je een cipher string instellen waarmee je cipher suites kunt bepalen.
Alleen TLS 1.3 is nu nog "good" en TLS 1.2 wordt als "sufficient" gezien.
Dit is een voorbeeld van een strikte cipher string voor GNUTLS (gnutls-cli 3.6.7):
NONE:PFS:%SERVER_PRECEDENCE:+VERS-TLS1.3:+VERS-TLS1.2:-NULL:+ECDHE-ECDSA:+ECDHE-RSA:+AES-256-GCM:+CHACHA20-POLY1305:+AES-128-GCM:-AES-256-CCM:-AES-128-CCM:-AES-256-CBC:-AES-128-CBC:+AEAD:+SHA384:+SHA256:-SHA1:+GROUP-SECP384R1:+GROUP-SECP256R1:+GROUP-X25519:+GROUP-FFDHE4096:+GROUP-FFDHE3072:-GROUP-FFDHE2048
CCM en CBC en FFHDE2048 moeten worden uitgeschakeld om gebruik te voorkomen.
Output sslscan 2.0.10 (openssl 1.1.11dev) van een Exim server met bovenstaande string:
Supported Server Cipher(s):
Preferred TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve P-256 DHE 256
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve P-256 DHE 256
Accepted TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve P-256 DHE 256
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384 DHE 3072 bits
Accepted TLSv1.2 256 bits DHE-RSA-CHACHA20-POLY1305 DHE 3072 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 DHE 3072 bits
Preferred TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve P-256 DHE 256
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve P-256 DHE 256
Accepted TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve P-256 DHE 256
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384 DHE 3072 bits
Accepted TLSv1.2 256 bits DHE-RSA-CHACHA20-POLY1305 DHE 3072 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 DHE 3072 bits
Tests zijn gedaan met Debian 10.
Zichtbaar is dat CBC en CCM zijn uitgeschakeld. TLS 1.3 is groen en alle suites voor TLS 1.2 zijn groen.
Specifiek voor mail servers is alles behalve TLS 1.2 en 1.3 afwijzen vaak niet een haalbare kaart. Web servers kun je praktisch wel beperken tot alleen die versies.
Zie je nog verbeteringen in de string qua volgorde, inhoud of compactheid?
Reacties (33)
Concrete voorbeelden van configuraties voor de diverse OS systems is iets wat ik mis. Nu moeten alle beheerders eerst dit document doornemen, alles snappen, en dan zelf de vertaling maken hoe dit in hun omgeving in de praktijk moet worden geïmplementeerd. Wanneer het NCSC voorbeelden zou posten met optimale configuraties, dan kunnen beheerders snel kijken of hun systeem up-to-date is, en aanpassingen maken indien nodig.
Wat ik mis zijn concrete voorbeelden als:
Debian Configuratie Mailserver X
file: /etc/mailserver-x.conf
Wat ik mis zijn concrete voorbeelden als:
Debian Configuratie Mailserver X
file: /etc/mailserver-x.conf
# SSL accepted variants
Cyphers Preferred TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve P-256 DHE 256
...
# Ignore list
...
Cyphers Preferred TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve P-256 DHE 256
...
# Ignore list
...
Op het eerste oog ziet dit er goed uit. Denk bij mailservers ook nog aan de DANE/TLSA standaard. Zowel de TLS als DANE-instellingen kunnen, volgens de NCSC richtlijn, getest worden via de website https://internet.nl/.
Door Anoniem: Concrete voorbeelden van configuraties voor de diverse OS systems is iets wat ik mis. Nu moeten alle beheerders eerst dit document doornemen, alles snappen, en dan zelf de vertaling maken hoe dit in hun omgeving in de praktijk moet worden geïmplementeerd. Wanneer het NCSC voorbeelden zou posten met optimale configuraties, dan kunnen beheerders snel kijken of hun systeem up-to-date is, en aanpassingen maken indien nodig.
Mee eens, dit is meer iets voor een security specialist.
In appendix C staat wel een lijst suites. Het is SSL library onafhankelijk beschreven. Het lijkt me niet nodig om iedere beheerder diverse wielen heruit te vinden, we kunnen op dit forum ook wat delen.
Voor Exim4 onder Debian met GNUTLS zijn de suites in te stellen via tls_require_ciphers = NONE:PFS:.. in exim4.conf.template.
Apache2 onder Debian gebruikt openssl: /etc/apache2/mods-available/ssl.conf
SSLProtocol -all +TLSv1.3 +TLSv1.2
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
SSLCipherSuite SSL TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
SSLOpenSSLConfCmd Curves prime256v1:secp384r1:X448:X25519
#openssl prime256v1 is secp256r1
SSLOpenSSLConfCmd DHParameters "/etc/apache2/dhparam.pem"
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
SSLCipherSuite SSL TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
SSLOpenSSLConfCmd Curves prime256v1:secp384r1:X448:X25519
#openssl prime256v1 is secp256r1
SSLOpenSSLConfCmd DHParameters "/etc/apache2/dhparam.pem"
Het voordeel van deze opzet van openssl is dat je complete suites in volgorde kan opgeven.
Resultaat met sslscan:
Supported Server Cipher(s):
Preferred TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253
Accepted TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384* Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305* Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256* Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-256 DHE 256
Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384* DHE 4096 bits
Accepted TLSv1.2 256 bits DHE-RSA-CHACHA20-POLY1305* DHE 4096 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256* DHE 4096 bits
Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA256 DHE 4096 bits
Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA DHE 4096 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA256 DHE 4096 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA DHE 4096 bits
Server Key Exchange Group(s):
TLSv1.3 128 bits secp256r1 (NIST P-256)
TLSv1.3 192 bits secp384r1 (NIST P-384)
TLSv1.3 128 bits x25519
TLSv1.3 224 bits x448
TLSv1.2 128 bits secp256r1 (NIST P-256)
TLSv1.2 192 bits secp384r1 (NIST P-384)
TLSv1.2 128 bits x25519
TLSv1.2 224 bits x448
Preferred TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253
Accepted TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384* Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305* Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256* Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-256 DHE 256
Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384* DHE 4096 bits
Accepted TLSv1.2 256 bits DHE-RSA-CHACHA20-POLY1305* DHE 4096 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256* DHE 4096 bits
Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA256 DHE 4096 bits
Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA DHE 4096 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA256 DHE 4096 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA DHE 4096 bits
Server Key Exchange Group(s):
TLSv1.3 128 bits secp256r1 (NIST P-256)
TLSv1.3 192 bits secp384r1 (NIST P-384)
TLSv1.3 128 bits x25519
TLSv1.3 224 bits x448
TLSv1.2 128 bits secp256r1 (NIST P-256)
TLSv1.2 192 bits secp384r1 (NIST P-384)
TLSv1.2 128 bits x25519
TLSv1.2 224 bits x448
TLSv1.3 ciphers zijn groen en de met * gemarkeerde suites voor TLSv1.2 zijn ook groen. Key exchange curves X448 en x25519 zijn groen. De NIST curves worden verdacht: https://en.wikipedia.org/wiki/Curve25519
Door DHE uit te schakelen heb je niet meer te maken met de zelf gegenereerde 4096 bit key.
openssl dhparam -out /etc/apache2/dhparam.pem 4096
Mozilla heeft een generator: https://ssl-config.mozilla.org/#server=apache&version=2.4.41&config=modern&openssl=1.1.1d&guideline=5.6
Met modern blijft alleen TLSv1.3 over. Dat is veruit het makkelijkste, maar oude browsers (o.a. op mobieltjes) zullen daar mogelijk problemen mee hebben. Mozilla's intermediate lijkt nog het meest op het advies van NCSC.
https://www.ssllabs.com/ssltest/index.html vergelijkt web sites met allerlei browsers en oudere versies. Daaruit blijkt dat DHE cipher suites niet worden gebruikt door die browsers. Daarom kunnen waarschijnlijk DHE cipher suites voor web servers worden geschrapt. Voor anderssoortige servers kun je in plaats van een zelf gegenereerde groep de RFC 7919 standaard finite field group ffdhe3072 en/of ffdhe4096 gebruiken. Die staan o.a. hier: https://github.com/internetstandards/dhe_groups en https://wiki.openssl.org/index.php/Diffie-Hellman_parameters.
Deze DH bestanden zijn publieke groepen, het is niet nodig om lees permissies weg te halen.
Deze DH bestanden zijn publieke groepen, het is niet nodig om lees permissies weg te halen.
Door Anoniem: Voor anderssoortige servers kun je in plaats van een zelf gegenereerde groep de RFC 7919 standaard finite field group ffdhe3072 en/of ffdhe4096 gebruiken.
Nitpick: Na de Logjam-aanval was het advies om zelf een groep te genereren omdat het idee bestond dat de ffdhe1024 groep (en kleinere) gekraakt zou kunnen zijn. Echter realiseerde men later pas dan bij het genereren van een DHE-groep niet alle controles worden uitgevoerd die wel worden uitgevoerd bij het publiceren van een publieke groep. Daarom is het advies tegenwoordig om alleen gebruik te maken van de gestandaardiseerde groep(en).Door Anoniem: Op het eerste oog ziet dit er goed uit. Denk bij mailservers ook nog aan de DANE/TLSA standaard. Zowel de TLS als DANE-instellingen kunnen, volgens de NCSC richtlijn, getest worden via de website https://internet.nl/.
En als je dan toch bezig bent:MS en Google ondersteunen geen DANE (omdat ze niet in DNSSEC geloven(?)) en hebben een eigen standaard uitgevonden: MTA-STS
https://datatracker.ietf.org/doc/html/rfc8461
Al of niet in combinatie met SMTP TLS Reporting
https://datatracker.ietf.org/doc/html/rfc8460
DANE dwingt TLS af op de MX (mailserver), MTA-STS op het domein en vereist, buiten de nodige DNS, een HTTPS site.
Maar zoals OT al aangaf: "Specifiek voor mail servers is alles behalve TLS 1.2 en 1.3 afwijzen vaak niet een haalbare kaart". Op mijn mailservers komt nog steeds legitieme zakelijke mail binnen met te lage, of zelfs zonder enige vorm van encryptie.
Ik gebruik https://ssl-config.mozilla.org/ om een config te genereren. Werkt prima.
De komende tijd ga ik de volgende instellingen testen:
Debian 10, Apache2, openssl 1.1.1d
Het gaat verder dan de NCSC voorschriften. Geen DHE, geen CBC, geen SHA1.
DHE blijkt niet nodig in de praktijk met de door SSL Labs geteste applicaties. Het aangegeven ffdhe bestand wordt daarom niet gebruikt.
De CHACHA20-POLY1305 cipher suites hebben geen SHA256 aanduiding in de string, als SHA256 wordt aangegeven werkt het niet.
Deze instellingen werken niet voor Safari 8 of ouder en niet voor Internet Explorer 11 of ouder onder Windows 7 t/m 8.1. SSLLabs test site: https://www.ssllabs.com/ssltest/
De cipher suite kan worden gelogd:
Debian 10, Apache2, openssl 1.1.1d
SSLProtocol -all +TLSv1.3 +TLSv1.2
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
SSLCipherSuite SSL ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
SSLOpenSSLConfCmd Curves X448:X25519:secp384r1:prime256v1
SSLOpenSSLConfCmd DHParameters "/etc/ssl/ffdhe4096.pem"
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
SSLCipherSuite SSL ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
SSLOpenSSLConfCmd Curves X448:X25519:secp384r1:prime256v1
SSLOpenSSLConfCmd DHParameters "/etc/ssl/ffdhe4096.pem"
#openssl ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256'
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-RSA-AES128-GCM-SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-RSA-AES128-GCM-SHA256
Het gaat verder dan de NCSC voorschriften. Geen DHE, geen CBC, geen SHA1.
DHE blijkt niet nodig in de praktijk met de door SSL Labs geteste applicaties. Het aangegeven ffdhe bestand wordt daarom niet gebruikt.
De CHACHA20-POLY1305 cipher suites hebben geen SHA256 aanduiding in de string, als SHA256 wordt aangegeven werkt het niet.
Deze instellingen werken niet voor Safari 8 of ouder en niet voor Internet Explorer 11 of ouder onder Windows 7 t/m 8.1. SSLLabs test site: https://www.ssllabs.com/ssltest/
De cipher suite kan worden gelogd:
CustomLog ${APACHE_LOG_DIR}/ssl_request.log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x %{User-agent}i \"%r\" %b"/code]
MS en Google ondersteunen geen DANE (omdat ze niet in DNSSEC geloven(?)) en hebben een eigen standaard uitgevonden: MTA-STS
https://datatracker.ietf.org/doc/html/rfc8461
Al of niet in combinatie met SMTP TLS Reporting
https://datatracker.ietf.org/doc/html/rfc8460
DANE dwingt TLS af op de MX (mailserver), MTA-STS op het domein en vereist, buiten de nodige DNS, een HTTPS site.
https://datatracker.ietf.org/doc/html/rfc8461
Al of niet in combinatie met SMTP TLS Reporting
https://datatracker.ietf.org/doc/html/rfc8460
DANE dwingt TLS af op de MX (mailserver), MTA-STS op het domein en vereist, buiten de nodige DNS, een HTTPS site.
En als ik dan op dat https domein's .well-known/mta-sts.txt kijk...
zie ik niks meer dan hetgeen ook in DNS in MX records te vinden viel, sterker met nog een label "mode".
Kortom; duplicate data, zonder meerwaarde,welke ik dus niet van hogere waarde acht dan DNSSEC-signed data uit DNS.
Alleen maar extra administratie, precies even nuttig/nutteloos als PTR records.
MS en Google ondersteunen geen DANE (omdat ze niet in DNSSEC geloven(?)) en hebben een eigen standaard uitgevonden: MTA-STS
* Microsoft werkt aan de implementatie van DANE: https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494
* Google biedt wel al alternatieve Google mail servers waarvan de domeinnamen met DNSSEC ondertekend zijn, namelijk mx[1-4].smtp.goog. Zie bijv. https://internet.nl/mail/broadcom.com/481939/#control-panel-2
Over de verhouding tussen DANE en MTA-STS zie ook het volgende citaat (bron: https://twitter.com/internet_nl/status/1389250863252885508):
Yes, but with a fairly low priority as we prefer DANE for mail transport security. The MTA-STS RFC recognises DANE to be more secure (i.e. more resistant against downgrade attacks). See: https://tools.ietf.org/html/rfc8461#section-10.2
Furthermore MTA-STS seems mostly fit for the largest cloud mail providers. The bigger a mail provider the greater the chance that (a) its MTA-STS policy is already cached by other sending mail servers, (b) it already has a valid cached policy of other receiving mail servers.
So a bigger mail provider will run less often into ‘trust on first use’ (i.e. unenforced and unauthenticated TLS) than a small provider. See also: https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md#how-about-mta-sts
Furthermore MTA-STS seems mostly fit for the largest cloud mail providers. The bigger a mail provider the greater the chance that (a) its MTA-STS policy is already cached by other sending mail servers, (b) it already has a valid cached policy of other receiving mail servers.
So a bigger mail provider will run less often into ‘trust on first use’ (i.e. unenforced and unauthenticated TLS) than a small provider. See also: https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md#how-about-mta-sts
Specifiek voor mail servers is alles behalve TLS 1.2 en 1.3 afwijzen vaak niet een haalbare kaart.
Merk op dat Microsoft op Exchange Online TLS 1.0 en 1.1 ook voor mailserver-verbindingen heeft uitgeschakeld (of dat gaat doen): https://techcommunity.microsoft.com/t5/exchange-team-blog/understanding-email-scenarios-if-tls-versions-cannot-be-agreed/ba-p/2065089
Leuk topic! Even een reactie vanuit Platform Internetstandaarden (de organisatie achter internet.nl).
Op Github plaatsen wij how-to's die we met de internet community verder willen ontwikkelen. Zie: https://github.com/internetstandards/toolbox-wiki. Een van onze doelen van deze how-to's is het verlagen van de implementatiedrempel van de verschillende standaarden waaronder STARTTLS o.b.v. de NCSC TLS richtlijnen. Je vind hier onder andere:
- een handig overzicht (spreadsheet) met alle cipher suites uit de NCSC TLS richtlijnen inclusief de TLS versies waarbinnen deze suites worden ondersteund.
- How-to voor STARTTLS: https://github.com/internetstandards/toolbox-wiki/blob/master/under%20construction/STARTTLS-how-to.md (Nog "under construction" omdat er momenteel alleen info staat voor Postfix i.c.m. OpenSSL, en omdat intro nog moet worden toegevoegd.)
- How-to voor DANE: https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
Ook houden we hier een overzicht bij met producten en diensten die DANE ondersteunen: https://github.com/baknu/DANE-for-SMTP/wiki/3.-Software-and-service-support.
Pull Requests zijn overigens van harte welkom! Je mag eventuele bijdragen ook mailen naar vraag@internet.nl. Heb je andere vragen, voel je dan ook vrij om te mailen.
Op Github plaatsen wij how-to's die we met de internet community verder willen ontwikkelen. Zie: https://github.com/internetstandards/toolbox-wiki. Een van onze doelen van deze how-to's is het verlagen van de implementatiedrempel van de verschillende standaarden waaronder STARTTLS o.b.v. de NCSC TLS richtlijnen. Je vind hier onder andere:
- een handig overzicht (spreadsheet) met alle cipher suites uit de NCSC TLS richtlijnen inclusief de TLS versies waarbinnen deze suites worden ondersteund.
- How-to voor STARTTLS: https://github.com/internetstandards/toolbox-wiki/blob/master/under%20construction/STARTTLS-how-to.md (Nog "under construction" omdat er momenteel alleen info staat voor Postfix i.c.m. OpenSSL, en omdat intro nog moet worden toegevoegd.)
- How-to voor DANE: https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
Ook houden we hier een overzicht bij met producten en diensten die DANE ondersteunen: https://github.com/baknu/DANE-for-SMTP/wiki/3.-Software-and-service-support.
Pull Requests zijn overigens van harte welkom! Je mag eventuele bijdragen ook mailen naar vraag@internet.nl. Heb je andere vragen, voel je dan ook vrij om te mailen.
Door Anoniem:
Merk op dat Microsoft op Exchange Online TLS 1.0 en 1.1 ook voor mailserver-verbindingen heeft uitgeschakeld (of dat gaat doen): https://techcommunity.microsoft.com/t5/exchange-team-blog/understanding-email-scenarios-if-tls-versions-cannot-be-agreed/ba-p/2065089
Specifiek voor mail servers is alles behalve TLS 1.2 en 1.3 afwijzen vaak niet een haalbare kaart.
Merk op dat Microsoft op Exchange Online TLS 1.0 en 1.1 ook voor mailserver-verbindingen heeft uitgeschakeld (of dat gaat doen): https://techcommunity.microsoft.com/t5/exchange-team-blog/understanding-email-scenarios-if-tls-versions-cannot-be-agreed/ba-p/2065089
Ik zie bij [domain.tld].mail.protection.outlook.com dat alleen TLS 1.2 aan staat. Microsoft doet nog niet aan TLSv1.3.
Een mail server kan ook email zonder STARTTLS accepteren. Ik weet niet of Microsoft dat doet.
Iemand met een Office adres zou kunnen testen via https://ssl-tools.net/mails om te zien of Microsoft plain text mails verstuurd. Dat werkt door een mail te sturen naar check at ssl-tools.net vanuit Office 365.
Er zijn dus twee te controleren zaken: acceptatie van plain text email bij inkomende en bij uitgaande mail.
Door Anoniem:
In de door jouzelf gequote link:Door Anoniem:
Merk op dat Microsoft op Exchange Online TLS 1.0 en 1.1 ook voor mailserver-verbindingen heeft uitgeschakeld (of dat gaat doen): https://techcommunity.microsoft.com/t5/exchange-team-blog/understanding-email-scenarios-if-tls-versions-cannot-be-agreed/ba-p/2065089
Er zijn dus twee te controleren zaken: acceptatie van plain text email bij inkomende en bij uitgaande mail.Specifiek voor mail servers is alles behalve TLS 1.2 en 1.3 afwijzen vaak niet een haalbare kaart.
Merk op dat Microsoft op Exchange Online TLS 1.0 en 1.1 ook voor mailserver-verbindingen heeft uitgeschakeld (of dat gaat doen): https://techcommunity.microsoft.com/t5/exchange-team-blog/understanding-email-scenarios-if-tls-versions-cannot-be-agreed/ba-p/2065089
Before diving into further details, keep in mind that generally speaking, the TLS implementation in Exchange on-premises or Exchange Online is done opportunistically. This means:
For receiving mail into Exchange: If the sending server does not support TLS, or if the TLS negotiation fails, Exchange Online will still accept messages unencrypted and without TLS (provided the sending server’s configuration allows that).
For sending mail from Exchange: For outbound email, if the receiving server does not support TLS (does not advertise the STARTTLS Verb), Exchange on-premises and Exchange Online will send email without TLS (provided TLS is not forced on the send connector or outbound connector).
Door gebruik te maken van MTA-STS (mode: enforce) of DANE kun je encryptie afdwingen, zonder wordt gekeken of er STARTTLS wordt gebruikt en zo niet wordt mail onversleuteld verstuurd.For receiving mail into Exchange: If the sending server does not support TLS, or if the TLS negotiation fails, Exchange Online will still accept messages unencrypted and without TLS (provided the sending server’s configuration allows that).
For sending mail from Exchange: For outbound email, if the receiving server does not support TLS (does not advertise the STARTTLS Verb), Exchange on-premises and Exchange Online will send email without TLS (provided TLS is not forced on the send connector or outbound connector).
Wat maakt het nu uit of je TLS gebruikt of niet, wanneer je email met PGP versleuteld?
Door Anoniem:
Door Anoniem:
In de door jouzelf gequote link:Door Anoniem:
Merk op dat Microsoft op Exchange Online TLS 1.0 en 1.1 ook voor mailserver-verbindingen heeft uitgeschakeld (of dat gaat doen): https://techcommunity.microsoft.com/t5/exchange-team-blog/understanding-email-scenarios-if-tls-versions-cannot-be-agreed/ba-p/2065089
Er zijn dus twee te controleren zaken: acceptatie van plain text email bij inkomende en bij uitgaande mail.Specifiek voor mail servers is alles behalve TLS 1.2 en 1.3 afwijzen vaak niet een haalbare kaart.
Merk op dat Microsoft op Exchange Online TLS 1.0 en 1.1 ook voor mailserver-verbindingen heeft uitgeschakeld (of dat gaat doen): https://techcommunity.microsoft.com/t5/exchange-team-blog/understanding-email-scenarios-if-tls-versions-cannot-be-agreed/ba-p/2065089
Before diving into further details, keep in mind that generally speaking, the TLS implementation in Exchange on-premises or Exchange Online is done opportunistically. This means:
For receiving mail into Exchange: If the sending server does not support TLS, or if the TLS negotiation fails, Exchange Online will still accept messages unencrypted and without TLS (provided the sending server’s configuration allows that).
For sending mail from Exchange: For outbound email, if the receiving server does not support TLS (does not advertise the STARTTLS Verb), Exchange on-premises and Exchange Online will send email without TLS (provided TLS is not forced on the send connector or outbound connector).
Door gebruik te maken van MTA-STS (mode: enforce) of DANE kun je encryptie afdwingen, zonder wordt gekeken of er STARTTLS wordt gebruikt en zo niet wordt mail onversleuteld verstuurd.For receiving mail into Exchange: If the sending server does not support TLS, or if the TLS negotiation fails, Exchange Online will still accept messages unencrypted and without TLS (provided the sending server’s configuration allows that).
For sending mail from Exchange: For outbound email, if the receiving server does not support TLS (does not advertise the STARTTLS Verb), Exchange on-premises and Exchange Online will send email without TLS (provided TLS is not forced on the send connector or outbound connector).
Je hebt gelijk dat Microsoft zelf zegt dat ze terugvallen naar plain text. Ik ben geen Microsoft klant dus dat kan ik niet zelf controleren. Microsoft is dan vatbaar voor striptls aanvallen. Die kunnen overigens ook self-inlficted lokaal door proxies/firewalls kunnen worden uitgevoerd.
https://www.digicert.com/dc/blog/striptls-attacks-and-email-security/
Als de kwaliteit van implementatie van MTA-STS hetzelfde is als de reporting van Microsoft zou ik niet erop vertrouwen dat MTA-STS terugval naar plain text voorkomt. Sowieso is het gebruik van MTA-STS laag onder mailservers. Het beste middel is het om het op je eigen server zo in te stellen. Voor Exim4 is dat:
#uitgaande mail
remote_smtp:
hosts_require_tls = *
#binnenkomende mail
acl_check_mail:
deny ! encrypted = *
message = TLS is required
accept
encrypted = *
Dit geeft een melding aan derden die mail willen zenden vanaf een server die geen STARTTLS gebruikt.
Door Anoniem: Wat maakt het nu uit of je TLS gebruikt of niet, wanneer je email met PGP versleuteld?
PGP is één beveiligingslaag en het lekt meta data (timestamps, afzender, ontvangers, soms onderwerpregels) en is dus niet goed voor privacy. TLS is veilig als mail servers voldoende checks uitvoeren. Ze moeten controleren of het certificaat in de CA infrastructuur klopt (self-signed afwijzen), DANE via DNSSEC controleren, eventueel ook CAA. Daarmee wordt het voor een MitM aanvaller moeilijk om een aanval succesvol uit te voeren.
Sommige implementaties van PGP werken niet betrouwbaar, het kan voorkomen dat mail in plain text wordt verstuurd.
Door Anoniem:
PGP is één beveiligingslaag en het lekt meta data (timestamps, afzender, ontvangers, soms onderwerpregels) en is dus niet goed voor privacy. TLS is veilig als mail servers voldoende checks uitvoeren. Ze moeten controleren of het certificaat in de CA infrastructuur klopt (self-signed afwijzen), DANE via DNSSEC controleren, eventueel ook CAA. Daarmee wordt het voor een MitM aanvaller moeilijk om een aanval succesvol uit te voeren.
Sommige implementaties van PGP werken niet betrouwbaar, het kan voorkomen dat mail in plain text wordt verstuurd.
Door Anoniem: Wat maakt het nu uit of je TLS gebruikt of niet, wanneer je email met PGP versleuteld?
PGP is één beveiligingslaag en het lekt meta data (timestamps, afzender, ontvangers, soms onderwerpregels) en is dus niet goed voor privacy. TLS is veilig als mail servers voldoende checks uitvoeren. Ze moeten controleren of het certificaat in de CA infrastructuur klopt (self-signed afwijzen), DANE via DNSSEC controleren, eventueel ook CAA. Daarmee wordt het voor een MitM aanvaller moeilijk om een aanval succesvol uit te voeren.
Sommige implementaties van PGP werken niet betrouwbaar, het kan voorkomen dat mail in plain text wordt verstuurd.
TLS is veilig als mail servers voldoende checks uitvoeren.
PGP in onveilig omdat niet alle implementaties goed zijn.
Tja, zo kun je elke discussie naar je hand draaien.
vatbaar voor striptls aanvallen.
Bij STARTTLS tussen mailservers is er sprake van opportunistische encryptie. De versleutelde verbinding (indien ondersteund door beide mailservers) wordt vanuit plain text opgezet. Bovendien controleert de verzendende mailserver het certificaat van de ontvangende mailserver niet (geen authenticatie). Mailservers hebben doorgaans namelijk geen trust store met vertrouwde root certificaten Daardoor is de verbinding kwetsbaar voor een MITM-aanval (STRIPTLS of omleiding van mailverkeer). Het afdwingen van TLS helpt ten dele; het zorgt namelijk niet voor authenticatie van de ontvangende mailserver.
STARTTLS voorkomt dat passieve aanvallers e-mails onderweg kunnen lezen. DANE beschermt tegen actieve aanvallers, die door manipulatie van het mailverkeer de encryptie kunnen verwijderen.
Met DANE kan je namelijk informatie over jouw mailservercertificaten publiceren in een speciaal DNS-record, een TLSA-record. Verzendende mailservers kunnen de certificaten dan via deze TLSA-records controleren op authenticiteit. Een verzendende mail server kan het TLSA-record ook als signaal gebruiken om alleen via STARTTLS (en niet onversleuteld) te verbinden. Als de DANE-fingerprint van een ontvangende mailserver wordt gecontroleerd door de verzendende mailserver, dan kan een actieve aanvaller die in staat is het berichtenverkeer te manipuleren de STARTTLS-encryptie niet verwijderen.
Zie ook: "Risks of SMTP with opportunistic TLS", https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md#risks-of-smtp-with-opportunistic-tls
13:59 door Anoniem: Mailservers hebben doorgaans namelijk geen trust store met vertrouwde root certificaten Daardoor is de verbinding kwetsbaar voor een MITM-aanval (STRIPTLS of omleiding van mailverkeer). Het afdwingen van TLS helpt ten dele; het zorgt namelijk niet voor authenticatie van de ontvangende mailserver.
Het zijn naar mijn weten de mailclients die deze emailserver-certificaten vaak niet controleren, en daarom geen error geven als certificaat / certificate-chain van de email server niet in orde mocht zijn. (zoals je browser dus wél doet, omdat browsers de authenticiteit van de server doorgaans wél controleren)
Door Anoniem:
TLS is veilig als mail servers voldoende checks uitvoeren.
PGP in onveilig omdat niet alle implementaties goed zijn.
Tja, zo kun je elke discussie naar je hand draaien.
TLS is veilig als mail servers voldoende checks uitvoeren.
PGP in onveilig omdat niet alle implementaties goed zijn.
Tja, zo kun je elke discussie naar je hand draaien.
De conclusie die je kunt trekken (die ik trek) is dat je voor betere beveiliging beide soorten beveiliging kunt toepassen.
@ Vandaag, 19:59 door Anoniem
MX servers (als clients) accepteren vaak self signed certificaten of plain text mail. Dan valt er niets na te trekken bij CA's. De standaard Debian configuratie van Exim accepteert mail ongeacht of het type certificaat (self-signed of CA).
Het is duidelijk nodig dat mail servers naar een hoger niveau van beveiliging moeten worden getild. Het huidige niveau ligt ver onder dat van web servers/browsers. Dat kan veel beter. Het helpt niet dat grote mail providers vatbaar zijn voor striptls aanvallen. Iemand zou het lef moeten hebben een RFC te maken die STARTTLS met CA certificaat op redelijke termijn verplicht stelt, in ieder geval voor MX verkeer over Internet.
Door Anoniem: ...
Het is duidelijk nodig dat mail servers naar een hoger niveau van beveiliging moeten worden getild. Het huidige niveau ligt ver onder dat van web servers/browsers. Dat kan veel beter. Het helpt niet dat grote mail providers vatbaar zijn voor striptls aanvallen. Iemand zou het lef moeten hebben een RFC te maken die STARTTLS met CA certificaat op redelijke termijn verplicht stelt, in ieder geval voor MX verkeer over Internet.
Het is duidelijk nodig dat mail servers naar een hoger niveau van beveiliging moeten worden getild. Het huidige niveau ligt ver onder dat van web servers/browsers. Dat kan veel beter. Het helpt niet dat grote mail providers vatbaar zijn voor striptls aanvallen. Iemand zou het lef moeten hebben een RFC te maken die STARTTLS met CA certificaat op redelijke termijn verplicht stelt, in ieder geval voor MX verkeer over Internet.
Voor geïnteresseerden hoe een CA (Certificate Authority) een grote blooper sloeg:
https://en.wikipedia.org/wiki/DigiNotar
(ter lering & vermaak, maar eigenlijk diep triest)
Door Anoniem 22-5-2021 19:59:Het zijn naar mijn weten de mailclients die deze emailserver-certificaten vaak niet controleren, en daarom geen error geven als certificaat / certificate-chain van de email server niet in orde mocht zijn.
Elke MUA die ik ooit voor klanten heb ingesteld toen ik nog gebruik maakte van self-signed certificaten, gaf die waarschuwing wél - mét de mogelijkheid om dan dit certificaat alsnog te accepteren...Door Anoniem 22-5-2021 22:50:
MX servers (als clients) accepteren vaak self signed certificaten of plain text mail. Dan valt er niets na te trekken bij CA's. De standaard Debian configuratie van Exim accepteert mail ongeacht of het type certificaat (self-signed of CA).
Het is duidelijk nodig dat mail servers naar een hoger niveau van beveiliging moeten worden getild. Het huidige niveau ligt ver onder dat van web servers/browsers. Dat kan veel beter. Het helpt niet dat grote mail providers vatbaar zijn voor striptls aanvallen. Iemand zou het lef moeten hebben een RFC te maken die STARTTLS met CA certificaat op redelijke termijn verplicht stelt, in ieder geval voor MX verkeer over Internet.
Nog een RFC? We hebben er al twee:MX servers (als clients) accepteren vaak self signed certificaten of plain text mail. Dan valt er niets na te trekken bij CA's. De standaard Debian configuratie van Exim accepteert mail ongeacht of het type certificaat (self-signed of CA).
Het is duidelijk nodig dat mail servers naar een hoger niveau van beveiliging moeten worden getild. Het huidige niveau ligt ver onder dat van web servers/browsers. Dat kan veel beter. Het helpt niet dat grote mail providers vatbaar zijn voor striptls aanvallen. Iemand zou het lef moeten hebben een RFC te maken die STARTTLS met CA certificaat op redelijke termijn verplicht stelt, in ieder geval voor MX verkeer over Internet.
Bij MTA-STS wordt de mailserver geacht een CA certificaat te hebben...
Bij DANE is dat niet (per se) nodig en kun je een self-signed cert gebruiken, echter staat hiervan een hash in de TLSA - die DNSSEC gesigned moet zijn.
In beide gevallen wordt dus STARTTLS afgedwongen én kan de verzendende server controleren of hij de juiste MX aan de lijn heeft.
Door Anoniem 22-5-2021 23:07:Voor geïnteresseerden hoe een CA (Certificate Authority) een grote blooper sloeg:
Daarom heb ik ook meer vertrouwen in DANE, hoewel ik CA certificaten gebruik om ook aan MTA-STS te voldoen.Door Anoniem:
Bij MTA-STS wordt de mailserver geacht een CA certificaat te hebben...
Bij DANE is dat niet (per se) nodig en kun je een self-signed cert gebruiken, echter staat hiervan een hash in de TLSA - die DNSSEC gesigned moet zijn.
In beide gevallen wordt dus STARTTLS afgedwongen én kan de verzendende server controleren of hij de juiste MX aan de lijn heeft.
Door Anoniem 22-5-2021 22:50:
MX servers (als clients) accepteren vaak self signed certificaten of plain text mail. Dan valt er niets na te trekken bij CA's. De standaard Debian configuratie van Exim accepteert mail ongeacht of het type certificaat (self-signed of CA).
Het is duidelijk nodig dat mail servers naar een hoger niveau van beveiliging moeten worden getild. Het huidige niveau ligt ver onder dat van web servers/browsers. Dat kan veel beter. Het helpt niet dat grote mail providers vatbaar zijn voor striptls aanvallen. Iemand zou het lef moeten hebben een RFC te maken die STARTTLS met CA certificaat op redelijke termijn verplicht stelt, in ieder geval voor MX verkeer over Internet.
Nog een RFC? We hebben er al twee:MX servers (als clients) accepteren vaak self signed certificaten of plain text mail. Dan valt er niets na te trekken bij CA's. De standaard Debian configuratie van Exim accepteert mail ongeacht of het type certificaat (self-signed of CA).
Het is duidelijk nodig dat mail servers naar een hoger niveau van beveiliging moeten worden getild. Het huidige niveau ligt ver onder dat van web servers/browsers. Dat kan veel beter. Het helpt niet dat grote mail providers vatbaar zijn voor striptls aanvallen. Iemand zou het lef moeten hebben een RFC te maken die STARTTLS met CA certificaat op redelijke termijn verplicht stelt, in ieder geval voor MX verkeer over Internet.
Bij MTA-STS wordt de mailserver geacht een CA certificaat te hebben...
Bij DANE is dat niet (per se) nodig en kun je een self-signed cert gebruiken, echter staat hiervan een hash in de TLSA - die DNSSEC gesigned moet zijn.
In beide gevallen wordt dus STARTTLS afgedwongen én kan de verzendende server controleren of hij de juiste MX aan de lijn heeft.
Je leest over het aspect verplicht stellen voor MX verkeer over internet. Een regulerende RFC dus, meer dan een best practices RFC of een techniek beschrijvende RFC.
quote]Door Anoniem 24-5-2021 11:33:
Je leest over het aspect verplicht stellen voor MX verkeer over internet. Een regulerende RFC dus, meer dan een best practices RFC of een techniek beschrijvende RFC.Een RFC is, zelfs nadat deze is gepromoveerd tot Internet Standard, een afspraak over hoe iets voor elkaar te krijgen.
Het is geen wet en er is geen instantie die controleert of jij je wel of niet aan deze afspraken houdt. Met andere woorden: het staat jou geheel vrij om je mail naar poort 27 te sturen, of je eigen afwijkende versie van TCP te gebruiken.
Daar staat dan weer tegenover dat jij niet "verplicht" bent om mail te accepteren van, of te versturen naar mailservers die niet zijn voorzien van een CA certificaat en/of geen TLS ondersteunen terwijl je dit volgens de RFC wel zou "moeten".
In de praktijk zullen DANE, MTA-STS en/of nog een andere RFC pas "verplicht" worden als de grote partijen zoals Google, Microsoft en Amazon besluiten om hun mailservers nog alleen mail met TLS te laten accepteren en te versturen. Iets wat ik nog niet direct vandaag of morgen, maar hopelijk wél in de toekomst, zie gebeuren.
Je leest over het aspect verplicht stellen voor MX verkeer over internet. Een regulerende RFC dus, meer dan een best practices RFC of een techniek beschrijvende RFC.
Het is geen wet en er is geen instantie die controleert of jij je wel of niet aan deze afspraken houdt. Met andere woorden: het staat jou geheel vrij om je mail naar poort 27 te sturen, of je eigen afwijkende versie van TCP te gebruiken.
Daar staat dan weer tegenover dat jij niet "verplicht" bent om mail te accepteren van, of te versturen naar mailservers die niet zijn voorzien van een CA certificaat en/of geen TLS ondersteunen terwijl je dit volgens de RFC wel zou "moeten".
In de praktijk zullen DANE, MTA-STS en/of nog een andere RFC pas "verplicht" worden als de grote partijen zoals Google, Microsoft en Amazon besluiten om hun mailservers nog alleen mail met TLS te laten accepteren en te versturen. Iets wat ik nog niet direct vandaag of morgen, maar hopelijk wél in de toekomst, zie gebeuren.
Ik merk dat Exim4 onder Debian (gnutls) RSA gebruikt als het certificaat RSA is. In een vroege ECDSA RFC was ECDSA certificaat verplicht in TLS, maar dat is herroepen. Weet iemand of Exim4 te bewegen is toch te kiezen voor ECDSA ook al is het certificaat RSA?
Door Anoniem: Ik merk dat Exim4 onder Debian (gnutls) RSA gebruikt als het certificaat RSA is. In een vroege ECDSA RFC was ECDSA certificaat verplicht in TLS, maar dat is herroepen. Weet iemand of Exim4 te bewegen is toch te kiezen voor ECDSA ook al is het certificaat RSA?
Eerst een tegenvraag (t.b.v. een workaround i.p.v. oplossing):gebruik je Let's Encrypt?
Door Anoniem:
gebruik je Let's Encrypt?
Door Anoniem: Ik merk dat Exim4 onder Debian (gnutls) RSA gebruikt als het certificaat RSA is. In een vroege ECDSA RFC was ECDSA certificaat verplicht in TLS, maar dat is herroepen. Weet iemand of Exim4 te bewegen is toch te kiezen voor ECDSA ook al is het certificaat RSA?
Eerst een tegenvraag (t.b.v. een workaround i.p.v. oplossing):gebruik je Let's Encrypt?
Ja.
Weet iemand of Exim4 te bewegen is toch te kiezen voor ECDSA ook al is het certificaat RSA?
Eerst een tegenvraag (t.b.v. een workaround i.p.v. oplossing):gebruik je Let's Encrypt?
Toevallig alsnog het antwoord op je vraag:
tls_require_ciphers = ECDSA:RSA:!COMPLEMENTOFDEFAULT
De workaround:
ECDSA certificaten in Let's Encrypt zijn mogelijk als je de CSR handmatig doet.
Nadeel; renewals kunnen niet automatisch (als mijn info nog altijd actueel is).
Ook worden de files niet in het normale path gezet, en krijg je weinig distinctive filenames.
https://community.letsencrypt.org/t/howto-obtain-ecdsa-cert-in-addition-to-rsa-with-certbot/61687
https://illuad.fr/2020/09/07/obtain-an-elliptic-curve-certificate-from-let-s-encrypt.html
Behalve dat werkt alles gewoon normaal en gaat alles goed (spreek ik uit ervaring i.c.m. HTTPS).
Door Anoniem:
gebruik je Let's Encrypt?Ja.
Toevallig alsnog het antwoord op je vraag:
Weet iemand of Exim4 te bewegen is toch te kiezen voor ECDSA ook al is het certificaat RSA?
Eerst een tegenvraag (t.b.v. een workaround i.p.v. oplossing):gebruik je Let's Encrypt?
Toevallig alsnog het antwoord op je vraag:
tls_require_ciphers = ECDSA:RSA:!COMPLEMENTOFDEFAULT
Bedankt, maar helaas dat is voor openssl en exim4 op Debian werkt met gnutls. Ik zal eens even kijken of gnutls iets vergelijkbaars heeft.
De workaround:
ECDSA certificaten in Let's Encrypt zijn mogelijk als je de CSR handmatig doet.
Nadeel; renewals kunnen niet automatisch (als mijn info nog altijd actueel is).
Ook worden de files niet in het normale path gezet, en krijg je weinig distinctive filenames.
https://community.letsencrypt.org/t/howto-obtain-ecdsa-cert-in-addition-to-rsa-with-certbot/61687
https://illuad.fr/2020/09/07/obtain-an-elliptic-curve-certificate-from-let-s-encrypt.html
Behalve dat werkt alles gewoon normaal en gaat alles goed (spreek ik uit ervaring i.c.m. HTTPS).
ECDSA certificaten in Let's Encrypt zijn mogelijk als je de CSR handmatig doet.
Nadeel; renewals kunnen niet automatisch (als mijn info nog altijd actueel is).
Ook worden de files niet in het normale path gezet, en krijg je weinig distinctive filenames.
https://community.letsencrypt.org/t/howto-obtain-ecdsa-cert-in-addition-to-rsa-with-certbot/61687
https://illuad.fr/2020/09/07/obtain-an-elliptic-curve-certificate-from-let-s-encrypt.html
Behalve dat werkt alles gewoon normaal en gaat alles goed (spreek ik uit ervaring i.c.m. HTTPS).
Ja, het is tegenwoordig mogelijk om ECDSA certificaten te genereren vanaf certbot v1.10 en het kon ook al eerder met aangepaste source. Debian 10 gebruikt nog v0.31.0. Debian Testing/unstable heeft v1.12.0. Met wat truckage is dat misschien toch te gebruiken.
Documentatie certbot over ECDSA:
https://certbot.eff.org/docs/using.html#using-ecdsa-keys
Bij Let's Encrypt staat op het todolijstje dat ze ECDSA volledig willen ondersteunen. Hoewel je een ECDSA certificaat kunt aanvragen, wordt die getekend met RSA omdat het onderliggende certificaat een RSA certificaat is: sha256WithRSAEncryption in de https://www.immuniweb.com/ssl test.
Hier wordt dat aangekaart: https://community.letsencrypt.org/t/sha256withrsa-instead-ecdsa-with-sha256-with-certbot/145358/2. Er zitten een paar inhoudelijk bruikbare reacties tussen.
Het todo lijstje kun je hier vinden: https://letsencrypt.org/upcoming-features/. Added the ability for Let’s Encrypt to sign ECDSA keys with Let’s Encrypt’s RSA intermediates. Support for signing ECDSA keys with a full ECDSA cert chain will be added later.
Dit kan, maar je moet je er wel voor inschrijven, via een Google formulier en zonder de optie van verwijdering - geen optie voor mij. De link naar het formulier wordt in een forumbericht van 29 april vermeldt: https://community.letsencrypt.org/t/ecdsa-availability-in-production-environment/150679.
Er zijn ECDSA intermediates E1 en E2: https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html. De E verwijst naar ECDSA, voor RSA is er bijvoorbeeld R3 (R van RSA).
Er is een X2 root die ECDSA met P-384 key heeft. Die heeft geen ocsp responder en gebruikt alleen CRL.
TL;DR
Volledige ECDSA ondersteuning is er nog niet, maar het kan al wel worden geregeld als je niet wil wachten.
Hier wordt dat aangekaart: https://community.letsencrypt.org/t/sha256withrsa-instead-ecdsa-with-sha256-with-certbot/145358/2. Er zitten een paar inhoudelijk bruikbare reacties tussen.
Het todo lijstje kun je hier vinden: https://letsencrypt.org/upcoming-features/. Added the ability for Let’s Encrypt to sign ECDSA keys with Let’s Encrypt’s RSA intermediates. Support for signing ECDSA keys with a full ECDSA cert chain will be added later.
Dit kan, maar je moet je er wel voor inschrijven, via een Google formulier en zonder de optie van verwijdering - geen optie voor mij. De link naar het formulier wordt in een forumbericht van 29 april vermeldt: https://community.letsencrypt.org/t/ecdsa-availability-in-production-environment/150679.
Er zijn ECDSA intermediates E1 en E2: https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html. De E verwijst naar ECDSA, voor RSA is er bijvoorbeeld R3 (R van RSA).
Er is een X2 root die ECDSA met P-384 key heeft. Die heeft geen ocsp responder en gebruikt alleen CRL.
TL;DR
Volledige ECDSA ondersteuning is er nog niet, maar het kan al wel worden geregeld als je niet wil wachten.
ECDSA aanvragen via https://community.letsencrypt.org/t/ecdsa-availability-in-production-environment/150679 werkt. Het uiteindelijk root certificaat is een RSA certificaat van X1 maar het gebruikt ECDSA signing van de E1 intermediate.
Dit kun je afzonderlijk testen omdat de cert name niet standaard is.
certbot certonly --staple-ocsp --key-type ecdsa --elliptic-curve=secp384r1 -d domein.nl,www.domein.nl,mail.domein.nl,mta-sts.domein.nl --cert-name domein.nl-ecdsa
Dit kun je afzonderlijk testen omdat de cert name niet standaard is.
Mijn 2 GnuTLS centen:
--priority="SECURE128:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.3:-RSA:-DHE-RSA:-AES-128-CCM:-AES-256-CCM:-GROUP-FFDHE2048:-GROUP-FFDHE3072:-AES-256-CBC:+AES-256-CBC:-AES-128-CBC:+AES-128-CBC:%SERVER_PRECEDENCE"
Cipher suites for SECURE128:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.3:-RSA:-DHE-RSA:-AES-128-CCM:-AES-256-CCM:-GROUP-FFDHE2048:-GROUP-FFDHE3072:-AES-256-CBC:+AES-256-CBC:-AES-128-CBC:+AES-128-CBC:%SERVER_PRECEDENCE
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_128_GCM_SHA256 0xc0, 0x2b TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA1 0xc0, 0x0a TLS1.0
TLS_ECDHE_ECDSA_AES_128_CBC_SHA1 0xc0, 0x09 TLS1.0
TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2
TLS_ECDHE_RSA_CHACHA20_POLY1305 0xcc, 0xa8 TLS1.2
TLS_ECDHE_RSA_AES_128_GCM_SHA256 0xc0, 0x2f TLS1.2
TLS_ECDHE_RSA_AES_256_CBC_SHA1 0xc0, 0x14 TLS1.0
TLS_ECDHE_RSA_AES_128_CBC_SHA1 0xc0, 0x13 TLS1.0
$ sslscan localhost
Version: 2.0.10-static
OpenSSL 1.1.1k 25 Mar 2021
Connected to ::1
Testing SSL server localhost on port 443 using SNI name localhost
SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 disabled
TLSv1.1 disabled
TLSv1.2 enabled
TLSv1.3 enabled
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Session renegotiation not supported
TLS Compression:
Compression disabled
Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve P-256 DHE 256
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve P-256 DHE 256
Accepted TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve P-256 DHE 256
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-256 DHE 256
Server Key Exchange Group(s):
TLSv1.3 128 bits secp256r1 (NIST P-256)
TLSv1.3 192 bits secp384r1 (NIST P-384)
TLSv1.3 260 bits secp521r1 (NIST P-521)
TLSv1.3 128 bits x25519
TLSv1.3 224 bits x448
TLSv1.3 150 bits ffdhe4096
TLSv1.3 175 bits ffdhe6144
TLSv1.3 192 bits ffdhe8192
TLSv1.2 128 bits secp256r1 (NIST P-256)
TLSv1.2 192 bits secp384r1 (NIST P-384)
TLSv1.2 260 bits secp521r1 (NIST P-521)
TLSv1.2 128 bits x25519
TLSv1.2 224 bits x448
SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength: 4096
Subject: Woei Inc. CA
Issuer: Woei Inc. CA
Not valid before: Oct 18 12:54:22 2021 GMT
Not valid after: Oct 18 12:54:22 2022 GMT
De volgorde is redelijk lelijk, maar dit zorgt er voor dat de CBC ciphers in de volgorde na de GCM komen. Anders staat de 256 CBC boven de 128 GCM.
--priority="SECURE128:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.3:-RSA:-DHE-RSA:-AES-128-CCM:-AES-256-CCM:-GROUP-FFDHE2048:-GROUP-FFDHE3072:-AES-256-CBC:+AES-256-CBC:-AES-128-CBC:+AES-128-CBC:%SERVER_PRECEDENCE"
Cipher suites for SECURE128:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.3:-RSA:-DHE-RSA:-AES-128-CCM:-AES-256-CCM:-GROUP-FFDHE2048:-GROUP-FFDHE3072:-AES-256-CBC:+AES-256-CBC:-AES-128-CBC:+AES-128-CBC:%SERVER_PRECEDENCE
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_128_GCM_SHA256 0xc0, 0x2b TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA1 0xc0, 0x0a TLS1.0
TLS_ECDHE_ECDSA_AES_128_CBC_SHA1 0xc0, 0x09 TLS1.0
TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2
TLS_ECDHE_RSA_CHACHA20_POLY1305 0xcc, 0xa8 TLS1.2
TLS_ECDHE_RSA_AES_128_GCM_SHA256 0xc0, 0x2f TLS1.2
TLS_ECDHE_RSA_AES_256_CBC_SHA1 0xc0, 0x14 TLS1.0
TLS_ECDHE_RSA_AES_128_CBC_SHA1 0xc0, 0x13 TLS1.0
$ sslscan localhost
Version: 2.0.10-static
OpenSSL 1.1.1k 25 Mar 2021
Connected to ::1
Testing SSL server localhost on port 443 using SNI name localhost
SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 disabled
TLSv1.1 disabled
TLSv1.2 enabled
TLSv1.3 enabled
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Session renegotiation not supported
TLS Compression:
Compression disabled
Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve P-256 DHE 256
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve P-256 DHE 256
Accepted TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve P-256 DHE 256
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-256 DHE 256
Server Key Exchange Group(s):
TLSv1.3 128 bits secp256r1 (NIST P-256)
TLSv1.3 192 bits secp384r1 (NIST P-384)
TLSv1.3 260 bits secp521r1 (NIST P-521)
TLSv1.3 128 bits x25519
TLSv1.3 224 bits x448
TLSv1.3 150 bits ffdhe4096
TLSv1.3 175 bits ffdhe6144
TLSv1.3 192 bits ffdhe8192
TLSv1.2 128 bits secp256r1 (NIST P-256)
TLSv1.2 192 bits secp384r1 (NIST P-384)
TLSv1.2 260 bits secp521r1 (NIST P-521)
TLSv1.2 128 bits x25519
TLSv1.2 224 bits x448
SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength: 4096
Subject: Woei Inc. CA
Issuer: Woei Inc. CA
Not valid before: Oct 18 12:54:22 2021 GMT
Not valid after: Oct 18 12:54:22 2022 GMT
De volgorde is redelijk lelijk, maar dit zorgt er voor dat de CBC ciphers in de volgorde na de GCM komen. Anders staat de 256 CBC boven de 128 GCM.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
