I’ve been working infosec for a long time. Normally, when I see news of breaches, hacks, leaks, misconfigurations, critical information stored in the clear, I simply don’t bat an eye. This one got me. Ok, sort of. It’s an article over at The Register indicating that SSL Pulse surveyed 179,000 “popular websites” and found that 71% are still vulnerable to the BEAST. My reaction was simple astonishment. How could it still be that bad?
While my career path has taken me out of the cryptographic weeds, I happen to know a few things about SSL/TLS, proper configurations, and attacks against them (dating back to the Bleichenbacher attack; an adaptive chosen-ciphertext attack that can be used in a variety of ways). Truth be told, I feel embarrassed for our community of information security professionals. Why is BEAST so hard to tame? Why haven’t we been able to improve this situation more than we already have?
The only conclusion I can reach at this point is that we haven’t done enough to help users update and configure their systems. The first step to identify a solution is to understand the problem. So, why aren’t users updating and configuring their systems?
It is arguable that the driving force behind use of secured sockets is really online transactions between businesses and consumers. It’s further arguable that the majority of end-users don’t know (or care to know) what sockets are, much less how to secure them – nor should they have to, in my opinion. But, in this world, we all have to learn and know some things we’d rather not. It’s also arguable that ensuring the security of online transactions is critical to our global economy, which brings in the additional problem of crossing jurisdictional boundaries.
In brief, securing online transactions is (at least):
- An educational issue – users aren’t aware of good practices
- An accountability issue – neither users nor services are held accountable for poor practices
- A legal issue – any regulation or enforcement must contend with jurisdictional issues
How can we solve this problem? It seems that we could approach this on two fronts: 1) Address the browser providers from this point forward, and 2) address the users with browsers already in the field.
Regulation could be used to address browser vendors from this point forward. A number of US agencies could issue regulations on browser and server vendors to:
- Always support the latest secure socket protocols
- Always default to limited, “known-strong” cipher suites
- Provide a segregated updating mechanism for security updates with a default configuration to auto-update.
Addressing fielded browsers and services is somewhat more difficult, but we could argue that addressing the browsers first is the better way to go. To that end, what if:
- A simple set of proper secure socket configuration were provided by each major browser provider, while, at the same time,
- Servers were configured to provide links to those instructions whenever a insufficiently strong cipher suite was negotiated?
Yes, this requires coordination. Yes, some users would be inconvenienced. But, wouldn’t businesses and service providers – the operators of these poorly configured servers – be viewed favorably by demonstrating that the care about the security of their users activities and information? It seems that they would.
Maybe the SSL Pulse group should consider attempting to orchestrate such an effort. It seems worthy to try, even if it might be futile. Or, perhaps the EFF, whose mission is entirely about protecting privacy online. How about the FTC, SEC, US Department of Commerce, or even the United Nations should get involved (this is a global issue, after all).
Or, perhaps we should just let this whole thing fail when users and businesses aren’t taking any responsibility for securing the Internet we all know and (dare I say) love? I mean, is Internet security really too big to fail?
In any case, if you’re an infosec genius, IT administrator, business professional, or plain-old user and you’re reading this, do yourself and your loved ones a favor. Update your systems and configure your browsers correctly – help those you know, but who don’t practice good system hygiene.
Here’s all the appropriate links I could find inside 15 minutes.
- Google Chrome SSL Settings
- Internet Explorer (7) SSL Settings
- Safari (5.1 or earlier) Secure Connections
- Enabling SSL in IIS
- Apache HTTP 2.4 SSL/TLS Strong Encryption FAQ
- Apache HTTP 2.2 SSL/TLS Strong Encryption FAQ
Short of getting some regulation moving or getting cooperation among vendors, this is about all we can do.