Update TLS Protocols, TLS Ciphers and ECDH curves for SMTP

[psychofaktory]

As test tools show, this area should be adjusted somewhat: https://www.hardenize.com/report/mailinabox.email/1645055796#email_tls https://tls.imirhil.fr/smtp/mailinabox.email https://www.immuniweb.com/ssl/box.occams.info/5Ok1YDYT/

TLSv1.0 and TLSv1.1 should be disabled, the used Cipher-Suites and ECDH curves and their order should be reviewed, so that the server meets the current security standards. I have found a recommendation for this here: https://ciphersuite.info/cs/?tls=tls12&security=recommended&software=openssl&sort=desc&singlepage=true

I found a description for the required adjustments here: https://the-digital-native.de/?p=26

The tests also indicate that the nginx configuration of the web server could still be improved: https://securityheaders.com/?q=mailinabox.email&hide=on&followRedirects=on

[myfirstnameispaul]

When serving web services, we can happily run the latest encryption standards knowing that the users will have devices being regularly updated to support the configuration.

Browser developers know that some sites the browser reaches will not support the latest encryption standards or may still have yet other problems. For this, the browser developers know that the user is directly interfacing with the browser at the moment it is connecting to the site, so they can build into their browsers the ability to inform the users of the problems encountered and ask whether the user wants to continue under these conditions. Additionally, modern browsers still support serving plain text websites without asking any questions.

My observation is that many admins want to take the standards applied to web services and use them on mail servers, usually without any consideration of what actually happens when the server is configured this way.

Many mail servers legitimately do not use encryption. For example, forum notifications and mailing list servers are sending messages of public information. Some servers do not support later encryption, for whatever reason, so sending or receiving from them will be made impossible by configuring to only support the latest encryption standards. Unlike browsers, however, mail servers are not user-interactive. It is either sent or undeliverable, and that is all, so the aforementioned scenarios prevent the usage of mail services with no other options for users when the server is configured to only support modern encryption standards.

However, mail servers that support the latest encryption standards will use them when sending to or receiving from Mail-in-a-Box. Thus, in practice, the transport communications are almost always appropriately encrypted.

[psychofaktory]

Thanks for the clarification.

I am aware that some older or not so secure standards also need to be maintained for compatibility reasons.

But I think that maybe not all parameters of the current configuration have to be kept as they are currently. Other, also commercial and very common mail service providers, show that there seems to be a good compromise between security and compatibility. 2 popular examples: gmail.com posteo.de

Is there anything against the mentioned adjustments to the web server?

[myfirstnameispaul]

If you want to offer something for the web server, I suspect you will need to at least provide recommended configuration changes if not a PR and the headers do differ slightly based on which part of Mail-in-a-Box is being requested. Note that Probely has issues with the way they evaluate headers and your provided link is for the Mail-in-a-Box project home page, which is not a part of the Mail-in-a-Box project, itself.

Whenever I have looked at the mail encryption question, I end up back with the same questions that lead me to conclude to just leave it alone, but I don't claim to speak for everybody:

Do I have any examples of transaction log messages with servers that I think should have been using higher grade encryption?

Should encryption be mandatory?

If encryption is not mandatory, what is the difference between a lower-grade encryption and no encryption?

If encryption is mandatory, should I require DANE or CA signed certificates? What is the point of mandatory encryption with an imposter server?

When a user receives an undeliverable mail message, what do they do?

[JoshData]

Just for reference, the Mail-in-a-Box homepage (mailinabox.email) is hosted on my personal Mail-in-a-Box instance, so it's OK to test with that URL.

[psychofaktory]

your provided link is for the Mail-in-a-Box project home page

Sorry, this should be a proper link: https://securityheaders.com/?q=box.occams.info&hide=on&followRedirects=on

I don't think we should be discussing basic questions about whether encryption is useful, and whether it should be mandatory in general.

In the context of this software, we can only try to meet the maximum possible standard at the moment, without limiting compatibility. In the hope that newer standards will also establish themselves faster in the area of mail servers and replace outdated standards.

Lets say every mail software would always keep all standards that were ever used for compatibility reasons, then the compatibility would be maximum, but the structures would also be very vulnerable and insecure, or not trustworthy.

I think the two providers from my example above have been able to find a good middle ground here. Perhaps we can orient on this.

[mo-n4nln]

Citing Gmail as an example of carefully crafted compromise in supporting email interoperability is an example of unintentional irony.

Jon Postel's original definition of protocol interoperability reads: Be conservative in what you do and liberal it what you accept.

Gmail is not a particularly good example of either. I'm willing to assume that Gmail's choices are motivated by an attempt to "lead the charge" (in some sense) toward a better world for email.

However, nobody designated, much less elected, Gmail to be the Internet Email Sheriff. They seem to have assumed the job after deciding it wasn't being done. There is a reason for that. The IETF Standards serve that role, painfully ineffective as that may be sometimes. (And email can certainly be painful.)

Email remains one of the few services of the Moderne Internet that is not a delay/bandwidth pig. It is also one of the few services readily usable by the visually-impaired. It also requires the least amount of machinery to provide useful service. This means it runs on small, slow, and old computers over slow, cranky network infrastructure, so it can provide useful service in remote areas with slow, expensive network connectivity. (It can be run over barbed-wire fencing network links, quite literally.)

As such, email interoperability is one of the most essential services which can be provided by a network, and that includes the Internet. Not that long ago a 64 kilobit line across an ocean was the ONLY connectivity across said water, and the people who were suddenly enfranchised were thrilled beyond words.

I am unapologetically jealous of email interoperability and take an extremely dim view of unilateral decisions that isolate email users.

[psychofaktory]

I had only mentioned Google as an example of a popular service that on the one hand has a large number of users, but at the same time offered more secure encryption than MiaB as a minimum.

I also mentioned Posteo to make it clear that not just one provider sets certain standards.

The choice of encryption standards does have an impact on the interoperability of e-mail servers, but also on security.

I agree with you that interoperability is certainly important for a basic service. But just because it's a basic service, a certain level of security/confidentiality is also important. So it's not about isolating users, it's about using cryptography techniques that enable interoperability as well as security and confidentiality. Orientation to widespread, established providers is certainly useful here.

If I interpret your point of view correctly, the consequence would be to allow all protocols (and thus also insecure or unencrypted communication) in order to have the greatest possible interoperability. But this is probably not the intention behind Mail-in-a-Box. And the times when Jon Postels formulated his definition of protocol interoperability and the only connection across oceans was a 64 kilobit line are long gone. A lot has changed since then, especially on the Internet...