Introducing Cloudflare Orbit: A Private Network for IoT Devices
blog.cloudflare.com
blog.cloudflare.com
- The PC security model can't scale to handle 22;
- The IoT builders don't have an update mechanism, and are scared to send bad updates;
- Consumers don't think about applying updates;
That is some serious FUD used by CloudFlare. Each of these have a simple solution:
- More infrastructure;
- Write good updates. This is not impossible, it is simply a matter of cost. NASA needs to write error-free software, and manages to send updates to devices throughout the solar system.[1];
- They wouldn't have to, if your mechanism is good enough;
Moreover, the whole argument is disingenuous. IoT devices are likely to be several orders of magnitude simpler than PC's (Or Mac's or whatever) which are general purpose computing devices as opposed to an IoT devices which is likely single or limited purpose, significantly reducing the complexity in most cases.
This isn't to say the CloudFlare solution is a bad thing per-se, but the way CloudFlare goes about selling it is too easy to shoot down.
This is a double-edged sword. The increased capabilities of my laptop and smartphone (having human-friendly input and output) are what makes upgrading them so easy. The simplicity of a lightbulb, lacking a monitor and keyboard, is what makes updating it relatively difficult for a non-technical person, and this is on top of Cloudflare's fair (IMHO) opinion that consumers also don't even think to update such an apparently simple device.
I agree with you, of course, that IoT security should work better outside of the consumer's hands entirely, but I think Cloudflare has targeted an existing market opportunity fairly well with this announcement.
I have a suspicion though, that any vendor who cares enough to use this new service will also likely be better at security than other IoT vendors anyway. At that level, I can't criticise such a defense-in-depth approach, but if Cloudflare ever stops operating, it won't be pretty.
I see your overall point and don't disagree. However, most IoT devices will have some kind of UI, in the form of a smartphone app or other kind remote access - think routers, WiFI AP's (not IoT per-se, but devices without keyboard/mouse) or recently there was some brouhaha over garage door openers, I believe. The App/Webpage is a clear route to notify users, and manage the upgrade process. I believe it is possible, and doable, but will cost money. And until we are going to start seeing some serious attacks with real day-to-day impact, IoT makers will remain unmoved to invest in this process. I believe that CF fuels insecurity in the medium to long term by removing further incentives for the makers to invest in secure practices.
I believe that CF is aware of this, hence their marketing message appears to be "it's too hard, don't bother, we'll take care of it"
There is no need to rely on closed source third party services and the security model is very robust.
It also relies on running a Tor node, which means having your internet connection and IP address act as a gateway for random network traffic from around the world. No thank you.
And you think this will scale to billions of IoT devices? Somebody has to run the relays. And then you end up with the same situation.
But if Tor loses its "the network for drugs and CP" reputation and instead becomes the "network for lightbulbs and toasters", this might change.
What is the exit strategy for a Cloudflare Orbit-using vendor? If said vendor has shipped a million IoT devices which all answer only to Cloudflare-proxied requests, what do I do if Cloudflare suddenly ceases operations one day? These devices aren't likely to all be in the hands of technical end users. Even with a short notice, it could be difficult to update all the devices in time.
Of course the vendor themselves may be far more likely to go out of business than Cloudflare, but in such a case there won't be any further device updates to worry about. This on the other hand adds yet another point of failure in to the mix.
I can't help but feel that if I was a vendor with a bit of extra money to throw at security, I should throw it at ensuring better practices on my end rather than a service.
Then I can add my own non-cloudflare certificate to the list and then move off cloudflare and remove their cert.
That should work pretty well right there.
Instead they should build updates into the OS and have the proper infrastructure for it. May be Google's new OS Fuscia, is he way to go. I don't know much about it.
What we need is a gateway/proxy solution where IoT devices can be configured to only connect to our gateway, or optionally, a gateway hosted by the manufacturer or a 3rd party like Cloudflare. Then we can apply updates as we choose, control PII and spying, and change our devices without the manufacturers approval.
As an aside: Orbit branding should be a circle around IoT; both a barrier and a literal orbit, and it would be written as (IoT)
None of those things require CDN.
Doing your own SSL termination is not hard. And HTTP 2.0 almost let’s you get away without it.
I wasn't implying you required a CDN to address those points. The issue the GP raised was about "a single company proxying a significant amount of internet's traffic" which is a much larger topic than with regards to CDN alone.
However to address your point specifically, many of the larger players in the CDN market do tout the features I discussed as a key reason to use their infrastructure. Which makes a lot of sense because if you are going use a proxying CDN like Akamai, CloudFlare or CloudFront then you would expect some level of DDoS mitigation, geolocated nodes, and, most importantly, offloading.
> Doing your own SSL termination is not hard. And HTTP 2.0 almost let’s you get away without it.
SSL termination is completely irrelevant to the points myself and the GP raised. While some low traffic blog sites might use (for example) CloudFlare for their free SSL termination (less of an issue these days with the likes of LetsEncrypt) it's fair to say that the vast majority of CDN-proxied traffic is behind a CDN for reasons other than obtaining a free SSL certificate - reasons such as those I described above. Source: my experience delivering a multitude of high profile, high traffic sites (eg 100,000+ concurrent users) for a variety of different clients.
Anyway my point was you can get all those features without involving heavy L7 multitenant MITMaaS. I stand by it.
> Which makes a lot of sense because if you are going use a proxying CDN
Yes, but is proxying CDN the most optimal solution if you need those features. Isn’t that the relevant question.
That really depends on your infrastructure and how it copes with load. Latency can be introduced in so many different areas. While some parts of the stack might operate at a much lower latency, they can quickly cause far more significant bottlenecks once throughput is increased - even just marginally. This is why load testing is so important - it's easy to make generalised statements but it's even easier to overlook something or poorly tune one of the numerous ratios one defines in a typical complex stack.
> Anyway my point was you can get all those features without involving heavy L7 multitenant MITMaaS. I stand by it.
It's an irrelevant point because the discussion was never about whether it was possible or not to do the above.
> Yes, but is proxying CDN the most optimal solution if you need those features. Isn’t that the relevant question.
* It's cheaper than rolling your own solution,
* It's quicker than rolling your own solution,
* And it's easier to maintain than rolling your own solution.
Plus, frankly, most companies don't have the infrastructure talent to build solutions that could compete with the uptimes, throughput and latency that they would get from Akamai, Cloudflare or AWS.
So basically "yes"; in a great many cases a proxying CDN is the most optimal solution for the same reasons why writing backend web code in higher level languages is optimal than writing them in C or assembly.
They seem to be focusing on updating patch levels, but again, completely unclear on what value they're adding.
John, their CTO is the OP, so John can you shed some light on the technical aspects of what you folks announced today? The threads and responses you've received here make it clear that questions abound.
Cloudflare is running a firewall in thousands of nodes in over 100 data centers. As requests are proxied through Cloudflare to the devices, Cloudflare inspects the request and checks them against a list of known attack requests. Orbit customers can additionally create custom rules to detect and filter traffic based on any traffic pattern. When rules are added, they take less than 30 seconds to propagate to all data centers, and then will protect traffic to all devices.
In IoT, attackers use things like Shodan or their own scans to find targets and then target based on target IP, directly. So CF don't have the opportunity to inject themselves in between attacker and victim.
Unless they're cutting deals with ISPs to transparently proxy traffic.
But the whole point here is we're left guessing. The announcement is a drawing of an IoT device with a Cloudflare ring around it. I guess I'm just a bit curious what that ring actually is. Besides a press release.
I have no clue what CloudFlare is offering with this announcement.
Can a CF person please explain?
One way to secure IoT from DDoS etc is that is relatively painless for manufactures and more importantly actually effective, would be to adopt the best of what already works on mobile:
Hypervisor/Microkernel that offers network driver that can enforce any network rules for user-supplied payload that does everything else. Basically have a trusted base that can handle security & brick-safe updates.
See: https://en.wikipedia.org/wiki/Open_Kernel_Labs (no affiliation)
If so, are they powerful enough to now connect to VPNs and encrypt all their traffic in an efficient manner?
Builder: Just hire security guards until you sell the house.
But my point was that the builder should just build houses without any holes (pun intended) in them in the first place.