Talk:Security/Server Side TLS

From MozillaWiki
Revision as of 15:14, 24 April 2014 by Sdl (talk | contribs) (Add IIS guidance)
Jump to navigation Jump to search

Page protection

This wiki page is protected against changes. Changes must be discussed in this section beforehand. If you have any comments, please leave them here, with your nickname and date.

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)

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.

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.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. 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.

Retrieved from "https://wiki.allizom.org/index.php?title=Talk:Security/Server_Side_TLS&oldid=968423"