Talk:Security/Server Side TLS: Difference between revisions

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.
Confirmed users
529

edits