Sophos Cloud Optix
Some things just aren’t meant to be exciting. In fact, some things are supposed to be so far from novelty, surprise and frivolity that any whiff of excitement at all is a bad sign indeed.
In my world, elevators should operate with humdrum predictability, suspension bridges should not be zany and bankers ought to behave like accountants rather than croupiers.
The software that drove the Space Shuttle was famously specified, checked, tested and re-tested until every last drop of free-wheeling joie de vivre was drained from its 420,000 lines (and, no doubt, from the people who wrote them).
NASA knew that in order for us to do exciting things in space we ought to make getting there as dull as we could.
And it’s the same with the pillars of software infrastructure that keep up the internet – they are supposed to be the doughty columns that go unnoticed but upon which a universe of interesting things can be buit.
One such pillar is the stalwart OpenSSL library – a bit of encryption software whose immense popularity means that it bears a great deal of weight indeed.
Earlier this year a crack appeared in that particular pillar which was worrisome enough to get everyone’s heart racing.
The crack, a buffer overflow bug, caused the software almost everyone was using to secure secret things like passwords, session keys and private data to actively disgorge secret things like passwords, session keys and private data.
A great deal of excitement ensued and a piece of software that should have had no truck with limelight found itself centre stage on the 11 o’clock news.
To make matters worse, the bug – which would normally get away with a fabulously dull name like CVE-2014-0160 – ended up with a cracking moniker; Heartbleed.
Until that moment OpenSSL had enjoyed a long history of being just as dull as it should have been.
We now know that we were all guilty of assuming it was dull. It wasn’t. There were plenty of things to set pulses racing in OpenSSL, it just seemed like there wasn’t because almost nobody was actually looking at the code to find out.
The internet can’t be built on the faux mundanity of OpenSSL, what’s needed is something genuinely uncool.
Thankfully Google’s Adam Langley has something in mind; it’s called BoringSSL and it aims to do exactly what it says on the tin.
BoringSSL is a version of OpenSSL that has diverged so much from its parent that it’s now become a distinct entity in its own right.
According to Langley, Google has for years been routinely patching OpenSSL before using it. Some of the patches have been accepted back into OpenSSL proper but many more of them haven’t.
The burden of keeping Google’s patch set in sync with OpenSSL has now become so great they’ve decided to fork the code.
... things have grown very complex. The effort involved in keeping all these patches (and there are more than 70 at the moment) straight across multiple code bases is getting to be too much.
The project will continue to exchange code with OpenSSL where possible but, perhaps more importantly, they will also be free to share code with LibreSSL, another recently announced attempt to bring dullness and sobriety to the beleaguered crypto code.
Theo de Raadt, founder of the OpenBSD team behind LibreSSL, welcomed the news:
I suspect everyone working on LibReSSL is happy to hear the news about BoringSSL. Choice is good!!
And of course he’s right.
Choice, competition and cooperation between three teams of not too shabby security experts should result in higher quality code, safer data and software that really is as boring as it seems.
Of course, calling something boring doesn’t make it so and Langley himself describes the name as an ‘aspiration’.
I guess we’ll only know if he’s succeeded if we’ve got better things to do than take any notice.
Image of bored girl courtesy of Shutterstock.
If Google is willing to throw their weight behind this, I would rather see a full implementation using formal methods than a series of seemingly haphazard patches. They don’t even need to build a full OpenSSL replacement. If they could do the portions needed to negotiate session keys and conduct the symmetric-key communications on a TCP based TLS connection (and not, say, generating or signing keys) they would go a long way to producing a boring protocol library. This just seems like a differently-patched OpenSSL.
I see what you’re saying, but I’m not sure I agree with the “don’t have to do it all” piece of your argument.
Sometimes the best thing to do with a product is throw it away and start over from scratch.
Steam engine technology was continually updating itself throughout the 1800s. But then someone invented the internal combustion engine, and steam was effectively history.
DOS was king in the 80s, but in the middle of that MS and IBM decided to try something else, and NT was born.
FAT worked well enough. FAT32 tried to extend it, but true security never happened until NTFS.
I’m not saying we have to ditch SSL completely, but, some thought should be given to the idea.
I suspect that the biggest “benefit” of Heartbleed is that we’re not as complacent now. I’ve been in this business for over 3 decades, and yet it never crossed my mind to ethically hack SSL. ID10T!
I suspect that now, there are quite a few white hat (and grey?) hackers who have added it to their list. 🙂
We know the black hats have. 🙁
I don’t exactly trust Google, but competition in this arena can’t possibly hurt, and it’s certainly in their interests to help lock down e-commerce. It’s too bad it’s so expensive to throw white-hatters at this, but Google certainly has the money.
Maybe we need some old-school thinking? In my mainframe days, we certainly had bugs (security and otherwise). But, we also had this chunk of code that had to be perfect. We called it the Kernel, and it was the heart of the operating system.
Kernel bugs we massive undertakings compared to bugs elsewhere. We know that the kernel didn’t do a whole lot, but what it did do, it had to always do correctly. So, no expense was spared fixing them AND reviewing the fixes. The entire evaluation team would go at it with the digital equivalent of sledgehammers.
We actually called ourselves “Muggers”. MUG = malicious user group. When a MUG was called for, every other priority was put on hold. We were instructed to use all of our programming expertise and naughty-user skills to break the system. We hit it in ways it was not designed to operate.
But MUGs occurred on live production systems, an action not condoned in modern programming.
Could SSL (Open, Boring, Libre, etc.) perhaps use such a concept? Obviously, it would be limited, but … ?
Modern penetration testers do something not dissimilar on live systems…the rules of engagement (if the pen testers aren’t cowboys) are carefully worked out in advance [a] to make their actions lawful through authorisation and [b] so that some attacks can be avoided or very carefully scheduled, based on an estimate of how likey they are to break things.
(Exploits that give you remote code execution 10% of the time might cause denial of service the other 90%. If you really want to determine your resilience you either have to tidy up the exploit – thus making it more dangerous for potetial intrusion – or choose your time wisely 🙂
Yeah, it’s a classic Catch-22: If you do pen-testing on live production systems, you’re likely to crash them in the process. But, if you only do them on devices designed for the purpose, then you don’t find out whether it works in production (which is what the bad guys are doing).
It’s a tough line to straddle. Good pen-testers will use a hybrid process, completely crushing the honeypots first, in the hope of finding things about production without actually killing off the production systems. But, no matter what you do, you eventually have to test against real live production systems.
It’s like the old adage that the only true test of a backup is to fry the system and restore it. Unpleasant, but you don’t REALLY know if it works until you do.
Here’s a Heartbleed question I’ve been dying to ask you or Duck. When does the responsibility for fixing a bug like this end?
Two weeks before Heartbleed was announced I bought a new Android tablet, Craig Electronics CMP748. It’s a cookie-cutter design using the Rockchip 2928 chipset. When Heartbleed was announced, I took a look at the OS version. Sure enough, it was Android 4.1.1.
Ran the “Check for Updates” for a few days and nothing was forthcoming. Checked on the Craig site. No updates. Checked on the Rockchip site. It instructed users to get updates from the product manufacturer, not them. Wrote the product manufacturer, Craig Electronics, and they stated the (new) product was not supported.
As I see it, my options are:
1) Use the product as is.
2) Throw it away.
3) Exercise my warranty. (I bought the $8.00 no-questions-asked warranty.)
4) There is currently no CyanogenMod code for this product, but I could get the open source from Craig (it’s on their website) and the CyanogenMod code and learn how to do the build (Craig refuses to tell you.) and fix the problem. I suppose that means a lifetime of making updates for new Android versions…
Which would you do?
I’d like to hear your comments on how long you think a company should provide product updates and whether you think they should stop providing them while the product is still offered for sale.
Would you let me know if you respond to this post? The website doesn’t generate a “Someone has replied to your post.” message as it should.
Laurence Marks
Personally, I’d opt for #3.
Did you know you were buying an unsupported product? It seems that Craig at least have a responsibility to let you know that in advance. If they do support it then they have a responsibility to spell out what that support consists of.
Perhaps in a free market that allows software to be sold with license terms that say it’s sold as-is and without warranty the question should be “who *will* take responsibility?” or “who will provide the best service for my money?”.
The company that steps up gets my money. Since you’re left asking the question it seems nobody has stepped up and nobody is making a good case for your money.
You have the option to use your warranty and vote with your dollars elsewhere.
Mark wrote: “Did you know you were buying an unsupported product?”
Actually I bought the product retail (one-day special) at $29.99. At that price I wasn’t inclined to go to the manufacturer’s website to do a lot of research. When I subsequently went to the manufacturer’s website the product was featured on the home page (implies a supported current offering) and prominently labelled “GP Supported Device.” In a subsequent email exchange with Product Support, they disclaimed support and explained that “GP Supported Device” merely means they have not blocked access to the Google Play store.
There are actually two warranties on the device: 3 months warranty from the manufacturer and three years from SquareTrade. I could exercise either one, I suppose.
At $30 I’d turn it into a toy, errr, research device and go for #4 – it sounds as though the device has a bootloader you can unlock to allow you to reflash it with an OS build of your choice.
The Android open source code is huge to download and takes hours to build…you also end up with very basic functionality, but since you already have an Android licence with the device, I think it’s lawful to install your own copies of Google’s core non-open-source apps. That includes the Play Store components so you can get third party software easily.
If you have some spare time, Android is a lot fo fun to play around with, and it’s a decent learning exercise to do so, too.
The “Someone has replied to your post” feature was part of IntenseDebate – a comment system we no longer use.
Although we’ve lost a useful feature we feel we’ve gained more than we’ve lost by switching.
You can get comment updates using our RSS feeds. You can get the comments for any page as a feed by adding /feed to the end of the URL and you can get the latest comments across the whole site from this URL:
http://nakedsecurity.sophos.com/comments/feed/
Just stopping by to say I really enjoy the point made in this article – SSL should be beyond boring.