Talk:Security/Server Side TLS
Contents
Why is PSK Disabled?
PSK has various use cases, such as with kiosks and other trusted clients. If said trusted clients are embedded systems, not having to do the public key exchange every time a connection is made saves significant CPU cycles. However, your article implies PSK weakens security -- else why include it in the disabled ciphers? --DisplayName (talk) 21:57, 20 May 2015 (PDT)
- Since No one has responded, I'm planning to remove !PSK from the recommendations. --DisplayName (talk) 18:24, 2 June 2015 (PDT)
Proposed changes to ciphersuites
This change was proposed by zwdg on IRC.
Modern:
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
Intermediate:
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-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA
Old:
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-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA
gnutls:
NONE:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+ECDHE-ECDSA:+ECDHE-RSA:+DHE-RSA:+RSA:+AES-128-GCM:+AES-256-GCM:+AES-128-CBC:+AES-256-CBC:+SIGN-ECDSA-SHA512:+SIGN-RSA-SHA512:+SIGN-ECDSA-SHA384:+SIGN-RSA-SHA384:+SIGN-ECDSA-SHA256:+SIGN-RSA-SHA256:+SIGN-DSA-SHA256:+SIGN-RSA-SHA1:+SIGN-DSA-SHA1:+CURVE-SECP521R1:+CURVE-SECP384R1:+CURVE-SECP256R1:+AEAD:+SHA384:+SHA256:+SHA1:+COMP-NULL
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
IIS
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.
RC4
Full discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=927045
RC4-based ciphers ought to be completely removed from the list, better attacks are coming like this one: https://www.usenix.org/conference/usenixsecurity13/security-rc4-tls
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 https://bugzilla.mozilla.org/show_bug.cgi?id=927045. 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 https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses 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?
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK
or for people lacking trust in ECC/NIST curves:
DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK
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 https://wiki.mozilla.org/index.php?title=Security%2FServer_Side_TLS&diff=779260&oldid=768649
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.07k3. 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. https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf
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 124.13.nc" 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 https://wiki.mozilla.org/Security/Guidelines/OpenSSH. Another document you might want to look at: https://wiki.mozilla.org/Security/Key_Management
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
PEM_FILE=${1}
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:http://ocsp.startssl.com/sub/class1/server/ca
CA Issuers - URI:http://aia.startssl.com/certs/sub.class1.server.ca.crt
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 CA_CERT="/etc/haproxy/myca.pem" SRV_CERT="/etc/haproxy/mycert.pem" OCSP_URL="http://ocsp.startssl.com/sub/class1/server/ca" 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
