Ciphers - How to configure

Does anyone know if you can configure the cipher suite? Right now it seems the https security leaves several weak available.


Hi Ryan,

As I mentioned to you in the helpdesk, it’s not possible for you to affect the configuration.

We’d have to make changes on our entire CDN, as these changes are at a system level.

In general we aim to have an “A+” for SSL with the well respected third party testing tool “SSL Labs”: (I used one of my test sites to demonstrate here), so we believe the current cypher suite to be not just sufficient but great.

I understand that some scanners disagree and as I mentioned in the helpdesk also, I’ll be checking in with our CTO on his plans in that area and will follow up here as well as in your helpdesk case with his plans.

Just wanted to let the audience know that we do have plans to change out our cypher suites alongside roll-out of the next version of our CDN edge software. I don’t have a timeline for this work but will follow up in this thread when it is live.

Hi @fool - wondering if there’s an update on this?

While SSL Labs does score sites on Netlify as A+, it does also show that Netlify supports weak ciphers known to be vulnerable to BREACH and LUCKY13 attacks.

Those being CBC mode ciphers - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 and TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

hi @delpiersos - just want you to know we haven’t forgotten about this - we will get back to you as soon as we can.

1 Like

Hi again @delpiersos and thanks for your patience while I talked through the situation with our operations team. Sweeping changes to our CDN such as changes to SSL configuration (they affect all customers and their visitors) require thought and planning around implementation details, testing, and rollout, and all of that takes time. Of course security is a priority, so that isn’t to say we never make them, just that they won’t necessarily be fast due to logistics and care needed, and we must prioritize support for any browsers in wide use, since we cannot control what our customers’ visitors use within a context of keeping things secure.

So, we did roll out a major change to our cyphersuites which brought us to the level you see now at ssl labs; we do serve our own site using our settings so that SSL Labs report is representative of all sites on our systems.

The two weak cyphers you point out were left in intentionally - BUT are used with the absoute lowest priority - they will ONLY be used for the ancient browsers which still account for non-trivial amounts of traffic to our CDN’s; no modern browser will prioritize those cyphers, and due to the way our service is configured, they are offered as the “last option” so they will never be used in normal practice by modern browsers, and thus not attackable except from those clients that can do no better:

  • ECDHE-RSA-AES128-SHA256 : Various outdated IE, Safari<9, Android<4.4
  • DHE-RSA-AES128-SHA256 : Android 2.x, openssl-0.9.8, etc

We feel this is as secure as possible (protects our customers and their visitors), without denying access from older devices and services (many of which are in educational and corporate environments, or poorer parts of the world where they can’t “just upgrade” - but who still deserve to be able to use the web). Even SSL Labs themselves seems to agree with this decision (beyond just giving us a good grade): and as you can read there, does grade you an F in case your implementation is vulnerable to the POODLE class of attacks, which are by their and our understanding, more severe and with worse impact, than the ones you mention.

As a general note, we intentionally and constantly monitor both SSL Labs’ grading of our implementation and will react quickly should it fall below an “A”, as well as the actual usage of our CDN. Should the old cyphers stop being needed or become a bigger problem in Qualys’ opinion, we will make further configuration changes at that time.

Hope that is clear, but let me know if there are any followup questions.

1 Like

Hi @fool - it’s been a few months, I’m wondering if there are any updates on being able to opt out of those vulnerable ciphers?

Nope! What I said above remains true:

  • cypher selection is not user-configurable and may never be.
  • we deconfigure cyphers that are most vulnerable
  • we leave the rest enabled (even less strong ones, with the lowest priority so a capable browser will never use them), for the benefit of older devices and to help keep the web open.