Security/Server Side TLS

https://wiki.mozilla.org/Security/Server_Side_TLS

by jvehent • 13 years ago

134 26 13 years ago

wiki.mozilla.org

nodesocket2• 13 years ago

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?

jvehent7• 13 years ago

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.

nodesocket2• 13 years ago

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

zobzu2• 13 years ago

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

flylib• 13 years ago

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

jakozaur• 13 years ago

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.

ivanr3• 13 years ago

What functionality are you missing?

jvehent7• 13 years ago

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.

ck2• 13 years ago

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• 13 years ago

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• 13 years ago

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

jvehent7• 13 years ago

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.

e12e2• 13 years ago

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• 13 years ago

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

e12e2• 13 years ago

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?

jvehent7• 13 years ago

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

alextingle• 13 years ago

Is there an equivalent of this for GnuTLS?

jvehent7• 13 years ago

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

daemon133• 13 years ago

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

jvehent7• 13 years ago

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.

daemon133• 13 years ago

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?

Security/Server Side TLS

Related Stories