Default TLS policy doesn't allow connections with ECC certificate

Bug
1

Again, fresh install of 7.5beta on a test VM. After realizing that signal-event certificate-update didn’t restart httpd-admin, doing that restart manually gets it using the new cert, but it also implements the 20180330 TLS policy, which I’d already chosen in my 7.4 production server without a problem. However, on 7.5, I can’t connect when this policy is in effect. I’ve tried using Firefox Mac 59.0.2 and Safari 11.1. Firefox gives the error of “SSL_ERROR_NO_CYPHER_OVERLAP”, while Safari doesn’t give anything useful at all.

Checking the admin-conf/httpd.conf files between the two servers, the SSLCipherSuite and SSLProtocol settings are identical. However, OpenSSL can make a connection on the 7.4 box, but not on the 7.5 box. Here’s the output on 7.4:

[root@neth admin-conf]# openssl s_client -connect localhost:980
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = neth.familybrown.org
verify return:1
---
Certificate chain
 0 s:/CN=neth.familybrown.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHbjCCBlagAwIBAgISA9hrBt2o7fdLq9D7NpelUvjRMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
(snip)

…and on 7.5:

[root@neth-automx admin-conf]# openssl s_client -connect localhost:980
CONNECTED(00000003)
140134488483728:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1527197604
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

:lightbulb: I’d created an ECC cert, which Apache itself seems perfectly happy with. But on a hunch, I re-issued the cert as a standard RSA cert–now it works fine. I’d suggest that perhaps the CipherSuite should be updated to include ECC-compatible protocols, as it’s unnecessarily restrictive at this time. The Mozilla generator gives the following:

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
3 Likes
2

In short IIUC the bug depends on the lack of ECC-compatible ciphers in our setup! Thanks for pointing it out @danb35!

What do you think @stephdl? Can we fix the 20180330 or shall we implement a new one?

1 Like
3

Yes, I think so–and if the other services are set up using the same CipherSuite, maybe that’s why they don’t work either. But yes, changing to an RSA cert appears to have fixed all three issues.

I’d suggest that, if we’re going to be changing protocols/ciphersuites, we should call it a new policy.

4

fix, we cannot have a weak buggy setting

1 Like
5

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
6

sorry for my bad english, corrected :S

7

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 :-?

8

“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
9

@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
10

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
11

Please, I Will need your help for others services, I will be back

12

Glad to, though I’m going to be traveling quite a lot in the next few weeks. I’ll do what I can, though.

13

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
14

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
15

Ahem @alefattorini we have our @crypto_wizards here :wink:

Great job guys!

3 Likes
16

Oh yes!!! :mage: :mage::mage::mage:

17

I think this bug/feature is going a little bit out of the road.
We have 2 different issues here:

  1. after upgrade to 7.5 ECC certificate doesn’t allow connection to httpd/httpd-admin
  2. 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.

18

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
19

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
20

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