Uhg, looks like it's been pending since 2014:
Conversation
Replying to
I ended up migrating to Postfix to get DANE verification for my outbound mail along with the potential to start checking MTA-STS policies via github.com/Snawoot/postfi if I decide to integrate that. Also switched to OpenDKIM from dkimproxy and added in spf-engine to verify SPF.
1
2
Replying to
I used havedane.net as a basic test and it passed that with sensible output in the logs. It would make sense to test it a bit more though.
2
1
I wish I could use ssllabs.com/ssltest/ with IMAP and SMTP. I used ssl-config.mozilla.org to deal with generating the baseline. I added `tls_ssl_options = NO_RENEGOTIATION` to that in addition to `smtp_dns_support_level = dnssec` and `smtp_tls_security_level = dane`.
1
1
en.internet.nl is useful, although they still recommend server cipher order. Mozilla stopped recommending that for the Modern/Intermediate configurations since all the ciphers are strong with forward secrecy. Might as well let the client use whatever is fastest for them.
1
1
Replying to
Yeah I was kinda confused by their cipher warnings. OTOH I like that they're the only site that didn't say either "you're perfect" or "you're insecure because MTA-STS is required to be secure".
1
Replying to
At the moment I still set server cipher order so that test suites like this will pass. Mozilla used to recommend that, but they stopped doing it. en.internet.nl is based around guidelines from the Netherlands government which encourage stronger than 128-bit security.
1
1
They want to force using the strongest available ciphers while Mozilla just wants 128-bit security or better with forward secrecy. Using the Mozilla configuration and changing server cipher to `on` will pass all the test suites like this following EU guidelines with no real loss.
1
1
TLSv1.3 is a lot saner. It only has ECDHE (no DHE parameter gotchas) and OpenSSL only implements the 5 standard ciphers which all have at least 128-bit security and forward secrecy. Gets rid of all the obscure curves too. That's why the Modern configuration has no cipher config.
1
1
Sadly, can't really use Modern configuration for much in practice. Definitely not a mail server... and there are too many non-browser things that will break with a web server. I did start using TLSv1.3 only for services like time.grapheneos.org where we control the client.
Also one more thing is you need to ffdhe3072.txt or better instead of ffdhe2048.txt as recommended by the Mozilla configuration to provide 128-bit security, which internet.nl checks. TLSv1.3 gets rid of DHE so one less thing to worry about at some point in the future.
1
Security level for DHE / ECDHE key exchange matters more than the actual certificate due to forward secrecy. If at some point RSA 2048 is broken, it doesn't matter if you used RSA 2048 keys for certificates today as long as you only ever used ciphers with forward secrecy today.
1
1
Show replies
Replying to
Isn't there a way to prevent downgrade when client does support TLS 1.3, by validating the session prior to handshake after making the handshake? Or is that just not supported still?
1
Replying to
There's downgrade protection but there have historically been vulnerabilities in it along with inability to fully deploy it due to persistently broken middleboxes, etc. As an example, one of the workarounds is being removed in the next release of Chrome:
chromestatus.com/feature/512835
2
Show replies