Security Test

Hello all,

I did a test for a new MiaB instance via I got an 97% score for email and 95% for web which is pretty neat! But, in security I would like to have the highest score possible, so I would like to see what I could do or could be updated to gain a 100% score.

The following things are insufficient in the email server test:

  • TLS Version: TLS 1.0 (not sure) and TLS 1.1 are still supported.
  • Ciphers: AES256-GCM-SHA384 is selected as Cipher
  • Key Exchange parameters: At least one of your mail servers supports insufficiently secure parameters for Diffie-Hellman key exchange. Affected parameters: DH-2048

The following things are insufficient in the web server test:

  • HTTP Compression: enabled and could possibly be a security risk
  • HSTS policy: web server offers an HSTS policy with a cache validity period (max-age) that is not sufficiently long (i.e. less than 1 year). max-age=15768000 (generally, you want to set a custom HTTP header for Strict-Transport-Security with the value max-age=31536000)
  • Key Exchange parameters: Web server supports insufficiently secure parameters for Diffie-Hellman key exchange. affected parameters: DH-2048
  • No security options are selected, see: Security options has a very good reputation and is backed by many organisations in the Netherlands. See About for more information.

I hope we can make MiaB as safe as possible and hopefully the above ‘insufficient’ matters can be fixed by default.



I found TLS Version Warning.

What is the latest status regarding TLS 1.0 and 1.1?

The problem here is that there are still mail servers on the Internet that have not been upgraded to use a newer TLS version. So long as enough Mail-in-a-Box users want to be able to receive emails from or send emails to these servers, we need to still allow these protocols to be used to communicate with other mail servers.


These are excellent scores. With the exception perhaps of the security options, the complaints are, IMNSHO, bordering on the theoretically extreme. They are for the most part calling out weaknesses that only a determined government-scale entity could exploit, and if such an entity is out to crack or spoof your email and web encryption you’ve got more important things to worry about, and MIAB’s 100% score wouldn’t improve your outlook! :wink:

1 Like

Hi Josh,

Thank you for your response. I completely understand that point of view.
How do you think about adding a feature for users that want to disable TLS 1.0 and 1.1?
I think it is the end users responsibility if TLS 1.0/1.1 is disabled.

For example Microsoft disabled TLS 1.0 and 1.1 for Microsoft 365 service back in 2018. See Disabling TLS 1.0 and 1.1 for Microsoft 365 - Microsoft Purview (compliance) | Microsoft Learn.

I’m very interested in your opinion about that.

Thank you for your IMNSHO haha,

You are right about the government-scale entities. I think a lot of MiaB users are using MiaB because of privacy concerns, but I’ll speak for myself . I’m happy a lot of security features are already in MiaB, it makes me feel more in control and/or safe.

For example: the encryption keys which are now RSA 2048 are fast but a bit older. RSA 4096 is more secure but slow. X25519 is modern, fastest and secure. All I’m trying to say is that an option for end users would be a very nice feature and would possibly draw the attention of more security/privacy enthusiasts.

I’m very interested in your opinion!

Before you ask that, why don’t you try it yourself and see if you can still successfully receive and send emails with every other mail server that you might want to email with?

The Office 365 link doesn’t really have anything to do with how email servers should talk to each other.

This topic was automatically closed after 61 days. New replies are no longer allowed.