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

141–150 of 437 posts

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

#141

Post by GoblinSlayer »

unscaled wrote: post #76
tux3 wrote: post #6

JOSE/JWK is indeed some galactically overengineered piece of spec, but the rest seems.. fine? There are private keys and hash functions involved. But base64url and json aren't the worst web crimes to have been inflicted upon us. It's not _that_ bad, is it?

Yes, JOSE is certainly overengineered and JWK is arguably somewhat overengineered as well. But "the rest" of ACME also include X.509 certificates and PKCS#10 Certificate Signing Requests, which are in turn based on ASN.1 (you're fortunate enough you only need DER encoding) and RSA parameters. ASN.1 and X.509 are devilishly complex if you don't let openssl do everything for you and even if you do. The first few paragr…

>ASN.1 and X.509 are devilishly complex

Most of it is unused though, only CN, SANs and public key are used.

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

#143

Post by 01HNNWZ0MV43FF »

marcosdumay wrote: post #126
eadmund wrote: post #61

> So, yes, instead of saying that "e" equals "65537", you're saying that "e" equals "AQAB". Aren't you glad you did those extra steps? Oh JSON. For those unfamiliar with the reason here, it’s that JSON parsers cannot be relied upon to treat numbers properly. Is 4723476276172647362476274672164762476438 a valid JSON number? Yes, of course it is. What will a JSON parser due with it? Silently truncate it to a 64-bit or 6…

What I don't understand is why you (and a lot of other people) just expect S-expression parsers to not have the exact same problems.

I think they mean that Common Lisp has bigints by default

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

#144

Post by mr_toad »

wolf550e wrote: post #101

Implementing an ACME client in python using pyca/cryptography (or in Go) would be fine, but why do it in C++ ?

Not everyone wants to deal with maintaining Python and untold dependencies on their web server. A C++ binary often has no additional dependencies, and even if it does they’ll be dealt with by the OS package manager.

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

#145

Post by [deleted] »

marcosdumay wrote: post #126
eadmund wrote: post #61

> So, yes, instead of saying that "e" equals "65537", you're saying that "e" equals "AQAB". Aren't you glad you did those extra steps? Oh JSON. For those unfamiliar with the reason here, it’s that JSON parsers cannot be relied upon to treat numbers properly. Is 4723476276172647362476274672164762476438 a valid JSON number? Yes, of course it is. What will a JSON parser due with it? Silently truncate it to a 64-bit or 6…

What I don't understand is why you (and a lot of other people) just expect S-expression parsers to not have the exact same problems.

[deleted]

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

#146

Post by Aachen »

They thought it was too complex and therefore insecure so the natural solution was to roll your own implementation and now they feel comfortable running that version of it?!

Edit: to be clear, I'd not be too surprised if their homegrown client survives an audit unscathed, I'm sure they're a great coder, but the odds just don't seem better than to the alternative of using an existing client that was already audited by professionals as well as other people

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

#147

Post by cAtte_ »

bigstrat2003 wrote: post #135
g-b-r wrote: post #42

Earlier quoted context omitted.

For god's sake, however complex ACME might be it's better than not supporting TLS

There's no good reason to serve a blog over TLS. You're not handling sensitive data, so unencrypted is just fine.

relevant blog post and HN discussion: https://news.ycombinator.com/item?id=22146291

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

#148

Post by [deleted] »

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…

[deleted]

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

#149

Post by kevingadd »

q3k wrote: post #105
matja wrote: post #102

Earlier quoted context omitted.

So a JSON parser that cannot store a 2 is technically compliant? :(

Yep. Or one that parses it into a 7 :)

I once debugged a production issue that boiled down to "A PCI compliance .dll was messing with floating point flags, causing the number 4 to unserialize as 12"

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

#150

Post by Arnavion »

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…

You can have multiple TXT records for the same domain identifier, and the ACME server will look through all of them to find the one that it expects. So for an order that requests SANs example.org and *.example.org, where the server asks for two authorizations to be completed for _acme-challenge.example.org, you can create both TXT records at the same time.

https://datatracker.ietf.org/doc/html/rfc8555#section-8.4

>2. Query for TXT *records* for the validation domain name

>3. Verify that the contents of *one of the TXT records* match the digest value

(Emphasis mine.)

Post reply on HN