Harden BadgeApp TLS settings: Remove 3DES in permitted list and require TLS 1.2+?

[david-a-wheeler]

There's a new collision attack that appears to be devastating to 3DES and Blowfish. See: https://threatpost.com/new-collision-attacks-against-3des-blowfish-allow-for-cookie-decryption/120087/

Our current site supports 3DES, and that is now being frowned on: https://tls.imirhil.fr/https/bestpractices.coreinfrastructure.org

That's sad, 3DES is slow but it has held up well against other attacks. But crypto algorithm agility to the rescue: we'll just remove it from our permitted crypto algorithms.

A challenge: This is actually controlled by Heroku and Fastly. We need to figure out how to invoke that agility.

[david-a-wheeler]

Hmm, don't see a way to configure the crypto suite on Heroku in these docs: https://devcenter.heroku.com/articles/ssl-endpoint

[david-a-wheeler]

For the record, a lot of people are looking at removing 3DES. Here's the discussion for Python: https://bugs.python.org/issue27850

[david-a-wheeler]

Submitted ticket to Heroku: https://help.heroku.com/tickets/425806

This may be painfully obvious & a stupid question, but I don't see the answer.

[david-a-wheeler]

Heroku has responded (and quite quickly too). My plan is to update the master and staging tiers, try that out, and if it works roll it out to production.

[david-a-wheeler]

Qualys currently gives our site an "A+", but they also plan to update their grading criteria to penalize 3DES support. Details here: https://blog.qualys.com/ssllabs/2016/11/16/announcing-ssl-labs-grading-changes-for-2017

[david-a-wheeler]

Fastly is our CDN. Fastly's schedule for 3DES and TLS 1.2 is as follows:

• "Customers with dedicated endpoints (hosted offsets) can elect at any time to require TLS 1.2 by contacting support. We strongly encourage all customers with dedicated offsets to ask to switch to TLS-1.2 before the hard deadline of June 30, 2018. Customers with dedicated endpoints will not be affected by changes made on January 9 or April 30, 2017."
• "On April 30, 2017, we’ll convert all shared offsets to TLS-1.2 and drop 3DES cipher support. Note: if you have legacy TLS support requirements for a service on a Fastly shared endpoint, contact support to migrate to Fastly’s designated shared endpoint for legacy protocol support or to your own dedicated endpoint with TLS 1.0 and 1.1 supported. No changes to dedicated endpoints (hosted offsets) will be made at this time."
• "By June 30, 2018, all customers, including those on dedicated endpoints, must have converted to TLS-1.2. Due to the PCI Security Standards Council mandate, older TLS implementations will no longer be supported on Fastly infrastructure on shared or dedicated endpoints. There will be no exceptions made after this date."

[david-a-wheeler]

I'm thinking we should switch to "no lower than TLS 1.2" and "no 3DES".

All major browsers support TLS version 1.2 as of 2014, and practically everyone at least supports AES (not just 3DES). We can ask Fastly to do this for us, via customer service, and enforce in other ways.

@dankohn @jdossett Marcus Streets - what do you think? Time to tighten the HTTPS requirements for BadgeApp in this way?

[david-a-wheeler]

The only problem with upgrading the TLS minimum is that many old Android versions don't support TLS 1.2 - and Android phones often don't get upgraded properly.

But I think it's doable. Android 5.0 (Lollipop) or better directly handle TLS 1.2, and Android 5.0 or better covers 60% of the Android market (and probably much more of those who'd visit this website). Android 4.1-4.4.4 disable TLS 1.2 by default, and they're almost all the rest. That said, Android 4.1-4.4.4 merely disable TLS 1.2 by default but do have it... so those users could enable TLS 1.2, and if we included them that includes 97.9% of the Android market.