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.
Conversation
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.
2
1
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
Enabling only TLSv1.3 eliminates a lot of attack surface including the potential of downgrade attacks via vulnerabilities.
Traditional TLS version negotiation isn't actually used anymore thanks to broken implementations:
imperialviolet.org/2016/05/16/agi
TLSv1.3 pretends to be TLSv1.2.
TLSv1.3 is version (3, 4) but the traditional version has been frozen at (3, 3) forever due to broken implementations. They had to add an extension for version negotiation, which is what shipped, and turned out to break with certain printers using the id:
blog.cryptographyengineering.com/2017/12/19/the