Confirm
529
edits
Changes
no edit summary
<td style="min-width: 25em;">__TOC__</td>
<td style="vertical-align: top; padding-left: 1em;">The goal of this document is to help operational teams with the configuration of TLS on servers. All Mozilla sites and deployment should follow the recommendations below.
The Operations Security (OpSec) team maintains this document as a reference guide to navigate the TLS landscape. It contains information on TLS protocols, known issues and vulnerabilities, configuration examples and testing tools. Changes are reviewed and merged by the OpSec team, and broadcasted to the various Operational teams.
If you are looking for the configuration generator, click the image below:<br />
[[Image:Server-side-tls-config-generator.png|500px|center|link=https://mozilla.github.io/server-side-tls/ssl-config-generator/]]
</td>
</tr>
The size of the prime number ''p'' constrains the size of the pre-master key ''PMS'', because of the modulo operation. A smaller prime almost means weaker values of ''A'' and ''B'', which could leak the secret values ''X'' and ''Y''. Thus, the prime ''p'' should not be smaller than the size of the RSA private key.
-----BEGIN DH PARAMETERS-----
-----END DH PARAMETERS-----
</source>
== Pre-defined DHE groups = ffdhe3072 ===In order to lower the burden of system administrators, several servers provide pre<source>-----computed BEGIN DH groups. Unfortunately, the [https:PARAMETERS-----MIIBiAKCAYEA//////////+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz+8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7YdEIqUuyyOP7uWrat2DX9GgdT0Kj3jlN9K5W7edjcrsZCwenyO4KbXCeAvzhzffi7MA0BM0oNC9hkXL+nOmFg/+OTxIy7vKBg8P+OxtMb61zO7X8vC7CIAXFjvGDfRaDssbzSibBsu/6iGtCOGEfz9zeNVs7ZRkDW7w09N75nAI4YbRvydbmyQd62R0mkff37lmMsPrBhtkcrv4TCYUTknC0EwyTvEN5RPT9RFLi103TZPLiHnH1S/9croKrnJ32nuhtK8UiNjoNq8Uhl5sN6todv5pC1cRITgq80Gv6U93vPBsg7j/VnXwl5B0rZsYuN//////weakdh.org/ logjam] report showed that it is very likely that a state-level adversary may have broken the most widely used 1024-bit DH group, Oakley group 2, standardized in [https://tools.ietf.org/html/rfc2409#sectionAgEC-----6.2 rfc2409]].END DH PARAMETERS-----</source>
== DHE and ECDHE support ==
If keeping the compatibility with Java < 7 is a necessity, thus preventing the use of large DH keys, three solutions are available:
* using custom 1024-bit DH parameters, different from Oakley group 2 , preferably generated with '''openssl dhparam 1024''' ;* if the software used does not support custom DH parameters, like Apache HTTPd < 2.2.30, it is possible to keep using the 1024-bit DH Oakley group 2, knowing these clients will may be at risk from of a state-level adversary compromise;
* it is also possible to completely disable DHE. This means that clients not supporting ECDHE will be reverting to static RSA, giving up Forward Secrecy.
Certificates Switching is a technique by which a server provides a different X.509 certificate to a client based on specific selection criteria. This technique is used primarily to maintain backward compatibility with very old clients, such as Internet Explorer 6 on Windows XP SP2.
On XPSP2, IE6 is only able to establish connections to servers that provide a certificate signed with sha1WithRSAEncryption. Those certificates are note not issued by modern CAs anymore, and all sites have been encouraged to upgrade to SHA-256 certificates. As modern browsers gradually block connections backed by SHA-1 certificates, sites that need to maintain compatibility with XPSP2 must implement certificates switching to provide a SHA-1 cert to old clients and a SHA-256 cert to modern ones.
Certificate switching can be implemented in various ways. A simplistic approach is to select the certificate based on the protocol version (SHA-256 to TLS clients, SHA-1 to SSLv3 ones). A more sophisticated approach consists at looking inside the CLIENT HELLO for SHA-256 support in the "signature_algorithms" extension.
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 RC4 with 3DES 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. At Mozilla, we evaluated that the impact on CPU usage is minor, and thus decided to replace RC4 with 3DES where backward compatibility is required.
The root cause of the problem is information leakage that occurs when data is compressed prior to encryption. If someone can repeatedly inject and mix arbitrary content with some sensitive and relatively predictable data, and observe the resulting encrypted stream, then he will be able to extract the unknown data from it.
== TLS tickets (RFC 5077) ==
Once a TLS handshake has been negociated negotiated between the server and the client, both may exchange a session ticket, which contains an the session and is usually encrypted with AES-CBC 128bit key which can decrypt the session. This AES key is generally static and only regenerated when the web server is restarted (with recent versions of Apache, it's stored in a file and also kept upon restarts).
The current workkey that encrypts TLS tickets in servers is very hard to manage and potentially introduces a security risk if not renewed regularly: if a server is breached, the key can be stolen and used to decrypt recorded TLS tickets, thus leaking session keys. TLS tickets do bring a performance benefit because of session resumption, but administrators that are more concerned about security than performance may want to disable them entirely. The trade-around off we recommend is to disable RFC 5077 supportimplement restarts of web servers and force deletion of local caches to renew encryption keys.
moreinformation: https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-Slides.pdf
== Cipher names correspondence table ==
! Editor
! Changes
|-
| style="text-align: center;" | 4.1
| style="text-align: center;" | Julien Vehent
| Clarify Logjam notes, Clarify risk of TLS Tickets
|-
| style="text-align: center;" | 4
