Security/Server Side TLS | Hacker News Reader

Security/Server Side TLS

wiki.mozilla.org

134 pointsjvehent26 comments

We just implemented perfect forward secrecy for https://commando.io this weekend on all of our nginx web servers (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?

"However, one optimization that can be made for some browsers is OCSP stapling: the server can include (staple) the OCSP response from the CA to its certificate chain, allowing the browser to skip the online check. Moving the OCSP fetch to the server allows the server to cache the signed OCSP response and save the extra request for many clients. However, there are also a few things to watch out for:

OCSP responses can vary from 400 to 4,000 bytes in size. Stapling this response to your certificate chain may once again overflow your TCP congestion window—pay close attention to the total size.

Only one OCSP response can be included, which may still mean that the browser will have to issue an OCSP request for other intermediate certificates, if it has not been cached already."

http://chimera.labs.oreilly.com/books/1230000000545/ch04.htm...

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

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

See http://en.wikipedia.org/wiki/OCSP_stapling

Useful tool to test your domain: https://www.ssllabs.com/ssltest/index.html

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

What functionality are you missing?

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.

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.

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

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.

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)

Yes, the goal is to provide a ciphersuite that can be copied directly. But instead of stopping after the first paragraph, we explain why we think this ciphersuite is best. The guideline is not just a ciphersuite, it's a study of the state-of-the-art of SSL/TLS.

At the end of the day, it's not realistic to imagine that everyone will spend days researching this to come up with a proper ciphersuite. There is a strong need for guidance.

You are correct about SSLv3: it is up to each organization to stop supporting it. But do know that it is still widely used, if not in browser, in client libraries. I wouldn't turn it off on a corporation site if I were you.

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

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

> 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 :-)

We don't control what the client enables. Any client could decide tomorrow to disable AES-128, and we need to support that.

The ciphersuite focuses on ordering ciphers by strength and performance, and we don't just disable cipher for the sake of keeping it small. After all, it's the same number of clicks to copy a large ciphersuite than a small one ;)

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

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?

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

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.

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?

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)

a-ha, got it, thanks :)

true, esp if use HaProxy as LB

Is there an equivalent of this for GnuTLS?

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

Reply on news.ycombinator.com