21 ms·

I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no w

by simias 6y ago

I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they decide to proceed, or just go with good old HTTP but then you hit all sorts of limitations, and obviously zero security. I wish there was a way to opt into a "TOFU" https mode for these use cases (which is how browser dealt with invalid HTTPS certificates for a long time), although I realize that doing that without compromising the security of the internet at large might be tricky. If somebody has a solution, I'm all ears. As far as I can tell the "solution" employed by many IoT vendors is simply to mandate an internet connection and have you access your own LAN devices through the cloud, which is obviously a privacy nightmare. But it's HTTPS so your browser will display a very reassuring padlock telling you all is fine!

nahuel0x 6y ago
There is a (defunct?) W3C working group about this, see https://www.w3.org/community/httpslocal/ https://www.w3.org/community/httpslocal/ and https://github.com/httpslocal https://github.com/httpslocal
liveoneggs 6y ago
let's encrypt with *.lan.mydomain.com via DNS validation, installed all over where needed, and annoying to update every 90 days because it's in weird/internal/non-standard places :)
- simias 6y ago
  I develop broadcast TV equipments which are often rented all over the place for short amounts of time, often don't have any direct internet access etc... I simply cannot make any assumption about the network these devices will run, and can certainly not rely on any sort of DNS validation. Virtually 100% of the time the devices are addressed directly by IPv4. I really can't think of a solution for this situation. For network you control your solution makes a lot of sense though.
  - londons_explore 6y ago
    DNS validation can entirely be done by a server on the internet, which does all the stuff necessary to get the certificate, and then gives the certificate to your end user device. All the end user device needs is a connection to the internet once per 90 days. The vast majority of networks have sufficient network connectivity for this.
    - scruple 6y ago
      I worked in embedded radios for the broadcast industry and SCADA applications for a spell and dealt with the same problems that the GP is describing. Many of these systems are composed of networks built on top of radio modems. It is very common that these devices can't reach the Internet...
      - rswail 6y ago
        They don't have to reach the internet, they need to reach your infrastructure. Your infrastructure needs to reach the internet.
    - xg15 6y ago
      I think the more frustrating point is that you need all this internet infrastructure (with running costs) at all - even if your device has nothing to do with the internet at all. If the vendor of your dumb device goes out of business, you can just keep using the device until it breaks down. If the vendor of a "smart" device - or now anything with a modern web interface - goes out of business, the device will have a broken UX at best and at worst turns into a brick 90 days later. In the end, browsers are now a platform and you have to register and pay a subscription fee to make use of them.
    - xg15 6y ago
      > All the end user device needs is a connection to the internet once per 90 days. The vast majority of networks have sufficient network connectivity for this. I'm no expert on long-tail use cases, but I'd imagine that most networks either have internet connectivity or they don't. I can't think of many situations where you'd only have internet once every 90 days. Of course one could argue that 90 days long is enough so an employee could go around with a memory stick and manually copy the certificate to every device - which is theoretically possible but sounds like a ridiculous thing to do just to keep a web interface workable. (And even then, you'd somehow need a unique certificate for every device)
- merb 6y ago
  let's encrypt does not like that use case btw. because you would need to validate the cert and store it somewhere and then download it to the specified box, since the service can only be inside an intranet.
  - liveoneggs 6y ago
    What does "does not like" mean in the context of let's encrypt?
boardwaalk 6y ago
It seems like we should have something like known_hosts for ssh, yeah. As long as it’s trusting one domain at a time (not a root CA), would it really be /that/ bad? This and browser vendors being overbearing about extensions (I know they’re powerful) gets me down.
- wjrtyjw 6y ago
  Isn't this the default behavior of most browsers? Access an https service with an untrusted tls certificate, the browser throws a warning and offers a way to permanently trust the certificate.
  - somehnguy 6y ago
    Neither Chrome nor Edge offer a simple way to permanently trust the cert. I’m sure there is a way to do it but they don’t make it obvious. It’s maddening as someone who develops and distributes local network apps with https.
    - gpas 6y ago
      I'm on chromium right now and it does remember my decision to trust self signed cert once I click proceed to unsafe domain the first time. It's not ideal, and it shows an alert to inform the user of the fake certificate, but it works and unlocks the https only APIs on a local offline environment. It's permanent until you switch user profile or click on the alert on the left of the address bar and reenable the warnings for that domain.
    - oarsinsync 6y ago
      Sounds like you're using Windows, and I believe both ultimately outsource that to the OS, so you'd need to look whereever windows manages certificate trust to find and remove any old trusted certs. HTH.
  - WanderPanda 6y ago
    I am actually glad that they don’t permanently trust it like I belief Safari does it. Accepting invalid certificates in Safari always freaks me out
j1elo 6y ago
It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. What happens with offline LAN? And the ideal IoT devices that we would all want to have? (I mean those we dream about in all IoT HN posts, where the rants typically are that no internet connection should be needed for most of these kinds of devices) What about offline tutorials? I'd like to provide a ZIP with a plain HTML tutorial that shows how WebRTC works, but users cannot serve it up in their LAN and access through their laptops or phones, because WebRTC requires HTTPS. What's even worse, a self-signed cert doesn't work either. iOS Safari does NOT work with self-signed certs at all! It's maddening, obstacles everywhere once you don't walk the path "they" (industry leaders, focused on mainstream online web services) want you to follow. EDIT: There are some (lots [0]) of features that require a secure context, i.e. a web page served through HTTPS. So the defaults to HTTP are not a silver bullet, and the security exceptions for localhost are not really that useful either, being limited to the same host. [0]: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
- alecbz 6y ago
  > without recourse Doesn't the post say they'll fall back to http if the https attempt fails? > For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails. The only change here seems like it's that, from the user's perspective, initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower).
  - j1elo 6y ago
    I'm talking about the general state of HTTPS implantation. If you develop an offline device which offers a web UI, and it happens to use any feature that is deemed to require a Secure Context, you're out of luck. WebRTC is such a feature, but there are lots more, and they can change from one version of the browser to the next one. The players who are pushing so hard to shove HTTPS down our throats are simply closing their eyes and ignoring the use cases that are not interesting to them. The mandatory renewal timing is a good example: it used to be more than 1 year, now it is 90 days (and some would like to reduce it to mere weeks!) Absolutely great for the grand scheme of things and global security of the Internet, but dismaying for lots of other use cases.
heavyset_go 6y ago
> https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they decide to proceed, or just go with good old HTTP but then you hit all sorts of limitations, and obviously zero security. If you go the self-signed route, you'll encounter devices that simply won't work with them, especially IoT devices. If you got the HTTP route, you'll still encounter devices that simply won't work with them. For example, you can't cast an HTTP resource from Chrome or Chromium to a Chromecast, even if it exists on your LAN. As long as there are devices that you can't insert your own certificates into their certificate stores, this will be an issue.
dcow 6y ago
It's funny how pushing stringent privacy and security defaults in one domain degrades the privacy and security experience in another domain. My jaded takeaway from the last 5 or so years is that the internet companies (understandably) don't care about non-internet experiences. I empathize with how annoying that reality is because internet technology certainly works locally if you configure everything correctly.. just not how things work by default. The actual problem though is fascinating and there is a ton to unpack. For one, the internet was always supposed to be zero-trust. Security-by-NAT was an accident not a feature. And IPv6 enshrines this reality (and it breaks my heart when I see tech companies trying to make IPv6 work like IPv4 in the home). The privacy problem is not really an issue if everything is appropriately firewalled and communicating securely. And as you mention, half the IoT things out there only use a central server to get around what is ultimately a problem NAT introduced: devices don't have public IPs and aren't 1st class internet citizens. Here's how it's supposed to work: Your ISP delegates you an IPv6 prefix. As the gateway to your home site, your router advertises the public prefix, as well as a ULA prefix to your home devices. Devices construct both permanent and temporary IP addresses from the public and universal local prefixes (at this point a device that needs public internet access has 4 IP addresses). That's just IPv6 so far but the point is that devices have multiple addresses, ones for public communication and ones for local communication. Once you have the setup above you can do this: Your ISP provides you a domain (optionally you purchase your own vanity domain, of course) and their nameservers delegate to your gateway device (or possibly some other one, but conveniently your gateway) as the nameserver for your home site. After a device comes online it dynamically registers its desired hostname with gateway, which will now respond to DNS queries with its address. The gateway should also serve PTR and SRV records for your site unicast DNS-SD style. Your nameserver can serve the public record if the request comes from a public IP and the ULA record if the request comes from that prefix. All public traffic stays public and all local traffic stays local. Since your devices now are publicly routable, they get certs using ACME. If you want to run local ACME on your ULA network, go for it, but you'll continue to run into the original problem that browsers aren't configured to use your local CA by default and getting users to bootstrap that is essentially impossible. In that vein I do wish there was a way to start a browser window for "local" browsing where it only trust one CA (your local one) and thus isn't mixing public and local security domain concerns. If devices don't want to communicate on the public internet because that's a privacy or security concern, then they simply don't provision themselves a public-prefixed address or add a public DNS entry, etc. In short, NAT killed the internet and we're still recovering from it.
franga2000 6y ago
Yeah, there really needs to be a "secure, but not trusted" mode. My suggestion would be add a "trusted-only" TXT DNS entry that a browser could check when presented with an untrusted connection. HTTP: gray broken padlock HTTPS+Cert: green padlock HTTPS+no cert: gray padlock HTTPS+no cert+trusted-only: red broken padlock Any complaints? No? Ok, let's make it a standard! Oh wait... we're not in control of the standard, it's the world's largest cloud hosting, service and product providers. Intranets and locally-accessible embedded devices are a threat to their business model. Fuck.....
- MaxBarraclough 6y ago
  On the face of it, it sounds simple enough: special treatment when the IP address is an IETF-designated private IPv4 address (e.g. 192.168.x.y). Is there some reason this wouldn't work, that I haven't thought of?
  - Wowfunhappy 6y ago
    Whitelisting specific addresses makes me uncomfortable. But I can't actually articulate why it would be bad in this instance, so maybe it's fine...
  - simias 6y ago
    I considered that, but I think at the moment there's no concept of IP address for web certificates, it's all based on domain names as far as I know. It doesn't mean it's not doable of course, but I could understand if it make people uneasy since it means that the same domain and the same certificate would behave differently depending on what it resolves to. It may be an interesting solution to consider though. That would definitely make my life easier.
    - oarsinsync 6y ago
      > there's no concept of IP address for web certificates, it's all based on domain names as far as I know Regardless of whether you can or can't issue a certificate with a CN of an IP address, the browser doesn't receive the certificate in isolation, it receives it from an IP address, and can handle certificate validation differently depending on what it's connected to. This may be a terrible idea for reasons I haven't considered (it probably is), but I can't think of any off head myself right now. EDIT: this is probably terrible because someone can just stick a MITM proxy on your lan, and poison your DNS to resolve google.com to a RFC1918 address and boom.
jiri 6y ago
I agree. Am I right - would it be solved by prefering https for all ip addresses except 10.0.0.0/8, 192.168.0.0/24 and 172.16.0.0/16?
- oarsinsync 6y ago
  > all ip addresses except 10.0.0.0/8, 192.168.0.0/24 and 172.16.0.0/16 I assume you're trying to exclude RFC1918 addressing. As such: > 192.168.0.0/24 This should actually be: 192.168.0.0/16 > 172.16.0.0/16 This should actually be: 172.16.0.0/12 (10.0.0.0/8 was correct)
tony101 6y ago
> "I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they decide to proceed, or just go with good old HTTP but then you hit all sorts of limitations, and obviously zero security." How about what Plex did for its self-hosted media servers? "First they solved the problem of servers not having a domain name or a stable IP (they are mostly reached via bare dynamic IPs or even local IPs) by setting up a dynamic DNS space under plex.direct" "Then they partnered with Digicert to issue a wildcard certificate for *.HASH.plex.direct to each user, where HASH is - I guess - a hash of the user or server name/id." "This way when a server first starts it asks for its wildcard certificate to be issued (which happened almost instantly for me) and then the client, instead of connecting to http://1.2.3.4:32400 http://1.2.3.4:32400, connects to https://1-2-3-4.625d406a00ac415b978ddb368c0d1289.plex.direct:32400 https://1-2-3-4.625d406a00ac415b978ddb368c0d1289.plex.direct... which resolves to the same IP, but with a domain name that matches the certificate that the server (and only that server, because of the hash) holds." 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-...
- vladvasiliu 6y ago
  But this requires the manufacturer of the IoT device to provide a central service like Plex does. Maybe they can't afford it, or the device is expected to run for a very long time, like even after the manufacturer goes out of business. Or as some other commenters have said, it's a personal / hobby project and the "manufacturer" doesn't have the means nor the will to maintain some outside management server.
- simias 6y ago
  That's very cool, but it still requires a working and reliable internet connection. Also these ultra-long URLs are very clumsy and can't really be used directly, so you need to have some sort of cloud frontend that where the device phones home in order to announce its LAN IP, then the user can go through there in order to connect to their LAN devices. For something like Plex it makes a lot of sense since you're probably going to have an internet connection when you use it anyway, but for my devices it's a deal breaker. And at any rate, that's a whole lot of infrastructure just to be able to expose a simple web interface.
davidkhess 6y ago
Here's an approach I've used before successfully. It's not perfect but it's better than nothing. 1. Create your own root Certificate Authority. 2. Create a script using your favorite language and libraries that will create a new certificate for each device something along the lines of "myiotdevice-AABBCCDD.local". The AABBCCDD needs to be some sort of serialized number that's assigned during manufacturing and won't be repeated between devices. 3. Add to your product support for ZeroConf/mDNS/DNS Service Discovery and advertise an https web server at myiotdevice-AABBCCDD.local. 4. Provide instructions to your users on how to download and install the certificate for your root CA (this only needs to be done once). 5. Print the name "myiotdevice-AABBCCDD.local" on the device and instruct users to type that in to a browser's address bar. I'm doing this from memory so I may have missed an intricacy here or there (like DNS SD is a weird story on Windows 10) but this approach should basically work well enough. EDIT - good commentary in replies about the dangers of the CA being compromised. Also, good mention of X.509 Name Constraints and how they can be used to mitigate that danger somewhat. More info here: https://systemoverlord.com/2020/06/14/private-ca-with-x-509-name-constraints.html https://systemoverlord.com/2020/06/14/private-ca-with-x-509-...
- oarsinsync 6y ago
  > 1. Create your own root Certificate Authority. 2. Ensure that the security around your new root CA is watertight, so that if your environment ever gets compromised, someone can't generate a new *.google.com or *.yourbank.com certificate signed by your CA and then MITM your connection.
  - merb 6y ago
    3. use cross signing with name constraints to not have this problem https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10
    - fomine3 6y ago
      Issuing CA cert with Name Constraints is good, but end user should recognize the certificate is constrained to their domains or not.
INTPenis 6y ago
Yeah I came here to say just that. It's really annoying when Firefox is stuck on https for some reason, maybe history? So I have to test if one of my LAN services works with curl. I think it has to do with history so I have to clear all history for that site and then start using it with http and it should work fine. This is only Firefox.
- capitainenemo 6y ago
  Strict-Transport-Security perhaps? My preferred method for testing is a clean profile (firefox -no-remote -P) or just ctrl-shift-p to open private browsing which does not read SiteSecurityServiceState.txt
billpg 6y ago
Browsers would need to be modified, but I wonder if TOR's method of URLs with the public key encoded could be repurposed for devices on a LAN? https://hashhash.lan/ https://hashhash.lan/ (Causes browser to broadcast a message on LAN and wait for a response. Keys are exchanged and if valid, completes connection.) Devices would need to be programmed with a private key at the factory and print out a QR with the encoded hash and stick it somewhere discreet. What's that? The factory is producing devices all with the same private key to save money? This is why we can't have nice things.
danShumway 6y ago
The very partial solution that I've been experimenting with and trying to refine is to "abuse" DNS records and Certbot's DNS tests so that I can have a bunch of public subdomains that point at intranet sites.[0] There's no rule that says you can't point a DNS record at a local IP. This really isn't a full solution though because there are instances where you don't want a public DNS record at all. It's also not particularly plug and play, at least right now. And it requires you to have a static domain name and an Internet connection. It's a step in the right direction, but not perfect, and not usable in every situation. Setting up a custom certificate server and configuring every device is a no-go for me, maybe that works for highly managed networks. I don't trust myself to do it, and even if I did, it's too time consuming and annoying to set up for new devices. At least with my current setup I don't need to transfer any information (other than the DNS lookup) out of my network, and anyone and any device on my network will immediately be able to connect to whatever service I have, and I don't need to worry about accidentally compromising every website I visit. I'm not sure what the better solution would be. I'd also be interested in hearing ideas about this, it's a problem I'm running into as I try to figure out how to get HTTPS encryption on my local projects. And I do want HTTPS on those projects. I don't want my local network to be running everything unencrypted just because it's behind a LAN. But it's very tricky to try and set something up that's both robust and dependable, and that is fast enough to be usable within 1-2 minutes of me starting a new project that I'm just hacking on. It's also something that we're thinking about at work. We'd love to manage HTTPS for software installations on our client networks, but we don't want to force them to reveal too much info about their networks on the public Internet, and we don't want to deal with trying to integrate with whatever weird, half-broken certificate servers they have running. [0]: https://danshumway.com/blog/encrypting-internal-networks/ https://danshumway.com/blog/encrypting-internal-networks/
- trvz 6y ago
  Your solution comes to closest to mine, so I'll comment under here: - Register the domain names you'll use in your LAN, point them to a public VPS and generate a wildcard TLS certificates. - Copy the certificates to the servers in your LAN. This is the annoying part, as it needs to be done after every renewal (90 days with LE). - Have Pi-hole in your LAN. It's necessary for security reasons to every serious IT professional anyway. It allows to set local DNS records - configure your domain names to point to the LAN servers. This way, you get valid certificates on private servers without exposing DNS records into the public, without having to configure each client individually. Other people here still using self signed certificates are crazy...
skybrian 6y ago
Perhaps something like bluetooth pairing would work, where you enter a code into your browser to authenticate?
rossdavidh 6y ago
Probably, and I have found myself in the same situation btw, the best solution would be a fork of one of the browsers, that would (for example) only browse to addresses in the user's hosts file. That way, it could still piggyback all of the web interface machinery of a modern browser, but the things like "omg that's a self signed certificate you will die now" warnings can be safely removed, since the browser will only be able/willing to go to addresses in the user's hosts file. Just a thought.
nilsbunger 6y ago
Seems like a browser could treat the scenario when a user types an IP address differently from a normal domain name resolution (eg even just changing the messaging to be less scary). If you're actually using domain names on your LAN maybe you just have to bite the bullet and sign certificates too. You don't need internet access to have a properly signed certificate.
- kazen44 6y ago
  what about every major network that is not a very small bussiness or home network? Split DNS is used all across to globe to build internal networks.
  - nilsbunger 6y ago
    Could you use an domain that’s internal only and get a wildcard certificate for it ?
beauzero 6y ago
An arguably "not finished" solution for me has been to ramp up adoption of IPFS and use Brave as a default until other browsers support it. It is speeding up my transition to full fledged adoption.
bodhi_mind 6y ago
Could always ship your browser.
tmm 6y ago
I think the solution is TLS-PSK[0]. But browsers don't support pre-shared key mode. If they did, each IoT device (or consumer router, NAS, etc) could ship with a unique key which your browser could prompt for on first use. These could be even be managed by password managers, so you'd get the trust on all your devices. Why isn't this a thing? [0] https://en.wikipedia.org/wiki/TLS-PSK https://en.wikipedia.org/wiki/TLS-PSK
- marshray 6y ago
  In the grand scheme of things, IoT devices that don't phone home to a central server just aren't a big enough scenario to drive browser features.
smokey_circles 6y ago
>I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. Don't use the browser? I understand the temptation to use the browser, but this is the price you pay for using someone else's platform: They're free to close whatever door they want. HTML renderers are dime a dozen. Electron is a thing. Serve the HTML using _another_renderer. JavaFX isn't bad either but I'm not gonna sell anyone on that front because I don't even do it, but the option is there. Please stop using my browser in obscure and painful ways just so you can (understandably) avoid having to write a native UI.
- jodrellblank 6y ago
  I would much rather a web UI, please. A router, webcam, network storage, firewall, etc. that responds on ports 80 or 443 and serves up a usable web interface is a dream , all you need is a username and password and you can guess the rest. The distant past where you needed a desktop program, and that needed a login to the manufacturer's website and a support contract to download, and it's never native it always needs Java and must be 3 versions out of date to work, then needs fiddling with Java's excrable and innumerable "security" prompts, then uncommon ports to be opened, and the older the device is the more likely it is to not work with UAC and need to run with Admin rights and depend on old versions of libraries, and then you end up with one carefully curated fossilised-in-amber management VM for that specific device; that time was much much much worse. A 3D printer where you need CAD software to make much use of it, fine, have a desktop program. A thing which only needs an IP address for management and maybe it to talk to cloud services, browser web management absolutely any day please.
- michaelt 6y ago
  Telling users that, in order to connect their new router to the internet they must first download your native app from the internet... sounds like a non-ideal design?
  - drusepth 6y ago
    To be fair, my current ISP (xFinity) and my previous ISP (Google Fi) both technically support some kind of web interface, but both push hard to get you to download their app and use that instead. I had no problem (in either case) just downloading the app and using it to set up my networks. Most people know how app stores work now.
bcoates 6y ago
IMHO, what's needed is a way for appliances to obtain a real, permanent global domain name (and therefore certificates, email, etc.). There's a bunch of mostly-obsolete rules that assume domains are held by organizations with full-time staffs (like whois contact records, per-domain ICANN fees, UDRP, etc.) a tld like ".thing" that allows non-humans to claim permanent global names on a first-come-first-serve basis would let autonomous hardware devices integrate with the existing infrastructure without hacks and exceptions. Maybe a ccTLD could be convinced to do this?
kevin_thibedeau 6y ago
You can get embedded devices with TLS running in 200K of RAM. Cypress has WiFi MCUs based on Cortex M4 running their WICED stack which is a customized FreeRTOS, LwIP, and MbedTLS. I can't wholeheartedly recommend it as a platform because their modifications to reduce memory consumption break the MbedTLS API in subtle ways that make porting code more difficult than it needs to, but it is possible to get secure networking on something less capable than an RPi.
kccqzy 6y ago
The article says > IP addresses, single label domains, and reserved hostnames such as test/ or localhost/ will continue defaulting to HTTP. I don't think this affects you. If you are accessing a device on your LAN, you either use its IP address, or if you use DNS, you must be using your own DNS resolver then. In that case you can just use a single-label domain name such as http://media/ http://media/ and you can omit the "http:// http://" in that case. This is also the case for many enterprise networks. Tip: you need to enter a trailing slash to tell Chrome is a single-label domain, otherwise Chrome will think you want to search. I see nothing to worry about.
- stormbrew 6y ago
  You could be using mDNS (bonjour), in which case local addresses look like 'whatever.local'. This is actually pretty common? Honestly if they just made it so self-signed worked for .local that would probably help a lot.
  - zajio1am 6y ago
    mDNS uses link-local multicast so it does not work if your local network is more than one (l2) network segment (e.g. separate segment for wired and wireless).
alexchamberlain 6y ago
Would something like an electron app allow you to embed an alternative root/public certificate?
Pxtl 6y ago
I wish we could get industry standard making .local official, then we could get browser-level support for ".local is allowed to be self-signed". Of course, a crapload of software still recommends against .local. And consumer routers and the like don't create a nice .local domain for all your crap. Nevermind.
chovybizzass 6y ago
I think all you have to do is redirect https to http and it'll work. They are just "defaulting" to https
throwaway823882 6y ago
> If somebody has a solution, I'm all ears. We've known the solution forever: public-key cryptography [using asymmetric keys to share a symmetric key]. Every single server admin in the entire world already depends on it to secure access to their servers. You might also know it as "ssh keys". You connect once, it says "this is the first time you've visited this site. please confirm these numbers are legit???", you compare some numbers, then you save those numbers, and if they ever change, the browser screams. There are ways to make it more user-friendly, such as QR codes or serial numbers. You could do this a million different ways to differentiate it from the rest of the internet. They could require non-DNS-compliant names so the services could never route to the internet. They could dedicated a TLD like ".lan" or ".local" to it. They could add a new protocol prefix, like "local://" (but that doesn't jive with their vision of completely eliminating the address bar). You could just create a new PKI cert attribute that specifies this is a local-only cert and to use public keys, and the browser could enforce that the IP address could only be RFC1918 (but this is a terrible idea as a hacker could just proxy requests from your router to bankofamerica.com or something). Good luck getting any browser vendor to accept it if it doesn't personally benefit them. You could try bribery.
deleted 6y ago
[deleted]
EvangelicalPig 6y ago
On a related note, pinning the public keys of TLS certificates in browsers used to be a thing (HPKP) and it did mitigate certain classes of attacks with caveats (i.e, let's hijack a domain using an "incompetent" domain registrar and MITM clients that previously visited this site before, happens more than you think[1][2]). Given how it was configured using HTTP headers and with the average site that has buggy webapps and such that could be used for header "injection" independent of the webserver it was unfortunately considered a theoretical persistent DoS vector, and thus removed from browsers. I'm not convinced other solutions (CAA, CT) are adequate replacements because it best, they are reactive (versus preventative) solutions, and CAA assumes all CA's are properly checking DNS records at the time of issuance and that those DNS queries are not being intercepted, which is a big assumption in my book. [1]: https://www.fox-it.com/en/news/blog/fox-it-hit-by-cyber-attack/ https://www.fox-it.com/en/news/blog/fox-it-hit-by-cyber-atta... [2]: https://krebsonsecurity.com/2020/03/phish-of-godaddy-employee-jeopardized-escrow-com-among-others/ https://krebsonsecurity.com/2020/03/phish-of-godaddy-employe... (okay, was just a deface, but still accomplished with a hijacked registrar account)
stjohnswarts 6y ago
Now http will tell them that they are treading on thin ice and surely imminent death now :) . That's what firefox does.
tim-- 6y ago
> I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN There almost is! Instead of self signed certificates, use a certificate authority, and install that on the LAN's machines. https://github.com/devilbox/cert-gen https://github.com/devilbox/cert-gen You can use macOS Server or Active Directory to push out the Certificate as trusted. It's not perfect, but it's close enough for a LAN.
nine_k 6y ago
An ability for a browser to talk https over a Unix socket, or a Windows pipe, would help a lot. Each can be secured by regular OS means, so a rouge impostor process won't be an issue.
grahamburger 6y ago
This is a huge pain point for me as a user, too. I interact with a lot of managed network devices that have web UIs as their primary configuration method. All existing options for this stink. At least Firefox still lets me click through the security warnings - in Chrome you have to know the 'thisisunsafe' incantation, and who knows when that will just go away. There has to be a better way.
kenneth 6y ago
I wonder if you'd be able to use a .local name and somehow get a proper signed certificate for it, which you embed into your local device. Alternatively (and this is pretty hacky, but should work), you get a full domain unique to your device, e.g. mydevice-admin.com, and you require users to run a small installation script on their local devices that'll map that hostname to the local IP of the device. If not setup, it'd show a webpage that has instructions on how to run said installer. Then you embed the certificate on your devices. There's some obvious security risks on this (if someone could extract the certificate and MITM the website and then trick people into running a malicious installer…) but at least your default experience would have the desired green check-marks. (These are all probably shitty ideas.)
cookiengineer 6y ago
A hypothetical solution would be to stick with the DNS SD / avahi concept and use domains ending in .local. That would have the benefit to be able to create a CA for that domain that can cross-sign your certificates in order to prevent the snakeoil workflow, which must stick to local IPv4 ranges and the fe80:: IPv6 prefix. I've been digging through the DNS SD specifications lately (and how airplay, airprint, airscan and others work)...and I'm mindblown on how simple all things IoT could be if everything would support the DNS service discovery RFC. In a parallel world nobody has IP problems, and nobody has problems connecting to their printers. The way it's currently going though, I don't see any legacy firmware working in the near future due to CORS. I mean, most of the admin interfaces will break, probably, because of how they use forms to submit configs and settings.
- dcow 6y ago
  > I've been digging through the DNS SD specifications lately (and how airplay, airprint, airscan and others work)...and I'm mindblown on how simple all things IoT could be if everything would support the DNS service discovery RFC. It's amazing when you see it all, isn't it? IMO the slow process is communicating to product owners and IPv4-locked technical architects about how these things are actually supposed to work.
scottlamb 6y ago
> I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. I don't know how it could work if you're truly disconnected from the Internet, want to connect arbitrary machines with no setup (not install local CA certs), and don't want any sort of prompt on first use (the TLS-PSK someone else mentioned). We might just be stuck with http in that case. Chrome isn't turning off http support, just changing the default behavior to try https first. What I can imagine though is home LAN appliances being able to get certificates automatically when you have an Internet connection, have a domain name (they're pretty cheap), and set up your router for it. The router could present a (hypothetical) DHCP option saying "get certificates from me" (maybe via the standard ACME interface) and use the DNS-01 challenge with the upstream ACME server (letsencrypt) behind the scenes on each request. This is certainly more complicated than just doing the DHCP request for a hostname and being done, and it makes your appliance hostnames public, but you wouldn't have to make appliances accept traffic from the Internet, much less have all your traffic proxied through some cloud service. And I can imagine it being a standard router feature some day with a wizard that walks you through the setup.
donmcronald 6y ago
Just host a certificate + private key at a well known location and have all the devices download / update it every month. /s (I'd bet someone has done this).
- mike22 6y ago
  How do you trust that the devices are allowed to pull down the private key?
  - donmcronald 6y ago
    This was a joke. It would make things look secure, but it would be extremely stupid to actually do it.
emiliosic 6y ago
A suggestion would be to treat destinations that do not need to traverse a gateway (ie local network) differently. Browsers would need to implement this. Further, they could present an initial dialog to 'trust' the local network. Obviously we don't want to do this in public Wi-Fi networks, but the OS already has a concept of 'private' vs 'public' networks, and the browser can easily know if the destination needs to be routed or it's local.
goldsteinq 6y ago
What if someone bought `httpslan.net`, issued a wildcard certificate for `*.httpslan.net` and published the private key? Then anyone could just add `my.httpslan.net 192.168.0.13` to `/etc/hosts` and use published private key to verify connections? It wouldn't be secure, as anyone could decrypt the connection, but for LAN it's not relevant, and it will make browser shut up.

by simias 6y ago

nahuel0x 6y ago

There is a (defunct?) W3C working group about this, see https://www.w3.org/community/httpslocal/ https://www.w3.org/community/httpslocal/ and https://github.com/httpslocal https://github.com/httpslocal

liveoneggs 6y ago

let's encrypt with *.lan.mydomain.com via DNS validation, installed all over where needed, and annoying to update every 90 days because it's in weird/internal/non-standard places :)

simias 6y ago
I develop broadcast TV equipments which are often rented all over the place for short amounts of time, often don't have any direct internet access etc... I simply cannot make any assumption about the network these devices will run, and can certainly not rely on any sort of DNS validation. Virtually 100% of the time the devices are addressed directly by IPv4. I really can't think of a solution for this situation. For network you control your solution makes a lot of sense though.
- londons_explore 6y ago
  DNS validation can entirely be done by a server on the internet, which does all the stuff necessary to get the certificate, and then gives the certificate to your end user device. All the end user device needs is a connection to the internet once per 90 days. The vast majority of networks have sufficient network connectivity for this.
  - scruple 6y ago
    I worked in embedded radios for the broadcast industry and SCADA applications for a spell and dealt with the same problems that the GP is describing. Many of these systems are composed of networks built on top of radio modems. It is very common that these devices can't reach the Internet...
    - rswail 6y ago
      They don't have to reach the internet, they need to reach your infrastructure. Your infrastructure needs to reach the internet.
  - xg15 6y ago
    I think the more frustrating point is that you need all this internet infrastructure (with running costs) at all - even if your device has nothing to do with the internet at all. If the vendor of your dumb device goes out of business, you can just keep using the device until it breaks down. If the vendor of a "smart" device - or now anything with a modern web interface - goes out of business, the device will have a broken UX at best and at worst turns into a brick 90 days later. In the end, browsers are now a platform and you have to register and pay a subscription fee to make use of them.
  - xg15 6y ago
    > All the end user device needs is a connection to the internet once per 90 days. The vast majority of networks have sufficient network connectivity for this. I'm no expert on long-tail use cases, but I'd imagine that most networks either have internet connectivity or they don't. I can't think of many situations where you'd only have internet once every 90 days. Of course one could argue that 90 days long is enough so an employee could go around with a memory stick and manually copy the certificate to every device - which is theoretically possible but sounds like a ridiculous thing to do just to keep a web interface workable. (And even then, you'd somehow need a unique certificate for every device)
merb 6y ago
let's encrypt does not like that use case btw. because you would need to validate the cert and store it somewhere and then download it to the specified box, since the service can only be inside an intranet.
- liveoneggs 6y ago
  What does "does not like" mean in the context of let's encrypt?

boardwaalk 6y ago

It seems like we should have something like known_hosts for ssh, yeah. As long as it’s trusting one domain at a time (not a root CA), would it really be /that/ bad? This and browser vendors being overbearing about extensions (I know they’re powerful) gets me down.

wjrtyjw 6y ago
Isn't this the default behavior of most browsers? Access an https service with an untrusted tls certificate, the browser throws a warning and offers a way to permanently trust the certificate.
- somehnguy 6y ago
  Neither Chrome nor Edge offer a simple way to permanently trust the cert. I’m sure there is a way to do it but they don’t make it obvious. It’s maddening as someone who develops and distributes local network apps with https.
  - gpas 6y ago
    I'm on chromium right now and it does remember my decision to trust self signed cert once I click proceed to unsafe domain the first time. It's not ideal, and it shows an alert to inform the user of the fake certificate, but it works and unlocks the https only APIs on a local offline environment. It's permanent until you switch user profile or click on the alert on the left of the address bar and reenable the warnings for that domain.
  - oarsinsync 6y ago
    Sounds like you're using Windows, and I believe both ultimately outsource that to the OS, so you'd need to look whereever windows manages certificate trust to find and remove any old trusted certs. HTH.
- WanderPanda 6y ago
  I am actually glad that they don’t permanently trust it like I belief Safari does it. Accepting invalid certificates in Safari always freaks me out

j1elo 6y ago

It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. What happens with offline LAN? And the ideal IoT devices that we would all want to have? (I mean those we dream about in all IoT HN posts, where the rants typically are that no internet connection should be needed for most of these kinds of devices) What about offline tutorials? I'd like to provide a ZIP with a plain HTML tutorial that shows how WebRTC works, but users cannot serve it up in their LAN and access through their laptops or phones, because WebRTC requires HTTPS. What's even worse, a self-signed cert doesn't work either. iOS Safari does NOT work with self-signed certs at all! It's maddening, obstacles everywhere once you don't walk the path "they" (industry leaders, focused on mainstream online web services) want you to follow. EDIT: There are some (lots [0]) of features that require a secure context, i.e. a web page served through HTTPS. So the defaults to HTTP are not a silver bullet, and the security exceptions for localhost are not really that useful either, being limited to the same host. [0]: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

alecbz 6y ago
> without recourse Doesn't the post say they'll fall back to http if the https attempt fails? > For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails. The only change here seems like it's that, from the user's perspective, initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower).
- j1elo 6y ago
  I'm talking about the general state of HTTPS implantation. If you develop an offline device which offers a web UI, and it happens to use any feature that is deemed to require a Secure Context, you're out of luck. WebRTC is such a feature, but there are lots more, and they can change from one version of the browser to the next one. The players who are pushing so hard to shove HTTPS down our throats are simply closing their eyes and ignoring the use cases that are not interesting to them. The mandatory renewal timing is a good example: it used to be more than 1 year, now it is 90 days (and some would like to reduce it to mere weeks!) Absolutely great for the grand scheme of things and global security of the Internet, but dismaying for lots of other use cases.

heavyset_go 6y ago

> https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they decide to proceed, or just go with good old HTTP but then you hit all sorts of limitations, and obviously zero security. If you go the self-signed route, you'll encounter devices that simply won't work with them, especially IoT devices. If you got the HTTP route, you'll still encounter devices that simply won't work with them. For example, you can't cast an HTTP resource from Chrome or Chromium to a Chromecast, even if it exists on your LAN. As long as there are devices that you can't insert your own certificates into their certificate stores, this will be an issue.

dcow 6y ago

It's funny how pushing stringent privacy and security defaults in one domain degrades the privacy and security experience in another domain. My jaded takeaway from the last 5 or so years is that the internet companies (understandably) don't care about non-internet experiences. I empathize with how annoying that reality is because internet technology certainly works locally if you configure everything correctly.. just not how things work by default. The actual problem though is fascinating and there is a ton to unpack. For one, the internet was always supposed to be zero-trust. Security-by-NAT was an accident not a feature. And IPv6 enshrines this reality (and it breaks my heart when I see tech companies trying to make IPv6 work like IPv4 in the home). The privacy problem is not really an issue if everything is appropriately firewalled and communicating securely. And as you mention, half the IoT things out there only use a central server to get around what is ultimately a problem NAT introduced: devices don't have public IPs and aren't 1st class internet citizens. Here's how it's supposed to work: Your ISP delegates you an IPv6 prefix. As the gateway to your home site, your router advertises the public prefix, as well as a ULA prefix to your home devices. Devices construct both permanent and temporary IP addresses from the public and universal local prefixes (at this point a device that needs public internet access has 4 IP addresses). That's just IPv6 so far but the point is that devices have multiple addresses, ones for public communication and ones for local communication. Once you have the setup above you can do this: Your ISP provides you a domain (optionally you purchase your own vanity domain, of course) and their nameservers delegate to your gateway device (or possibly some other one, but conveniently your gateway) as the nameserver for your home site. After a device comes online it dynamically registers its desired hostname with gateway, which will now respond to DNS queries with its address. The gateway should also serve PTR and SRV records for your site unicast DNS-SD style. Your nameserver can serve the public record if the request comes from a public IP and the ULA record if the request comes from that prefix. All public traffic stays public and all local traffic stays local. Since your devices now are publicly routable, they get certs using ACME. If you want to run local ACME on your ULA network, go for it, but you'll continue to run into the original problem that browsers aren't configured to use your local CA by default and getting users to bootstrap that is essentially impossible. In that vein I do wish there was a way to start a browser window for "local" browsing where it only trust one CA (your local one) and thus isn't mixing public and local security domain concerns. If devices don't want to communicate on the public internet because that's a privacy or security concern, then they simply don't provision themselves a public-prefixed address or add a public DNS entry, etc. In short, NAT killed the internet and we're still recovering from it.

franga2000 6y ago

Yeah, there really needs to be a "secure, but not trusted" mode. My suggestion would be add a "trusted-only" TXT DNS entry that a browser could check when presented with an untrusted connection. HTTP: gray broken padlock HTTPS+Cert: green padlock HTTPS+no cert: gray padlock HTTPS+no cert+trusted-only: red broken padlock Any complaints? No? Ok, let's make it a standard! Oh wait... we're not in control of the standard, it's the world's largest cloud hosting, service and product providers. Intranets and locally-accessible embedded devices are a threat to their business model. Fuck.....

MaxBarraclough 6y ago
On the face of it, it sounds simple enough: special treatment when the IP address is an IETF-designated private IPv4 address (e.g. 192.168.x.y). Is there some reason this wouldn't work, that I haven't thought of?
- Wowfunhappy 6y ago
  Whitelisting specific addresses makes me uncomfortable. But I can't actually articulate why it would be bad in this instance, so maybe it's fine...
- simias 6y ago
  I considered that, but I think at the moment there's no concept of IP address for web certificates, it's all based on domain names as far as I know. It doesn't mean it's not doable of course, but I could understand if it make people uneasy since it means that the same domain and the same certificate would behave differently depending on what it resolves to. It may be an interesting solution to consider though. That would definitely make my life easier.
  - oarsinsync 6y ago
    > there's no concept of IP address for web certificates, it's all based on domain names as far as I know Regardless of whether you can or can't issue a certificate with a CN of an IP address, the browser doesn't receive the certificate in isolation, it receives it from an IP address, and can handle certificate validation differently depending on what it's connected to. This may be a terrible idea for reasons I haven't considered (it probably is), but I can't think of any off head myself right now. EDIT: this is probably terrible because someone can just stick a MITM proxy on your lan, and poison your DNS to resolve google.com to a RFC1918 address and boom.

jiri 6y ago

I agree. Am I right - would it be solved by prefering https for all ip addresses except 10.0.0.0/8, 192.168.0.0/24 and 172.16.0.0/16?

oarsinsync 6y ago
> all ip addresses except 10.0.0.0/8, 192.168.0.0/24 and 172.16.0.0/16 I assume you're trying to exclude RFC1918 addressing. As such: > 192.168.0.0/24 This should actually be: 192.168.0.0/16 > 172.16.0.0/16 This should actually be: 172.16.0.0/12 (10.0.0.0/8 was correct)

tony101 6y ago

> "I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they decide to proceed, or just go with good old HTTP but then you hit all sorts of limitations, and obviously zero security." How about what Plex did for its self-hosted media servers? "First they solved the problem of servers not having a domain name or a stable IP (they are mostly reached via bare dynamic IPs or even local IPs) by setting up a dynamic DNS space under plex.direct" "Then they partnered with Digicert to issue a wildcard certificate for *.HASH.plex.direct to each user, where HASH is - I guess - a hash of the user or server name/id." "This way when a server first starts it asks for its wildcard certificate to be issued (which happened almost instantly for me) and then the client, instead of connecting to http://1.2.3.4:32400 http://1.2.3.4:32400, connects to https://1-2-3-4.625d406a00ac415b978ddb368c0d1289.plex.direct:32400 https://1-2-3-4.625d406a00ac415b978ddb368c0d1289.plex.direct... which resolves to the same IP, but with a domain name that matches the certificate that the server (and only that server, because of the hash) holds." 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-...

vladvasiliu 6y ago
But this requires the manufacturer of the IoT device to provide a central service like Plex does. Maybe they can't afford it, or the device is expected to run for a very long time, like even after the manufacturer goes out of business. Or as some other commenters have said, it's a personal / hobby project and the "manufacturer" doesn't have the means nor the will to maintain some outside management server.
simias 6y ago
That's very cool, but it still requires a working and reliable internet connection. Also these ultra-long URLs are very clumsy and can't really be used directly, so you need to have some sort of cloud frontend that where the device phones home in order to announce its LAN IP, then the user can go through there in order to connect to their LAN devices. For something like Plex it makes a lot of sense since you're probably going to have an internet connection when you use it anyway, but for my devices it's a deal breaker. And at any rate, that's a whole lot of infrastructure just to be able to expose a simple web interface.

davidkhess 6y ago

Here's an approach I've used before successfully. It's not perfect but it's better than nothing. 1. Create your own root Certificate Authority. 2. Create a script using your favorite language and libraries that will create a new certificate for each device something along the lines of "myiotdevice-AABBCCDD.local". The AABBCCDD needs to be some sort of serialized number that's assigned during manufacturing and won't be repeated between devices. 3. Add to your product support for ZeroConf/mDNS/DNS Service Discovery and advertise an https web server at myiotdevice-AABBCCDD.local. 4. Provide instructions to your users on how to download and install the certificate for your root CA (this only needs to be done once). 5. Print the name "myiotdevice-AABBCCDD.local" on the device and instruct users to type that in to a browser's address bar. I'm doing this from memory so I may have missed an intricacy here or there (like DNS SD is a weird story on Windows 10) but this approach should basically work well enough. EDIT - good commentary in replies about the dangers of the CA being compromised. Also, good mention of X.509 Name Constraints and how they can be used to mitigate that danger somewhat. More info here: https://systemoverlord.com/2020/06/14/private-ca-with-x-509-name-constraints.html https://systemoverlord.com/2020/06/14/private-ca-with-x-509-...

oarsinsync 6y ago
> 1. Create your own root Certificate Authority. 2. Ensure that the security around your new root CA is watertight, so that if your environment ever gets compromised, someone can't generate a new *.google.com or *.yourbank.com certificate signed by your CA and then MITM your connection.
- merb 6y ago
  3. use cross signing with name constraints to not have this problem https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10
  - fomine3 6y ago
    Issuing CA cert with Name Constraints is good, but end user should recognize the certificate is constrained to their domains or not.

INTPenis 6y ago

Yeah I came here to say just that. It's really annoying when Firefox is stuck on https for some reason, maybe history? So I have to test if one of my LAN services works with curl. I think it has to do with history so I have to clear all history for that site and then start using it with http and it should work fine. This is only Firefox.

capitainenemo 6y ago
Strict-Transport-Security perhaps? My preferred method for testing is a clean profile (firefox -no-remote -P) or just ctrl-shift-p to open private browsing which does not read SiteSecurityServiceState.txt

billpg 6y ago

Browsers would need to be modified, but I wonder if TOR's method of URLs with the public key encoded could be repurposed for devices on a LAN? https://hashhash.lan/ https://hashhash.lan/ (Causes browser to broadcast a message on LAN and wait for a response. Keys are exchanged and if valid, completes connection.) Devices would need to be programmed with a private key at the factory and print out a QR with the encoded hash and stick it somewhere discreet. What's that? The factory is producing devices all with the same private key to save money? This is why we can't have nice things.

danShumway 6y ago

The very partial solution that I've been experimenting with and trying to refine is to "abuse" DNS records and Certbot's DNS tests so that I can have a bunch of public subdomains that point at intranet sites.[0] There's no rule that says you can't point a DNS record at a local IP. This really isn't a full solution though because there are instances where you don't want a public DNS record at all. It's also not particularly plug and play, at least right now. And it requires you to have a static domain name and an Internet connection. It's a step in the right direction, but not perfect, and not usable in every situation. Setting up a custom certificate server and configuring every device is a no-go for me, maybe that works for highly managed networks. I don't trust myself to do it, and even if I did, it's too time consuming and annoying to set up for new devices. At least with my current setup I don't need to transfer any information (other than the DNS lookup) out of my network, and anyone and any device on my network will immediately be able to connect to whatever service I have, and I don't need to worry about accidentally compromising every website I visit. I'm not sure what the better solution would be. I'd also be interested in hearing ideas about this, it's a problem I'm running into as I try to figure out how to get HTTPS encryption on my local projects. And I do want HTTPS on those projects. I don't want my local network to be running everything unencrypted just because it's behind a LAN. But it's very tricky to try and set something up that's both robust and dependable, and that is fast enough to be usable within 1-2 minutes of me starting a new project that I'm just hacking on. It's also something that we're thinking about at work. We'd love to manage HTTPS for software installations on our client networks, but we don't want to force them to reveal too much info about their networks on the public Internet, and we don't want to deal with trying to integrate with whatever weird, half-broken certificate servers they have running. [0]: https://danshumway.com/blog/encrypting-internal-networks/ https://danshumway.com/blog/encrypting-internal-networks/

trvz 6y ago
Your solution comes to closest to mine, so I'll comment under here: - Register the domain names you'll use in your LAN, point them to a public VPS and generate a wildcard TLS certificates. - Copy the certificates to the servers in your LAN. This is the annoying part, as it needs to be done after every renewal (90 days with LE). - Have Pi-hole in your LAN. It's necessary for security reasons to every serious IT professional anyway. It allows to set local DNS records - configure your domain names to point to the LAN servers. This way, you get valid certificates on private servers without exposing DNS records into the public, without having to configure each client individually. Other people here still using self signed certificates are crazy...

skybrian 6y ago

Perhaps something like bluetooth pairing would work, where you enter a code into your browser to authenticate?

rossdavidh 6y ago

Probably, and I have found myself in the same situation btw, the best solution would be a fork of one of the browsers, that would (for example) only browse to addresses in the user's hosts file. That way, it could still piggyback all of the web interface machinery of a modern browser, but the things like "omg that's a self signed certificate you will die now" warnings can be safely removed, since the browser will only be able/willing to go to addresses in the user's hosts file. Just a thought.

nilsbunger 6y ago

Seems like a browser could treat the scenario when a user types an IP address differently from a normal domain name resolution (eg even just changing the messaging to be less scary). If you're actually using domain names on your LAN maybe you just have to bite the bullet and sign certificates too. You don't need internet access to have a properly signed certificate.

kazen44 6y ago
what about every major network that is not a very small bussiness or home network? Split DNS is used all across to globe to build internal networks.
- nilsbunger 6y ago
  Could you use an domain that’s internal only and get a wildcard certificate for it ?

beauzero 6y ago

An arguably "not finished" solution for me has been to ramp up adoption of IPFS and use Brave as a default until other browsers support it. It is speeding up my transition to full fledged adoption.

bodhi_mind 6y ago

Could always ship your browser.

tmm 6y ago

I think the solution is TLS-PSK[0]. But browsers don't support pre-shared key mode. If they did, each IoT device (or consumer router, NAS, etc) could ship with a unique key which your browser could prompt for on first use. These could be even be managed by password managers, so you'd get the trust on all your devices. Why isn't this a thing? [0] https://en.wikipedia.org/wiki/TLS-PSK https://en.wikipedia.org/wiki/TLS-PSK

marshray 6y ago
In the grand scheme of things, IoT devices that don't phone home to a central server just aren't a big enough scenario to drive browser features.

smokey_circles 6y ago

>I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. Don't use the browser? I understand the temptation to use the browser, but this is the price you pay for using someone else's platform: They're free to close whatever door they want. HTML renderers are dime a dozen. Electron is a thing. Serve the HTML using _another_renderer. JavaFX isn't bad either but I'm not gonna sell anyone on that front because I don't even do it, but the option is there. Please stop using my browser in obscure and painful ways just so you can (understandably) avoid having to write a native UI.

jodrellblank 6y ago
I would much rather a web UI, please. A router, webcam, network storage, firewall, etc. that responds on ports 80 or 443 and serves up a usable web interface is a dream , all you need is a username and password and you can guess the rest. The distant past where you needed a desktop program, and that needed a login to the manufacturer's website and a support contract to download, and it's never native it always needs Java and must be 3 versions out of date to work, then needs fiddling with Java's excrable and innumerable "security" prompts, then uncommon ports to be opened, and the older the device is the more likely it is to not work with UAC and need to run with Admin rights and depend on old versions of libraries, and then you end up with one carefully curated fossilised-in-amber management VM for that specific device; that time was much much much worse. A 3D printer where you need CAD software to make much use of it, fine, have a desktop program. A thing which only needs an IP address for management and maybe it to talk to cloud services, browser web management absolutely any day please.
michaelt 6y ago
Telling users that, in order to connect their new router to the internet they must first download your native app from the internet... sounds like a non-ideal design?
- drusepth 6y ago
  To be fair, my current ISP (xFinity) and my previous ISP (Google Fi) both technically support some kind of web interface, but both push hard to get you to download their app and use that instead. I had no problem (in either case) just downloading the app and using it to set up my networks. Most people know how app stores work now.

bcoates 6y ago

IMHO, what's needed is a way for appliances to obtain a real, permanent global domain name (and therefore certificates, email, etc.). There's a bunch of mostly-obsolete rules that assume domains are held by organizations with full-time staffs (like whois contact records, per-domain ICANN fees, UDRP, etc.) a tld like ".thing" that allows non-humans to claim permanent global names on a first-come-first-serve basis would let autonomous hardware devices integrate with the existing infrastructure without hacks and exceptions. Maybe a ccTLD could be convinced to do this?

kevin_thibedeau 6y ago

You can get embedded devices with TLS running in 200K of RAM. Cypress has WiFi MCUs based on Cortex M4 running their WICED stack which is a customized FreeRTOS, LwIP, and MbedTLS. I can't wholeheartedly recommend it as a platform because their modifications to reduce memory consumption break the MbedTLS API in subtle ways that make porting code more difficult than it needs to, but it is possible to get secure networking on something less capable than an RPi.

kccqzy 6y ago

The article says > IP addresses, single label domains, and reserved hostnames such as test/ or localhost/ will continue defaulting to HTTP. I don't think this affects you. If you are accessing a device on your LAN, you either use its IP address, or if you use DNS, you must be using your own DNS resolver then. In that case you can just use a single-label domain name such as http://media/ http://media/ and you can omit the "http:// http://" in that case. This is also the case for many enterprise networks. Tip: you need to enter a trailing slash to tell Chrome is a single-label domain, otherwise Chrome will think you want to search. I see nothing to worry about.

stormbrew 6y ago
You could be using mDNS (bonjour), in which case local addresses look like 'whatever.local'. This is actually pretty common? Honestly if they just made it so self-signed worked for .local that would probably help a lot.
- zajio1am 6y ago
  mDNS uses link-local multicast so it does not work if your local network is more than one (l2) network segment (e.g. separate segment for wired and wireless).

alexchamberlain 6y ago

Would something like an electron app allow you to embed an alternative root/public certificate?

Pxtl 6y ago

I wish we could get industry standard making .local official, then we could get browser-level support for ".local is allowed to be self-signed". Of course, a crapload of software still recommends against .local. And consumer routers and the like don't create a nice .local domain for all your crap. Nevermind.

chovybizzass 6y ago

I think all you have to do is redirect https to http and it'll work. They are just "defaulting" to https

throwaway823882 6y ago

> If somebody has a solution, I'm all ears. We've known the solution forever: public-key cryptography [using asymmetric keys to share a symmetric key]. Every single server admin in the entire world already depends on it to secure access to their servers. You might also know it as "ssh keys". You connect once, it says "this is the first time you've visited this site. please confirm these numbers are legit???", you compare some numbers, then you save those numbers, and if they ever change, the browser screams. There are ways to make it more user-friendly, such as QR codes or serial numbers. You could do this a million different ways to differentiate it from the rest of the internet. They could require non-DNS-compliant names so the services could never route to the internet. They could dedicated a TLD like ".lan" or ".local" to it. They could add a new protocol prefix, like "local://" (but that doesn't jive with their vision of completely eliminating the address bar). You could just create a new PKI cert attribute that specifies this is a local-only cert and to use public keys, and the browser could enforce that the IP address could only be RFC1918 (but this is a terrible idea as a hacker could just proxy requests from your router to bankofamerica.com or something). Good luck getting any browser vendor to accept it if it doesn't personally benefit them. You could try bribery.

deleted 6y ago

[deleted]

EvangelicalPig 6y ago

On a related note, pinning the public keys of TLS certificates in browsers used to be a thing (HPKP) and it did mitigate certain classes of attacks with caveats (i.e, let's hijack a domain using an "incompetent" domain registrar and MITM clients that previously visited this site before, happens more than you think[1][2]). Given how it was configured using HTTP headers and with the average site that has buggy webapps and such that could be used for header "injection" independent of the webserver it was unfortunately considered a theoretical persistent DoS vector, and thus removed from browsers. I'm not convinced other solutions (CAA, CT) are adequate replacements because it best, they are reactive (versus preventative) solutions, and CAA assumes all CA's are properly checking DNS records at the time of issuance and that those DNS queries are not being intercepted, which is a big assumption in my book. [1]: https://www.fox-it.com/en/news/blog/fox-it-hit-by-cyber-attack/ https://www.fox-it.com/en/news/blog/fox-it-hit-by-cyber-atta... [2]: https://krebsonsecurity.com/2020/03/phish-of-godaddy-employee-jeopardized-escrow-com-among-others/ https://krebsonsecurity.com/2020/03/phish-of-godaddy-employe... (okay, was just a deface, but still accomplished with a hijacked registrar account)

stjohnswarts 6y ago

Now http will tell them that they are treading on thin ice and surely imminent death now :) . That's what firefox does.

tim-- 6y ago

> I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN There almost is! Instead of self signed certificates, use a certificate authority, and install that on the LAN's machines. https://github.com/devilbox/cert-gen https://github.com/devilbox/cert-gen You can use macOS Server or Active Directory to push out the Certificate as trusted. It's not perfect, but it's close enough for a LAN.

nine_k 6y ago

An ability for a browser to talk https over a Unix socket, or a Windows pipe, would help a lot. Each can be secured by regular OS means, so a rouge impostor process won't be an issue.

grahamburger 6y ago

This is a huge pain point for me as a user, too. I interact with a lot of managed network devices that have web UIs as their primary configuration method. All existing options for this stink. At least Firefox still lets me click through the security warnings - in Chrome you have to know the 'thisisunsafe' incantation, and who knows when that will just go away. There has to be a better way.

kenneth 6y ago

I wonder if you'd be able to use a .local name and somehow get a proper signed certificate for it, which you embed into your local device. Alternatively (and this is pretty hacky, but should work), you get a full domain unique to your device, e.g. mydevice-admin.com, and you require users to run a small installation script on their local devices that'll map that hostname to the local IP of the device. If not setup, it'd show a webpage that has instructions on how to run said installer. Then you embed the certificate on your devices. There's some obvious security risks on this (if someone could extract the certificate and MITM the website and then trick people into running a malicious installer…) but at least your default experience would have the desired green check-marks. (These are all probably shitty ideas.)

cookiengineer 6y ago

A hypothetical solution would be to stick with the DNS SD / avahi concept and use domains ending in .local. That would have the benefit to be able to create a CA for that domain that can cross-sign your certificates in order to prevent the snakeoil workflow, which must stick to local IPv4 ranges and the fe80:: IPv6 prefix. I've been digging through the DNS SD specifications lately (and how airplay, airprint, airscan and others work)...and I'm mindblown on how simple all things IoT could be if everything would support the DNS service discovery RFC. In a parallel world nobody has IP problems, and nobody has problems connecting to their printers. The way it's currently going though, I don't see any legacy firmware working in the near future due to CORS. I mean, most of the admin interfaces will break, probably, because of how they use forms to submit configs and settings.

dcow 6y ago
> I've been digging through the DNS SD specifications lately (and how airplay, airprint, airscan and others work)...and I'm mindblown on how simple all things IoT could be if everything would support the DNS service discovery RFC. It's amazing when you see it all, isn't it? IMO the slow process is communicating to product owners and IPv4-locked technical architects about how these things are actually supposed to work.

scottlamb 6y ago

> I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. I don't know how it could work if you're truly disconnected from the Internet, want to connect arbitrary machines with no setup (not install local CA certs), and don't want any sort of prompt on first use (the TLS-PSK someone else mentioned). We might just be stuck with http in that case. Chrome isn't turning off http support, just changing the default behavior to try https first. What I can imagine though is home LAN appliances being able to get certificates automatically when you have an Internet connection, have a domain name (they're pretty cheap), and set up your router for it. The router could present a (hypothetical) DHCP option saying "get certificates from me" (maybe via the standard ACME interface) and use the DNS-01 challenge with the upstream ACME server (letsencrypt) behind the scenes on each request. This is certainly more complicated than just doing the DHCP request for a hostname and being done, and it makes your appliance hostnames public, but you wouldn't have to make appliances accept traffic from the Internet, much less have all your traffic proxied through some cloud service. And I can imagine it being a standard router feature some day with a wizard that walks you through the setup.

donmcronald 6y ago

Just host a certificate + private key at a well known location and have all the devices download / update it every month. /s (I'd bet someone has done this).

mike22 6y ago
How do you trust that the devices are allowed to pull down the private key?
- donmcronald 6y ago
  This was a joke. It would make things look secure, but it would be extremely stupid to actually do it.

emiliosic 6y ago

A suggestion would be to treat destinations that do not need to traverse a gateway (ie local network) differently. Browsers would need to implement this. Further, they could present an initial dialog to 'trust' the local network. Obviously we don't want to do this in public Wi-Fi networks, but the OS already has a concept of 'private' vs 'public' networks, and the browser can easily know if the destination needs to be routed or it's local.

goldsteinq 6y ago

What if someone bought `httpslan.net`, issued a wildcard certificate for `*.httpslan.net` and published the private key? Then anyone could just add `my.httpslan.net 192.168.0.13` to `/etc/hosts` and use published private key to verify connections? It wouldn't be secure, as anyone could decrypt the connection, but for LAN it's not relevant, and it will make browser shut up.