I agree. It would be useful if there was a setting in the admin control panel to select stricter settings. MIAB can still ship with compatibility in mind but the admin can harden things easily if they want.
2 Likes
Extra settings means extra maintenance and people asking questions. Also MIAB is supposed to work with on click and no configuration options.
1 Like
@JoshData Thank you for your wonderful Work! @cromulus , DrMartin, JoshData, Filippos : Taking a look at security is for sure a good thing, and it looks like people are getting involved in this discussion. This can be profitable on all sides and that is cool! Security will be a major issue in the coming years!
Yes, Michael! But it could be still the same Setup procedure as it is now (one-click-style) just with the possibility for extra settings in regards to Security after the initial Setup - just for those interested. I (or others) are for sure willing to write a guideline / best practice for your website once implemented.
Question: I have Mailinabox deployed on a VM (xen). Is it possible to make the admin page mailinabox.email/admin not accessible from outside? Was thinking about to block 443 or 80 on the Firewall in front of MIAB, but I guess then i can not access Webmail anymore?
1 Like
MIAB should include all the best default settings but could include a tab for advanced settings and a list of pages for additional configuration. Anything advanced should be kept under that tab to keep things simple. Users who want to make specific changes will be able to do so but the standard system should be kept so no advanced changes will be necessary.
2 Likes
Questions get asked about the simplest things, how many questions will be asked about an advanced tab. If the changes you propose have an actual proven benefit to miab, make a pr so it can be the default setting.
But as Josh said, proof that the attack is possible on the current setup.
In my opinion it makes no sense in doing something in a guide if we donât know for sure it applies to us. The easiest way to figure that out is make a PR for each proposed change so it can be assessed based on it merits. Otherwise this is just a meta discussion about an advanced tab.
yes with one (very) weak cipher mentioned
âTLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAKâ
this one can be safely removed imho.
It does actually because those are well known âentry pointsâ. And to wait until a possible attack happens and is successful is imho not an argument for security. For some reasons, implementations and guidance are around. If you are familiar or sensitive to security issues in IT, you should know that most cases are recognized much later when harm is already done. So âwait until something happensâ is not an argument, especially not for already best practices around. Or would you leave all your doors wide open in your house and ignore community burglar warnings and recommendations to mitigate dangers, unless you âknow for sureâ at the moment you realize somebody has broken in? 
But I agree, this way the discussion goes into the direction of a meta discussion. Reading the comments here, it seems possible with adding some lines to improve the security of system, and thatâs a good thing, right?
Indeed. No one on this thread has made that argument.
Or would you leave all your doors wide open in your house
Letâs take this metaphor further. When you leave your house, whatâs the first thing you do after you lock your door? You wiggle the door knob to check that itâs actually locked, right? Thatâs been my request the whole time. Demonstrate that the header has successfully locked a door. If you canât demonstrate that itâs locked, thereâs a good chance itâs not locked and you only have the appearance of security.
All of the (negative) feedback Iâve gotten to that request suggests you want a feature in Mail-in-a-Box but expect me or another maintainer to do the work to make sure that the feature is working as intended and has not broken functionality for others. If you want the header, youâre going to have to put in the time with a patch that adds the header, reports due diligence on what this might break, and shows how to demonstrate that itâs solving the problem itâs meant to solve.
2 Likes
The whole point that Josh and others here try to make, is that if you want to roll out to a full user base, it is not âjust adding some linesâ.
Why not just âadding some linesâ? First of all the lines should demonstrably improve the security of the system. Second, the lines should then demonstrably not break any functionality that users rely on, and this should be tested first.
For instance, your suggestion to set X-XSS-Protection has little to no benefit, because the modern browsers that support it have the filter behaviour enabled by default. Worse, if enabled (set to 1) it actually CAUSED a XSS injection vulnerability in IE8. And any added header just needs to be tested, for instance, if you would roll out strict-origin or same-origin for Referrer-Policy many Chrome users will now end up with broken websites.
Just to say that adding some lines for your own config is another ballgame than rolling changes out to production. If you do not like that, fine of course: you can always run your own customized post-update script to set things completely how you want it and break anything you like (or not). Or you can make a convincing case how a change will demonstrably improve security, test it well, and open up a pull request.
1 Like
@jege: [quote=âFilippos, post:6, topic:2015â]
Currently MIAB is on version 1.2. (May 2016) or 1.2.1 (?) (Aug. 2016).
[/quote]
First: Suggested to make (more) regular updates of Roundcube.
Second: Applies to special headers; yes, to state-of-the art headers; no. See comment from @Synchro.
Third: Suggested imho this cipher can be safely removed.
Fourth: Suggested to remove TLS v1.0 support. This is not even âadding linesâ , its actually not even a word: -tls1 in ssl.conf. My amateurish guess was that TLSv1 is not used anymore by MiaB users, but @JoshData`s argument is comprehensible and I understand that POV.
Sixthly: @jege Speaking of headers and chrome: âA new security header: Expect-CTâ.
Seventh: See quote above - it still holds. Wanted to make some starting points on security. There seems no interest to implement them (based on different arguments), and that`s fine. At least the topic kicked off some discussion on security. Maybe it will go on and can make some real changes.
Keep up the good work! 
I noticed that the HTTP headers objected to above are already in use in MIAB - just not everywhere. They are all present in /admin, but not /mail or /cloud. Iâve no idea why they would be wanted in one place but not another, but it renders the âsome people might be adversely affected by themâ argument moot - if itâs good enough for one place, it should be good enough for all - I canât think of any particular reason to use lower security in some parts. Having gone to all that effort to support complex things like DNSSEC, it just seems really odd to ignore such low-hanging fruit.
FWIW, in terms of public acceptability, I recently had a PR accepted that added these same headers to the French presidentâs site (en-marche.fr). This isnât exactly radical stuff.
I can understand if you donât want to change things, and Iâm quite happy to make my own modifications - but it would really help if they didnât get trashed with every update, and the mechanism thatâs supposed to keep such changes is (deliberately) undocumented and doesnât appear to work anyway.
Who said we donât want the headers? I didnât say that.