Security concepts about mailu

[kaiyou]

I see your point and I do agree about the lack of security tests and procedures so far. On the security vs. usuability scale, I wanted Freeposte.io to be simple to set-up and have easy defaults to ensure that setting up a mail server is simple enough for individuals and SME. Security should not be left apart however.

A quick answer to your three concerns:

1. I do not agree, most people who are not aware of the security issues related to TLS/HTTPS will not care about SSH security and are just as prone to interception over SSH as they are over HTTPS (maybe even more, as a lot of effort was put into educating them to pay attention to HTTPS-related issues). Additionally, the admin interface is intended for global admins, per-domain admins and mailbox owners, switching to a private administration interface would require a separate Web interface and increasing the complexity (thus reducing both usuability and maintainability, and possibly harming security in the process).
2. I still do not agree, it is a shame but people are used to having a Webmail available. Even if mail server administrators probably will never use it, Freeposte.io is not just intended for them but also for mailbox owners. Therefore I believe a default setup should include a Webmail. You make a great point about updates however, having an auto-update feature could be interesting if implemented properly.
3. Certbot is being implemented as part of #35 and will be part of the next release. A strong emphasis is put on using proper certificates, and I am wondering if disabling STARTTLS could increase security a bit.

Aditionnally :

• There will always be much debating about the usuability vs. security scale and no perfect solution. Why not ship multiple docker-compose.yml and configuration files, then let users make a well-informed choice based on proper documentation? Like option 1 without a webmail and a private administration interface and option 2 with both publicly available.
• I myself am a former pentester and security professional and will try and detect then fix as many security issues in Freeposte.io as I possibly can, I do not have much time on my hands however and am not the best suited man for the job (I wrote most of the code). Some issues are documented already (absolutely no CSRF protection for instance) and awaiting a fix, but you are more than welcome to look for issues and report them (even privately if you find some are too cricial to be disclosed). I could not be happier if anyone could take on the burden of pentesting and/or auditing the solution on a regular basis.

[greshake]

(Bullet point numbers unrelated to the above)

1. Having multiple configuration files of varying security configurations is not going to make things better, reducing maintainability. Instead, the default configuration should be the most conservative & secure and extending/enabling other features documented where the user can be educated about consequences for security.
2. SSH not only solves the MITM attack vector: It also mitigates authentication and other vulnerabilities which arise from open access.
3. The problems regarding usability for mailbox owners mentioned do not arise, which I will clarify using the two use cases I think are mutually exclusive and matching almost all uses:
   a) The mailbox owner is the administrator (private email server):
   In this case, requiring ssh to connect relieves the user of the hassle to setup HTTPS,
   and protects the web interface when the backend is not required.
   b) An admin sets up an emailserver for multiple users (e.g. company email)
   In this case, the admin should have the ability and technical knowledge to set up a correct reverse proxy with HTTPS. But, I do not believe this project is suited for use in such an environment, any larger setup managing more than a few accounts should be done manually. This is due to the lack of manpower behind this project; Security and Confidentiality of (important) (company) data can not be ensured. This software has not gone through thourough enough testing to withstand a targeted attack.
4. Users expect Webmail? State why webmail is bad, and let them use a real client software. Any user not willing to go through such hassle is not suited to host an email server or any server for that matter. They will be better off using e.g. GMail, where the security of their data can be properly ensured (although Google etc. is bad, I know)

[kaiyou]

I still disagree about SSH versus HTTPS (it does not prevent MitM any more than TLS does, and edution is much stronger regarding HTTPS than SSH), but I see your point about not exposing services by default and I actually agree about your two use cases.

Regarding the security issues for companies with serious users, it's a common problem with early free/community software, which I believe will resolve itself if the user base grows and the project is in fact used by such companies. Therefore I see no reason to exclude them when analyzing use cases.

Finally about the Webmail, this is your opinion and I tend to agree, but I have been managing many email servers over the years and I can tell that it's not the most shared one. Even if not enabled by default, a Webmail is necessary, just like a Web administration interface for most common tasks.

I see multiple technical approaches for providing a conservative configuration:

• different configuration sets, which is a hassle to maintain;
• comment/uncomment containers to enable/disable features, which sounds very erro-prone;
• configuration variables in the environment file, which sounds good enough.

I would prefer to enable/disable on a per-feature basis instead of providing either a conservative or a full-featured option. And I am still hesistating about the best default option (conservative or full-featured), I will ask around and get some additional feeback/advice on that matter.

Thank you very much for your thoughts. Also, the implied question in my previous message: would you have the knowledge and/or resources to lead an audit or a pentest against the solution?

[kaiyou]

After some thinking, a per-feature approach based on the environment file sounds great. For instance :

# Set to true to expose the administration interface publicly
EXPOSE_ADMIN=false

# Set to true to enable and expose the Webmail
ENABLE_WEBMAIL=false

# Set to false to disable automatic updates
ENABLE_UPDATES=true

What do you think?

[greshake]

1. Yes, I'll have a look. I'm currently a computer science student/ researcher (yes, both right now) specialized in security. But I haven't done a lot with Django Flask, so I can't promise a lot when it comes to the implementation. As for general best practices/ hardening of the email stack, I'll certainly come up with a few more suggestions.
2. Secure defaults are a must-have. If you're trying to determine the default setting, one should always default to the most secure option imho. And yes, this is especially true for a system intended for not security-savy users. You as a security guy yourself certainly know how hard it can be to get users to employ any security measure, even if it takes little to no effort.
3. I like the last approach, a system-wide config file is certainly the way to go, but I wouldn't integrate this into the admin interface. Don't make it too easy to do without looking into the docs and being informed about the risks.

[greshake]

Damn, these Postfix configs are hard to read! But as far as I can tell the config allows for PLAIN auth even if certificates are provided? This should default to only allowing TLS connections if there are certificates

[greshake]

After extensive testing on my own server with freeposte, I think the default encryption settings on postfix may be too weak. Some old ciphers are supported, and TLS is not rigourously enforced (At least from what I can tell from my server, maybe I misconfigured something, too). I'd suggest taking this paper draft as a baseline:
https://bettercrypto.org/static/applied-crypto-hardening.pdf

They already include a sample configuration for Postfix, I'll merge it with the current config and make a pull request tomorrow.

Better Crypto, fuck yeah!

[kaiyou]

Thank you for the pointer, their suggested configuration is of course prone to discussion (enabling/disabling TLSv1 for instance) but it sounds like a great base ground to me, provided that we can apply it to Nginx, Postfix and Dovecot consistently.

[kaiyou]

Keeping this thread open to keep discussing the "secure by default" options, while moving TLS related stuff to #45.

[kaiyou]

I am trying to implement configuration variables to enable or disable the Webmail and the exposed admin interface, but I am struggling.

My goal was for instance to implement a global environment variable named ENABLE_WEBMAIL that would disable the Webmail if not set to 1. There does not seem to be any way of disabling the container dynamically inside the docker-compose.yml file.

Another possiblity would be to exit conditionally in the startup script, but then Docker will keep trying to restart the container and there is no restart configuration that both restarts the container upon Docker restarts and avoids restarting it when it exits gracefully on its own.

Yet another possibility would be to sleep indefinitely in the startup script, but then it becomes impossible to guess easily if the service is up or not. Also for containers exposing ports, the ports would be held by Docker proxy anyway.

I see one last option for Web interfaces: having Lua enabled in the Nginx container and disable the forwards with a default 403 page if nothing is available. That would still mean that the Webmail is running even when not specifically enabled. Does not seem right either.

I would like to avoid having users modifying the docker-compose.yml too much (or at all), maybe introducing some external variables for versions and base path, but conditional container startup will remain an issue.

[kaiyou]

Another proposal: use conditional image for the Webmail. Something like WEBMAIL= in the configuration file, that could be set to WEBMAIL=roundcube or WEBMAIL=none (thus loading a special image that does nothing).

Later on we could support various Webmails with WEBMAIL=squirrel for instance. That would solve part of the problem and ensure that the solution is simple enough for future evolutions.

And exposing the administration interface would be tested by the front HTTP service. Remains one issue: the HTTP front would still hold ports 80 and 443 even if nothing is exposed.

[kaiyou]

Still ugly, but here is a first try: https://github.com/kaiyou/freeposte.io/tree/feat-secure-by-default

[kaiyou]

It is getting cleaner and could actually improve maintainability a lot. I will maybe merge these into master today and open a separate issue regarding unused ports being held by the Docker proxy.

[kaiyou]

The branch is now merged into master, still missing a proper way to expose a Webmail but not the admin interface. This could be implemented using conditionals in the Nginx proxy.