Talk:Security/Server Side TLS

From MozillaWiki
Jump to: navigation, search

Proposed changes to ciphersuites

This change was proposed by zwdg on IRC.


With the following comments:

< zwdg> GCM modes are the only ones without known crypto vulnerabilities. CBC in TLSv1.2 is secure, but the block mode of operation has some theoretical problems.
< zwdg> only AEAD cipher suits have no vulnerabilities, and all modern browsers and tools are compatible with them, hence they should be the only ones in modern
< zwdg> I evaluated [the ciphersuites] with browsers, crypto tools, and java
10:01 < zwdg> for intermediate, just add the CBC modes, SHA1, and TLSv1.0 to the modern list I posted, and for old just add 3des plus SSLv3


Is there a particular reason there are no recommendations present for secure SSL/TLS configuration of IIS servers? This page is a fantastic resource for web server administrators maintaining HTTPS configurations but the omission of any IIS guidance seems quite significant given its prevalence. I'd be happy to create some draft guidance for community review for inclusion if this is desirable. Apologies if there's a specific obvious reason I've missed. ralish (talk)

ulfr, 20140424

It's simple really: as far as I know, we don't use IIS for SSL termination. If we did, we would have a recommendation for it. My concern about adding an IIS section is finding someone committed to maintaining it, because I have no idea what the right way of configuring windows services is.

sdl, 20140426

A key part of the merit question for me depends on the primary purpose of the page: is it primarily a guide for TLS configuration of Mozilla sites (for the Ops teams that run them), with its value for non-Mozilla staff more incidental due to the public nature of Mozilla, or is the providing of quality guidance on TLS configurations for any and all also a primary goal? If the latter, IIS seems worthwhile, if the former, much less so unless Mozilla starts using IIS servers at some point. As for maintaining it, I'd be happy to volunteer, but only on a best-effort basis. That being said, updates should be relatively infrequent as IIS features are largely pinned to Windows releases. So guidance would typically change in response to either new IIS versions introducing new security features or new TLS attacks resulting in recommended changes to mitigate (as in the case of BEAST, CRIME, etc...).

ulfr, 20140428

The value of this page outside of Mozilla is not incidental: it was written with the goal to be publicly available. The SSL/TLS rationale is generic and can be applied to any daemon on any system. The configuration samples section, however, is targeted to Ops teams within Mozilla corporation and community. Maintaining these configuration samples is time consuming, and we (OpSec) want to stay focused on what our Ops need to preserve resources. But it is a public resource and we will always welcome contributions from inside and outside of Mozilla. Add IIS if you think it is valuable, and I'm sure people will help maintaining it.


Full discussion:

RC4-based ciphers ought to be completely removed from the list, better attacks are coming like this one:

by Kroeckx on 15 December 2013‎

The reason to keep RC4 or 3DES is to support windows XP. Maybe 3DES should be kept instead since it it's still considered secure but slow.

by ulfr on 15 December 2013

See the discussion in Cryptographic strength is one of many parameters that we have to consider when hosting large scale websites. Speed and resources consumption is another one. While 3DES could, theoretically, replace RC4, the difference in cost makes it tricky to do in practice. We are looking at ways to measure our CPU usage to see if it is feasible at all.

That being said, sites that don't want to support WinXP users can feel free to disable RC4, or swap it with 3DES.

by mkwan on 30 April 2014

It seems like the ciphersuite in might be out of date now? There seem to be non-RC4-related inconsistencies between it and the Recommended Ciphersuite. In order to stay up to date as the Recommended Ciphersuite changes, would it be better to give instructions on how to replace RC4 with 3DES in the Recommended Ciphersuite? Is it more complicated than just replacing "RC4" with "DES-CBC3" and "!3DES" with "!RC4"?

Prioritzation logic and ciphersuite recommendation

The Prioritization logic says to prioritize 128 bit AES over 256 bit, but recommended ciphersuite has DHE-RSA-AES256* prioritized over DHE-RSA-AES128*. Breaking rule #3. Lots of non-forward-secret ciphers are prioritized over DHE-RSA-AES128*, breaking rule #2.

I think the recommended ciphersuite should be fixed to reflect the rules in the priorization logic. Maybe change the recommended cipher suite to the following?


or for people lacking trust in ECC/NIST curves:


answer from ulfr, 20131202

That's a good catch! Thanks for reporting it. I had missed a couple of aes256 above aes128 in the density of the ciphersuite. I updated the page, see the diff at

However, I am confused by your comment that "Lots of non-forward-secret ciphers are prioritized over DHE-RSA-AES128*, breaking rule #2.". Even before the latest change, only PFS ciphers where listed above DHE-RSA-AES128. Did you mean something different?

Reply to ulfr, 20131209 -- janfrode

> However, I am confused by your comment that "Lots of non-forward-secret ciphers are prioritized over DHE-RSA-AES128*, breaking rule #2.". Even before the latest change, only PFS ciphers where listed above DHE-RSA-AES128. Did you mean something different?

Not sure what I did previously. I now see DHE-RSA-AES128* before all non-PFS ciphers. On RHEL6.5/apache-2.2.15 With the currently suggested cipher suites, I got the following order:

prio  ciphersuite                protocols                    pfs_keysize
1     DHE-RSA-AES128-GCM-SHA256  SSLv3,TLSv1,TLSv1.1,TLSv1.2
2     DHE-RSA-AES256-GCM-SHA384  SSLv3,TLSv1,TLSv1.1,TLSv1.2
3     DHE-RSA-AES128-SHA256      SSLv3,TLSv1,TLSv1.1,TLSv1.2
4     DHE-RSA-AES128-SHA         SSLv3,TLSv1,TLSv1.1,TLSv1.2
5     DHE-RSA-AES256-SHA256      SSLv3,TLSv1,TLSv1.1,TLSv1.2
6     DHE-RSA-AES256-SHA         SSLv3,TLSv1,TLSv1.1,TLSv1.2
7     AES128-GCM-SHA256          SSLv3,TLSv1,TLSv1.1,TLSv1.2
8     AES256-GCM-SHA384          SSLv3,TLSv1,TLSv1.1,TLSv1.2
9     AES128-SHA256              SSLv3,TLSv1,TLSv1.1,TLSv1.2
10    AES128-SHA                 SSLv3,TLSv1,TLSv1.1,TLSv1.2
11    AES256-SHA256              SSLv3,TLSv1,TLSv1.1,TLSv1.2
12    AES256-SHA                 SSLv3,TLSv1,TLSv1.1,TLSv1.2
13    RC4-SHA                    SSLv3,TLSv1,TLSv1.1,TLSv1.2
14    DHE-RSA-CAMELLIA256-SHA    SSLv3,TLSv1,TLSv1.1,TLSv1.2
15    CAMELLIA256-SHA            SSLv3,TLSv1,TLSv1.1,TLSv1.2
16    DHE-RSA-CAMELLIA128-SHA    SSLv3,TLSv1,TLSv1.1,TLSv1.2
17    CAMELLIA128-SHA            SSLv3,TLSv1,TLSv1.1,TLSv1.2

This still prefers 256 bit DHE-RSA-AES256-GCM-SHA384 over various 128 bit ciphers. And the DHE-RSA-CAMELLIA* suites should probably be moved above the non-PFS.

And did you really mean to introduce the DHE-DSS-suites in the new list? The qualys ssl servertest says these can't be used for PFS because they're effectivly limited to 1024 bit DSS key.

ulfr, 20131215

1. ordering

Your findings are consistent with the recommendation. But maybe the section that explains the prioritization logic could be clarified:

  • PFS is always preferred. Non PFS ciphers will be listed after PFS cipher, regardless of keys size.
  • AES GCM is preferred to AES CBC, regardless of key size.

2. Camellia

Unlike AES with AES-NI, Camellia is not accelerate in CPU (as far as I know). That makes it significantly slower than AES and RC4.

type                 16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc        576200.99k   614446.29k   624010.15k   626885.29k   627610.97k     <= with AES-NI
rc4                411475.31k   529825.54k   675312.13k   711441.07k   715860.65k
camellia-128 cbc    89921.94k   136523.43k   150717.61k   152728.23k   160970.07k

3. DHE keysize

On DHE, it is important to note that, right now, all TLS servers that need backward compatibility are limited to 1024 bits DHE keys. Java 6, for example, doesn't support DHE keys higher than 1024 bits. The question is between trusted a single RSA key that's 2048 bits, or accepting to reduce the security to 1024bits, but using different keys for each session. We chose the later, and use 1024 bits DHE keys.

SSL v3

SSL Labs recommends not support SSL v3 unless there's a very good reason.

All the recommended configurations here support SSL v3. Is there a reason for that?

ulfr, 20140417

Actually, yes: we privilege backward compatibility. In the future, we want to selectively disable SSLv3 on sites that don't need to be backward compatible that far in time. But for now we recommend it everywhere.

NetScaler TLS 1.2 DHE issue reference?

Re "There is an issue with Netscaler's TLS1.2 and DHE ciphers. When DHE is used, the TLS handshake fails with a fatal 'Decode error'. TLS1.2 works fine with AES and RC4 ciphers."

Is there a release note from Citrix on this issue which can be referenced here? If discovered via testing, what NetScaler model and firmware where used in the testing?

We've not seen problems with TLS 1.2 and DHE on MPX class boxes running "NetScaler NS10.1: Build" firmware, wondering if the problem witnessed was due to issue in a specific firmware release or possibly sporadically occurring so not easily reproduced.

It is worth noting that the virtualized (VPX) NetScaler model does not yet support TLS 1.1/1.2 in any firmware version.

SSH and IPsec

Acknowledging that it's slightly off-topic, I'd like to request that this document at least mention SSH and IPsec. While searching for information on cipher suite selection, multiple sources led me here. It's the most instructive document I've found, but it doesn't make any mention of other uses of cipher suites such as SSH and IPsec. I think many people would appreciate it if these topics were covered at least minimally, such as a statement about how suite selection differs for these use cases vs HTTPS, or links to more in-depth documents to help users select ciphers for these applications. Currently such information is not easy to find. Thanks!

Answer from kang 20150223

We have a specific page for OpenSSH which I believe documents what you're looking for - have a looky look at Another document you might want to look at:

Having the same for IPSEC would be a good idea, however, we do not have this right now.

OCSP in HAProxy

This little script can come handy:

#!/bin/bash -eux

CRT_FILE=/tmp/`basename ${PEM_FILE} | sed 's/pem/crt/'`
DIR=`dirname ${PEM_FILE}`
URL=`openssl x509 -in ${PEM_FILE} -text | grep OCSP | cut -d: -f2,3`
HEADER=`echo $URL | cut -d/ -f3`
ISSUER_CRT_URL=`openssl x509 -in ${PEM_FILE} -text | grep Issuers | cut -d: -f2,3`
wget ${ISSUER_CRT_URL} -q -O - | openssl x509 -inform DER -outform PEM > ${PEM_FILE}.issuer
openssl x509 -outform PEM -in ${PEM_FILE} > ${CRT_FILE}
openssl ocsp -noverify -issuer ${PEM_FILE}.issuer -cert ${CRT_FILE} -url ${URL} -no_nonce -header Host ${HEADER}  -respout ${PEM_FILE}.ocsp

Don't forget to put this script in a cron and reload HAProxy afterward.

reply from ulfr, 20150415

My issue with this script is that not all certificates will have the CA Issuers URL present, which will make the script fail.

            Authority Information Access: 
                OCSP - URI:
                CA Issuers - URI:

For the sake of not confusing copy/paste users, I think we should stick to the OCSP retrieval command, and explain what information the operator should be providing to the command. Something like this:

#!/usr/bin/env bash
openssl ocsp -noverify -issuer $CA_CERT -cert $SRV_CERT -url $OCSP_URL -header Host $(echo $OCSP_URL | cut -d '/' -f 3) -out /dev/null -respout $SRV_CERT.ocsp
service haproxy reload 2>&1 1>/dev/null