Description of problem: When openssl based server or client is negotiating used cipher suite, it will use 3DES cipher before AES-128 cipher. According to Section 5.6.1 (page 63) in part 1, revision 3 of NIST SP 800-57, and also Table 2 on page 64, the 3DES cipher that uses 3 distinct keys (3TDEA) should be assigned 112 bit security margin, it is therefore less secure than the 128bit AES. Version-Release number of selected component (if applicable): openssl-1.0.1e-37.fc19.x86_64 How reproducible: Always Steps to Reproduce: 1. openssl ciphers -v 2. observe 3DES ciphers before AES-128 ciphers Actual results: all 3DES ciphers are listed before all AES-128 ciphers Expected results: 3DES ciphers listed after AES-128 ciphers, either directly below AES128-SHA or directly below CAMELLIA128-SHA in current cipher order. Additional info:
The rpm changelog entry for 1.0.1e-38 reads "make 3des strength to be 128 bits instead of 168 (#1056616)". As Hubert correctly says, the effective strength is 112 bits (due to the meet-in-the-middle attack), not 128 bits. I didn't check whether only the changelog is wrong or the change itself, too.
I surely know that but making it 112 bit it will order 3DES behind SEED, IDEA, and CAMELLIA and that we do not want to do. AES128 is preferred to 3DES in this setting anyway. So that is completely intentional change.
Either way, it seems wrong to set a strength the cipher doesn't actually have. If you don't get the order you want with the strength the cipher actually has, the ordering algorithm should be changed to match your actual ordering criteria. Your criteria cannot be strength alone if you want 3DES to be preferred over the other ciphers.
That would require substantial changes to the way the ordering algorithm works and it is a feature request for upstream. The patch will stay as is for now.
OK, I understand. But please make sure this "hack" is well documented in the source code, if not the case already. It will be very confusing to anyone trying to do an audit, otherwise. I will open a RFE then, here and upstream. BTW, I see a lot of Mac=SHA1 in openssl ciphers -v *sigh*. If at all, these should be lower than all others in priority. Further, SHA384 is used with AES256 instead of SHA512. In fact, SHA512 seems not be available at all?
Note that in regards to message authentication the birthday attack on hashes does not apply so the required size of the hmac sha is sufficient if it is the same as the size of the aes key.
(In reply to Peter Backes from comment #5) > BTW, I see a lot of Mac=SHA1 in openssl ciphers -v *sigh*. If at all, these > should be lower than all others in priority. Further, SHA384 is used with > AES256 instead of SHA512. In fact, SHA512 seems not be available at all? To rephrase what Tomas said, the security of SHA1 when used as a HMAC (the way it is used in TLS) is estimated at 160 bits, similarly, SHA384 provides 384 bits of security when used as a HMAC. As such, in most cipher suites the mac is the most secure part. (In reply to Tomas Mraz from comment #2) > I surely know that but making it 112 bit it will order 3DES behind SEED, > IDEA, and CAMELLIA and that we do not want to do. AES128 is preferred to > 3DES in this setting anyway. So that is completely intentional change. While I can agree with regards to SEED and IDEA, I don't like it with regards to Camellia. Both ENISA and CRYPTREC recommend the use of Camellia over 3DES rather strongly. If the current ordering algorithm doesn't provide enough granularity to make it happen, I'd rather see SEED and IDEA dropped from DEFAULT list than 3DES preferred over Camellia.
With the current state of the 3DES strength setting (128) Camellia can still be ordered ahead of 3DES. Basically ordering works in between the ciphers with the same strength.
Also the situation is even slightly more complicated as there is no ECDHE ciphersuite with CAMELLIA where on the other hand there is with 3DES and given the most commonly only 1024 bit DH supported by servers it would not be good idea to prefer 128 bit CAMELLIA with 1024 bit DH over 3DES with 256 bit ECDH. I'd suggest discussing any more details in ciphersuite ordering with upstream.
I'd say that SHA-1 signatures in certificates are bigger problem than 1024 bit DH. And while putting 3DES with ECDHE higher in list is not a bad idea per se, current openssl doesn't order cipher suites based of PFS as the primary criteria, only secondary. I'd like this changed, but this is definitely up for discussion with upstream.
SHA-1 signatures in certificates is something we have to live with for a few more years. I am afraid that's just a fact and we can't do much with it. And I'm definitely not going to mess with the ciphersuite ordering anymore than the 3DES strength setting to 128 bits without upstream acceptance first.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Resolved in Fedora 21, openssl-1.0.1k-1.fc21.x86_64