Confirmed users
529
edits
Security/Server Side TLS: Difference between revisions
Jump to navigation
Jump to search
Version 2.1: ulfr: RC4 vs 3DES discussion. r=joes r=tinfoil
m (Removed protection from "Security/Server Side TLS": unprotect per ulfr) |
(Version 2.1: ulfr: RC4 vs 3DES discussion. r=joes r=tinfoil) |
||
| Line 11: | Line 11: | ||
|- | |- | ||
| <span style="color:green;">'''READY'''</span> || | | <span style="color:green;">'''READY'''</span> || | ||
* Version 2.1: ulfr: RC4 vs 3DES discussion. r=joes r=tinfoil | |||
* Version 2: Public release. r=ulfr r=kang | * Version 2: Public release. r=ulfr r=kang | ||
* Version 1.5: Julien Vehent (ulfr) added details for PFS DHE handshake, added nginx configuration details; Guillaume Destuynder (kang): added Apache recommended conf | * Version 1.5: Julien Vehent (ulfr) added details for PFS DHE handshake, added nginx configuration details; Guillaume Destuynder (kang): added Apache recommended conf | ||
| Line 130: | Line 131: | ||
# AES 128 is preferred to AES 256. There has been [[http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html discussions]] on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks. | # AES 128 is preferred to AES 256. There has been [[http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html discussions]] on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks. | ||
# AES is preferred to RC4. [[#Attacks_on_TLS|BEAST]] attacks on AES are mitigated in TLS 1.1 and above, and difficult to achieve in TLS 1.0. In comparison, attacks on RC4 are not mitigated and likely to become more and more dangerous. | # AES is preferred to RC4. [[#Attacks_on_TLS|BEAST]] attacks on AES are mitigated in TLS 1.1 and above, and difficult to achieve in TLS 1.0. In comparison, attacks on RC4 are not mitigated and likely to become more and more dangerous. | ||
# RC4 is on the path to removal, but still present for backward compatibility, see the discussion in [[#RC4_weaknesses]] | |||
= Mandatory discards = | = Mandatory discards = | ||
| Line 136: | Line 138: | ||
* eNULL contains null-encryption ciphers (cleartext) | * eNULL contains null-encryption ciphers (cleartext) | ||
* EXPORT are legacy weak ciphers that were marked as exportable by US law | * EXPORT are legacy weak ciphers that were marked as exportable by US law | ||
* DES | * DES contains ciphers that use the deprecated Data Encryption Standard | ||
* SSLv2 contains all ciphers that were defined in the old version of the SSL standard, now deprecated | * SSLv2 contains all ciphers that were defined in the old version of the SSL standard, now deprecated | ||
* MD5 contains all the ciphers that use the deprecated message digest 5 as the hashing algorithm | * MD5 contains all the ciphers that use the deprecated message digest 5 as the hashing algorithm | ||
| Line 480: | Line 482: | ||
=== RC4 weaknesses === | === RC4 weaknesses === | ||
It has been proven that RC4 biases in the first 256 bytes of a cipherstream can be used to recover encrypted text. If the same data is encrypted a very large number of times, then an attacker can apply statistical analysis to the results and recover the encrypted text. While hard to perform, this attack shows that it is time to | It has been proven that RC4 biases in the first 256 bytes of a cipherstream can be used to recover encrypted text. If the same data is encrypted a very large number of times, then an attacker can apply statistical analysis to the results and recover the encrypted text. While hard to perform, this attack shows that it is time to remove RC4 from the list of trusted ciphers. | ||
In a public discussion ([[https://bugzilla.mozilla.org/show_bug.cgi?id=927045 bug 927045]]), it has been recommended to replace RC4 with 3DES. Internet Explorer 7 and 8 do not support AES, and will negotiate only RC4 or 3DES ciphers. While 3DES provides more resistant cryptography, it is also 30 times slower and more cpu intensive than RC4. For large web infrastructure, the CPU cost of replacing 3DES with RC4 is non-zero. For this reason, we recommend that administrators evaluate their traffic patterns, and make the decision of replacing RC4 with 3DES on a per-case basis. | |||
For information, the following ciphersuite replaces RC4 with 3DES: | |||
'''ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK''' | |||
=== CRIME CVE-2012-4929 === | === CRIME CVE-2012-4929 === | ||