MozillaWiki

Security/Server Side TLS: Difference between revisions

Page Discussion

Security/Server Side TLS (view source)

Revision as of 19:52, 31 October 2016

1,548 bytes added ,  31 October 2016
no edit summary
(followed but --> followed by - hopefully corrected what appeared to be an English misuse or typo (I may still need to get this change into github))
No edit summary
Line 3: Line 3:
     <td style="min-width: 25em;">__TOC__</td>
     <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.
     <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.
<span style="float: right; padding-top: 3em;">[[File:OpSec.png|300px]]</span>


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.
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.
Line 10: Line 9:


If you are looking for the configuration generator, click the image below:<br />
If you are looking for the configuration generator, click the image below:<br />
[[Image:Server-side-tls-config-generator.png|link=https://mozilla.github.io/server-side-tls/ssl-config-generator/]]
[[Image:Server-side-tls-config-generator.png|500px|center|link=https://mozilla.github.io/server-side-tls/ssl-config-generator/]]
     </td>
     </td>
   </tr>
   </tr>
Line 253: Line 252:


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.
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.
<source lang="bash">
 
$ openssl dhparam 2048
== Pre-defined DHE groups ==
Generating DH parameters, 2048 bit long safe prime, generator 2
 
..+..+...............+
Instead of using pre-configured DH groups, or generating their own with "openssl dhparam", operators should use the pre-defined DH groups ffdhe2048, ffdhe3072 or ffdhe4096 recommended by the IETF in [RFC 7919 https://tools.ietf.org/html/rfc7919]. These groups are audited and may be more resistant to attacks than ones randomly generated.
 
Note: if you must support old Java clients, Dh groups larger than 1024 bits may block connectivity (see [[#DHE_and_Java]]).
 
=== ffdhe2048 ===
<source>
-----BEGIN DH PARAMETERS-----
-----BEGIN DH PARAMETERS-----
MBYCEQCHU6UNZoHMF6bPtj21Hn/bAgEC.....
MIIBCAKCAQEA//////////+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz
......
+8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a
87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7
YdEIqUuyyOP7uWrat2DX9GgdT0Kj3jlN9K5W7edjcrsZCwenyO4KbXCeAvzhzffi
7MA0BM0oNC9hkXL+nOmFg/+OTxIy7vKBg8P+OxtMb61zO7X8vC7CIAXFjvGDfRaD
ssbzSibBsu/6iGtCOGEoXJf//////////wIBAg==
-----END DH PARAMETERS-----
-----END DH PARAMETERS-----
</source>
</source>


== Pre-defined DHE groups ==
=== ffdhe3072 ===
In order to lower the burden of system administrators, several servers provide pre-computed DH groups. Unfortunately, the [https://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#section-6.2 rfc2409]].
<source>
-----BEGIN DH PARAMETERS-----
MIIBiAKCAYEA//////////+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz
+8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a
87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7
YdEIqUuyyOP7uWrat2DX9GgdT0Kj3jlN9K5W7edjcrsZCwenyO4KbXCeAvzhzffi
7MA0BM0oNC9hkXL+nOmFg/+OTxIy7vKBg8P+OxtMb61zO7X8vC7CIAXFjvGDfRaD
ssbzSibBsu/6iGtCOGEfz9zeNVs7ZRkDW7w09N75nAI4YbRvydbmyQd62R0mkff3
7lmMsPrBhtkcrv4TCYUTknC0EwyTvEN5RPT9RFLi103TZPLiHnH1S/9croKrnJ32
nuhtK8UiNjoNq8Uhl5sN6todv5pC1cRITgq80Gv6U93vPBsg7j/VnXwl5B0rZsYu
N///////////AgEC
-----END DH PARAMETERS-----
</source>


For this reason, the use of this group is considered unsafe and you should either:
=== ffdhe4096 ===
* use a larger group, with a minimum size of 2048-bit, as recommended in the intermediate and modern configurations ;
<source>
* keep using a 1024-bit DH group if you need to (see [[#DHE_and_Java]]), but move away from Oakley group 2 and use a custom DH group instead, generated via the openssl dhparam 1024 command ;
-----BEGIN DH PARAMETERS-----
* disable DHE altogether, relying on ECDHE for PFS if you don't support legacy clients lacking ECDHE support (see [[#DHE_and_ECDHE_support]]).
MIICCAKCAgEA//////////+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz
 
+8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a
It is currently assumed that standardized 2048 bits DH groups provide sufficient security to resist factorization attacks. However, the careful administrator should generate a random DH group instead of using a
87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7
standardized one when setting up a new server, as advised by the [https://weakdh.org|logjam] authors.
YdEIqUuyyOP7uWrat2DX9GgdT0Kj3jlN9K5W7edjcrsZCwenyO4KbXCeAvzhzffi
7MA0BM0oNC9hkXL+nOmFg/+OTxIy7vKBg8P+OxtMb61zO7X8vC7CIAXFjvGDfRaD
ssbzSibBsu/6iGtCOGEfz9zeNVs7ZRkDW7w09N75nAI4YbRvydbmyQd62R0mkff3
7lmMsPrBhtkcrv4TCYUTknC0EwyTvEN5RPT9RFLi103TZPLiHnH1S/9croKrnJ32
nuhtK8UiNjoNq8Uhl5sN6todv5pC1cRITgq80Gv6U93vPBsg7j/VnXwl5B0rZp4e
8W5vUsMWTfT7eTDp5OWIV7asfV9C1p9tGHdjzx1VA0AEh/VbpX4xzHpxNciG77Qx
iu1qHgEtnmgyqQdgCpGBMMRtx3j5ca0AOAkpmaMzy4t6Gh25PXFAADwqTs6p+Y0K
zAqCkc3OyX3Pjsm1Wn+IpGtNtahR9EGC4caKAH5eZV9q//////////8CAQI=
-----END DH PARAMETERS-----
</source>


== DHE and ECDHE support ==
== DHE and ECDHE support ==
Line 288: Line 317:


If keeping the compatibility with Java < 7 is a necessity, thus preventing the use of large DH keys, three solutions are available:
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 ;
* 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 be at risk from a state-level adversary ;
* 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 may be at risk of a 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.
* 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.


Line 377: Line 406:
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.
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 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.
On XPSP2, IE6 is only able to establish connections to servers that provide a certificate signed with sha1WithRSAEncryption. Those certificates are 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.
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.
Line 463: Line 492:
   
   
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.
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.
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.
Line 512: Line 540:
== TLS tickets (RFC 5077) ==
== TLS tickets (RFC 5077) ==


Once a TLS handshake has been negociated between the server and the client, both may exchange a session ticket, which contains an AES-CBC 128bit key which can decrypt the session. This 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).
Once a TLS handshake has been negotiated between the server and the client, both may exchange a session ticket, which contains the session and is usually encrypted with AES-CBC 128bit. 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 work-around is to disable RFC 5077 support.
The key 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-off we recommend is to implement restarts of web servers and force deletion of local caches to renew encryption keys.


more: https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-Slides.pdf
more information: https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-Slides.pdf


== Cipher names correspondence table ==
== Cipher names correspondence table ==
Line 2,816: Line 2,844:
! Editor
! Editor
! Changes
! 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
| style="text-align: center;" | 4
Ulfr
Confirmed users
529

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1153120"