4 ms·

I am all for secure connections but I do lots of work with apps that run local webservers (inside your home network). AFAICT there's no way to make that non-tec

I am all for secure connections but I do lots of work with apps that run local webservers (inside your home network). AFAICT there's no way to make that non-techie friendly secure. The only non-techie friendly solution I know of is the Plex solution but the Plex solution costs $$$$$$$ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-... You can also think of this as an issue for any IoT device that wants to serve a webpage. Let's Encrypt doesn't cover this use case because it only provides certs for domains so every IoT device would need it's own domain or subdomain and that domain would need to be blessed in the list of domains that Let's Encrypt doesn't put limits on certs since you need a cert per device. Some company making a product (for example Plex) can pay to run the dynamic DNS and partner with a CA but at the moment there is no free and easy way for some open source project to this. I wish I knew how to make it happen. Get a giant grant like Let's Encrypt got or something to enable a solution. I'd love all my projects running local servers to be able to use HTTPS but at the moment it's way too painful.

Sephr 8y ago
The solution is for Let's Encrypt or a similar CA to start issuing certificates for direct IP addresses.
- parliament32 8y ago
  The parent was talking about a device on a home network, I definitely do not want a CA issuing a trusted cert for 192.168.0.1
  - Sephr 8y ago
    Obviously I'm only referring to public IP addresses. Let's Encrypt can't attest anything about local IPs.
    - parliament32 8y ago
      Which is a good idea, until we remember that most residential "local" networks have dynamic IPs. Honestly the best way to deal with this is to have a dynamic dns record pointing to a (sub)domain you own, then get a cert through that.
Ajedi32 8y ago
I actually just started using Let's Encrypt to issue certificates for web services (router config pages, Firewall, NAS server) on my local network. You _do_ need your own domain and DNS server so unfortunately it isn't free, but it _is_ definitely doable. Basically I just setup [acme-dns][1] on a VPS, pointed the relevant _acme-challenge domains at that server via a CNAME entry, and gave each device on my LAN an account on the acme-dns server so they can fulfill challenges at will. Unfortunately as you said that's probably a little too complex for the average user, not to mention domains and VPSes aren't free. Probably wouldn't be too expensive to offer as a service of some kind though; I'm only spending $3.50/month total, and I'm sure my VPS could handle _much_ more traffic than it currently does just fulfilling acme challenges for my LAN. [1]: https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns
- xg15 8y ago
  It's good that there is at least a way to do it, but it's still absurd that showing a page from a server in a LAN on a browser in the same LAN now requires third-party services on the internet and incurs running costs. (* yes, you could simply tolerate the insecurity warning if you're ok with not using more recent JS/CSS features. I imagine though the warnings will become more obnoxious and the amount of features you can't use will grow.) (* yes, you can install your own root CA cert. For admin pages, this is even a reasonable thing to do - however, you'll need to do it on any machine that is expected to open your page. So say goodbye to raspberry pi media experiments or kiosk systems.)
  - Ajedi32 8y ago
    The problem is that the address associated with a publicly trusted cert _has_ to be universal. We can't give users certificates for `https://192.168.1.1/` https://192.168.1.1/` or `https://my-router.local/` https://my-router.local/`, because then attackers could get certs for those names as well, which would defeat the whole purpose of HTTPS. DNS is well suited for allocating unique, memorable names to devices, but, as you said, it _does_ rely on third party services (registrars, at the very least) to operate. If we don't want to rely on third party services, we'll need to come up with an alternative to DNS that accomplishes the same goals.
notatoad 8y ago
I'd also like to find a solution for this. Part of me wants to say that the solution is to just accept that it's not secure and the warning is valid, and services only available behind my firewall don't need to be accessed over https. but that doesn't help when browser vendors are also making new features only available on secure origins. How are you supposed to build a serviceworker to run on your local server when serviceworker only runs on secure origins and there's no way to secure a local origin?
zeta0134 8y ago
You know, this has always bothered me to a certain extent. We have self-signed certificates, and we have CA certificates, but couldn't we have an in-between option? Say, a self-signed certificate which suggests to the browser that it could be installed locally. The browser could still displays a warning once, "Warning! We can't determine whether we should trust this site. It claims to be [Such and such local service.] Would you like to trust this site? [Yes, temporarily], [Yes, permanantly (installs local certificate)], [No, get me out of here!] Firefox already does something like this, but its wording is kind of vague, and the strong assumption from browser vendors seems to be CA or bust. The truth is, encryption is useful in some very common cases where a CA or a domain name is simply not feasible, and we need workarounds for those use cases that don't feel like a dirty hack for techies only.
BillinghamJ 8y ago
Does Plex's solution support IPv6? I tried querying some IPv6 addresses in a similar way and it didn't respond with anything, but perhaps I wasn't doing it correctly.
tokyodude 8y ago
I've wondered if there is a startup idea there. SecureIoT.com that provides free certs for free projects and commercial certs for commercial projects? A few cents per device and some good sales people to get IoT companies to sign up for a managed solution? I think the problem is few IoT devices (except maybe IP cameras and NAS) provide a webpage. Most provide an app and that app and device talk to the cloud not the device

Sephr 8y ago

The solution is for Let's Encrypt or a similar CA to start issuing certificates for direct IP addresses.

parliament32 8y ago
The parent was talking about a device on a home network, I definitely do not want a CA issuing a trusted cert for 192.168.0.1
- Sephr 8y ago
  Obviously I'm only referring to public IP addresses. Let's Encrypt can't attest anything about local IPs.
  - parliament32 8y ago
    Which is a good idea, until we remember that most residential "local" networks have dynamic IPs. Honestly the best way to deal with this is to have a dynamic dns record pointing to a (sub)domain you own, then get a cert through that.

Ajedi32 8y ago

I actually just started using Let's Encrypt to issue certificates for web services (router config pages, Firewall, NAS server) on my local network. You _do_ need your own domain and DNS server so unfortunately it isn't free, but it _is_ definitely doable. Basically I just setup [acme-dns][1] on a VPS, pointed the relevant _acme-challenge domains at that server via a CNAME entry, and gave each device on my LAN an account on the acme-dns server so they can fulfill challenges at will. Unfortunately as you said that's probably a little too complex for the average user, not to mention domains and VPSes aren't free. Probably wouldn't be too expensive to offer as a service of some kind though; I'm only spending $3.50/month total, and I'm sure my VPS could handle _much_ more traffic than it currently does just fulfilling acme challenges for my LAN. [1]: https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns

xg15 8y ago
It's good that there is at least a way to do it, but it's still absurd that showing a page from a server in a LAN on a browser in the same LAN now requires third-party services on the internet and incurs running costs. (* yes, you could simply tolerate the insecurity warning if you're ok with not using more recent JS/CSS features. I imagine though the warnings will become more obnoxious and the amount of features you can't use will grow.) (* yes, you can install your own root CA cert. For admin pages, this is even a reasonable thing to do - however, you'll need to do it on any machine that is expected to open your page. So say goodbye to raspberry pi media experiments or kiosk systems.)
- Ajedi32 8y ago
  The problem is that the address associated with a publicly trusted cert _has_ to be universal. We can't give users certificates for `https://192.168.1.1/` https://192.168.1.1/` or `https://my-router.local/` https://my-router.local/`, because then attackers could get certs for those names as well, which would defeat the whole purpose of HTTPS. DNS is well suited for allocating unique, memorable names to devices, but, as you said, it _does_ rely on third party services (registrars, at the very least) to operate. If we don't want to rely on third party services, we'll need to come up with an alternative to DNS that accomplishes the same goals.

notatoad 8y ago

I'd also like to find a solution for this. Part of me wants to say that the solution is to just accept that it's not secure and the warning is valid, and services only available behind my firewall don't need to be accessed over https. but that doesn't help when browser vendors are also making new features only available on secure origins. How are you supposed to build a serviceworker to run on your local server when serviceworker only runs on secure origins and there's no way to secure a local origin?

zeta0134 8y ago

You know, this has always bothered me to a certain extent. We have self-signed certificates, and we have CA certificates, but couldn't we have an in-between option? Say, a self-signed certificate which suggests to the browser that it could be installed locally. The browser could still displays a warning once, "Warning! We can't determine whether we should trust this site. It claims to be [Such and such local service.] Would you like to trust this site? [Yes, temporarily], [Yes, permanantly (installs local certificate)], [No, get me out of here!] Firefox already does something like this, but its wording is kind of vague, and the strong assumption from browser vendors seems to be CA or bust. The truth is, encryption is useful in some very common cases where a CA or a domain name is simply not feasible, and we need workarounds for those use cases that don't feel like a dirty hack for techies only.

BillinghamJ 8y ago

Does Plex's solution support IPv6? I tried querying some IPv6 addresses in a similar way and it didn't respond with anything, but perhaps I wasn't doing it correctly.

tokyodude 8y ago

I've wondered if there is a startup idea there. SecureIoT.com that provides free certs for free projects and commercial certs for commercial projects? A few cents per device and some good sales people to get IoT companies to sign up for a managed solution? I think the problem is few IoT devices (except maybe IP cameras and NAS) provide a webpage. Most provide an app and that app and device talk to the cloud not the device