
Let’s stop punishing IoT devices that embrace HTTPS - scarhill
https://neosmart.net/blog/2017/lets-stop-punishing-iot-devices-that-embrace-https-shall-we/
======
moo360
Completely agree with the author of the article. Would love to run https by
default for lan without having to require users to install my custom CA cert.
I don't really understand why self signed certs can't be allowed in browsers
and the browser just notify the user that the website identity can't be
verified while the actual communication between the two is still encrypted.

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

~~~
pfg
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.

~~~
moo360
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.

------
DKnoll
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](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.

~~~
scarhill
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.

~~~
DKnoll
>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.

------
lol768
> 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/](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!)

~~~
DKnoll
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.

~~~
wmf
I don't think an internal CA would solve the problem for consumer IoT devices.

~~~
DKnoll
Neither would the solution in quoted in the parent.

------
joshdev
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.

------
ciconia
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?

~~~
DKnoll
> 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.

~~~
rkeene2
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.

------
lawnchair_larry
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.

~~~
ComputerGuru
> 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.

~~~
lawnchair_larry
No. Your communications are not secret. Your channel does not have
confidentiality. _You are sending the message directly to the adversary_.

