fix, we cannot have a weak
1 Like
I don’t think 20180330 is a weak setting; I think it’s overly restrictive. It limits to only two cipher suites, despite there being other good, strong, TLS 1.2 ciphers (it also doesn’t restrict to TLS 1.2 using the Protocols directive, which seems like a more direct way to accomplish that). Those cipher suites work fine with RSA certs, but not with ECC certs. Meanwhile, the upstream default works fine with ECC certs, but also includes a lot of lower-security stuff.
Using ECC certs with Nethserver is an edge case today–the default Let’s Encrypt configuration is going to use RSA, the self-signed cert is RSA, etc. But they’re growing in popularity, they’re at least as secure as RSA with a much smaller key size, and the result in faster connection negotiation. Therefore, I think we should use a secure cipher suite that does work with ECC keys; I’d suggest the Mozilla “modern” profile noted above unless someone knows why that wouldn’t work (and be sufficiently secure to satisfy whatever nonsense the GDPR requires). Whether we update 20180330 to do this or create, say, 20180601 doesn’t much matter to me, though I’d think that being a new policy we should identify it separately.
2 Likes
sorry for my bad english, corrected :S
yep new policy, why not, but how explain that will be compliant with ECC, it doesn’t worse the explanation, add those cipher and that all
For me a new policy could be -> only TLS1.2
we could add this (from https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility)
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
the question now is…what about for other services :-?
“Expanded TLS cipher suite list for compatibility with ECC certificates” should be a perfectly adequate changelog entry. If we need a “marketing-ready” explanation, something like “add support for next-generation ECC security certificates.”
If they’re all compiled against OpenSSL to provide their TLS capabilities, the same configuration should work for all of them. Some testing with openssl s_client should sort that out pretty quickly.
1 Like
@stephdl already provided a fix for this, could you please try the RPM from this PR?
Commands:
yum install http://packages.nethserver.org/nethserver/7.5.1804/autobuild/x86_64/Packages/nethserver-httpd-admin-2.3.0-1.3.pr30.ga97b9e2.ns7.noarch.rpm
1 Like
Installed that RPM, copied the ECC key/cert to /etc/pki/tls, and ran signal-event certificate-update. The server-manager seems to be working, and I’m able to connect using my browser. Haven’t tested the LDAP issue though.
2 Likes
Please, I Will need your help for others services, I will be back
Glad to, though I’m going to be traveling quite a lot in the next few weeks. I’ll do what I can, though.
Out of topic, we want to add the support for ECC, but if they are not so used everywhere it is maybe for good reasons.
- backdoor of NSA ?
- sony hack in 2010 has been done on ECC key (badly implemented, k factor was not random)
- it seems that a ECC key is weaker than a strong RSA (do not be afraid, you do not have the time to break the key)
1 Like
The reasons you mention are possible, but don’t overlook sheer inertia. RSA-based public-key crypto was the first major player in that field–it was the foundation for SSL, as well as for PGP. And the underlying math is relatively straightforward, which always helps. And, well, if it ain’t broke, don’t fix it.
Certainly a concern post-Snowden, but even well before his revelations, there was a great deal of skepticism of the NSA–and his revelation that NSA did in fact backdoor Dual EC_DRBG doesn’t improve their reputation. And it’s undeniably true that they pushed hard for adoption of ECC in its early days. OTOH, this paper seems to argue pretty convincingly that it would be infeasible for NSA to have backdoored the single-curve systems that are in current use, and also that for them to have done so would have greatly weakened their own security.
Edit: This doesn’t account for NSA’s relative freak-out over ECC in August 2015, though, and I’m still reading through that paper for some analysis on the subject.
The most common ECC curves appear to be P-256 and P-384, and roughly speaking, they appear to give comparable security to 2048-bit and 3072-bit RSA keys, respectively. There doesn’t appear to be a widely-used curve in a larger field, so yes, a 4096-bit RSA key would be more secure than any widely-used key length in ECC.
5 Likes
Oh yes!!! 
I think this bug/feature is going a little bit out of the road.
We have 2 different issues here:
- after upgrade to 7.5 ECC certificate doesn’t allow connection to httpd/httpd-admin
- add ECC support for all NS services
Regarding the first point, we can update the release notes and invite user with this problem to switch back to an older TLS policy.
After seeing the patches, I strongly believe we need to create a new policy: actual 20180330 is too much different.
Also, we need to release NS 7.5 rc/final and I don’t think this issue has such wide impact to block it.
Let’s document the new behavior, and we can go back on a deeper fix after the final release.
I agree with @danb35 and @stephdl that ECC support can be a very good marketing feature, but I also support @davidep comment on the issue tracker: we can postpone such feature just after the final.
Just for the record, NethServer 7.5 does not upgrade the TLS policy automatically! It’s a sysadmin’s choice. What was changed is the default policy, that affects only new installations.
1 Like
I’d agree with this as well–I posted bugs because the services weren’t working, and didn’t realize until I was finishing up that the ECC cert might have something to do with it. Though I think ECC support would be good to add (and sooner rather than later), I don’t think it needs to block 7.5–the default LE cert process won’t generate an ECC cert, and they otherwise don’t appear to be that common yet. Would be good to mention somewhere in the docs that the default TLS policy doesn’t work with ECC certs though.
2 Likes
Just for the sake of developers, how did you upload the certificate, the server-manager does not allow certificate wich are not encrypted by RSA
I followed the procedure I wrote up here, adding the appropriate flags to acme.sh to use an ECC key.
2 Likes
Released as a new feature here
1 Like