Having used NS for over a year, I found that last week it fell-over and died - reason unknown! On a daily basis it was successfully defending against typically 2,000+ failed log-ins. Maybe one of these were eventually successful?
Could the developers consider making available a menu of check-boxes for users to selectively choose which TLS versions are available on their NS installations, please?
With that and a few other “tweaks”, it might be possible to get a NS installation to be rated “A+”!
However we can do it by following our approach and releasing a new “TLS policy” number. Thus I’d avoid adding UI checkboxes to disable specific protocols.
If we are smart enough we’ll do it for every TLS-based service on NethServer 7.7. Let’s start experimenting.
I moved your post to a new thread, because I’m afraid that TLS policy and PCI compliance are still far to find an agreement!
I hope this makes a step forward in that direction though
My reason for asking for option boxes on each policy is that it would allow each NS installation to be tailored as needed for TLS.
Some users might require choose to offer the support of TLS 1.0 whereas others might prefer to have a tighter/stricter installation that has TLS 1.0 and 1.1 turned off. As mentioned in my previous post, supporting TLS 1.0 and 1.1 from next month will harm the security rating of any such system from next month onwards.
Ok, we can also split the upgrade in two distinct policies: the first one disables 1.0, the second one (also) 1.1, so that everyone can gradually enforce the new security trends.
To save development and QA times, both will be tested and released together.
Well we already have menus for users to select options on say, samba and the associated scripts - would it be overly difficult to do something similar as a TLS policy sub menu?
A radio button could select between your preference of it being handled fully automatically or a manual option would then allow the specific selections of the various policies?
That report is looking good. Specific to HSTS, I would not enable it by default–too much risk of losing access to your site if something goes wrong with your TLS configuration (like your cert doesn’t renew). But it’d be nice, if it isn’t already there, to have a property to enable it.
In fact it will be an optional new tls policy, the sysadmin must enable it on his own. I used a default certificate, I think the score will be better with a letsencrypt certificate
It would, and also better with accessing it by hostname. I do think HSTS should be available, but it shouldn’t be a default part of any TLS policy–that should be a separate configuration item.
About 6 months ago I requested the option of disabling tls1.0 and tls1.1 on the basis that the server security testing sites were weighting against servers supporting these standards - now it seems to be happening. And therefore these same testing sites will
report NethServers as being A+ secure again!
TLS 1.3 should be supported also.
Also, it should also be possible to have a policy with only STRONG ciphers and key exchanges, i.e. those which are not flagged WEAK by https://www.ssllabs.com/ssltest
No, it isn’t. We use primarily software packages from upstream, and they keep the same versions throughout the release cycle (backporting any security fixes) for the sake of stability and compatibility.
I hope this makes a step forward in that direction though