Hacker News Reader

Comment by xg15 | Hacker News Reader

Without buying a domain. (and continously spending money to keep it owned)

Run your own CA internally and handle the CA distribution problem with MDM tools.

That is also an insane and unrealistic suggestion.

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

> 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

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

Can you name and shame those that ignored the critical extension? Sounds CVE-worthy. A date to guess the versions you used would also help.

No, 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.

IDK NSS seems to have code to verify it:

https://searchfox.org/mozilla-central/source/security/nss/li...

As does webpki:

https://github.com/briansmith/webpki/blob/482627c40dad2148da...

But haven't tested it (or checked other libraries).

Update: tested it with openssl and webpki. both claim to have support but it only works with openssl. For webpki I had to file two bugs:

https://github.com/briansmith/webpki/issues/134

https://github.com/briansmith/webpki/issues/135

How do you actually generate a constrained CA certificate? I have tried to do this for a long time but openssl is inscrutable.

There seems to be a guide for openssl here [0] but it seems kinda complicated. This discussion inspired me to add name constraints support to rcgen [2]. If you aren't afraid to write Rust, you should give using it a try.

[0] https://www.marcanoonline.com/post/2016/09/restrict-certific...

[1] https://tools.ietf.org/html/rfc5280#page-41

[2] https://github.com/est31/rcgen/commit/059cc19fcd1b8bb57feed5...

Thanks!

It is no more complicated than a self signed certificate. Two clicks in Firefox, 4 taps in iOS

Every time and no tracking if device indentity changes.

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

Honestly, 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.

No. Your DNS can also be locally, so you have no Internet dependence.

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

Will you also add it to the iPhones of other people that would want to use the device? (Or more realistically, would they let you add it?)

Depends on them I guess. If it's a corporate phone then it's no problem. The rest can either add it or get used to cert warnings.

If you're in a context where you can personally install it on phones of friends and relatives, that will work, I agree.

I'm thinking of an example to illustrate what I mean. (Sorry if this appears to be moving the goalposts)

Imagine some small business is selling a home surveillance camera, or a network printer or whatever else. The thing is that it's a product intended for perivate, layman consumers and intended for LAN use.

With HTTP, you could add a local web server as a simple way to manage the device pretty easily: Just open a server, communicate the IP address to the user, done. No internet connection required, no continuing support from the company required. Even if the company went bust, the existing units continued to work and the web interface stayed accessible.

There seems to be no good way to replicate this with HTTPS. The closest seems indeed to be a custom root CA - however, then you need to communicate to your users how to install the CA certificate on their own devices, clicking through all kinds of scary warnings and dismissing "this section is for admins only" notices. I predict that not a lot of people would do that.

This also leaves you with the challange to safely get the certificate to your users. You could serve the certificate from the device over HTTP - however, then you'll require that your customers download a root certificate, over an unencrypted connection without any integrity checks and install it on their device. This seems like ripping open a mojor security hole.

Meanwhile, even if the company purchases a domain and attempts to get a certificate from a public CA, deployment will be difficult as described in all the other branches of this thread.

In short, I think you can pick any three of the following four conditions, but I see no way to archieve all four at the same time.

(1) use modern web features (all recently added and all future features require https)

(2) have your site usable on a client device that does not belong to you

(3) present a non-confusing user experience (no cert warnings, etc)

(4) have the device stay accessible even after you stop actively supporting it (by purchasing domains, running cloud services, having deals with CAs, etc etc)

> This also leaves you with the challange to safely get the certificate to your users.

Because the hardware vendor does not own nor configure the private network, they are not able to certify to the network’s users that a particular network node is the device it’s supposed to be, and not an impersonator. Only the network administrators can do that, and so it is the network administrators that must generate the certificate and install it on the device. In this way the admins bestow a programatic declaration of trust on the network node.

The device manufacturers can only provide tools for showing that the device was not tampered with. TLS/SSL certificates are not for that purpose.

This only applies if they want to access internal services without cert warnings, so asking them to install a cert seems reasonable?

> Honestly, my main issue is not even the price, it's that devices cannot be stand-alone anymore.

I'm wondering where the impression fo" not any more" comes from. Really the situation hasn't changed much. You can have your HTTP webinterface. You can have HTTPS with a selfsigned cert and click away the warning. The only thing that really has changed is that for your HTTP connection you will get a warning that the connection is not secure.

I don't think the ability of browsers to load HTTP pages will go away any time soon.

Aren't browsers preventing submission of form data over http now?

A .net is 83 cents a month.

That's usually a limited special offer. Not everyone wants to change domains every year.

https://www.cloudflare.com/products/registrar/

There’s always the .local TLD, which is reserved for this use case:

https://en.m.wikipedia.org/wiki/.local

I haven't heard about that yet. this sounds interesting indeed. But how would I get a valid certificate for a .local domain?

You 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.)

That works, but you can't get public certs for it, because you can't prove you own that domain (indeed, you don't :))

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

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

Why not just use mDNS too and stick with .local?

I think you’re talking about running DNS locally (not sure) and resolving .local addresses by DNS. In that case, yes, the devices that do lookups by mDNS will experience a delay caused by first querying mDNS before falling back onto DNS. The solution is to set up mDNS for the internal resources.

Using an unregistered domain like .lan has serious security implications. See here: https://serverfault.com/a/17566

.lan is called out in appendix G of the MDNS RFC as "not recommended, but many people do this".

Personally speaking, I'm not too worried about .lan getting registered as a gTLD anytime soon. I'm a lot more worried about forgetting to renew my domain and having things horrifically break if/when that domain gets picked up by someone else. This is a lot more likely...

I’m not sure I understand... What would break on your local network if a public domain you own and use only for internal resources is registered by someone else? How is this different from making up a domain name? In both cases you have to set up something to resolve the names to IP addresses on your local network, be it a hosts file or DNS. I would expect that to keep working regardless of the ownership of the domain name.

I would have said the same about .dev, and did, until Google came along and registered it.

Reply on news.ycombinator.com