I am not sure I agree with CF's example of why security for the IoT is too difficult. They claim:
- 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.
"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 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.
The simplicity of a lightbulb, lacking a monitor and keyboard, is what makes updating it relatively difficult for a non-technical person
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.
I thought the only problem was with exit nodes? If you have both the client and the server within the tor network, doesn't that make things because then everything is always encrypted?
The problem here is bandwidth - people on capped internet plans won't want to participate in the tor network traffic by running a relay on their IoT devices.
I think the real problem is the questionable legality of relaying Tor traffic. At least for exit nodes visits by LEAs happen somewhat regularly. Depending on your jurisdiction you can also get in real trouble (as opposed to having all your computers confiscated and returned when the law is through with them)...
But if Tor loses its "the network for drugs and CP" reputation and instead becomes the "network for lightbulbs and toasters", this might change.
I am an avid Cloudflare user who of course maintains an exit strategy in case I need to stop using their service for any reason. On the web, this isn't a big deal - I can switch DNS and reconfigure my web server with relative ease, and others can do likewise. Web servers tend to be maintained by people who know what they're doing.
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.
The typical solution would be to have a longer-term contract. I don't think Jeep in the example is going month to month; for something like this I'd expect a large enterprise to be looking at years-long contracts (around the lifetime of the product in question, actually).
I don't get the development model. The IoT devices have to route all their traffic through CF network, that means existing devices cannot make use of this. If this is for new devices then it's a terrible model for security. It's like telling companies that you don't have to fix the leak in the dam you just evacuate every person in the flood path. This is also going to create a false impression of security and companies are not incentivized to do proper security engineering. Companies would claim this as security.
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.
This solution is all manufacturer and no end-user. We are responsible because we OWN the devices.
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)
While I agree with your sentiment in theory, CloudFlare are far from being the only company that handles a significant amount of internet traffic and pragmatically there will always be a need for such organisations to exist. eg if you want DDoS protection, or geolocated content delivery end points, or the ability to scale traffic cost effectively should your content go viral. Heck, even without discussing cloud services you still have privately owned backbones to the internet that can cause mayhem when they experience disruptions to service.
> eg if you want DDoS protection, or geolocated content delivery end points, or the ability to scale traffic cost effectively should your content go viral
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.
SSL termination is the most latency sensitive thing in the stack, I wasn’t talking about provisioning. With HTTP 2.0 you get to reuse the connection, so it’s not as critical.
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.
> SSL termination is the most latency sensitive thing in the stack
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.
There are no other companies that match the functionality and price combination that Cloudflare provides. For most businesses, it's a better value regardless of centralization. It's unfortunate there isn't stronger competition even though Cloudflare continues to innovate.
This is clear as mud. To solve IoT security you'd have to create a firewall to protect IoT devices from attacks. Is Cloudflare doing that? If so, how is it implemented?
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.
^ yes, exactly. Most IoT security solutions focus on the security of the device itself today, but when a device isn't patched, that security model breaks down.
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.
I don't think so. You're describing a WAF for IOT devices. Their WAF is for websites. Websites are accessed using a domain. You point your DNS at CF and that gets them to filter all traffic.
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.
IoT software developer here. I just came out of a meeting regarding future cloud infrastructure for our devices (we have a simple poll-and-pull setup for updates now, but want do address devices from outside the home network).
I have no clue what CloudFlare is offering with this announcement.
I don't buy their notion that IoT security is drastically different from PC security. Every IoT botnet incident I have heard of would have been avoided by placing the devices behind a non-fancy firewall that drops incoming traffic from the public Internet.
Why is "IoT" even a separate thing? What is fundamentally different about small computers vs large computers when it comes to getting them on the Internet?
Small computers are built by companies that used to make light bulbs and toasters and other hardware that you sell and forget about. They try to do the same with software that is connected to the net.
I don't quite get how cloudflare do authentication. Is it just a diffie-hellman key exchange? And CF to generate millions of public-private key pairs like the good old CAs? What happens to devices with extremely limited storage space and computing power? One needs to use something like NaCl for key exchange and encryption afterall right? Can someone shed some light on this area? thanks!
So a 0day goes through this reactive-only security product, promptly reconfigures the device to bypass Cloudflare, ???, profit/DDoS.
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.
- 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.
[1]https://www.fastcompany.com/28121/they-write-right-stuff