14 ms·
With the tightening of certificate trust, demise of self-signed certificates, etc., is there any remaining way to establish a consumer-oriented HTTPS server on
by paledot 6y ago
With the tightening of certificate trust, demise of self-signed certificates, etc., is there any remaining way to establish a consumer-oriented HTTPS server on a local network? Thinking of things like routers, printers, and self-hosted IoT devices here. Some of the label printers we support at work have simply atrocious workarounds to get them to work, and I'm wondering if it's the manufacturer's fault or if that use case has been completely abandoned in the push for tighter security on the Internet.
- dharmab 6y agoBuy a domain, create a subdomain for local use, and issue ACME certs with Let's Encrypt every 60 days. If your vendor device or software doesn't support automated certificate rotation, put nginx/haproxy/envoy in front of it.
- xg15 6y agoWithout buying a domain. (and continously spending money to keep it owned)
- dharmab 6y agoRun your own CA internally and handle the CA distribution problem with MDM tools.
- lawnchair_larry 6y agoThat is also an insane and unrealistic suggestion.
- xg15 6y agoI admit, that's a solution, even if a very unpleasant one: Installing a custom root CA is intentionally complicated, so this is hardly doable as an onboarding experience. The setup must be repreated for every single client device that should access the server. There remains the question how I would get the CA certificate onto client devices in the first place. Lastly, with asking consumers to install a CA certificate, I ask for a significantly more powerful permission than if I could just have them trust my certificate. This seems like a step backwards security-wise.
- est31 6y ago> Lastly, with asking consumers to install a CA certificate, I ask for a significantly more powerful permission than if I could just have them trust my certificate. CA certificates can be constrained. https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10
- toast0 6y agoAre common certificate validation libraries honoring these constraints? When I tried to use this many moons ago, most things ignored the constraints; although I could mark the extension critical, and then some (but not all, yay) of the things that didn't understand would refuse the CA.
- namibj 6y agoCan you name and shame those that ignored the critical extension? Sounds CVE-worthy. A date to guess the versions you used would also help.
- toast0 6y agoNo, it was on the order of 5 years ago; everybody was garbage back then. But, if this had become usable, I would expect to have seen articles about using it since then.
- est31 6y agoIDK NSS seems to have code to verify it: https://searchfox.org/mozilla-central/source/security/nss/lib/mozpkix/lib/pkixnames.cpp#285 https://searchfox.org/mozilla-central/source/security/nss/li... As does webpki: https://github.com/briansmith/webpki/blob/482627c40dad2148da8b9bf64c2c781ea30a7e4d/src/name.rs#L158 https://github.com/briansmith/webpki/blob/482627c40dad2148da... But haven't tested it (or checked other libraries).
- est31 6y ago
- demersb 6y ago~$5/year (US) for a domain, and a one time investment of setting up a few scripts might save you a lot of time in the long run.
- xg15 6y agoHonestly, my main issue is not even the price, it's that devices cannot be stand-alone anymore. Even if my device is purely for LAN use and wouldn't need the internet at all, I now need to ensure it has an internet connection and I have to keep a domain owned that must be constantly renewed. The device will also only be accessible if an internet connection is present, even if both the device and the client are in the same LAN - because the client has to access the device through the domain. This means, should I ever lose the capacity to support the device and renew the domain, the device will become useless, even if technically, it is still completely functional.
- gsich 6y agoNo. Your DNS can also be locally, so you have no Internet dependence.
- p2t2p 6y ago> Honestly, my main issue is not even the price, it's that devices cannot be stand-alone anymore. That’s not true at all. I’ve created a CA and a script to generate and sign server certificates and I generated them left right and centre now for my very standalone, local network only with no access to the internet whatsoever services. I added my CA to my browsers and my iPhone and everything works perfectly.
- dimensi0nal 6y agoA .net is 83 cents a month.
- imtringued 6y agoThat's usually a limited special offer. Not everyone wants to change domains every year.
- dimensi0nal 6y agohttps://www.cloudflare.com/products/registrar/ https://www.cloudflare.com/products/registrar/
- jt2190 6y agoThere’s always the .local TLD, which is reserved for this use case: https://en.m.wikipedia.org/wiki/.local https://en.m.wikipedia.org/wiki/.local
- xg15 6y agoI haven't heard about that yet. this sounds interesting indeed. But how would I get a valid certificate for a .local domain?
- jt2190 6y agoYou need to set up your own “chain of trust” to verify your self-generated certificates. You can run your own Certificate Authority for example. (There are other approaches too.)
- lvh 6y agoThat works, but you can't get public certs for it, because you can't prove you own that domain (indeed, you don't :))
- jt2190 6y agoPlease remind me where I said anything about public certificates. ;-) xg15 is going to have to run a self-hosted Certificate Authority (CA) and generate certificates himself.
- Karunamon 6y agoThat article goes on to state that .local is reserved by RFC6762 (multicast DNS), which if you use that domain on your network, will cause problems with any services using it, usually Macs or iPhones. This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. [...] Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB). I'd recommend using something like .lan instead.
- lawnchair_larry 6y agoThis is a ridiculous requirement that is not at all practical.
- gsich 6y agoYou can also run your own CA.
- geerlingguy 6y ago> This is a ridiculous requirement that is not at all practical.
- gsich 6y agoFor a company? Absolutely not. In private? Probably not worth the effort, just skip the cert warning.
- nitrogen 6y agoMost hardware in this category really needs to be set-and-forget, whether online or not. You can't have every random sound system and light controller having to dial out to a third party every month. You need to be able to come back five years later and still be able to configure the hardware.
- rad_gruchalski 6y agoReally. This: https://jamielinux.com/docs/openssl-certificate-authority/ https://jamielinux.com/docs/openssl-certificate-authority/ gives you a CA in about an hour. HashiCorp Vault will give you a CA in 5 minutes. certstrap will give you a CA in 15 seconds. It’s 2020, it ain’t voodoo anymore.
- Karunamon 6y agoJust spinning up a CA is a couple of commands. Running one sanely (to include security of the private keys, availability and auditability of the signing machine, keeping backups, publishing a CRL, setting up ACME if you want any kind of automation) is significantly more involved.
- xg15 6y agoThis won't work either, btw: You'd have to request from Let's Encrypt a new certificate for each individual device. LE has several rate limits that will prevent that from working for anything more than a trivial number of devices: https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/ The only way I see how this would work is if you not just purchase a domain but also an internet-facing server and do the renewal and certificate management centrally for all devices - at which point, your device is definitly not standalone anymore.
- MikeHardman 6y agoYou can do wildcard certs with LE, I run hundreds of k8s services all secured with LE and wildcard certs.
- stefan_ 6y agoWe're talking about customer hardware. If someone looks at the insides of the device and finds, of course, the private key for your one shared wildcard certificate, the issuer is required to invalidate it immediately.
- lvh 6y agoYou can, but that wouldn't quite work for the prosumer router manufacturer case the OP mentioned: LE would revoke the cert once you distributed it.
- AdamJacobMuller 6y agoYou can, but, you can't (by policy) distribute keys across multiple customers.
- tgsovlerkhgsel 6y agoI have a nasty habit of requesting revocation of such compromised keys whenever I find them. CAs are required to revoke within 24 hours, I think, though unfortunately revocation is surprisingly ineffective.
- pilif 6y agoBackdate your self-signed cert. so far that works around any validity length restrictions.
- cpncrunch 6y agoNo, that won't work. https://chromium.googlesource.com/chromium/src/+/ae4d6809912f8171b23f6aa43c6a4e8e627de784/net/cert/cert_verify_proc.cc#957 https://chromium.googlesource.com/chromium/src/+/ae4d6809912...
- secabeen 6y agoDo self-signed certs not work? Yes, you have to tell your browser to permanently accept them the first time you connect, but after that, they work.
- stefan_ 6y agoWhy as a vendor would you use a self-signed certificate that causes the browser to scream at the customer when you could just not use TLS, plain old HTTP.
- PersonalOps 6y agoBecause the alternative is to embed a TLS private key that would allow you to MITM every other one of those devices. Someone extracted it? Looks like you have to either (a) bury your head in the sand or (b) rollout an expensive recall to change certs on those devices. Why use slightly compromised HTTPS versus plaintext HTTP? Same reason they have those super cheap locks on diaries from the 90s: it's a deterrent. Makes it a little harder to do a bad thing.
- stefan_ 6y agoYou have already answered why no one in their right mind would embed a shared certificate across all devices. I don't think you are being realistic with yourself when you believe people use self-signed certificates; they don't. You are missing what happens instead. There is just simply no web management interface on the device anymore. You need to download the vendors app to configure and use the device. Maybe, if the vendor cares, they use their own CA to secure a local connection to the device. Much more likely, the app and device exclusively talk to their cloud and use that as a middleman to exchange information.
- andrewnicolalde 6y agoBut it also makes it a little harder for the user to do what they want too because they have to click through a (correctly) scary-looking security warning.
- 6y ago
- lvh 6y agoIf only we had NameConstraints: we could have a CA limited to *.clientdevices.manufacturer.com, installed in everyone's trust root.
- pas 6y agoInstalled? Everyone? It would be enough to send it as an intermediate CA cert, no need to install. Going the self-signed DNS name restricted CA way would likely still not fly with browsers, because there's no way to securely deploy the trust root. (Because if it requires user interaction to install that can be exploited by malicious actors.)
- AdamJacobMuller 6y agoI'm not a huge fan of it, but, it seems like the way things are going is to simply run a service which is basically a large proxy. Your device connects out with some kind of persistent connection to their central service then requests to your device go to their server, which does AAA and routes to your local device. Fixes the SSL issue, avoids any NAT headaches, enables fully remote access and most importantly for PMs it makes the device useless without your server-side components. If there is any local accessibility at all, it can be neutered or reduced. I don't entirely hate this model, its not my favorite, but, its the way things are going.
- paledot 6y agoI think this is the only practical answer, unfortunately. Everything else might possibly be made to work for a personal project, but definitely isn't an option at scale.
- AdamJacobMuller 6y agoThe way plex does it works great at scale. It requires people to care more about "self hosted" than "PM says this will centralize user access and allow us to collect data and better monetize" I'm not knocking either model. They both work (technically) but you need to understand your market and what works better for them.
- heavenlyblue 6y agoI would be happy if my router supported letsencrypt. Why would I even bother copying and distributing self-signed certificates if I can just properly get a certificate for my own personal router? It’s idiotic that people still trust pure HTTP and have no option of switching.
- robocat 6y agoIf your router needs configuring before it can access the Internet, then it can’t use certificates that require the internet to generate or validate. Or if you change ISP and need to change your router internet connection configuration, your router cannot be accessed.
- elcritch 6y agoIt’s a glaring security hole, IMHO. I create such devices and the only way I know is self-signed certs, but the browsers complain a lot about that. Ideally there’d be a way to sign .local domains with browsers handling it while letting people know to verify the identity of their local devices/services and that the identity isn’t verified by https like most sites. The issue lies between the browsers and https system. SSH can do encryption without requiring identity verification. It handles it by asking "Do you want to trust this new server?". Then if it changes informs you of that. Browsers could easily implement that for .local with self-signed certs. Of course browser developers assume everyone has internet all the time and you only access servers with signed domains. I’ve wondered what it’d take to get an ITEF/W3C RFQ published for .local self-signed behavior. (Edit: RFQ, not my autocomplete’s RTF)
- paledot 6y agoI love this idea. There are enough influential tech people who read HN, can we make this happen please?
- Sebb767 6y agoThirded. This sounds like a sound solution.
- arwineap 6y ago> It handles it by asking "Do you want to trust this new server?" That's basically how it works though; your OS packages a group of trusted CA certs. You can add additional trusted CA certs, even ones minted by you to ensure your apps trust the connection
- loeg 6y agoThe mechanism SSH uses is called Trust on First Use ("TOFU") and is closer to what used to be HTTPS certificate pinning. In this scheme, certificates never expire, and if they do, clients warn about the unexpected change in certificate. It is different from the CA PKI system, where the client trusts any certificate signed by a trusted CA without prompting the user at all, and doesn't prompt the user if the certificate for a site changes.
- alyandon 6y agoI've just resigned myself to accepting the fact that I am not the browser vendor's target market anymore and I'll have to keep an older copy of FF around for the sole purpose of accessing devices I own that will never see an update to modern crypto/certificate standards.
- iwalton3 6y agoPlex uses a combination of wildcard certificates and a custom DNS resolver to offer HTTPS on local networks, but it does require a working internet connection to work. [1] You can also get a certificate through the Let's Encrypt DNS challenge without having to expose a server to the Internet, but you'll still need ownership of a domain name and either an internet connection or a local DNS server to support HTTPS using that certificate. There is always the option of creating a local certificate authority for your devices, but this is kind of a pain. There are some new applications that aim to make this easier [2], but there is no easy way around having to install the root certificate on each device. [1] 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-... [2] https://github.com/smallstep/certificates https://github.com/smallstep/certificates
- tgsovlerkhgsel 6y agoIf you just want the green lock to show up, the device can get a certificate from Let's Encrypt. The manufacturer would need to provide an API that lets the device pass the DNS challenge. For example, you could have serialnumber.manufactuerer-homedevices.net, and each device would get a cert for its serial's host name. Ideally, you should properly secure that API with some form of attestation key included on the device. Alternatively, the host name could be e.g. the hash of the devices' generated key (that way you could ship the devices without placing individual keys on them, but the host name would change after a factory reset). Making this actually secure is hard, though, because you need the user to visit the URL for his device. If an attacker can simply get a cert for differentserial.manufacturer-homedevices.net and direct the victim there, you don't win much actual security.
- deleted 6y ago[deleted]
- whoopdedo 6y agoThe answer to that may be to stop using the web browser to do damn near everything. Your computer will load an app, distributed by a trusted app store or downloaded directly from the device, that talks only to the device on the local network, and to a whitelist of allowed internet hosts, and nothing else. The app will have a client certificate so the device won't blindly trust the computer either. Firefox will only communicate over the local network in a limited way, enough to download the app from the device or get a link to the manufacturer's app store profile. Or that discovery can become part of the operating system and browsers will stop talking over the local network at all.
- pstrateman 6y agoUnfortunately the answer is no.
- majewsky 6y agoYou can always issue the TLS certificate on an internet-facing system that can do the corresponding ACME challenge, then give it to the internal service and have all clients of that service resolve the domain name for the certificate via a static configuration in /etc/hosts. That's how I do TLS for my intranet-only LDAP server.
- herf 6y agoIt would be nice if there were a way to be a CA for a subdomain. Then each manufacturer could sign *.mydevice.com.