Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I no longer have an old-school cert on my HTTPS site

rachelbythebay.com

Post reply on HN
Print view View original

81–90 of 437 posts

Re: Why I no longer have an old-school cert on my HTTPS site

#81

Post by kjs3 »

hannob wrote: post #23
immibis wrote: post #12

Earlier quoted context omitted.

Some people don't want to be forced to run a bunch of stuff they don't understand on the server, and I agree with them. Sadly, security is a cat and mouse game, which means it's always evolving and you're forced to keep up - and it's inherent by the nature of the field, so we can't really blame anyone (unlike, say, being forced to integrate with the latest Google services to be allowed on the Play Store). At least yo…

> Some people don't want to be forced to run a bunch of stuff they > don't understand on the server, and I agree with them. Honest question: * Do you understand OS syscalls in detail? * Do you understand how your BIOS initializes your hardware? * Do you understand how modern filesystems work? * Do you understand the finer details of HTTP or TCP? Because... I don't. But I know enough about them that I'm quite convince…

I hear some variation of this line of 'reasoning' about once a week, and it's always followed by some variation of "...and that's why we shouldn't have to do all this security stuff you want us to do".

Re: Why I no longer have an old-school cert on my HTTPS site

#82

Post by castillar76 »

sam_lowry_ wrote: post #63
JoshTriplett wrote: post #53

Earlier quoted context omitted.

> Why? The days of MITM boxes injecting content into HTTP traffic are basically over The reason you don't see many MITM boxes injecting content into HTTP anymore is because of widespread HTTPS adoption and browsers taking steps to distrust HTTP, making MITM injection a near-useless tactic. (This rhymes with the observation that some people now perceive Y2K as overhyped fear-mongering that amounted to nothing, without…

How do browsers distrust HTTP, exactly?

They’ve been making it harder and harder to serve things over HTTP-only for a while now. Steps like marking HTTP with big “NOT SECURE” labels and trying to auto-push to HTTP have been pretty effective. (With the exception of certain contexts, I think this is a generally good trend, FWIW.)

Re: Why I no longer have an old-school cert on my HTTPS site

#83

Post by JoshTriplett »

sam_lowry_ wrote: post #63
JoshTriplett wrote: post #53

Earlier quoted context omitted.

> Why? The days of MITM boxes injecting content into HTTP traffic are basically over The reason you don't see many MITM boxes injecting content into HTTP anymore is because of widespread HTTPS adoption and browsers taking steps to distrust HTTP, making MITM injection a near-useless tactic. (This rhymes with the observation that some people now perceive Y2K as overhyped fear-mongering that amounted to nothing, without…

How do browsers distrust HTTP, exactly?

They show any site served over HTTP as explicitly not secure in the address bar (making HTTPS the "default" and HTTP the visibly dangerous option), they limit many web APIs to sites served over HTTPS ( https://developer.mozilla.org/en-US/docs/Web/Security/Secure...) , https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ), they block or upgrade mixed-content by default (HTTPS sites cannot request HTTP-only resources anymore), they require HTTPS for HTTP/2 and HTTP/3, they increasingly attempt HTTPS to a site first even if linked/typed as http, they warn about downloads over http, and they're continuing to ratchet up such measures over time.

Re: Why I no longer have an old-school cert on my HTTPS site

#84

Post by drob518 »

pixl97 wrote: post #50
amiga386 wrote: post #35

Things change over time. Part of not wanting to let go is the sunk cost fallacy. Part of it is being suspicious of being (more) dependent on someone else (than you are already dependent on a different someone else). (As an aside, the n-gate guy who ranted against HTTPS in general and thought static content should just be HTTP also thought like that. Unfortunately, as I'm at a sketchy cafe using their wifi, his page c…

> thought static content should just be HTTP Yep, I've seen that argument so many times and it should never make sense to anyone that understands MITM. The only way it could possibly work is if the static content were signed somehow, but then you need another protocol the browser and you need a way to exchange keys securely, for example like signed RPMs. It would be less expensive as the encryption happens once, but…

The argument doesn’t even make sense for static content ignoring mitm attacks.

Re: Why I no longer have an old-school cert on my HTTPS site

#85

Post by fpoling »

XorNot wrote: post #71
z3t4 wrote: post #19

At some stage you need to update your TXT records, and if you register a wildcard domain you have to do it twice for the same request! And you have to propagate these TXT records twice to all your DNS servers, and wait for some third party like google dns to request the TXT record. And it all has to be done within a minute in order to not time out. DNS servers are not made to change records from one second to another…

Or just use the HTTP protocol, which works fine.

For wildcard certificates DNS is the only option.

Re: Why I no longer have an old-school cert on my HTTPS site

#86

Post by Shadowmist »

JoshTriplett wrote: post #66
ndsipa_pomu wrote: post #4

I was amazed by them having so much distrust of the various clients. Certbot is typically in the repositories for things like Debian/Ubuntu. My favourite client is probably https://github.com/acmesh-official/acme.sh If you use a DNS service provider that supports it, you can use the DNS-01 challenge to get a certificate - that means that you can have the acme.sh running on a completely different server which should h…

Certbot is definitely one of the strongest arguments against ACME and Let's Encrypt. Personally, I find that tls-alpn-01 is even nicer than dns-01. You can run a web server (or reverse proxy) that listens to port 443, and nothing else, and have it automatically obtain and renew TLS certificates, with the challenges being sent via TLS ALPN over the same port you're already listening on. Several web servers and reverse…

Does this only work if LE can reach port 443 on one of your servers/proxies?

Re: Why I no longer have an old-school cert on my HTTPS site

#87

Post by JoshTriplett »

Shadowmist wrote: post #86
JoshTriplett wrote: post #66

Earlier quoted context omitted.

Certbot is definitely one of the strongest arguments against ACME and Let's Encrypt. Personally, I find that tls-alpn-01 is even nicer than dns-01. You can run a web server (or reverse proxy) that listens to port 443, and nothing else, and have it automatically obtain and renew TLS certificates, with the challenges being sent via TLS ALPN over the same port you're already listening on. Several web servers and reverse…

Does this only work if LE can reach port 443 on one of your servers/proxies?

Yes. If you want to create certificates for a private server you have to use a different mechanism, such as dns-01.

Re: Why I no longer have an old-school cert on my HTTPS site

#89

Post by xorcist »

ndsipa_pomu wrote: post #4

I was amazed by them having so much distrust of the various clients. Certbot is typically in the repositories for things like Debian/Ubuntu. My favourite client is probably https://github.com/acmesh-official/acme.sh If you use a DNS service provider that supports it, you can use the DNS-01 challenge to get a certificate - that means that you can have the acme.sh running on a completely different server which should h…

acme.sh is 8000 lines, still a magnitude better than certbot for something security-critical, but not great.

tiny-acme.py is 200 lines, easy to audit and incorporate parts into your own infrastructure. It works well for the tiny work it does but it does support anything more modern.

Re: Why I no longer have an old-school cert on my HTTPS site

#90

Post by jeroenhd »

mschuster91 wrote: post #41
jeroenhd wrote: post #11

There's something to be said for implementing stuff like this manually for the experience of having done it yourself, but the author's tone makes it sound like she hates the protocol and all the extra work she needs to do to make the Let's Encrypt setup work. Kind of makes me wonder what kind of stack her website is running on that something like a lightweight ACME library ( https://github.com/jmccl/acme-lw comes to…

> but the author's tone makes it sound like she hates the protocol and all the extra work she needs to do to make the Let's Encrypt setup work. The problem is, SSL is a fucking hot, ossified mess . Many of the noted core issues, especially the weirdnesses around encoding and bitfields, are due to historical baggage of ASN.1/X.509. It's not fun to deal with it, at all... the math alone is bad enough, but the old abstr…

There's no easy way to "just" transmit data in a foolproof manner. You practically need to support CSRs as a CA anyway, so you might as well use the existing ASN.1+X509 system to transmit data.

ASN.1 and X509 aren't all that bad. It's a comprehensively documented binary format that's efficient and used everywhere, even if it's hidden away in binary protocols you don't look at every day.

Unlike what most people seem to think, ACME isn't something invented just for Let's Encrypt. Let's Encrypt was certainly the first high-profile CA to implement the protocol, but various CAs (free and paid) have their own ACME servers and have had them for ages now. It's a generic protocol for certificate authorities to securely do domain validation and certificate provisioning that Let's Encrypt implemented first.

The unnecessarily complex parts of the protocol when writing a from-the-ground-up client are complex because ACME didn't reinvent the wheel, and reused existing standard protocols instead. Unfortunately, that means having to deal with JWS, but on the other hand, it means most people don't need to write their own ACME-JWS-replacement-protocol parsers. All the other parts are complex because the problem ACME is solving is actually quite complex.

The author wrote [another post](https://rachelbythebay.com/w/2023/01/03/ssl/) about the time they fell for the lies of a CA that promised an "easier" solution. That solution is pretty much ACME, but with more manual steps (like registering an account, entering domain names).

I personally think that for this (and for many other protocols, to be honest) XML would've been a better fit as its parsers are more resilient against weird data, but these days talking about XML will make people look at you like you're proposing COBOL. Hell, I even exchanging raw, binary ASN.1 messages would probably have gone over pretty well, as you need ASN.1 to generate the CSR and request the certificate anyway. But, people chose "modern" JSON instead, so now we're base64 encoding values that JSON parsers will inevitably fuck up instead.

Post reply on HN