Tag Archives: SSL

Over the last month I've read a lot of inane crap posted by security journalists who should know better. I'm specifically addressing the issue around the vulnerability discovered in Juniper's NetScreen devices. Conspiracy theories ranging from "it's a US agency pretending to mimic Chinese state intelligence" to NSA influenced or deliberately backdoored code making its way into the release system bypassing internal QE testing.

I do "not" know the full story and nobody ever will but heres my starter for ten.

Juniper just like two dozen major US technical vendors providing catalogue items to US Government and Federal Agency / Defense customers (as well as other global government accounts and the private sector which makes up 70% of their revenues) have grown by acquisition. Not innovation. Acquisition.

Having been a CEO that exited handsomely from his own non VC funded startup I've got some experience here. As a casual investor, VC and journalist I sit and research this stuff to the nth degree and I'm still none the wiser about the rationale behind some "marriages" of technology vendors. There seems to be an expectation from a lot of analysts who frankly haven't the first clue about where tech comes from and is going, and institutional shareholders that companies should use warchests of saved revenue to grow their product range by acquiring other companies.

Rather than innovate and grow their own products safely and sanely - even if it means an increased R&D curve. Not every acquisition leads to bottom line success but often a company is acquired for its people not its product, or its market position and revenue share rather than it's product and people. It's not a precise science and you can count the number of commercially savvy acquisitions in the network sector where direct reflected growth has resulted on two hands. Often its the weak hugging the almost as sickly or it's the oft commented over valued acquisition where the inbound company (and their advisors) run towards the hills rubbing both hands as soon as their vesting period is done.

One of the problems with acquisition of technology is that most companies in the EU and the US are utterly clueless as to how to do due diligence. The financial due diligence and the locking down of commercially sensitive news and key figures takes precedence. The concept of code escrow or sanity checking of code and process is hardly ever adhered to, often there "isn't time". Sadly for Juniper (and other companies) this has cost them because as well as acquiring brand and market share and position they also acquired a lot of accidentally naive processes and a company who had gone to market delivering great value and promise that wasn't reflected in the methodology in engineering.

In October 2003 Netscreen acquired Neoteris to bolt on a lot of strength and focus around their SSL products, four months later Juniper acquired Netscreen. So you have a company, Netscreen who can't have onboarded Neoteris and their processes and engineering in key SSL processes by the time they are then acquired by Juniper. Then you have Juniper trusting the product specialists at Netscreen where there is already confusion and poor co-working on SSL engineering taking ownership of core PKI stuff.

Dumb decisions around key management and key generation, cipher strength and release engineering result because nobody at an engineering level is understanding the core skills and risks around how you onboard or do sanitisation of code and QE process. This is allowed to fester and results in a car crash that will eventually happen down the line - it was just a question of when.

Juniper aren't alone, and they're a great company. I could name six major companies all trading in the US and Israel five of them on NASDAQ, all six providing goods and services to US Gov and major government accounts where this lack of intrinsic technical and process management is compressed into forked Linux based appliances and where M&A mistakes and loss of key staff who have gone, once vested, over the horizon to do their next startup without back filling or competency checking. Worse there are two of them where GPL v3 code has been backported to GPL v2 to get around licencing issues that are generating cataclysmic future security issues which when you add to the dumb mistakes made in M&A process make you just want to bang your head on a desk.

Do I think the NSA went after Juniper ? No. Genuinely they aren't that silly, the NSA is run and managed by bright folk who are there for a reason. Do I think the NSA / GCHQ in the UK knew about the vulnerability ? Sure, I hope so, they hire the brightest and the best for a reason.

Enough poor security journalism, look at the underlying facts nobody wants to talk about - onboarding and QE failed and some engineering release managers probably held to ransom by sales guys rushed stuff out to hit a revenue cycle. It was going to happen it was just when.

Two years ago I sat in an auditorium and watched an enraged  Mikko Hypponen of F-Secure on stage at LinuxCon Edinburgh talking with passion about the double standards of the intelligence communities dealing with their stance on encryption. He was beyond furious at the methodologies and underhand ways that the US and UK intelligence services had burrowed into undersea cables and broken into communications at many of the technology and internet companies that we take for granted daily, with impunity.

Now heres the thing. I am the only member of the open source community - in the entire world, who has gone on the record on tape with somebody from the White House to ask them, openly, about their stance on post Snowden world for handling things like Heartbleed, like encryption and their relationship with industry and inter agency and inter ministerial responsibilities when handling security issues. I interviewed Richard Clarke now former Senior Cybersecurity Advisor to POTUS and former senior security advisor to four previous Presidents of the United States, the week of Heartbleed and he volunteered information that I never even asked for in a candid interview on my radio show (still available on Stitcher by clicking here).

So imagine my surprise this morning when I sit up in bed and read an article on the BBC news portal with Rob Wainwright from Europol who is complaining about the stance that technology companies are now having to endpoint security, to key management and to proper end to end, in transit encryption of data in the cloud. The point Europol make is that by the proper management of SSL traffic and the more intelligent use of encryption in AMQP and other protocols it makes it harder for the intelligence services to listen to potential terrorist traffic.

Now I have to be very circumspect and proper here in how I write this article to avoid arrest. I have signed the Official Secrets Act. I have worked within GCHQ. I have been involved with the design and implementation of secure communications and encryption endpoints to Top Secret and above. I do know where the bodies are buried with regard to the weak and lax vendor acquired devices that have formed the basis of government, agency and defence spending for the last seven years.

The fact that the current and former UK governments (and their US counterparts) alongside many industry partners across multiple verticals buying the same kit have overpaid for  weak industry acquirable catalogue standard run of the mill technology. Badly written, badly managed by their vendors (for once not the governments fault) and walked blindly down alleys. This has allowed accreditors with weak understanding of cipher management and underlying dependent libraries, binaries and protocols have allowed literally hundreds of millions of pounds to have been spent on devices with less security certification than an iPhone6. These devices sit in frontline daily use today across the EU and the US. It's farcical that many governments have approved catalogues where they have approved vendor lists for devices, many of which are so badly broken and so compromised in their design and implementation that the poor accreditor or purchasing manager armed with a requirement,  an accredited service catalogue is therefore buying an outdated inferior product for four times the cost of building it properly using current shipping available code. There is NO liason, co-operation, upstream engagement, engineering or security engagement between these vendors and their outdated OS source. None. At all. Can I make this any clearer. The people shipping the boxes running the embedded Linux that powers and protects our end points reliant on nation state security DO NOT talk to the people releasing and developing it. If you were not scared before you have every right to be now. I've got the actual sources (from the vendors with their consent under GPL compliance) of a few of these devices numbering the tens of thousands in their deployment and it's beyond scary. If you were to go back in time via Distrowatch to January 2009 you would see more current, more valid sources to base your security on.

It's terrifying, if not vaguely criminal, certainly deeply unethical, that these vendors have been allowed to make hay while the sun shone, and have not engaged with the upstream OS vendor, the SSL community nor had the brains to understand the downstream implication to their government customers and have now put at risk the entire infrastructure and emergency response capability of their customers reliant on their devices.

Even when warned in writing those government agencies and accreditors because they are hamstrung by weak upstream advice on SSL and encryption ciphers and key material, through ambivalence, have instead walked hand in hand into one of the biggest potential security nightmares they can imagine. Worse there is nothing today they can do other than rip it out and start again across UK, US, EU and many member state governments whose assumptions around encryption at the core of many services is broken.

If Europol are serious then it's time they worked upstream to secure the devices that have formed the basis of the planning and infrastructure of their government partners. Instead of moaning about not being able to watch us, they should actually be asking, who is watching us ?

You can't have it both ways. We react as an industry because we form best practices. The eyes of the community are on Open-SSL to race to make sure that the fixes that have come out since Heartbleed (I was the first person to get the Heartbleed story to ZDNet the night it broke) are stringent. The fixes that have come out in three tranches since October to further harden basic function calls reinforce that. Expect to see more in the coming weeks and months as further scrutiny is poured on older functions and calls. As the implementation of PKI across Cloud and across telecommunication products and services is hardened to enforce customer security and reduce risk of man in the middle attacks and the likely attack on weak endpoints then it reduces the attack vectors and the threat fabric.

In the Open Source community we are entirely open, practical and totally enshrined on ensuring that we release early and release often and that we work stoically to get patches out to protect people reliant on secure auditable code. We don't always get it right but it's therefore even more shocking how badly many companies who then take that code to build devices forget why and where and how it came to be. Thats especially true of many supplying sensitive areas of the target market where the threat fabric is larger and the attack vector surprisingly large.

Expect the bad guys to go after the soft targets, if you're an Android user then security through obscurity, e.g throw out your phone and tablet every seven or eight months and replace them given your vendor is probably clueless (unless its Google or Samsung), if you're an Apple user you can sleep easy as long as you don't use a myriad of apps any one of them that could be handling a listening function to a service harvesting your information or device credentials.

We aren't reacting, as an industry, to lock out police and intelligence services, to state that is beyond stupid. We are reacting to protect ourselves and our customers because of the ham handed, without recourse manner that GCHQ and the NSA and other government agencies have behaved and now we're locking down upstream and mainstream services to assure companies and individuals that they do have the security they always assumed they have.

What Europol should be doing, if they understood how to engage - which clearly they don't, would be sitting down to work with us to understand how and why and where and to foster better working practices. Until that day happens then its back to the old days of seizure of devices only now the issue is that they can't read, open or interpret them, even under warrant, even with industry partners or complex rootkits.

Sadly, gloss will be painted over the fact that the technology that they've acquired themselves is so 1998 in it's design and implementation that as I pointed out it should be more worrying as to who is watching them, and more focus should be spent on fixing that in the short term. Only issue they have there is that the vendors can't help them as the vendors have only one focus, revenue. The vendors themselves don't talk to the OS vendor. How do I know this ? My phone hasn't rung and we've never spoken to them. They're too busy making money from shoddy reimplemented badly coded, badly repackaged outdated insecure code selling it to governments who accredit it secure.

This is fixable. Issue is that the right people don't sit down to fix it or to emerge from the tunnel into daylight able to even understand the core problems. They're too busy making blanket procurement decisions to buy the wrong kit from the wrong people. I'd be more worried about your own infrastructure decisions than technology companies doing their job right to circle the wagons and lock you out.

Now for those who question my authority to make these claims remember it was my security invention that protects and ensures the online safety of millions of people every single day globally, from school children across the UK and US school districts to retail businesses, hotels and motorway service stations and the myriad of devices and platforms that took their lead from our sources. For fifteen years I've made a career out of keeping people safe and doing it openly and trying to do the best I possibly can to get people to play nicely. It would be nice if someone listened and sat round a table and did something practical.

Who wants to bet nothing changes ?


Early this morning I recorded remotely with Mark Cox Director of Product Security Engineering at Red Hat and one of the founders of the OpenSSL Foundation talking about the latest OpenSSL vulnerability. Listen in to find out what it means for you, the real actual picture of what it means for the industry and a proper picture of risk and mitigation.

I broke the Heartbleed SSL story to the world so this time I thought we'd do it properly and have something you could listen in to.

Click the link below to listen in or subscribe to my iTunes show,

 Download the podcast in MP3 format here - or alternatively browse the RSS.