Confirmed users
529
edits
No edit summary |
|||
Line 66: | Line 66: | ||
And did you really mean to introduce the DHE-DSS-suites in the new list? The qualys ssl servertest says these can't be used for PFS because they're effectivly limited to 1024 bit DSS key. | And did you really mean to introduce the DHE-DSS-suites in the new list? The qualys ssl servertest says these can't be used for PFS because they're effectivly limited to 1024 bit DSS key. | ||
=== ulfr, 20131215 === | |||
==== 1. ordering ==== | |||
Your findings are consistent with the recommendation. But maybe the section that explains the prioritization logic could be clarified: | |||
* PFS is always preferred. Non PFS ciphers will be listed after PFS cipher, regardless of keys size. | |||
* AES GCM is preferred to AES CBC, regardless of key size. | |||
==== 2. Camellia ==== | |||
Unlike AES with AES-NI, Camellia is not accelerate in CPU (as far as I know). That makes it significantly slower than AES and RC4. | |||
<source> | |||
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes | |||
aes-128-cbc 576200.99k 614446.29k 624010.15k 626885.29k 627610.97k <= with AES-NI | |||
rc4 411475.31k 529825.54k 675312.13k 711441.07k 715860.65k | |||
camellia-128 cbc 89921.94k 136523.43k 150717.61k 152728.23k 160970.07k | |||
</source> | |||
==== 3. DHE keysize ==== | |||
On DHE, it is important to note that, right now, all TLS servers that need backward compatibility are limited to 1024 bits DHE keys. Java 6, for example, doesn't support DHE keys higher than 1024 bits. The question is between trusted a single RSA key that's 2048 bits, or accepting to reduce the security to 1024bits, but using different keys for each session. We chose the later, and use 1024 bits DHE keys. |