In the Internet of Things, where almost everything is connected to the Internet, security risks lurk behind every corner. I wonder how secure the imp is. Would you recommend it to control a nuclear facility (probably not), a flood gate (probably not), a home automation system or a garage door opener (several people are doing this already)?
I know the imp uses SSL, but even SSL has its limits, and what about WiFi snooping, man-in-the-middle attacks, or attacks on electric imp’s servers, to name a few. Just curious to know what is the level of security build into this product. With closed-source hardware and software it’s always a bit of a risk to just assume it will be ok…
SSL does have its limits, but WiFi snooping and man-in-the-middle attacks are well within those limits. All the traffic is encrypted and hence unsnoopable, imps won’t connect to a server that don’t have our digital certificate, and servers won’t respond to imps that don’t have another digital certificate. Of your threat models, that only leaves someone obtaining control of our servers; if such a thing happened we have ways of retaking control, and anyway that’s sort-of the security deal anyone makes with any use of cloud-based services. You are in a lot of trouble if somebody pwns Google.
Peter
Well, you have the case where someone gets a hold of a URL for one of your IMPs inputs or http handlers.
Then they could send commands all they want. Since the inputs don’t use SSL (right?) then that is an attack vector, right?
The inputs also use SSL, the agent url is https://agent.electricimp.com/xxxx
Still it’s up to the app developer, or the third-party web service that connects to the imp, to implement security. Anyone obtaining an agent’s url could possibly gain control over hardware connected to an imp, so implementing a secret key, or even a challenge-response system, is essential in creating a secure remote control imp application. The agent’s url alone is not strong enough.
You do have to obtain the agent URL though. Big numbers are not easily guessable, and the URLs can’t be snooped as they are sent TLS encrypted when you use HTTPS.
It’s very easy to implement a simple HTTP header-based magic number in an agent which would mitigate that risk, too.
If one were paranoid… You could use a magic number as part of the agent URL that changes daily? Is that what you recommend? A simple algorithm that changes the HTTP header-based magic number.
Otherwise once a hacker gains an agent URL using Social Engineering, they’re in for life. We can’t change the URL?
It should probably be said that, at present, agents are accessible over insecure HTTP as well as over HTTPS. This is widely regarded as a bug: we intend that in a future release, agents will reject incoming HTTP by default, and those few who want it will need to opt in (probably by a new parameter to http.onrequest).
Peter
Aside from a “magic number”, implementing HTTP Basic Access Authentication and requiring a username and password for every HTTP message sent to the Agent is pretty trivial. (See Wikipedia) Over HTTP it’s pretty useless but as long as all your clients use HTTPS it seems like a decent solution…
For a secure implementation it is essential for all content loaded by a webpage or app to be server over HTTPS. This includes javascript or images loaded from third-party source, for example jQuery libraries or icon images from third parties. In many real-world applications this is not the case. It requires some effort from the application developer to implement a truly secure application.
See also: https://www.eff.org/https-everywhere/deploying-https
Peter,
I observe that plain HTTP is still usable to access agent…any idea on timeline to implement change to HTTPS only ?
Phil
You can enforce https only in your agent easily; some customers still rely on http. There are threads on this - I am on my phone and hence can’t tell you the header to check for right now.
Here’s the code I was looking for, to reject not HTTPS connections to an agent:
http.onrequest(function(request,res){ if (request.headers["x-forwarded-proto"] != "https") { res.send(401, "Insecure access forbidden"); return; } …other handler code here… }
For future reference, this code has been added to a note in the the Dev Center’s Troubleshooting section.
I don’t think SSL certificates really get you much. While I can’t personally read your SSL communication — there are people that can. No, they can’t break the encryption (or, probably anyway, see Logjam); but they can pretend to be an endpoint they are not. See, your browser trusts hundreds of CAs always, and forever, unconditionally (so does the Imp, I’m sure). Most of the CAs are trustworthy, but many are bumbling incompetents, and some are literally corrupt (e.g., every country has a top level CA… are you cool with the US reading your comms? How about Ireland? Poland?) – and post Heartbleed, I think it’s safe to assume some of the CA certs are in the wild.
Occasionally they revoke a top level CA, but until very recently, nobody really checked the revocation lists. Does the Imp? I highly doubt it. Even if the CRLs are checked, they’re not ever going to revoke some top level CAs even if they deserve it. Little ones? It happens. Big ones? best to sweep that under the rug. For that matter… my CA certificate list on my PC is 1.2megs. Did they put that on the Imp?
In short: don’t rely on X509 certificates for your security. You better use something on top of that if security is important to you. It’s possible the Imps ship with a blessed certificate for talking to the agents. I don’t really know how to check or where that’d be covered. That’d be something at least – as long as the secret key from the agent cloud never gets loose.
FWIW the imp does not trust the usual-suspect global certificate authorities – only a specific CA signed by us, whose root certificate is imbued into every imp.
If you don’t trust us (or our appointed representatives, or our cloud-service suppliers, or their appointed representatives, or the governments of the territories in which they operate, or their appointed representatives, etc.) then you could just encrypt your data on some other microprocessor before passing it to the imp (over UART maybe), and then decrypt it back at your headquarters once it’s been sent on by our agent server. The Electric Imp setup still gets you a lot of functionality even if you just use it as a “dumb pipe”.
Peter
I should add of course that we always strive to be worthy of your trust. But not trusting any more organisations than you have to, is simple good security practice. Indeed in certain applications subject to rigid security rules (HIPAA?, PCI DSS?) you might find yourself legally or contractually obliged to not trust us.
Peter
I have no reason to mistrust Imp,Co. I think one trusted CA on the device is the way to go. The only problem is losing the private key to intruders – normally solved by firmware update or by having used an intermediary key. I’ll assume it’s sorted.
If it matters, I wasn’t personally worried about the security, I was only taking the time to rant about X509 problems that don’t seem to be widely known (you know: the padlock makes you safe). SSL is basically just Diffie-Helman, which is perfect if you have enough bits, but you can’t know who you’re talking to. X509 is the answer to that, but it wasn’t really well thought out. It works (worked?), but the trusted CA model is broken.