Let’s stop punishing IoT devices that embrace HTTPS(neosmart.net)
neosmart.net
Let’s stop punishing IoT devices that embrace HTTPS
https://neosmart.net/blog/2017/lets-stop-punishing-iot-devices-that-embrace-https-shall-we/
19 comments
Are you suggesting this change merely for users navigating to IP addresses in reserved IP space, or for everything?
If it's the latter, all that stands between an active MitM and my paypal.com credentials is a non-blocking "Not Secure" indicator in the address bar. That's not really acceptable.
If it's the latter, all that stands between an active MitM and my paypal.com credentials is a non-blocking "Not Secure" indicator in the address bar. That's not really acceptable.
I just feel like separating the concerns of
1) Identity of the server
2) If the connection to the server is encrypted or not
would be a good idea in modern browsers. Because the article is completely correct, everything as it is right now essentially disincentives anyone producing IoT or any other kinds of consumer based lan devices from using https.
1) Identity of the server
2) If the connection to the server is encrypted or not
would be a good idea in modern browsers. Because the article is completely correct, everything as it is right now essentially disincentives anyone producing IoT or any other kinds of consumer based lan devices from using https.
So what is the Neosmart solution?
If I can request an SSL cert for a private IP address, how does the CA verify it? Even if they do verify it, what prevents me from using it for malicious purposes on other networks (MITM https://192.168.0.1 with a valid cert or similar)?
For enterprises you can run your own CA, push out the trusted root with Group Policy (or equivalent), so it's not a issue there.
IoT vendors should definitely use HTTPS, but document how to generate a self-signed cert (or generate a request) from their own proprietary interface and how to install it. This would fix the problem.
If I can request an SSL cert for a private IP address, how does the CA verify it? Even if they do verify it, what prevents me from using it for malicious purposes on other networks (MITM https://192.168.0.1 with a valid cert or similar)?
For enterprises you can run your own CA, push out the trusted root with Group Policy (or equivalent), so it's not a issue there.
IoT vendors should definitely use HTTPS, but document how to generate a self-signed cert (or generate a request) from their own proprietary interface and how to install it. This would fix the problem.
Not the author, but I think the proposal would be for browsers to not display scary warning pages HTTPS requests using self-signed certificates where the hostname is an RFC1918 IP address.
The argument is that self-signed certificates on internal-only IPs aren't any less secure than plain HTTP.
The argument is that self-signed certificates on internal-only IPs aren't any less secure than plain HTTP.
>Not the author, but I think the proposal would be for browsers to not display scary warning pages HTTPS requests using self-signed certificates where the hostname is an RFC1918 IP address.
In this case he makes no reference to hostnames, but short hostnames (not fully qualified) are a similar case. I believe they should still display a warning, but perhaps adjust the wording. SSL certs are not just useful for validation (domain validation, exstended validation) but also for fingerprinting. Self-signed certs are not a security risk provided you confirm it has the expected fingerprint and/or install it so it appears in browser as validated.
In this case he makes no reference to hostnames, but short hostnames (not fully qualified) are a similar case. I believe they should still display a warning, but perhaps adjust the wording. SSL certs are not just useful for validation (domain validation, exstended validation) but also for fingerprinting. Self-signed certs are not a security risk provided you confirm it has the expected fingerprint and/or install it so it appears in browser as validated.
Chrome already has a flag to allow self signed cert when accessing localhost.
> In fact, the only way workaround for this for a lan-only device that is not internet accessible but still wants security on the intranet is to obtain a certificate for some website https://example.com/ and, after obtaining said certificate, modify its DNS settings so that it points to an internal IP (where a copy of the certificate is installed)
No need to change DNS A/AAAA records, have it point to an internal IP from day one and use ACME's DNS challenge to get the cert. I'll readily admit this doesn't solve the underlying problem though, and you'd presumably end up re-using the same cert on all IoT devices too which isn't ideal (a unique self-signed cert would be much better here!)
No need to change DNS A/AAAA records, have it point to an internal IP from day one and use ACME's DNS challenge to get the cert. I'll readily admit this doesn't solve the underlying problem though, and you'd presumably end up re-using the same cert on all IoT devices too which isn't ideal (a unique self-signed cert would be much better here!)
I would just go with an internal/corporate CA which solves this problem elegantly. It's a widely used solution. You don't even need to power on the CA (ideally a VM) unless you're generating certs.
Also note that this will require internet access for no other reason than performing that DNS request - even if all the actual communication with the device were local.
I wonder if it makes sense to create a new uri scheme for local https access. Something along the lines of locals://<ip>, which would receive different treatment by browsers.
What's the point of using HTTPS on a local network? If you want to expose an IoT device to the internet (assuming you can deal with the NAT barrier), why not use a domain name like for any other server?
> What's the point of using HTTPS on a local network?
The same reason you use HTTPS for anything else. If I can get on your WiFi network and you're using HTTP to access local servers (say your NAS) I can inject resources or capture your traffic.
> If you want to expose an IoT device to the internet (assuming you can deal with the NAT barrier), why not use a domain name like for any other server?
Many people do this, but it requires that your router supports hairpinning/NAT loopback and also that you know the option is there... many consumers and their routers do not.
The same reason you use HTTPS for anything else. If I can get on your WiFi network and you're using HTTP to access local servers (say your NAS) I can inject resources or capture your traffic.
> If you want to expose an IoT device to the internet (assuming you can deal with the NAT barrier), why not use a domain name like for any other server?
Many people do this, but it requires that your router supports hairpinning/NAT loopback and also that you know the option is there... many consumers and their routers do not.
But since anyone can act the same as the IoT device, there's no way to prove that the IP you're connecting to is the same device and not a MITM, other than if you've been to that host and accepted it's key and the system warms you in key changes.
Since it is decidedly not TLS, we should call that protocol something else. HTTPC perhaps then use SSH protocol on the outside with HTTP on the inside. Port 223/TCP.
Since it is decidedly not TLS, we should call that protocol something else. HTTPC perhaps then use SSH protocol on the outside with HTTP on the inside. Port 223/TCP.
This suggestion is very misguided. There is no point in using TLS if you can't authenticate the endpoint. Your encryption is but an illusion at that point.
> There is no point in using TLS if you can't authenticate the endpoint. Your encryption is but an illusion at that point
You're falling for the same false dichotomy browser vendors have fallen for. There are two, disjoint factors: encryption and authentication. HTTPS provides encryption and recognized CAs provide authentication. HTTP provides neither. The encryption is most definitely NOT an illusion, it's real and it's working. But perhaps you meant to say "your security is but an illusion," which is a very different statement.
You're falling for the same false dichotomy browser vendors have fallen for. There are two, disjoint factors: encryption and authentication. HTTPS provides encryption and recognized CAs provide authentication. HTTP provides neither. The encryption is most definitely NOT an illusion, it's real and it's working. But perhaps you meant to say "your security is but an illusion," which is a very different statement.
No. Your communications are not secret. Your channel does not have confidentiality. You are sending the message directly to the adversary.
If anything I would say that a solution would be for browsers to adopt the following changes.
1) Make HTTP plaintext show the warning you currently get with a self signed cert (ie: warning of death)
2) Make HTTPS self-signed show a "not secure" warning in the address bar (currently what happens on HTTP plaintext) with more info available on a click
3) Standard CA signed HTTPS has no changes