4.2.28-T6 currently generates certificates that leave HTTPS connections vulnerable to man-in-the-middle (MITM) attacks. The encrypted-connection environment, as reported by FireFox v 37.0.2, is:
(TLS_DHE_RSA_WITH_AES_128_CBC_SHA,128 bit keys, TLS 1.0)
Since, US-CERT recommends upgrading TLS to 1.1 or higher and ensuring TLS 1.0 and SSL 1, 2, 3.x are disabled, would it be possible to upgrade the official 4.2.28 release certificates to the current minimum standards? Perhaps provide the same protection as offered by "www.google.com", which is:
(TLS_ECDHE_RSA_WITH_AES128_GCM_SHA256, 128 bit keys, TLS 1.2)
I have not seen US-CERT comments on self-signed certificates -- nor did I claim that. Certificates indicate the security protocols available for key exchange, session connections, etc., that the web site offers. Current 4.2.28-T6 certificates offer encryption that US-CERT considers unsafe (e.g. TLS 1.0). It is the encryption that we want to have up to date and the certificates should be too.
US-CERT recommends using certificate pinning and avoid the certificate verification chain back to a trusted root certificate. In other words, trust a specific named certificate, which could be a self-signed certificate. Since this is what our business users are doing to access our business machines, we would want our certificates to reflect the latest encryption recommendations (e.g. elliptical encryption for key exchange). Google's certificates are good examples of these best-practice certificates. ReadyNAS should offer similar security.
Since, US-CERT recommends upgrading TLS to 1.1 or higher and ensuring TLS 1.0 and SSL 1, 2, 3.x are disabled, would it be possible to upgrade the official 4.2.28 release certificates to the current minimum standards?
Since the certificates are you wanting to upgrade are self-signed, this sentence sounded to me like you were saying US-CERT had set a "current minimum standard" for self-signed.
This needs to be escalated!!! This is no longer just a matter of preference. We have two ReadyNAS devices on our network that host secure FTPS sites. Every service on the ReadyNas requires a security certificate in some way. And even though these devices have absolutely no credit card information on them, the simple fact that they allow TLS v1.0 and SSLv3 causes our PCI compliance scan to fail. Time to get current, PLEASE!
A couple of questions to you security gurus (not my strong area).
Just curious, where did you get this output in Firefox? I tried using Chrome and Firefox and I.E explorer to get that output. However in their Certificate GUI viewer I couldnt find similar output as you. The most I got was from running it against openssl x509.
(TLS_ECDHE_RSA_WITH_AES128_GCM_SHA256, 128 bit keys, TLS 1.2)
Below is the self signed cert from a 6.4.0-beta5 box. I see its using SHA256. as you mentioned is recommended by US-CERT. However I cannot find the TLS version of this cert. Where would I get that information? At first look I thought "Version: 1 (0x0)" indicated TLS 1.0, but that is not correct. The version label is simply the version of the structure of the cert, newer versions have more features etc (more about structure here https://en.wikipedia.org/wiki/X.509)
I trimmed the output of my cert that im showing you for security purposes (not all of the output as Im still curious about the answers to the above questions). My final question is about that to you security gurus. Was it necessary for me to alter/trim the output for security? Since these are self signed certs, does that mean everyone with a ReadyNAS 6.0 box have the same self signed certs? If yes then trimming is useless as you could just get one yourself. However if they are generated then trimming was a good option. To me it looks like these are unique to each ReadyNAS box as I have a field thats pointing to the time I preformed my factory default at "Not Before: Sep 16 05:44:45 2015 GMT" (from journalctl - mine still goes back to the beginning - Sep 15 22:44:44 readynasos kernel: Initializing cgroup subsys cpu). So perhaprs I answered my own question: They are generated and therefore each is unique and therefore altering the output im showing is a smart security decision.
# openssl x509 -in readynasos.local.crt -text -noout
Certificate:
data ;
Version: 1 (0x0)
Serial Number: 13346492640757468642 (0xb938445811b6cde2)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, CN=readynasos.local
Validity
Not Before: Sep 16 05:44:45 2015 GMT
Not After : Jan 18 05:44:45 2038 GMT
Subject: C=US, CN=readynasos.local
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a4:f4:cb:4e:6f:63:9d:20:73:d8:ad:ce:a3:24:
d2:73:63:c0:b7:11:ee:5a:75:34:66:bd:05:8c:c9:
e9:3d:77:c2:1f:69:0b:db:7b:1f:98:1d:4e:32:24:
d1:1a:81:6c:c6:4c:39:20:0f:5c:44:63:c7:ae:a2:
bf:53:55:c6:1f:26:59:44:68:7a:2d:fe:c5:96:0b:
c0:35:a8:fd:ef:4d:87:7a:38:56:b8:8a:6b:3a:f0:
7f:ea:42:ea:c5:f2:a3:ed:4c:b0:59:dd:cd:77:d9:
ed:64:1a:ae:7c:e5:c2:a0:11:01:63:97:fd:e9:06:
0d:ef
Exponent: 65537 (0x10001)
Signature Algorithm: sha256WithRSAEncryption
66:4f:b2:11:d4:13:7f:1c:c3:ed:73:44:f5:bd:36:9c:78:95:
e3:4c:24:f3:cf:fc:d4:58:63:d4:fb:24:d7:c5:97:df:77:55:
d7:e3:70:a2:78:9f:1c:9b:13:7e:e1:cb:78:37:d6:41:21:81:
35:10:3b:af:24:1a:33:f6:25:3f:0e:4b:6d:44:65:fb:97:ac:
52:cd:0b:24:c2:30:fa:44:34:56:ef:b9:22:63:9d:e3:1f:f2:
bc:ac:e8:de
The TLS version reported (when you click on the locks in firefox or chrome) is for the connection, and not for the certificate.
The concerns raised here are specific to 4.2.28 T6. It uses TLS 1.0, AES_128_CBC encryption, with HMAC-SHA1 for message authentication and DHE_RSA as the key exchange. The cert is sha1, Public Key is RSA 1024 bits
6.2.5 uses newer stuff: the connection uses TLS 1.2. The connection is encrypted/authenticated with AES_128_GCM and uses ECDHE_RSA for the key exchange.
The older certs are being phased out. CA certificates are verified by the browser using SHA signature. It is possible (though time consuming and very expensive) to forge a certificate that passes the verification process (for instance using Amazon Cloud Computing with GPU support). Current price curves on cloud computing suggest that cost of forging will drop to ~$100,000 by 2017. Moving to SHA256 pushes that cost back up to an astronomical value. The phaseout will take a couple of years, in order to give people time to convert their certificates.
Self-signed certs like the ReadyNAS uses aren't issued by a CA anyway, and aren't really verifiable. As a user, either you live with a security exception, or you add it to your root certificate list (which forces it to be trusted). However, security compliance scans used in many companies will still produce failures on the NAS, and it'd be easier for most IT folks if the scan simply passed (rather than forcing them to get an exception).
The original certificate version had a number of limitations (as explained in RFC 5280)
RFC 1422 uses the X.509 v1 certificate format. The limitations of
X.509 v1 required imposition of several structural restrictions to
clearly associate policy information or restrict the utility of
certificates. These restrictions included:
(a) a pure top-down hierarchy, with all certification paths
starting from IPRA;
(b) a naming subordination rule restricting the names of a CA's
subjects; and
(c) use of the PCA concept, which requires knowledge of
individual PCAs to be built into certificate chain
verification logic. Knowledge of individual PCAs was
required to determine if a chain could be accepted.
Version 3 adds extensions which overcome those limitations.
The version of TLS and the key exchange/encryption is also checked in those compliance scans, and increasingly companies have standards that must be met in the equipment they deploy. Even if the NAS has up-to-date security patches, that is often not enough to convince corporate security officers to create exceptions. They generally prefer information they can directly verify. As noted above, the key exchange/encryption being offered is stored in the certificate.
