Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

I don't actually see the problem. If you're on a local network, there's no practical way to deal with certificates, so use http. Chrome will fall back. Problem solved.

If http support ever gets truly removed, I will be very upset. But that hasn't happened, so what is there to complain about?

View on HN

HTTP is effectively considered legacy by the big web actors these days. More and more APIs are HTTPS-only (often for good reasons) and the "insecure" warnings you get from using HTTP become more intrusive every year.

The trajectory is pretty clear, the long term plan is to phase out HTTP completely. And I'm not against it, but I need a solution for LAN devices, and it doesn't exist at the moment because the big web actors do everything in the cloud these days and they don't care about this use case.

I AM against it, because it puts more centralized censorship power in the hands of the certificate authority.

Also, it completely cuts out "legacy" devices, basically anything more than 5 years old.

The Web is once again splitting into AOLized mainstream and "indie underground" that you have to make an effort to access.

Who is "the certificate authority" you're referring to here?

The OP means that in using https (and being forced to used https) you are also being forced into paying a 'third party' an annual fee just to get a valid certificate.

That 'third party' is one of the recognized 'certificate authorities'.

But the OPs point is by going https, you don't have a choice, you have to pay the certificate tax.

Right, and Let's Encrypt doesn't solve the problem, it just kicks the can to DNS, which is globally unique and costs money. Communicating between your computer and any device that you supposedly own without the slow, unnecessary, and increasingly intrusive permission of some cloud IoT stack will become more and more difficult.

This is not true, you can set your host to trust a self signed certificate without much difficulty. Check out this tool for example https://github.com/FiloSottile/mkcert (prev discussion at https://news.ycombinator.com/item?id=17748208)

Self signing doesn’t let the world access my website without some scary warning.

That’s irrelevant to this discussion about hosting sites on a LAN with no internet access.

If you need https on the public internet you need a trusted cert.

Don't think personal LAN, think e.g. industrial automation: Many sensible companies want modern sensor systems that provide REST APIs and so on, but don't want those to access the internet. The hosts in this case often are appliance-like devices from third parties.

But that’s my point, and many others’. Sure, we can self sign, but it’s useless for the WWW. You’re forced to pay up to one of the few certificate providers. Thankfully, Let’s Encrypt has made it free and easier, but it’s not a no-brainer.

I would like to trust a given root very for only a specific domain (and sub domain)

I.e *.int.mycorp.com, but not www.mybank.com

Browsers don’t let me do that, it’s either app or nothing. X509 name constraints aren’t great either and don’t give me, the browser operator, the power.

How long do you think it would take someone who has never been to HN?

I don't think they would even know the option exists.

Letsencrypt provide a really good service.

I can recommend the docker image made by linuxserver in particular [0]. Makes Https a (tax free) breeze.

[0] https://docs.linuxserver.io/general/swag

That's OK then, if that's we all have to do to run any devices inside our LAN/home network.

Want a NAS box for sharing family files/photos or some other IoT device at home? Just set yourself up some other device to run the docker image, get your self a certificate from LetsEncrypt and then... install it on the NAS box? How does that happen?

The authority who grants you your SSL certificate. There is more than one out there, sure, but you can't do it without them. And ultimately, they all answer to the same authority above them: the browser maker who populates the root trust store.

So, to summarize: one more way for the browser maker to control what the user can and cannot access without jumping through hoops.

Perfect time to radicalize the underground (say by beginning to experiment with Gemini or other protocols), the mainstream as usual only knows how to follow

I prefer HTTP :)

Gemini requires TLS 1.2 or higher.

But it doesn't rely on CAs. It relies on TOFU.

Let’s encrypt exists, your argument is moot.

Can you use it on a microcontroller in a home network?

The problem is that there is no way to deal with certs on a local network, but the OP would like to be able to use https anyways; http might be considered too insecure for their usecase

Make your own CA, install on each computer, install certificates, voila.

Repeat every 3 months or whenever the root certs expire.

3 months? I must have updated FireFox / Discord / VS Code /etc. about a hundred times in last 3 months. Plenty for them to add renewed SSL whatevers inside one of the updates.

> 3 months? I must have updated FireFox / Discord / VS Code /etc.

I think this state of affairs is nuts. With the exception of Firefox, because web browsers have an inordinate number of security issues to contend with.

And other programs don't?

An instant messaging client shouldn’t be executing arbitrary remote code, no.

It's not really possible to prevent that. E.g. a well crafted image can easily trigger an RCE on some older versions of Android: https://nakedsecurity.sophos.com/2019/02/08/android-vulnerab...

Issues like this exist at all layers of the stack, so anything touching the internet needs regular security patches.

I agree completely. But, I also think that in most cases, if a simplistic piece of software like an IM app needs a security patch every three months, regularly, it's a sign the attack surface is too large.

Why would the certs you create for this purpose be made to expire?

It needs to expire before 397 days, because otherwise the CA will not be valid, even if it is marked as trusted. https://www.zdnet.com/article/google-wants-to-reduce-lifespa...

edit: a word

The article you linked to is kind of confused and I'm not sure I blame them. This stuff is really complex!

According to the proposal[0], leaf certificates are prohibited from being signed with a validity window of more than 397 days by a CA/B[1] compliant Certificate authority. This is very VERY different from the cert not being valid. It means that a CA could absolutely make you a certificate that violated these rules. If a CA signed a certificate with a longer window, they would risk having their root CA removed from the CA/B trust store which would make their root certificate pretty much worthless.

To validate this, you can look at the CA certificates that Google has[2] that are set to expire in 2036 (scroll down to "Download CA certificates" and expand the "Root CAs" section) several of which have been issued since that CA/B governance change.

As of right now, as far as I know, Chrome will continue to trust certificates that are signed with a larger window. I've not heard anything about browsers enforcing validity windows or anything like that, but would be delighted to find out the ways that I'm wrong if you can point me to a link.

Further, your home made root certificate will almost certainly not be accepted by CA/B into their trust store (and it sounds like you wouldn't want that) which means you're not bound by their governance. Feel free to issue yourself a certificate that lasts 1000 years and certifies that you're made out of marshmallows or whatever you want. As long as you install the public part of the CA into your devices it'll work great and your phone/laptop/whatever will be 100% sure you're made out of puffed sugar.

I guess I have to disclose that I'm an xoogler who worked on certificate issuance infrastructure and that this is my opinion, that my opinons are bad and I should feel bad :zoidberg:.

[0] https://github.com/cabforum/servercert/pull/138/commits/2b06... [1] https://en.wikipedia.org/wiki/CA/Browser_Forum [2] https://pki.goog/repository/

Telling your clients to install your certificate in their computer/browser store is not very practical. And they will need to do that regularly.

It shouldn’t be practical, that’s by design. Imagine if every captive portal had you install their root certificate to access the WiFi, with just the click of a button.

Not regularly, my root is 10 years long.

What I do is buy localme.xyz and get a wildcard cert via DNS validation. This way you get SSL for offline devices. But you need to update the cert periodically.

I wish there was a way to automate wildcard certs, at the moment I'm building a python script that logins to my domain registrar's panel and updates DNS records

let's encrypt supports wildcard certificates: https://community.letsencrypt.org/t/acme-v2-and-wildcard-cer...

If your domain provider's API sucks, or doesn't exist, or requires generating a password/key with more permissions than you're willing to give a script, look at acme-dns [1] and delegated DNS challenges:

https://github.com/joohoi/acme-dns

HTTP does not solve the problem if you still want your traffic encrypted in transit.

Reply on news.ycombinator.com