
Security/Server Side TLS - jvehent
https://wiki.mozilla.org/Security/Server_Side_TLS
======
nodesocket
We just implemented perfect forward secrecy for
[https://commando.io](https://commando.io) this weekend on all of our nginx
web servers ([https://medium.com/devops-
programming/78e1acd80228](https://medium.com/devops-
programming/78e1acd80228)). The only thing we don't implement is OCSP
stapling. How much of a security and performance increase is there to gain
with it?

~~~
jvehent
> How much of a security and performance increase is there to gain with it?

The time it takes to establish a TCP connection to an OCSP responder, send a
query, wait for a response, parse it and close the TCP connection.

I think it's fair to say a few hundred milliseconds at the very least.

~~~
nodesocket
So it seems to be significant. Will implement OCSP stapling shortly. Thanks.

------
jakozaur
Useful tool to test your domain:
[https://www.ssllabs.com/ssltest/index.html](https://www.ssllabs.com/ssltest/index.html)

Not all things are there, but fairly useful to test that from user point of
view.

~~~
ivanr
What functionality are you missing?

~~~
jvehent
SSLLabs is great already, I use it constantly.

The one thing that could be improved is showing the detail of the score
calculation. It's rather confusing at the moment, and I have no idea what
criteria contributes to a better score.

DH and EC parameters are also hard to see at first.

~~~
ivanr
You are probably aware of the Rating Guide:

    
    
        https://www.ssllabs.com/projects/rating-guide/
    

but would like to see scoring hints within the test itself?

The current scoring approach does not make that easy, which is the main reason
why there are not more hints. I am planning a new version of the Rating Guide
for next year, which will (most likely) be purely rule based, making it
possible to explain the score in detail and, at the same time, point to the
areas that need to be improved.

There's a also the problem with the static-HTML design approach can no longer
withstand the amount of information presented.

In other words, it's time for v2, where we will apply what we've learned so
far.

~~~
jvehent
This is correct, I am looking for a way to understand the score from the UI
directly. Glad to see it's on the roadmap for V2, and thanks for the hard
work!

As a side note, while researching this guideline, we found that the benefit of
AES256 compared to 128 isn't as clear cut as it would seem [1]. So we decided
to prefer AES 128 because it is still 25/30% faster. It also matches a
proposal Brian Smith made for Firefox. So far, SSLLabs focuses on crypto
strengh, and not on performance. I'd be interested to see the performance
factor taken into account in the score calculation.

[1] [http://www.mail-archive.com/dev-tech-
crypto@lists.mozilla.or...](http://www.mail-archive.com/dev-tech-
crypto@lists.mozilla.org/msg11325.html)

~~~
ivanr
The performance aspect will definitely be included in the next version. It's a
valuable lesson (in human behaviour) I learned from the current version.

People love getting higher and higher scores and, before, when the overall
numerical score was included in the results, I observed many pushing their
scores up with no good reason, impacting performance. One example was using
4096-bit RSA keys, which are an overkill for virtually everyone.

------
ck2
And so begins years of copy/paste of cipher lists without knowing what they
mean or do.

Your cipher list should be far more paired down than their list.

And unless you need IE6 support for SSL, you can disable SSLv3 (v2 should
always be disabled)

~~~
Sambdala
Is/Are there resource(s) you'd point someone to if they didn't fully
understand the topic but would like to become competent?

~~~
cmhamill
The "OpenSSL Cookbook" book you get when you sign up for notifications about
the book at this site[1] is very good. Written by the guy behind SSLLabs, if I
recall correctly.

[1] [https://www.feistyduck.com/books/bulletproof-ssl-tls-and-
pki...](https://www.feistyduck.com/books/bulletproof-ssl-tls-and-pki/)

------
e12e
> The general purpose ciphersuite at the time of this writing is:

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:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

Whoa! I'd like to see some reasoning behind allowing that _many_. How many
user agents allow 128-bit aes and not 256? Why would you need to allow both?
If 128 is enough, you don't need 256. If you need 256 you should block 128.

It's not a very big deal, but given the choice between complexity and
simplicity _in encryption_ \-- I'd always prefer simplicity...

Not just "fewer cipher suites", but also what follows from that: "We allow X
bit symmetric keys _only_ ", we guarantee forward secrecy (or not) etc.

But still, a lot better than leaving things at their default, I guess :-)

~~~
hsivonen
The rationale for preferring 128-bit AES over 256-bit AES is given later in
the doc.

~~~
e12e
I was kind of arguing against including both, on the basis that it is
unlikely(?) that a client that enable 256bit aes suites disables 128bit -- and
so if indeed 128bit might be _more_ secure (see the note on timing attacks) --
why leave 256 bits enabled?

Has anyone seen clients in the wild that disable 128bit and enable 256?
Especially end-user clients, and/or "permanent" deployments/appliances, where
the new cipher-suite isn't a result of power-user tinkering, but a decision
that's taken out of the end-users hands?

------
daemon13
Since everybody is getting funky about PFS...

Julien, do you have any news to address this Adam's point:

>> So how do you run forward secrecy with several servers and support session
tickets? You need to generate session ticket keys randomly, distribute them to
the servers without ever touching persistent storage and rotate them
frequently. However, I'm not aware of any open source servers that support
anything like that.

[0]
[https://www.imperialviolet.org/2013/06/27/botchingpfs.html](https://www.imperialviolet.org/2013/06/27/botchingpfs.html)

~~~
jvehent
Nginx has a patch to store them in memcache, for what it's worth. It's far
from ideal, but at least it's not persistent storage. The standard is still to
point clients to a single termination endpoint, and do active/passive cluster,
so that there's no need to share the session tickets.

I still believe that using PFS, even with this limitation, is safer than
encrypting pre-master keys with a single private key that almost never rotates
and is stored on plenty of servers.

~~~
daemon13
thank you for update

>> I still believe that using PFS, even with this limitation, is safer ...

I definitely agree, the problem is that usually there is more than 1 web
server :-)

>> The standard is still to point clients to a single termination endpoint,
and do active/passive cluster, so that there's no need to share the session
tickets.

Sorry, I did not understand (esp. the active/passive cluster thing) - could
you please may be add some pointers (blog post, etc) with more details?

~~~
zobzu
That's a good point about master keys. The state is pretty bad with Apache for
example, and I'm not sure its much better with nginx at least by default.

I think that what he means is that you terminate SSL on the load balancers (=
single termination endpoint), then have your cluster beneath it (non-SSL/TLS,
or new SSL/TLS connection, thus different tickets)

~~~
daemon13
a-ha, got it, thanks :)

true, esp if use HaProxy as LB

------
alextingle
Is there an equivalent of this for GnuTLS?

~~~
jvehent
Not yet, but we plan to add a correspondence table between OpenSSL and GnuTLS.
Any contribution is most welcomed.

