MozillaWiki

Security/Server Side TLS: Difference between revisions

< Security
(Move cipher suite table elsewhere)
(Update to commit 7a81eec5519983e1408cafe4936b4f85ae6a0997)
 
(9 intermediate revisions by 2 users not shown)
Line 2: Line 2:
   <tr>
   <tr>
     <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; max-width: 60em; padding-left: .75rem;">The goal of this document is to help operational teams with the configuration of TLS. All Mozilla websites and deployments 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.
Mozilla maintains this document as a reference guide for navigating the TLS landscape, as well as a [https://ssl-config.mozilla.org configuration generator] to assist system administrators. Changes are reviewed and merged by the Mozilla Operations Security and Enterprise Information Security teams.


Updates to this page should be submitted to the [https://github.com/mozilla/server-side-tls source repository on github].
Updates to this page should be submitted to the [https://github.com/mozilla/server-side-tls server-side-tls] repository on GitHub. Issues related to the [https://ssl-config.mozilla.org configuration generator] are maintained in their own [https://github.com/mozilla/ssl-config-generator GitHub repository].


If you are looking for the configuration generator, click the image below:<br />
In the interests of usability and maintainability, these guidelines have been considerably simplified from the [[Security/Archive/Server Side TLS 4.0|previous guidelines]].
[[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 15: Line 14:


= Recommended configurations =
= Recommended configurations =
Three configurations are recommended. Pick the right configuration depending on your audience. If you do not need backward compatibility, and are building a service for modern clients only (post Firefox 27/Chrome 22), then use the Modern configuration. Otherwise, prefer the Intermediate configuration. Use the Old backward compatible configuration only if your service will be accessed by very old clients, such as Windows XP IE6, or ancient libraries & bots.
<span style="float: right; max-width: 600px; text-align: center;">
[[Image:Ssl-config.mozilla.org.png|600px|link=https://ssl-config.mozilla.org/|Mozilla SSL Configuration Generator]]<br>
The [https://ssl-config.mozilla.org/ Mozilla SSL Configuration Generator]
</span>
Mozilla maintains three recommended configurations for servers using TLS. Pick the correct configuration depending on your audience:


{| class="wikitable"
* <span style="color: green; font-weight: bold;">Modern</span>''':''' Modern clients that support TLS 1.3, with no need for backwards compatibility
* <span style="color: orange; font-weight: bold;">Intermediate</span>''':''' Recommended configuration for a general-purpose server
* <span style="color: gray; font-weight: bold;">Old</span>''':''' Services accessed by very old clients or libraries, such as Internet Explorer 8 (Windows XP), Java 6, or OpenSSL 0.9.8
 
{| class="wikitable" style="margin: 1.5rem 1rem;"
|-
|-
! Configuration !! Oldest compatible client
! Configuration
! Firefox
! Android
! Chrome
! Edge
! Internet Explorer
! Java
! OpenSSL
! Opera
! Safari
|-
|-
| <span style="color:green;">'''Modern'''</span> || Firefox 27, Chrome 30, IE 11 on Windows 7, Edge, Opera 17, Safari 9, Android 5.0, Java 8
| style="color: green;" | '''Modern'''
| style="text-align: center;" | 63
| style="text-align: center;" | 10.0
| style="text-align: center;" | 70
| style="text-align: center;" | 75
| style="text-align: center;" | --
| style="text-align: center;" | 11
| style="text-align: center;" | 1.1.1
| style="text-align: center;" | 57
| style="text-align: center;" | 12.1
|-
|-
| <span style="color:orange;">'''Intermediate'''</span> || Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3, Java 7
| style="color:orange;" | '''Intermediate'''
| style="text-align: center;" | 27
| style="text-align: center;" | 4.4.2
| style="text-align: center;" | 31
| style="text-align: center;" | 12
| style="text-align: center;" | 11 (Win7)
| style="text-align: center;" | 8u31
| style="text-align: center;" | 1.0.1
| style="text-align: center;" | 20
| style="text-align: center;" | 9
|-
|-
| <span style="color:gray;">'''Old'''</span> || Windows XP IE6, Java 6
| style="color:gray;" | '''Old'''
| style="text-align: center;" | 1
| style="text-align: center;" | 2.3
| style="text-align: center;" | 1
| style="text-align: center;" | 12
| style="text-align: center;" | 8 (WinXP)
| style="text-align: center;" | 6
| style="text-align: center;" | 0.9.8
| style="text-align: center;" | 5
| style="text-align: center;" | 1
|}
|}


<p style="max-width: 60em;">The ordering of cipher suites in the <span style="color: gray; font-weight: bold;">Old</span> configuration is very important, as it determines the priority with which algorithms are selected.</p>


Older versions of OpenSSL may not return the full list of algorithms. AES-GCM and some ECDHE are fairly recent, and not present on most versions of OpenSSL shipped with Ubuntu or RHEL. This listing below was obtained from a freshly built OpenSSL. If your version of OpenSSL is old, unavailable ciphers will be discarded automatically. Always use the full ciphersuite and let OpenSSL pick the ones it supports.
<p style="max-width: 60em;">OpenSSL will ignore cipher suites it doesn't understand, so always use the full set of cipher suites below, in their recommended order. The use of the <span style="color: gray; font-weight: bold;">Old</span> configuration with modern versions of OpenSSL may require custom builds with support for deprecated ciphers.</p>
 
<br style="clear: right;">
The ordering of a ciphersuite is very important because it decides which algorithms are going to be selected in priority. Each level shows the list of algorithms returned by its ciphersuite. If you have to pick ciphers manually for your application, make sure you keep the ordering.
 
The ciphersuite numbers listed come from the IANA [https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 TLS Cipher Suite Registry]. Previous versions of these recommendations included draft numbers for ECDHE-ECDSA-CHACHA20-POLY1305 (0xCC,0x14) and ECDHE-RSA-CHACHA20-POLY1305 (0xCC,0x13).


== <span style="color:green;">'''Modern'''</span> compatibility ==
== <span style="color:green;">'''Modern'''</span> compatibility ==
For services that don't need backward compatibility, the parameters below provide a higher level of security. This configuration is compatible with Firefox 27, Chrome 30, IE 11 on Windows 7, Edge, Opera 17, Safari 9, Android 5.0, and Java 8.
For services with clients that support TLS 1.3 and don't need backward compatibility, the <span style="color: green; font-weight: bold;">Modern</span> configuration provides an extremely high level of security.


* Ciphersuites: '''ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'''
* Cipher suites (TLS 1.3): '''TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'''
* Versions: '''TLSv1.2'''
* Cipher suites (TLS 1.2): (none)
* TLS curves: '''prime256v1, secp384r1, secp521r1'''
* Protocols: '''TLS 1.3'''
* Certificate type: '''ECDSA'''
* Certificate type: '''ECDSA (P-256)'''
* Certificate curve: '''prime256v1, secp384r1, secp521r1'''
* TLS curves: '''X25519, prime256v1, secp384r1'''
* Certificate signature: '''sha256WithRSAEncryption, ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512'''
* HSTS: '''max-age=63072000''' (two years)
* RSA key size: '''2048''' (if not ecdsa)
* Certificate lifespan: '''90 days'''
* DH Parameter size: '''None''' (disabled entirely)
* Cipher preference: '''client chooses'''
* ECDH Parameter size: '''256'''
* HSTS: '''max-age=15768000'''
* Certificate switching: '''None'''


<!-- This tabular openssl list can be produced by running "openssl ciphers -V" -->
<source>
<source>
0xC0,0x2C -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256)   Mac=AEAD
0x13,0x01 -  TLS_AES_128_GCM_SHA256        TLSv1.3 Kx=any Au=any Enc=AESGCM(128)             Mac=AEAD
0xC0,0x30 -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2 Kx=ECDH Au=RSA    Enc=AESGCM(256)   Mac=AEAD
0x13,0x02 -  TLS_AES_256_GCM_SHA384        TLSv1.3 Kx=any Au=any  Enc=AESGCM(256)             Mac=AEAD
0xCC,0xA9 -  ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=ChaCha20(256)  Mac=AEAD
0x13,0x03 -  TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0xCC,0xA8  -  ECDHE-RSA-CHACHA20-POLY1305   TLSv1.2  Kx=ECDH  Au=RSA    Enc=ChaCha20(256)  Mac=AEAD
0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)    Mac=AEAD
0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)    Mac=AEAD
0xC0,0x24  -  ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(256)      Mac=SHA384
0xC0,0x28  -  ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(256)      Mac=SHA384
0xC0,0x23  -  ECDHE-ECDSA-AES128-SHA256      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(128)      Mac=SHA256
0xC0,0x27  -  ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(128)      Mac=SHA256
</source>
</source>


Rationale:
* Rationale:
* AES256-GCM is prioritized above its 128 bits variant, and ChaCha20 because we assume that most modern devices support AESNI instructions and thus benefit from fast and constant time AES.
** All cipher suites are [https://en.wikipedia.org/wiki/Forward_secrecy forward secret] and [https://en.wikipedia.org/wiki/Authenticated_encryption authenticated]
* We recommend ECDSA certificates with P256 as other curves may not be supported everywhere. RSA signatures on ECDSA certificates are permitted because very few CAs sign with ECDSA at the moment.
** The cipher suites are all strong and so we allow the client to choose, as they will know best if they have support for hardware-accelerated AES
* DHE is removed entirely because it is slow in comparison with ECDHE, and all modern clients support elliptic curve key exchanges.
** We recommend ECDSA certificates using P-256, as P-384 provides negligible improvements to security and Ed25519 is not yet widely supported
* SHA1 signature algorithm is removed in favor of SHA384 for AES256 and SHA256 for AES128.


== <span style="color:orange;">'''Intermediate'''</span> compatibility (default) ==
== <span style="color:orange;">'''Intermediate'''</span> compatibility (recommended) ==
For services that don't need compatibility with legacy clients (mostly WinXP), but still need to support a wide range of clients, this configuration is recommended. It is is compatible with Firefox 1, Chrome 1, IE 7, Opera 5 and Safari 1.
<p style="max-width: 60em;">For services that don't need compatibility with legacy clients such as Windows XP or old versions of OpenSSL. This is the recommended configuration for the vast majority of services, as it is highly secure and compatible with nearly every client released in the last five (or more) years.</p>


* Ciphersuites: '''ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS'''
* Cipher suites (TLS 1.3): '''TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'''
* Versions: '''TLSv1.2, TLSv1.1, TLSv1'''
* Cipher suites (TLS 1.2): '''ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305'''
* TLS curves: '''prime256v1, secp384r1, secp521r1'''
* Protocols: '''TLS 1.2, TLS 1.3'''
* Certificate type: '''RSA'''
* TLS curves: '''X25519, prime256v1, secp384r1'''
* Certificate curve: '''None'''
* Certificate type: '''ECDSA (P-256)''' (recommended), or '''RSA (2048 bits)'''
* Certificate signature: '''sha256WithRSAEncryption'''
* DH parameter size: '''2048''' (ffdhe2048, [https://tools.ietf.org/html/rfc7919#appendix-A.1 RFC 7919])
* RSA key size: '''2048'''
* HSTS: '''max-age=63072000''' (two years)
* DH Parameter size: '''2048'''
* Certificate lifespan: '''90 days''' (recommended) to '''366 days'''
* ECDH Parameter size: '''256'''
* Cipher preference: '''client chooses'''
* HSTS: '''max-age=15768000'''
* Certificate switching: '''None'''


<!-- This tabular openssl list can be produced by running "openssl ciphers -V" -->
<source>
<source>
0xCC,0xA9 -  ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH  Au=ECDSA  Enc=ChaCha20(256) Mac=AEAD
0x13,0x01 -  TLS_AES_128_GCM_SHA256        TLSv1.3  Kx=any  Au=any    Enc=AESGCM(128)            Mac=AEAD
0xCC,0xA8 -  ECDHE-RSA-CHACHA20-POLY1305    TLSv1.2 Kx=ECDH  Au=RSA   Enc=ChaCha20(256)  Mac=AEAD
0x13,0x02  -  TLS_AES_256_GCM_SHA384        TLSv1.3 Kx=any  Au=any    Enc=AESGCM(256)             Mac=AEAD
0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)   Mac=AEAD
0x13,0x03 -  TLS_CHACHA20_POLY1305_SHA256  TLSv1.3 Kx=any  Au=any   Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)   Mac=AEAD
0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)             Mac=AEAD
0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)   Mac=AEAD
0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)             Mac=AEAD
0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)   Mac=AEAD
0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)             Mac=AEAD
0x00,0x9E  -  DHE-RSA-AES128-GCM-SHA256      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(128)    Mac=AEAD
0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0x00,0x9F  -  DHE-RSA-AES256-GCM-SHA384      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(256)    Mac=AEAD
0xCC,0xA9 -  ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0xC0,0x23 -  ECDHE-ECDSA-AES128-SHA256      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(128)      Mac=SHA256
0xCC,0xA8 -  ECDHE-RSA-CHACHA20-POLY1305   TLSv1.2  Kx=ECDH  Au=RSA   Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0xC0,0x27  -  ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(128)      Mac=SHA256
0x00,0x9E -  DHE-RSA-AES128-GCM-SHA256     TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(128)            Mac=AEAD
0xC0,0x09  -  ECDHE-ECDSA-AES128-SHA        SSLv3    Kx=ECDH  Au=ECDSA  Enc=AES(128)       Mac=SHA1
0x00,0x9F -  DHE-RSA-AES256-GCM-SHA384     TLSv1.2  Kx=DH   Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0xC0,0x28  - ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(256)      Mac=SHA384
0xCC,0xAA -  DHE-RSA-CHACHA20-POLY1305      TLSv1.2  Kx=DH   Au=RSA    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0xC0,0x13 -  ECDHE-RSA-AES128-SHA          SSLv3    Kx=ECDH  Au=RSA   Enc=AES(128)      Mac=SHA1
0xC0,0x24  -  ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(256)      Mac=SHA384
0xC0,0x0A  -  ECDHE-ECDSA-AES256-SHA        SSLv3   Kx=ECDH  Au=ECDSA  Enc=AES(256)       Mac=SHA1
0xC0,0x14  -  ECDHE-RSA-AES256-SHA          SSLv3    Kx=ECDH Au=RSA    Enc=AES(256)      Mac=SHA1
0x00,0x67 -  DHE-RSA-AES128-SHA256         TLSv1.2  Kx=DH    Au=RSA    Enc=AES(128)       Mac=SHA256
0x00,0x33  -  DHE-RSA-AES128-SHA             SSLv3    Kx=DH    Au=RSA    Enc=AES(128)      Mac=SHA1
0x00,0x6B -  DHE-RSA-AES256-SHA256          TLSv1.2  Kx=DH    Au=RSA    Enc=AES(256)      Mac=SHA256
0x00,0x39  - DHE-RSA-AES256-SHA            SSLv3    Kx=DH    Au=RSA    Enc=AES(256)      Mac=SHA1
0xC0,0x08  -  ECDHE-ECDSA-DES-CBC3-SHA      SSLv3    Kx=ECDH  Au=ECDSA  Enc=3DES(168)      Mac=SHA1
0xC0,0x12  -  ECDHE-RSA-DES-CBC3-SHA        SSLv3    Kx=ECDH  Au=RSA    Enc=3DES(168)      Mac=SHA1
0x00,0x16  -  EDH-RSA-DES-CBC3-SHA          SSLv3    Kx=DH    Au=RSA    Enc=3DES(168)     Mac=SHA1
0x00,0x9C  -  AES128-GCM-SHA256              TLSv1.2  Kx=RSA  Au=RSA   Enc=AESGCM(128)    Mac=AEAD
0x00,0x9D  -  AES256-GCM-SHA384              TLSv1.2  Kx=RSA  Au=RSA    Enc=AESGCM(256)   Mac=AEAD
0x00,0x3C -  AES128-SHA256                  TLSv1.2  Kx=RSA   Au=RSA    Enc=AES(128)      Mac=SHA256
0x00,0x3D  - AES256-SHA256                  TLSv1.2  Kx=RSA  Au=RSA   Enc=AES(256)      Mac=SHA256
0x00,0x2F  -  AES128-SHA                    SSLv3    Kx=RSA  Au=RSA    Enc=AES(128)      Mac=SHA1
0x00,0x35  -  AES256-SHA                    SSLv3    Kx=RSA  Au=RSA    Enc=AES(256)       Mac=SHA1
0x00,0x0A  - DES-CBC3-SHA                  SSLv3    Kx=RSA  Au=RSA    Enc=3DES(168)      Mac=SHA1
</source>
</source>


Rationale:
* Rationale:
* ChaCha20 is prefered as the fastest and safest in-software cipher, followed by AES128. Unlike the modern configuration, we do not assume clients support AESNI and thus do not prioritize AES256 above 128 and ChaCha20. There has been discussions ([http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html 1], [http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg12398.html 2]) on whether AES256 extra security was worth its computing cost in software (without AESNI), and the results are 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.
** All cipher suites are [https://en.wikipedia.org/wiki/Forward_secrecy forward secret] and [https://en.wikipedia.org/wiki/Authenticated_encryption authenticated]
* DES-CBC3-SHA and EDH-RSA-DES-CBC3-SHA are maintained for backward compatibility with clients that do not support AES.
** TLS 1.2 is the minimum supported protocol, as recommended by [https://tools.ietf.org/html/rfc7525#section-3.1.1 RFC 7525], PCI DSS, and others
* While the goal is to support a broad range of clients, we reasonably disable a number of ciphers that have little support (such as SEED, CAMELLIA, ...).
** ECDSA certificates are recommended over RSA certificates, as they allow the use of ECDHE with Windows 7 clients using Internet Explorer 11, as well as allow connections from IE11 on Windows Server 2008 R2
** The cipher suites are all strong and so we allow the client to choose, as they will know best if they have support for hardware-accelerated AES
** Windows XP (including all embedded versions) are no longer supported by Microsoft, eliminating the need for many older protocols and ciphers
** Administrators needing to provide access to [https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%207&key=36 IE 11 on Windows Server 2008 R2] and who are unable to switch to or add ECDSA certificates can add <tt>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</tt>
** While the goal is to support a broad range of clients, we reasonably disable a number of ciphers that have little support (such as ARIA, Camellia, 3DES, and SEED)
** 90 days is the recommended maximum certificate lifespan, to encourage certificate issuance automation


== <span style="color:gray;">'''Old'''</span> backward compatibility ==
== <span style="color:gray;">'''Old'''</span> backward compatibility ==


This is the old ciphersuite that works with all clients back to Windows XP/IE6. It should be used as a last resort only.
This configuration is compatible with a number of very old clients, and should be used only as a last resort.


* Ciphersuites: '''ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256: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-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP'''
* Cipher suites (TLS 1.3): '''TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'''
* Versions: '''TLSv1.2, TLSv1.1, TLSv1, SSLv3'''
* Cipher suites (TLS 1.0 - 1.2): '''ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA'''
* TLS curves: '''prime256v1, secp384r1, secp521r1'''
* Protocols: '''TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3'''
* Certificate type: '''RSA'''
* TLS curves: '''X25519, prime256v1, secp384r1'''
* Certificate type: '''RSA (2048-bits)'''
* Certificate curve: '''None'''
* Certificate curve: '''None'''
* Certificate signature: '''sha256WithRSAEncryption'''
* DH parameter size: '''1024''' (generated with <tt>openssl dhparam 1024</tt>)
* RSA key size: '''2048'''
* HSTS: '''max-age=63072000''' (two years)
* DH Parameter size: '''1024'''
* Certificate lifespan: '''90 days''' (recommended) to '''366 days'''
* ECDH Parameter size: '''256'''
* Cipher preference: '''server chooses'''
* HSTS: '''max-age=15768000'''
* Certificate switching: '''sha1WithRSAEncryption'''


<!-- This tabular openssl list can be produced by running "openssl ciphers -V" -->
<source>
<source>
0xCC,0xA9 -  ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2 Kx=ECDH  Au=ECDSA  Enc=ChaCha20(256) Mac=AEAD
0x13,0x01 -  TLS_AES_128_GCM_SHA256        TLSv1.3  Kx=any  Au=any    Enc=AESGCM(128)            Mac=AEAD
0xCC,0xA8 -  ECDHE-RSA-CHACHA20-POLY1305    TLSv1.2 Kx=ECDH  Au=RSA   Enc=ChaCha20(256)  Mac=AEAD
0x13,0x02  - TLS_AES_256_GCM_SHA384        TLSv1.3 Kx=any  Au=any    Enc=AESGCM(256)             Mac=AEAD
0xC0,0x2F -  ECDHE-RSA-AES128-GCM-SHA256     TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)   Mac=AEAD
0x13,0x03 -  TLS_CHACHA20_POLY1305_SHA256  TLSv1.3 Kx=any  Au=any   Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0xC0,0x2B -  ECDHE-ECDSA-AES128-GCM-SHA256   TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)   Mac=AEAD
0xC0,0x2B -  ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)             Mac=AEAD
0xC0,0x30 -  ECDHE-RSA-AES256-GCM-SHA384     TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)   Mac=AEAD
0xC0,0x2F -  ECDHE-RSA-AES128-GCM-SHA256   TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)             Mac=AEAD
0xC0,0x2C -  ECDHE-ECDSA-AES256-GCM-SHA384   TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)   Mac=AEAD
0xC0,0x2C -  ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)             Mac=AEAD
0x00,0x9E -  DHE-RSA-AES128-GCM-SHA256      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(128)   Mac=AEAD
0xC0,0x30 -  ECDHE-RSA-AES256-GCM-SHA384   TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0x00,0xA2 -  DHE-DSS-AES128-GCM-SHA256      TLSv1.2  Kx=DH    Au=DSS   Enc=AESGCM(128)   Mac=AEAD
0xCC,0xA9 -  ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x00,0xA3 -  DHE-DSS-AES256-GCM-SHA384      TLSv1.2  Kx=DH    Au=DSS   Enc=AESGCM(256)   Mac=AEAD
0xCC,0xA8 -  ECDHE-RSA-CHACHA20-POLY1305    TLSv1.2  Kx=ECDH  Au=RSA   Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x00,0x9F  -  DHE-RSA-AES256-GCM-SHA384       TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(256)   Mac=AEAD
0x00,0x9E -  DHE-RSA-AES128-GCM-SHA256      TLSv1.2  Kx=DH    Au=RSA   Enc=AESGCM(128)             Mac=AEAD
0xC0,0x27 -  ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(128)       Mac=SHA256
0x00,0x9F  -  DHE-RSA-AES256-GCM-SHA384     TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0xC0,0x23  -  ECDHE-ECDSA-AES128-SHA256       TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(128)       Mac=SHA256
0xCC,0xAA -  DHE-RSA-CHACHA20-POLY1305      TLSv1.2  Kx=DH    Au=RSA    Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xC0,0x13 -  ECDHE-RSA-AES128-SHA            SSLv3    Kx=ECDH  Au=RSA    Enc=AES(128)       Mac=SHA1
0xC0,0x23  -  ECDHE-ECDSA-AES128-SHA256     TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(128)               Mac=SHA256
0xC0,0x09  -  ECDHE-ECDSA-AES128-SHA         SSLv3   Kx=ECDH  Au=ECDSA  Enc=AES(128)       Mac=SHA1
0xC0,0x27 -  ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(128)               Mac=SHA256
0xC0,0x28 -  ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(256)       Mac=SHA384
0xC0,0x09  -  ECDHE-ECDSA-AES128-SHA         TLSv1   Kx=ECDH  Au=ECDSA  Enc=AES(128)               Mac=SHA1
0xC0,0x24  -  ECDHE-ECDSA-AES256-SHA384       TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(256)       Mac=SHA384
0xC0,0x13 -  ECDHE-RSA-AES128-SHA          TLSv1   Kx=ECDH  Au=RSA    Enc=AES(128)               Mac=SHA1
0xC0,0x14 -  ECDHE-RSA-AES256-SHA            SSLv3    Kx=ECDH  Au=RSA    Enc=AES(256)       Mac=SHA1
0xC0,0x24  -  ECDHE-ECDSA-AES256-SHA384     TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(256)               Mac=SHA384
0xC0,0x0A  -  ECDHE-ECDSA-AES256-SHA         SSLv3   Kx=ECDH  Au=ECDSA  Enc=AES(256)       Mac=SHA1
0xC0,0x28 -  ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(256)               Mac=SHA384
0x00,0x67 -  DHE-RSA-AES128-SHA256           TLSv1.2  Kx=DH    Au=RSA    Enc=AES(128)      Mac=SHA256
0xC0,0x0A  -  ECDHE-ECDSA-AES256-SHA         TLSv1   Kx=ECDH  Au=ECDSA  Enc=AES(256)               Mac=SHA1
0x00,0x33  - DHE-RSA-AES128-SHA              SSLv3    Kx=DH    Au=RSA    Enc=AES(128)       Mac=SHA1
0xC0,0x14 -  ECDHE-RSA-AES256-SHA           TLSv1   Kx=ECDH Au=RSA    Enc=AES(256)               Mac=SHA1
0x00,0x40 -  DHE-DSS-AES128-SHA256           TLSv1.2  Kx=DH    Au=DSS   Enc=AES(128)       Mac=SHA256
0x00,0x67 -  DHE-RSA-AES128-SHA256         TLSv1.2  Kx=DH    Au=RSA   Enc=AES(128)               Mac=SHA256
0x00,0x6B  -  DHE-RSA-AES256-SHA256           TLSv1.2  Kx=DH    Au=RSA    Enc=AES(256)       Mac=SHA256
0x00,0x6B  -  DHE-RSA-AES256-SHA256         TLSv1.2  Kx=DH    Au=RSA    Enc=AES(256)               Mac=SHA256
0x00,0x38  -  DHE-DSS-AES256-SHA              SSLv3    Kx=DH    Au=DSS    Enc=AES(256)      Mac=SHA1
0x00,0x9C  -  AES128-GCM-SHA256             TLSv1.2  Kx=RSA  Au=RSA    Enc=AESGCM(128)             Mac=AEAD
0x00,0x39  -  DHE-RSA-AES256-SHA              SSLv3    Kx=DH    Au=RSA    Enc=AES(256)      Mac=SHA1
0x00,0x9D  -  AES256-GCM-SHA384             TLSv1.2  Kx=RSA  Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0xC0,0x12  -  ECDHE-RSA-DES-CBC3-SHA          SSLv3    Kx=ECDH  Au=RSA    Enc=3DES(168)      Mac=SHA1
0x00,0x3C  -  AES128-SHA256                 TLSv1.2  Kx=RSA  Au=RSA    Enc=AES(128)               Mac=SHA256
0xC0,0x08  -  ECDHE-ECDSA-DES-CBC3-SHA        SSLv3    Kx=ECDH  Au=ECDSA  Enc=3DES(168)      Mac=SHA1
0x00,0x3D  -  AES256-SHA256                 TLSv1.2  Kx=RSA  Au=RSA    Enc=AES(256)               Mac=SHA256
0x00,0x16  -  EDH-RSA-DES-CBC3-SHA            SSLv3    Kx=DH    Au=RSA    Enc=3DES(168)      Mac=SHA1
0x00,0x2F  -  AES128-SHA                     SSLv3    Kx=RSA  Au=RSA    Enc=AES(128)               Mac=SHA1
0x00,0x9C  -  AES128-GCM-SHA256               TLSv1.2  Kx=RSA  Au=RSA    Enc=AESGCM(128)   Mac=AEAD
0x00,0x35  -  AES256-SHA                     SSLv3    Kx=RSA  Au=RSA    Enc=AES(256)               Mac=SHA1
0x00,0x9D  -  AES256-GCM-SHA384               TLSv1.2  Kx=RSA  Au=RSA    Enc=AESGCM(256)   Mac=AEAD
0x00,0x0A  -  DES-CBC3-SHA                   SSLv3    Kx=RSA  Au=RSA    Enc=3DES(168)               Mac=SHA1
0x00,0x3C  -  AES128-SHA256                   TLSv1.2  Kx=RSA  Au=RSA    Enc=AES(128)       Mac=SHA256
0x00,0x3D  -  AES256-SHA256                   TLSv1.2  Kx=RSA  Au=RSA    Enc=AES(256)       Mac=SHA256
0x00,0x2F  -  AES128-SHA                     SSLv3    Kx=RSA  Au=RSA    Enc=AES(128)       Mac=SHA1
0x00,0x35  -  AES256-SHA                     SSLv3    Kx=RSA  Au=RSA    Enc=AES(256)       Mac=SHA1
0x00,0x6A  -  DHE-DSS-AES256-SHA256          TLSv1.2  Kx=DH    Au=DSS    Enc=AES(256)      Mac=SHA256
0x00,0x32  -  DHE-DSS-AES128-SHA              SSLv3    Kx=DH    Au=DSS    Enc=AES(128)      Mac=SHA1
0x00,0x0A  -  DES-CBC3-SHA                   SSLv3    Kx=RSA  Au=RSA    Enc=3DES(168)     Mac=SHA1
0x00,0x9A  -  DHE-RSA-SEED-SHA                SSLv3    Kx=DH    Au=RSA    Enc=SEED(128)      Mac=SHA1
0x00,0x99  -  DHE-DSS-SEED-SHA                SSLv3    Kx=DH    Au=DSS    Enc=SEED(128)      Mac=SHA1
0xCC,0x15  -  DHE-RSA-CHACHA20-POLY1305      TLSv1.2  Kx=DH    Au=RSA    Enc=ChaCha20(256)  Mac=AEAD
0xC0,0x77  -  ECDHE-RSA-CAMELLIA256-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    Enc=Camellia(256)  Mac=SHA384
0xC0,0x73  -  ECDHE-ECDSA-CAMELLIA256-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=Camellia(256)  Mac=SHA384
0x00,0xC4  -  DHE-RSA-CAMELLIA256-SHA256      TLSv1.2  Kx=DH    Au=RSA    Enc=Camellia(256)  Mac=SHA256
0x00,0xC3  -  DHE-DSS-CAMELLIA256-SHA256      TLSv1.2  Kx=DH    Au=DSS    Enc=Camellia(256)  Mac=SHA256
0x00,0x88  -  DHE-RSA-CAMELLIA256-SHA        SSLv3    Kx=DH    Au=RSA    Enc=Camellia(256)  Mac=SHA1
0x00,0x87  -  DHE-DSS-CAMELLIA256-SHA        SSLv3    Kx=DH    Au=DSS    Enc=Camellia(256)  Mac=SHA1
0x00,0xC0  -  CAMELLIA256-SHA256              TLSv1.2  Kx=RSA  Au=RSA    Enc=Camellia(256)  Mac=SHA256
0x00,0x84  -  CAMELLIA256-SHA                SSLv3    Kx=RSA  Au=RSA    Enc=Camellia(256)  Mac=SHA1
0xC0,0x76  -  ECDHE-RSA-CAMELLIA128-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=Camellia(128)  Mac=SHA256
0xC0,0x72  -  ECDHE-ECDSA-CAMELLIA128-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=Camellia(128)  Mac=SHA256
0x00,0xBE  -  DHE-RSA-CAMELLIA128-SHA256      TLSv1.2  Kx=DH    Au=RSA    Enc=Camellia(128)  Mac=SHA256
0x00,0xBD  -  DHE-DSS-CAMELLIA128-SHA256      TLSv1.2  Kx=DH    Au=DSS    Enc=Camellia(128)  Mac=SHA256
0x00,0x45  -  DHE-RSA-CAMELLIA128-SHA        SSLv3    Kx=DH    Au=RSA    Enc=Camellia(128)  Mac=SHA1
0x00,0x44  -  DHE-DSS-CAMELLIA128-SHA        SSLv3    Kx=DH    Au=DSS    Enc=Camellia(128)  Mac=SHA1
0x00,0xBA  -  CAMELLIA128-SHA256              TLSv1.2  Kx=RSA  Au=RSA    Enc=Camellia(128)  Mac=SHA256
0x00,0x41  -  CAMELLIA128-SHA                SSLv3    Kx=RSA  Au=RSA    Enc=Camellia(128)  Mac=SHA1
0x00,0x96  -  SEED-SHA                        SSLv3    Kx=RSA  Au=RSA    Enc=SEED(128)      Mac=SHA1
</source>
</source>


Rationale:
* Rationale:
* You should take a hard look at your infrastructure needs before using this configuration; it is intended for special use cases only, and most servers should use the intermediate configuration instead.
** Take a hard look at your infrastructure needs before using this configuration; it is intended for special use cases only
* SSLv3 is enabled to support WinXP SP2 clients on IE.
** If possible, use this configuration only for endpoints that require it, segregating it from other traffic
* SHA1 certificates are authorized but only via certificate switching, meaning the server must implement custom logic to provide a SHA1 certs to old clients, and SHA256 certs to all others. More information in the "Certificates Switching" section later in this document.
** SSLv3 has been disabled entirely, ending support for older Windows XP SP2 clients. Users requiring support for Windows XP SP2 may use [[Security/Archive/Server Side TLS 4.0|previous versions]] of this configuration, with the caveat that SSLv3 is no longer safe to use
* Most ciphers that are not clearly broken and dangerous to use are supported
** This configuration requires custom builds to work with modern versions of OpenSSL, using <tt>enable-ssl3</tt>, <tt>enable-ssl3-method</tt>, <tt>enable-deprecated</tt>, and <tt>enable-weak-ssl-ciphers</tt>
** Most ciphers that are not clearly broken and dangerous to use are supported


= JSON version of the recommendations =
= JSON version of the recommendations =


You can find the recommendations above in JSON format at the address [https://statics.tls.security.mozilla.org/server-side-tls-conf-4.0.json https://statics.tls.security.mozilla.org/server-side-tls-conf-4.0.json].
<p style="max-width: 60em;">Mozilla also maintains [https://ssl-config.mozilla.org/guidelines/5.7.json these recommendations] in JSON format, for automated system configuration. This location is versioned and permanent, and can be referenced in scripts and tools. The file will not change, to avoid breaking tools when we update the recommendations.</p>


This location is permanent and can be referenced in scripts and tools. The file is versioned and will not change, to avoid breaking tools when we update the recommendations.
<p style="max-width: 60em;">We also maintain a [https://ssl-config.mozilla.org/guidelines/latest.json rolling version] of these recommendations, with the caveat that they may change '''without warning''' and '''without providing backwards compatibility'''. As it may break things if you use it to automatically configure your servers without review, we recommend you use the [https://ssl-config.mozilla.org/guidelines/5.7.json version-specific file] instead.</p>
 
If you wish to point to the latest version of the recommendations, use this address: [[https://statics.tls.security.mozilla.org/server-side-tls-conf.json https://statics.tls.security.mozilla.org/server-side-tls-conf.json].
Be advised the above will always point to the latest version and '''will not provide backward compatibility'''.
If you use it to automatically configure your servers without review, it may break things. Prefer the version-specific files instead.
 
== Previous versions ==
 
* None
 
= Mandatory discards =
 
* aNULL contains non-authenticated Diffie-Hellman key exchanges, that are subject to Man-In-The-Middle (MITM) attacks
* eNULL contains null-encryption ciphers (cleartext)
* EXPORT are legacy weak ciphers that were marked as exportable by US law
* RC4 contains ciphers that use the deprecated ARCFOUR algorithm
* 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
* MD5 contains all the ciphers that use the deprecated message digest 5 as the hashing algorithm
 
= Forward Secrecy =
 
The concept of forward secrecy is simple: client and server negotiate a key that never hits the wire, and is destroyed at the end of the session. The RSA private from the server is used to sign a Diffie-Hellman key exchange between the client and the server. The pre-master key obtained from the Diffie-Hellman handshake is then used for encryption. Since the pre-master key is specific to a connection between a client and a server, and used only for a limited amount of time, it is called Ephemeral.
 
With Forward Secrecy, if an attacker gets a hold of the server's private key, it will not be able to decrypt past communications. The private key is only used to sign the DH handshake, which does not reveal the pre-master key. Diffie-Hellman ensures that the pre-master keys never leave the client and the server, and cannot be intercepted by a MITM.
 
== DHE handshake and dhparam ==
 
When an ephemeral Diffie-Hellman cipher is used, the server and the client negotiate a pre-master key using the Diffie-Hellman algorithm. This algorithm requires that the server sends the client a prime number and a generator. Neither are confidential, and are sent in clear text. However, they must be signed, such that a MITM cannot hijack the handshake.
 
As an example, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 works as follow:
[[File:Dhe_params.png|frame|server key exchange message as displayed in Wireshark]]
[[File:Dhe_client_params.png|frame|client key exchange message as displayed in Wireshark]]
# Server sends Client a [http://tools.ietf.org/html/rfc5246#section-7.4.3 SERVER KEY EXCHANGE] message during the SSL Handshake. The message contains:
## Prime number ''p''
## Generator ''g''
## Server's Diffie-Hellman public value ''A = g^X mod p'', where ''X'' is a private integer chosen by the server at random, and never shared with the client. (note: A is called ''pubkey'' in wireshark)
## signature ''S'' of the above (plus two random values) computed using the Server's private RSA key
# Client verifies the signature ''S''
# Client sends server a [http://tools.ietf.org/html/rfc5246#section-7.4.7 CLIENT KEY EXCHANGE] message. The message contains:
## Client's Diffie-Hellman public value ''B = g^Y mod p'', where ''Y'' is a private integer chosen at random and never shared. (note: B is called ''pubkey'' in wireshark)
# The Server and the Client can now calculate the pre-master secret using each other's public values:
## server calculates ''PMS = B^X mod p''
## client calculates ''PMS = A^Y mod p''
# Client sends a [http://tools.ietf.org/html/rfc5246#section-7.1 CHANGE CIPHER SPEC] message to the server, and both parties continue the handshake using ENCRYPTED HANDSHAKE MESSAGES
 
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.
 
== Pre-defined DHE groups ==
 
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-----
MIIBCAKCAQEA//////////+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz
+8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a
87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7
YdEIqUuyyOP7uWrat2DX9GgdT0Kj3jlN9K5W7edjcrsZCwenyO4KbXCeAvzhzffi
7MA0BM0oNC9hkXL+nOmFg/+OTxIy7vKBg8P+OxtMb61zO7X8vC7CIAXFjvGDfRaD
ssbzSibBsu/6iGtCOGEoXJf//////////wIBAg==
-----END DH PARAMETERS-----
</source>
 
=== ffdhe3072 ===
<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>
 
=== ffdhe4096 ===
<source>
-----BEGIN DH PARAMETERS-----
MIICCAKCAgEA//////////+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz
+8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a
87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7
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 ==
Most modern clients that support both ECDHE and DHE typically prefer the former, because ECDHE provides faster handshakes than DHE ([http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html], [http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html]).
 
Unfortunately, some widely used clients lack support for ECDHE and must then rely on DHE to provide perfect forward secrecy:
* Android < 3.0.0
* Java < 7
* OpenSSL < 1.0.0
 
Note that schannel on Windows XP technically support DHE, but only with DSA keys, making it unusable on the internet in practice.
 
== DHE and Java ==
Java 6 and 7 do not support Diffie-Hellman parameters larger than 1024 bits. If your server expects to receive connections from java 6 clients and wants to enable PFS, it must provide a DHE parameter of 1024 bits.
 
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 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.
 
The case of Java 7 is a bit different. Java 7 supports ECDHE ciphers, so if the server provides ECDHE and prioritizes it before DHE ciphers using server side ordering, then Java 7 will use ECDHE and not care about the size of the DHE parameter. In this situation, the server can use 2048 bits DHE parameters for all other clients.
 
However, if the server does not support ECDHE, then Java 7 will use DHE and fail if the parameter is larger than 1024 bits. When failing, the handshake will not attempt to fall back to the next cipher in line, but simply fail with the error "java.lang.RuntimeException: Could not generate DH keypair".


= Version History =
{| class="wikitable"
{| class="wikitable"
|-
|-
! Java supported !! ECDHE prioritized !! smallest DH parameter size
! Version
! Editor
! Changes
|-
|-
| 6 || irrelevant || 1024
| style="text-align: center;" | 5.7
| style="text-align: center;" | Gene Wood
| Add DHE-RSA-CHACHA20-POLY1305 cipher to the Intermediate configuration
|-
|-
| 7 || NO || 1024
| style="text-align: center;" | 5.6
| style="text-align: center;" | April King
| Fixed incorrect cipher ordering for the Intermediate configuration
|-
|-
| 7 || YES || 2048
| style="text-align: center;" | 5.5
| style="text-align: center;" | April King
| Update certificate lifespan to reflect browser policy changes
|-
|-
| 8 || irrelevant || 2048
| style="text-align: center;" | 5.3
|}
| style="text-align: center;" | April King
 
| Bump links to point to 5.3 guidelines, since it fixes a small JSON error
 
|-
= OCSP Stapling =
| style="text-align: center;" | 5.0.1
When connecting to a server, clients should verify the validity of the server certificate using either a Certificate Revocation List (CRL), or an Online Certificate Status Protocol (OCSP) record. The problem with CRL is that the lists have grown huge and takes forever to download.
| style="text-align: center;" | April King
 
| Add note about IE 11 on Windows Server 2008 R2
OCSP is much more lightweight, as only one record is retrieved at a time. But the side effect is that OCSP requests must be made to a 3rd party OCSP responder when connecting to a server, which adds latency and potential failures. In fact, the OCSP responders operated by CAs are often so unreliable that browser will fail silently if no response is received in a timely manner. This reduces security, by allowing an attacker to DoS an OCSP responder to disable the validation.
 
The solution is to allow the server to send its cached OCSP record during the TLS handshake, therefore bypassing the OCSP responder. This mechanism saves a roundtrip between the client and the OCSP responder, and is called OCSP Stapling.
 
The server will send a cached OCSP response only if the client requests it, by announcing support for the '''status_request''' TLS extension in its CLIENT HELLO.
 
[[File:OCSP_Stapling.png]]
 
Most servers will cache OCSP response for up to 48 hours. At regular intervals, the server will connect to the OCSP responder of the CA to retrieve a fresh OCSP record. The location of the OCSP responder is taken from the Authority Information Access field of the signed certificate. For example, with StartSSL:
 
<pre>
Authority Information Access:
      OCSP - URI:http://ocsp.startssl.com/sub/class1/server/ca
</pre>
 
Support for OCSP Stapling can be tested using the '''-status''' option of the OpenSSL client.
 
<pre>
$ openssl s_client -connect monitor.mozillalabs.com:443 -status
...
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
...
</pre>
 
= Session Resumption =
 
Session Resumption is the ability to reuse the session secrets previously negotiated between a client and a server for a new TLS connection. This feature greatly increases the speed establishment of TLS connections after the first handshake, and is very useful for connections that use Perfect Forward Secrecy with a slow handshake like DHE.
 
Session Resumption can be performed using one of two methods:
 
# session identifier: When establishing a first session, the server generates an arbitrary session ID sent to the client. On subsequent connections, the client sends the session ID in the CLIENT HELLO message, indicating to the server it wants to reuse an existing state. If the server can find a corresponding state in its local cache, it reuse the session secrets and skips directly to exchanging encrypted data with the client. If the cache stored on the server is compromised, session keys from the cache can be used to decrypt past and future sessions.
# session tickets: Storing a cache on the server might be problematic for systems that handle very large numbers of clients. Session tickets provide an alternative where the server sends the encrypted state (ticket) to the client instead of storing it in its local cache. The client can send back the encrypted state to the server in subsequent connections, thus allowing session resumption. This method requires symmetric keys on the server to encrypt and decrypt session tickets. If the keys are compromised, an attacker obtains access to session keys and can decrypt past and future sessions.
 
Session resumption is a very useful performance feature of TLS, but also carries a significant amount of risk. Most servers do not purge sessions or ticket keys, thus increasing the risk that a server compromise would leak data from previous (and future) connections.
 
The current recommendation for web servers is to enable session resumption and benefit from the performance improvement, but to restart servers daily when possible. This ensure that sessions get purged and ticket keys get renewed on a regular basis.
 
= HSTS: HTTP Strict Transport Security =
 
[https://tools.ietf.org/html/rfc6797 HSTS] is a HTTP header sent by a server to a client, indicating that the current site must only be accessed over HTTPS until expiration of the HSTS value is reached.
 
The header format is very simple, composed only of a '''max-age''' parameter that indicates when the directive should expire. max-age is expressed in seconds. A typical value is 15768000 seconds, or 6 months.
<pre>
Strict-Transport-Security: max-age=15768000
</pre>
 
HSTS is becoming more and more of a standard, but should only be used when the site's operators are confident that HTTPS will be available continuously for the duration of max-age. Once the HSTS header is sent to client, HTTPS cannot be disabled on the site until the last client has expired its HSTS record.
 
= HPKP: Public Key Pinning Extension for HTTP =
 
See [http://tools.ietf.org/html/rfc7469 RFC7469].
 
HPKP is an '''experimental''' HTTP header sent by a server to a client, to indicate that some certificates related to the site should be pinned in the client. The client would thus refuse to establish a connection to the server if the pining does not comply.
 
Due to its experimental nature, HPKP is currently '''not''' recommended on production sites. More informations can be found on the [https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning MDN description page].
 
= Certificates Switching =
 
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 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.
 
Few servers currently support cert switching. It is possible to implement it using [https://jve.linuxwall.info/blog/index.php?post/2015/10/04/SHA1/SHA256-certificate-switching-with-HAProxy HAProxy], and vendors like Cloudflare propose it in their offering.
 
= Recommended Server Configurations =
 
All configuration samples have been moved to the configuration generator and the [[Security/TLS_Configurations]] archive. Access the generator by clicking the image below:
 
[[Image:Server-side-tls-config-generator.png|link=https://mozilla.github.io/server-side-tls/ssl-config-generator/]]
 
= Tools =
== CipherScan ==
 
See https://github.com/jvehent/cipherscan
 
Cipherscan is a small Bash script that connects to a target and list the preferred Ciphers. It's an easy way to test a web server for available ciphers, PFS key size, elliptic curves, support for OCSP Stapling, TLS ticket lifetime and certificate trust.
 
<source lang="bash">
$ ./cipherscan jve.linuxwall.info
..........................
prio  ciphersuite                  protocols              pfs_keysize
1    ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2                ECDH,P-256,256bits
2    ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2                ECDH,P-256,256bits
3    DHE-RSA-AES256-GCM-SHA384    TLSv1.2                DH,4096bits
4    DHE-RSA-AES128-GCM-SHA256    TLSv1.2                DH,4096bits
5    ECDHE-RSA-AES128-SHA256      TLSv1.2                ECDH,P-256,256bits
6    ECDHE-RSA-AES128-SHA        TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits
7    ECDHE-RSA-AES256-SHA384      TLSv1.2                ECDH,P-256,256bits
8    ECDHE-RSA-AES256-SHA        TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits
9    DHE-RSA-AES128-SHA256        TLSv1.2                DH,4096bits
10    DHE-RSA-AES128-SHA          TLSv1,TLSv1.1,TLSv1.2  DH,4096bits
11    DHE-RSA-AES256-SHA256        TLSv1.2                DH,4096bits
12    AES128-GCM-SHA256            TLSv1.2
13    AES256-GCM-SHA384            TLSv1.2
14    ECDHE-RSA-DES-CBC3-SHA      TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits
15    EDH-RSA-DES-CBC3-SHA        TLSv1,TLSv1.1,TLSv1.2  DH,4096bits
16    DES-CBC3-SHA                TLSv1,TLSv1.1,TLSv1.2
17    DHE-RSA-AES256-SHA          TLSv1,TLSv1.1,TLSv1.2  DH,4096bits
18    DHE-RSA-CAMELLIA256-SHA      TLSv1,TLSv1.1,TLSv1.2  DH,4096bits
19    AES256-SHA256                TLSv1.2
20    AES256-SHA                  TLSv1,TLSv1.1,TLSv1.2
21    CAMELLIA256-SHA              TLSv1,TLSv1.1,TLSv1.2
22    DHE-RSA-CAMELLIA128-SHA      TLSv1,TLSv1.1,TLSv1.2  DH,4096bits
23    AES128-SHA256                TLSv1.2
24    AES128-SHA                  TLSv1,TLSv1.1,TLSv1.2
25    CAMELLIA128-SHA              TLSv1,TLSv1.1,TLSv1.2
 
Certificate: trusted, 2048 bit, sha1WithRSAEncryption signature
TLS ticket lifetime hint: 300
OCSP stapling: supported
</source>
 
== SSL Labs (Qualys) ==
 
Available here: https://www.ssllabs.com/ssltest/
 
Qualys SSL Labs provides a comprehensive SSL testing suite.
 
GlobalSign has a modified interface of SSL Labs that is interesting as well: https://sslcheck.globalsign.com/
 
= Attacks on SSL and TLS =
== BEAST (CVE-2011-3389) ==
 
Beast is a vulnerability in the Initialization Vector (IV) of the CBC mode of AES, Camellia and a few other ciphers that use CBC mode. The attack allows a  MITM attacker to recover plaintext values by encrypting the same message multiple times.
 
BEAST is mitigated in TLS1.1 and above.
 
more: https://blog.torproject.org/blog/tor-and-beast-ssl-attack
 
== LUCKY13 ==
 
Lucky13 is another attack on CBC mode that listen for padding checks to decrypt ciphertext.
 
more: https://www.imperialviolet.org/2013/02/04/luckythirteen.html
 
== RC4 weaknesses ==
 
As of February 2015, the IETF explicitely prohibits the use of RC4: [http://www.ietf.org/rfc/rfc7465.txt RFC 7465].
 
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. This would impact Internet Explorer 7 and 8 users that, depending on the OS, do not support AES, and will negotiate only RC4 or 3DES ciphers. Internet Explorer uses the cryptographic library “schannel”, which is OS dependent. schannel supports AES in Windows Vista, but not in Windows XP.
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.
 
more: https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls
 
== BREACH ==
 
This is a more complex attack than CRIME, which does not require TLS-level compression (it still needs HTTP-level compression).
 
In order to be successful, it requires to:
 
# Be served from a server that uses HTTP-level compression
# Reflect user-input in HTTP response bodies
# Reflect a secret (such as a CSRF token) in HTTP response bodies
 
more: http://breachattack.com/
 
== POODLE ([http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566 CVE-2014-3566]) ==
 
POODLE is an attack on the padding used by SSLv3. It is a significant improvement of the BEAST attack which led the cryptography community to recommend disabling SSLv3 globally.
 
<blockquote>
''If you can arrange the message to be the correct length then the last block is 15 arbitrary bytes and the padding length (15). Then you arrange an interesting byte to be in the last position of a different block and duplicate that block to the end. If the record is accepted, then you know what the last byte contained because it decrypted to 15.''
''Thus the attacker needs to be able to control some of the plaintext in order to align things in the messages and needs to be able to burn lots of connections (256 per byte, roughly). Thus a secret needs to be repeated in connection after connection (i.e. a cookie).''
 
source: Adam Langley in https://bugzilla.mozilla.org/show_bug.cgi?id=1076983#c29
</blockquote>
 
Daniel Stenberg (Mozilla, cUrl) has a good description of the exploitability of POODLE in http://daniel.haxx.se/blog/2014/10/17/curl-is-no-poodle/
 
Our guidelines maintain support for SSLv3 in the Old configuration only. This is required for clients on Windows XP service pack 1 & 2 that do not have support for TLSv1.0. Internet Explorer and Chrome on those platforms are impacted. Mozilla wants to be reachable from very old clients, to allow them to download a better browser. Therefore, we maintain SSLv3 compatibility on a limited number of sites. But all sites that do not need that level of compatibility are encouraged to implement the Intermediate configuration
 
== Logjam attack on weak Diffie-Hellman ==
 
The Logjam attack describes methods of attacking TLS servers supporting DHE export ciphers, and with weak (<= 1024 bit) Diffie Hellman groups. Modern TLS must use DH parameters of 2048 bits and above, or only use ECDHE. The modern configuration in this guide provide configurations that are not impacted by this issue. The intermediate and old configurations are impacted, and administrators are encourage to use DH parameters of 2048 bits wherever possible.
 
more: https://weakdh.org
 
= SSL and TLS Settings =
== SPDY ==
 
(see also http://en.wikipedia.org/wiki/SPDY and http://www.chromium.org/spdy/spdy-protocol)
 
SPDY is a protocol that incorporate TLS, which attempts to reduce latency when loading pages. It is currently not an HTTP standard (albeit it is being drafted for HTTP 2.0), but is widely supported.
 
SPDY version 3 is vulnerable to the CRIME attack (see also http://zoompf.com/2012/09/explaining-the-crime-weakness-in-spdy-and-ssl) - this is due to the use of compression. Clients currently implement a non-standard hack in with gzip in order to circumvent the vulnerability. SPDY version 4 is planned to include a proper fix.
 
== TLS tickets (RFC 5077) ==
 
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 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 information: https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-Slides.pdf
 
= Cipher suites =
 
Different libraries support different cipher suites and refer to them by different names. Mozilla maintains a list of [[Security/Cipher Suites|all known cipher suites]] and their corresponding names.
 
== GnuTLS ciphersuite ==
 
Unlike OpenSSL, GnuTLS will panic if you give it ciphers aren't supported by the library. That makes it very difficult to share a default ciphersuite to use in GnuTLS. The next best thing is using the following ciphersuite, and removing the components that break on your own version:
 
'''NONE:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+ECDHE-RSA:+DHE-RSA:+RSA:+AES-128-GCM:+AES-128-CBC:+AES-256-CBC:+SIGN-RSA-SHA256:+SIGN-RSA-SHA384:+SIGN-RSA-SHA512:+SIGN-RSA-SHA224:+SIGN-RSA-SHA1:+SIGN-DSA-SHA256:+SIGN-DSA-SHA224:+SIGN-DSA-SHA1:+CURVE-ALL:+AEAD:+SHA256:+SHA384:+SHA1:+COMP-NULL'''
 
A ciphersuite can be tested in GnuTLS using '''gnutls-cli'''.
 
<source code=bash>
$ gnutls-cli --version
gnutls-cli 3.1.26
 
$ gnutls-cli -l --priority NONE:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+ECDHE-RSA:+DHE-RSA:+RSA:+AES-128-GCM:+AES-128-CBC:+AES-256-CBC:+SIGN-RSA-SHA256:+SIGN-RSA-SHA384:+SIGN-RSA-SHA512:+SIGN-RSA-SHA224:+SIGN-RSA-SHA1:+SIGN-DSA-SHA256:+SIGN-DSA-SHA224:+SIGN-DSA-SHA1:+CURVE-ALL:+AEAD:+SHA256:+SHA384:+SHA1:+COMP-NULL
Cipher suites for NONE:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+ECDHE-RSA:+DHE-RSA:+RSA:+AES-128-GCM:+AES-128-CBC:+AES-256-CBC:+SIGN-RSA-SHA256:+SIGN-RSA-SHA384:+SIGN-RSA-SHA512:+SIGN-RSA-SHA224:+SIGN-RSA-SHA1:+SIGN-DSA-SHA256:+SIGN-DSA-SHA224:+SIGN-DSA-SHA1:+CURVE-ALL:+AEAD:+SHA256:+SHA384:+SHA1:+COMP-NULL
TLS_ECDHE_RSA_AES_128_GCM_SHA256                    0xc0, 0x2f  TLS1.2
TLS_ECDHE_RSA_AES_128_CBC_SHA256                    0xc0, 0x27  TLS1.0
TLS_ECDHE_RSA_AES_128_CBC_SHA1                      0xc0, 0x13  SSL3.0
TLS_ECDHE_RSA_AES_256_CBC_SHA1                      0xc0, 0x14  SSL3.0
TLS_DHE_RSA_AES_128_GCM_SHA256                      0x00, 0x9e  TLS1.2
TLS_DHE_RSA_AES_128_CBC_SHA256                      0x00, 0x67  TLS1.0
TLS_DHE_RSA_AES_128_CBC_SHA1                        0x00, 0x33  SSL3.0
TLS_DHE_RSA_AES_256_CBC_SHA256                      0x00, 0x6b  TLS1.0
TLS_DHE_RSA_AES_256_CBC_SHA1                        0x00, 0x39  SSL3.0
TLS_RSA_AES_128_GCM_SHA256                          0x00, 0x9c  TLS1.2
TLS_RSA_AES_128_CBC_SHA256                          0x00, 0x3c  TLS1.0
TLS_RSA_AES_128_CBC_SHA1                            0x00, 0x2f  SSL3.0
TLS_RSA_AES_256_CBC_SHA256                          0x00, 0x3d  TLS1.0
TLS_RSA_AES_256_CBC_SHA1                            0x00, 0x35  SSL3.0
 
Certificate types: none
Protocols: VERS-TLS1.2, VERS-TLS1.1, VERS-TLS1.0
Compression: COMP-NULL
Elliptic curves: CURVE-SECP256R1, CURVE-SECP384R1, CURVE-SECP521R1
PK-signatures: SIGN-RSA-SHA256, SIGN-RSA-SHA384, SIGN-RSA-SHA512, SIGN-RSA-SHA224, SIGN-RSA-SHA1, SIGN-DSA-SHA256, SIGN-DSA-SHA224, SIGN-DSA-SHA1
</source>
 
A good way to debug the ciphersuite is by performing a test connection. If the ciphersuite isn't supported, gnutls-cli will stop reading it at the component that is causing the issue.
<source code=bash>
$ gnutls-cli --debug 9999 google.com --priority 'NONE:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+ECDHE-RSA:+DHE-RSA:+RSA:+AES-128-GCM:+AES-128-CBC:+AES-256-CBC:+SIGN-RSA-SHA256:+SIGN-RSA-SHA384:+SIGN-RSA-SHA512:+SIGN-RSA-SHA224:+SIGN-RSA-SHA1:+SIGN-DSA-SHA256:+SIGN-DSA-SHA224:+SIGN-DSA-SHA1:+CURVE-ALL:+AEAD:+SHA256:+SHA384:+SHA1:+COMP-NULL'
|<2>| ASSERT: gnutls_priority.c:812
Syntax error at: +SIGN-RSA-SHA224:+SIGN-RSA-SHA1:+SIGN-DSA-SHA256:+SIGN-DSA-SHA224:+SIGN-DSA-SHA1:+SHA256:+SHA384:+SHA1:+COMP-NULL
</source>
In the example above, the component SIGN-RSA-SHA224 is not supported by this version of gnutls and should be removed from the ciphersuite.
 
= Version History =
{| class="wikitable"
|-
|-
! Version
| style="text-align: center;" | 5.0
! Editor
| style="text-align: center;" | April King
! Changes
| Server Side TLS 5.0
|-
|-
| style="text-align: center;" | 4.2
| style="text-align: center;" | 4.2

Latest revision as of 22:47, 16 May 2023

The goal of this document is to help operational teams with the configuration of TLS. All Mozilla websites and deployments should follow the recommendations below.

Mozilla maintains this document as a reference guide for navigating the TLS landscape, as well as a configuration generator to assist system administrators. Changes are reviewed and merged by the Mozilla Operations Security and Enterprise Information Security teams.

Updates to this page should be submitted to the server-side-tls repository on GitHub. Issues related to the configuration generator are maintained in their own GitHub repository.

In the interests of usability and maintainability, these guidelines have been considerably simplified from the previous guidelines.

Recommended configurations

 
The Mozilla SSL Configuration Generator Mozilla maintains three recommended configurations for servers using TLS. Pick the correct configuration depending on your audience:

  • Modern: Modern clients that support TLS 1.3, with no need for backwards compatibility
  • Intermediate: Recommended configuration for a general-purpose server
  • Old: Services accessed by very old clients or libraries, such as Internet Explorer 8 (Windows XP), Java 6, or OpenSSL 0.9.8
Configuration Firefox Android Chrome Edge Internet Explorer Java OpenSSL Opera Safari
Modern 63 10.0 70 75 -- 11 1.1.1 57 12.1
Intermediate 27 4.4.2 31 12 11 (Win7) 8u31 1.0.1 20 9
Old 1 2.3 1 12 8 (WinXP) 6 0.9.8 5 1

The ordering of cipher suites in the Old configuration is very important, as it determines the priority with which algorithms are selected.

OpenSSL will ignore cipher suites it doesn't understand, so always use the full set of cipher suites below, in their recommended order. The use of the Old configuration with modern versions of OpenSSL may require custom builds with support for deprecated ciphers.


Modern compatibility

For services with clients that support TLS 1.3 and don't need backward compatibility, the Modern configuration provides an extremely high level of security.

  • Cipher suites (TLS 1.3): TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
  • Cipher suites (TLS 1.2): (none)
  • Protocols: TLS 1.3
  • Certificate type: ECDSA (P-256)
  • TLS curves: X25519, prime256v1, secp384r1
  • HSTS: max-age=63072000 (two years)
  • Certificate lifespan: 90 days
  • Cipher preference: client chooses
0x13,0x01  -  TLS_AES_128_GCM_SHA256        TLSv1.3  Kx=any  Au=any  Enc=AESGCM(128)             Mac=AEAD
0x13,0x02  -  TLS_AES_256_GCM_SHA384        TLSv1.3  Kx=any  Au=any  Enc=AESGCM(256)             Mac=AEAD
0x13,0x03  -  TLS_CHACHA20_POLY1305_SHA256  TLSv1.3  Kx=any  Au=any  Enc=CHACHA20/POLY1305(256)  Mac=AEAD
  • Rationale:
    • All cipher suites are forward secret and authenticated
    • The cipher suites are all strong and so we allow the client to choose, as they will know best if they have support for hardware-accelerated AES
    • We recommend ECDSA certificates using P-256, as P-384 provides negligible improvements to security and Ed25519 is not yet widely supported

Intermediate compatibility (recommended)

For services that don't need compatibility with legacy clients such as Windows XP or old versions of OpenSSL. This is the recommended configuration for the vast majority of services, as it is highly secure and compatible with nearly every client released in the last five (or more) years.

  • Cipher suites (TLS 1.3): TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
  • Cipher suites (TLS 1.2): ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
  • Protocols: TLS 1.2, TLS 1.3
  • TLS curves: X25519, prime256v1, secp384r1
  • Certificate type: ECDSA (P-256) (recommended), or RSA (2048 bits)
  • DH parameter size: 2048 (ffdhe2048, RFC 7919)
  • HSTS: max-age=63072000 (two years)
  • Certificate lifespan: 90 days (recommended) to 366 days
  • Cipher preference: client chooses
0x13,0x01  -  TLS_AES_128_GCM_SHA256         TLSv1.3  Kx=any   Au=any    Enc=AESGCM(128)             Mac=AEAD
0x13,0x02  -  TLS_AES_256_GCM_SHA384         TLSv1.3  Kx=any   Au=any    Enc=AESGCM(256)             Mac=AEAD
0x13,0x03  -  TLS_CHACHA20_POLY1305_SHA256   TLSv1.3  Kx=any   Au=any    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)             Mac=AEAD
0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)             Mac=AEAD
0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)             Mac=AEAD
0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0xCC,0xA9  -  ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0xCC,0xA8  -  ECDHE-RSA-CHACHA20-POLY1305    TLSv1.2  Kx=ECDH  Au=RSA    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0x00,0x9E  -  DHE-RSA-AES128-GCM-SHA256      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(128)             Mac=AEAD
0x00,0x9F  -  DHE-RSA-AES256-GCM-SHA384      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0xCC,0xAA  -  DHE-RSA-CHACHA20-POLY1305      TLSv1.2  Kx=DH    Au=RSA    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
  • Rationale:
    • All cipher suites are forward secret and authenticated
    • TLS 1.2 is the minimum supported protocol, as recommended by RFC 7525, PCI DSS, and others
    • ECDSA certificates are recommended over RSA certificates, as they allow the use of ECDHE with Windows 7 clients using Internet Explorer 11, as well as allow connections from IE11 on Windows Server 2008 R2
    • The cipher suites are all strong and so we allow the client to choose, as they will know best if they have support for hardware-accelerated AES
    • Windows XP (including all embedded versions) are no longer supported by Microsoft, eliminating the need for many older protocols and ciphers
    • Administrators needing to provide access to IE 11 on Windows Server 2008 R2 and who are unable to switch to or add ECDSA certificates can add TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    • While the goal is to support a broad range of clients, we reasonably disable a number of ciphers that have little support (such as ARIA, Camellia, 3DES, and SEED)
    • 90 days is the recommended maximum certificate lifespan, to encourage certificate issuance automation

Old backward compatibility

This configuration is compatible with a number of very old clients, and should be used only as a last resort.

  • Cipher suites (TLS 1.3): TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
  • Cipher suites (TLS 1.0 - 1.2): ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA
  • Protocols: TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3
  • TLS curves: X25519, prime256v1, secp384r1
  • Certificate type: RSA (2048-bits)
  • Certificate curve: None
  • DH parameter size: 1024 (generated with openssl dhparam 1024)
  • HSTS: max-age=63072000 (two years)
  • Certificate lifespan: 90 days (recommended) to 366 days
  • Cipher preference: server chooses
0x13,0x01  -  TLS_AES_128_GCM_SHA256         TLSv1.3  Kx=any   Au=any    Enc=AESGCM(128)             Mac=AEAD
0x13,0x02  -  TLS_AES_256_GCM_SHA384         TLSv1.3  Kx=any   Au=any    Enc=AESGCM(256)             Mac=AEAD
0x13,0x03  -  TLS_CHACHA20_POLY1305_SHA256   TLSv1.3  Kx=any   Au=any    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)             Mac=AEAD
0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)             Mac=AEAD
0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)             Mac=AEAD
0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0xCC,0xA9  -  ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0xCC,0xA8  -  ECDHE-RSA-CHACHA20-POLY1305    TLSv1.2  Kx=ECDH  Au=RSA    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0x00,0x9E  -  DHE-RSA-AES128-GCM-SHA256      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(128)             Mac=AEAD
0x00,0x9F  -  DHE-RSA-AES256-GCM-SHA384      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0xCC,0xAA  -  DHE-RSA-CHACHA20-POLY1305      TLSv1.2  Kx=DH    Au=RSA    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0xC0,0x23  -  ECDHE-ECDSA-AES128-SHA256      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(128)                Mac=SHA256
0xC0,0x27  -  ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(128)                Mac=SHA256
0xC0,0x09  -  ECDHE-ECDSA-AES128-SHA         TLSv1    Kx=ECDH  Au=ECDSA  Enc=AES(128)                Mac=SHA1
0xC0,0x13  -  ECDHE-RSA-AES128-SHA           TLSv1    Kx=ECDH  Au=RSA    Enc=AES(128)                Mac=SHA1
0xC0,0x24  -  ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(256)                Mac=SHA384
0xC0,0x28  -  ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(256)                Mac=SHA384
0xC0,0x0A  -  ECDHE-ECDSA-AES256-SHA         TLSv1    Kx=ECDH  Au=ECDSA  Enc=AES(256)                Mac=SHA1
0xC0,0x14  -  ECDHE-RSA-AES256-SHA           TLSv1    Kx=ECDH  Au=RSA    Enc=AES(256)                Mac=SHA1
0x00,0x67  -  DHE-RSA-AES128-SHA256          TLSv1.2  Kx=DH    Au=RSA    Enc=AES(128)                Mac=SHA256
0x00,0x6B  -  DHE-RSA-AES256-SHA256          TLSv1.2  Kx=DH    Au=RSA    Enc=AES(256)                Mac=SHA256
0x00,0x9C  -  AES128-GCM-SHA256              TLSv1.2  Kx=RSA   Au=RSA    Enc=AESGCM(128)             Mac=AEAD
0x00,0x9D  -  AES256-GCM-SHA384              TLSv1.2  Kx=RSA   Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0x00,0x3C  -  AES128-SHA256                  TLSv1.2  Kx=RSA   Au=RSA    Enc=AES(128)                Mac=SHA256
0x00,0x3D  -  AES256-SHA256                  TLSv1.2  Kx=RSA   Au=RSA    Enc=AES(256)                Mac=SHA256
0x00,0x2F  -  AES128-SHA                     SSLv3    Kx=RSA   Au=RSA    Enc=AES(128)                Mac=SHA1
0x00,0x35  -  AES256-SHA                     SSLv3    Kx=RSA   Au=RSA    Enc=AES(256)                Mac=SHA1
0x00,0x0A  -  DES-CBC3-SHA                   SSLv3    Kx=RSA   Au=RSA    Enc=3DES(168)               Mac=SHA1
  • Rationale:
    • Take a hard look at your infrastructure needs before using this configuration; it is intended for special use cases only
    • If possible, use this configuration only for endpoints that require it, segregating it from other traffic
    • SSLv3 has been disabled entirely, ending support for older Windows XP SP2 clients. Users requiring support for Windows XP SP2 may use previous versions of this configuration, with the caveat that SSLv3 is no longer safe to use
    • This configuration requires custom builds to work with modern versions of OpenSSL, using enable-ssl3, enable-ssl3-method, enable-deprecated, and enable-weak-ssl-ciphers
    • Most ciphers that are not clearly broken and dangerous to use are supported

JSON version of the recommendations

Mozilla also maintains these recommendations in JSON format, for automated system configuration. This location is versioned and permanent, and can be referenced in scripts and tools. The file will not change, to avoid breaking tools when we update the recommendations.

We also maintain a rolling version of these recommendations, with the caveat that they may change without warning and without providing backwards compatibility. As it may break things if you use it to automatically configure your servers without review, we recommend you use the version-specific file instead.

Version History

Version Editor Changes
5.7 Gene Wood Add DHE-RSA-CHACHA20-POLY1305 cipher to the Intermediate configuration
5.6 April King Fixed incorrect cipher ordering for the Intermediate configuration
5.5 April King Update certificate lifespan to reflect browser policy changes
5.3 April King Bump links to point to 5.3 guidelines, since it fixes a small JSON error
5.0.1 April King Add note about IE 11 on Windows Server 2008 R2
5.0 April King Server Side TLS 5.0
4.2 April King Updated cipher suite table
4.1 Julien Vehent Clarify Logjam notes, Clarify risk of TLS Tickets
4 Julien Vehent Recommend ECDSA in modern level, remove DSS ciphers, publish configurations as JSON
3.8 Julien Vehent redo cipher names chart (April King), move version chart (April King), update Intermediate cipher suite (ulfr)
3.7 Julien Vehent cleanup version table (April King), add F5 conf samples (warburtron), add notes about DHE (rgacogne)
3.6 Julien Vehent bump intermediate DHE to 2048, add note about java compatibility
3.5 alm comment on weakdh vulnerability
3.4 Julien Vehent added note about session resumption, HSTS, and HPKP
3.3 Julien Vehent fix SHA256 prio, add POODLE details, update various templates
3.2 Julien Vehent Added intermediate compatibility mode, renamed other modes
3.1 Julien Vehent Added non-backward compatible ciphersuite
3 Julien Vehent Remove RC4 for 3DES, fix ordering in openssl 0.9.8 (1024430), various minor updates
2.5.1 Julien Vehent Revisit ELB capabilities
2.5 Julien Vehent Update ZLB information for OCSP Stapling and ciphersuite
2.4 Julien Vehent Moved a couple of aes128 above aes256 in the ciphersuite
2.3 Julien Vehent Precisions on IE 7/8 AES support (thanks to Dobin Rutishauser)
2.2 Julien Vehent Added IANA/OpenSSL/GnuTLS correspondence table and conversion tool
2.1 Julien Vehent RC4 vs 3DES discussion. r=joes r=tinfoil
2.0 Julien Vehent, kang Public release.
1.5 Julien Vehent, kang added details for PFS DHE handshake, added nginx configuration details; added Apache recommended conf
1.4 Julien Vehent revised ciphersuite. Prefer AES before RC4. Prefer 128 before 256. Prefer DHE before non-DHE.
1.3 Julien Vehent added netscaler example conf
1.2 Julien Vehent ciphersuite update, bump DHE-AESGCM above ECDH-RC4
1.1 Julien Vehent, kang integrated review comments from Infra; SPDY information
1.0 Julien Vehent creation
 
Document Status: READY
Retrieved from "https://wiki.allizom.org/index.php?title=Security/Server_Side_TLS&oldid=1246509"