Hacker News Reader

Comment by mcpherrinm | Hacker News Reader

I’m the technical lead for the Let’s Encrypt SRE/infra team. So I spend a lot of time thinking about this.

The salt here is deserved! JSON Web Signatures are a gnarly format, and the ACME API is pretty enthusiastic about being RESTful.

It’s not what I’d design. I think a lot of that came via the IETF wanting to use other IETF standards, and a dash of design-by-committee.

A few libraries (for JWS, JSON and HTTP) go a long way to making it more pleasant but those libraries themselves aren’t always that nice, especially in C.

I’m working on an interactive client and accompanying documentation to help here too, because the RFC language is a bit dense and often refers to other documents too.

View on HN

> JSON Web Signatures are a gnarly format

They are??

As someone who wallows in ASN.1, Kerberos, and PKI, I don't find JWS so "gnarly". Even if you're open-coding a JSON Web Signature it will be easier than to open-code S/MIME, CMS, Kerberos, etc. Can you explain what is so gnarly about JWS?

Mind you, there are problems with JWT. Mainly that HTTP user-agents don't know how to fetch the darned things because there is not standard for how to find out how to fetch the darned things, when you should honor a request for them, etc.

I'd take ASN.1/DER over JWS any day :) It's the weekend and I don't feel I have the energy to launch a full roast of JWS, but to give some flavour, I'll link

https://auth0.com/blog/critical-vulnerabilities-in-json-web-...

Implementations can be written securely, but it's too easy to make mistakes.

Yeah, there's worse stuff from the 90s around, but JOSE and ACME is newer than that - we could have done better!

Alas, it's not changing now.

I think ASN.1 has some warts, but I think a lot of the problems with DER are actually in creaky old tools. People seem way happier with Protobuf, for example: I think that's largely down to tooling.

The whole not validating the signatures thing is a problem, yes. That can happen with PKI certificates too, but those have been around longer and -perhaps because one needed an ASN.1 stack- only people with more experience wrote PKI stacks than we see in the case of JWS?

I think Protocol Buffers is a disaster. Its syntax is worse than ASN.1 because you're required to write in tags, and it is a TLV encoding very similar to DER so... why _why_ does PB exist? Don't tell me it's because there were no ASN.1 tools around -- there were no PB tools around either!

Don't you think you are falling for classic whataboutism here?

Just because ASN.1 and friends are exceptionally bad, it does not mean that Json Web * cannot be bad also.

> Don't you think you are falling for classic whataboutism here?

I do not. This sort of codec complexity can't be avoided. And ASN.1 is NOT "exceptionally bad" -- I rather like ASN.1. The point was not "wait till you see ASN.1", but "wait till you see Kerberos" because Kerberos requires a very large amount of client-side smarts -- too much really because it's got more than 30 years of cruft.

What is she talking about that you have to pay for certs if you want more than 3? Am I about to get a bill for the past 5 years or did she just misunderstand?

to quote the article (or rather, the 2023 article which is the one mentioning the number 3).

"Somehow, a couple of weeks ago, I found this other site which claimed to be better than LE and which used relatively simple HTTP requests without a bunch of funny data types."

"This is when the fine print finally appeared. This service only lets you mint 90 day certificates on the free tier. Also, you can only do three of them. Then you're done. 270 days for one domain or 3 domains for 90 days, and then you're screwed. Isn't that great? "

She don't mention what this "other site" is.

FWIW, it is ZeroSSL. I want there to be more major ACME providers than just LE, but I'm not sure about ZeroSSL, personally. It seems to have the same parent company as IdenTrust (HID Global Corporation). Probably a step up from Honest Achmed but recently I recall people complaining that their EV code signing certificates were not actually trusted by Windows which is... Interesting.

IdenTrust participates in the US Federal PKI ecosystem, so they likely have strong incentives to charge exorbitantly. Those free certs are probably meant to facilitate development of gov-specific capabilities by random subcontractors long enough to figure out how to structure a contract mod that passes the anticipated cost onto the government.

Don’t hate the player, hate the game.

> Honest Achmed

I had to stop and Google that, wondering if it was a pastiche of “Akbar & Jeff’s Certificate Hut”...

https://bugzilla.mozilla.org/show_bug.cgi?id=647959

I'm glad to give you an xkcd 1053 moment. Honest Achmed is one for the books.

Google's CA offers them for free via ACME https://pki.goog/

That's pretty cool, though it does seem that you need to authenticate with a GCP account. A little bit less convenient. I do think there are actually a few other providers of ACME out there that require registration beforehand, ZeroSSL actually offers it without pre-registration like Let's Encrypt.

Buypass provides ACME certificates as well [1]. The usage limits are not quite as generous as LE, but they work pretty well in my experience.

[1] https://www.buypass.com/products/tls-ssl-certificates/read-m...

A while ago I saw that acme.sh now uses ZeroSSL by default.

https://github.com/acmesh-official/acme.sh/blob/42bbd1b44af4...

"We now have another confirmation on Twitter that remote code is executed and a glimpse into what the script is... it appears to be benign."

https://github.com/acmesh-official/acme.sh/issues/4659

It was not. Don't use acme.sh.

I went down the acme/HiCA/RCE rabbit hole a year or so ago and, while I don't remember the specifics, my feeling was that the RCE was not that dangerous and was put into place by greedy scammers thwarting the rules of cert (re)selling and not by shadowy actors trying to infiltrate sensitive infra ...

Is there new information ? Was my impression wrong ?

ZeroSSL is owned by Identrust, but the infra is operated by another CA. Also Microsoft killed EV codesigning early last year - not stopping it working, just making it identical to ‘normal’ codesigning certs.

Could you please provide more info on this topic, e.g. a link? I intended to buy EV code signing certificate as a sole proprietor to fix long-standing problem with my software when Windows Defender pops up every time I release a new version. Is EV code signing certificate no longer a viable solution to this problem? Is there no longer a difference between EV and non-EV code signing certificate?

After Microsoft's March 2024 update, EV Code signing certs don't offer instant Microsoft Defender reputation. Now, OV and EV both code signing certificates can be installed and stored on FIPS 140 Level 2 or Common Criteria EAL 4+ certified HSM, tokens, or cloud HSMs. So, you can consider EV Code Signing as higher security and higher validation with no more difference. If u want to buy code signing at affordable cost, I recommend: https://signmycode.com/cheap-code-signing-certificates

Sure: https://learn.microsoft.com/en-us/security/trusted-root/prog...

3.D.3 covers the details about EV CS.

> and the ACME API is pretty enthusiastic about being RESTful

Without looking at it, are you sure about that?

I once used to know what REST meant. Are you doing REST as in HATEOAS or as in "we expose some http endpoints"?

Everything is an object, identified by a URL. You start from a single URL (the directory), and you can find all the rest of the resources from URLs provided from there.

ACME models everything as JSON objects, each of which is identified by URL. You can GET them, and they link to other objects with Location and Link headers.

To quote from the blog post:

> Dig around in the headers of the response, looking for one named "Location". Don't follow it like a redirection. Why would you ever follow a Location header in a HTTP header, right? Nope, that's your user account's identifier! Yes, you are a URL now.

I don't know if it's the pure ideal of HATEOS, but it's about as close as I've seen in use.

It has the classic failing though: it’s used by scripts which know exactly what they want to do (get a cert), so the clients still hardcode the actions they need. It just adds a layer of indirection as they need to keep track of URLs.

I would have preferred if it was just an RPC-over-HTTP/JSON with fixed endpoints and numeric object IDs.

That's pretty good! Better than 99% claims of REST for sure! Thanks for the long reply.

REST has for a long long time meant "rpc via json over http". HATEOAS is a mythical beast nobody has ever seen in the wild.

Eh, I think that’s what it meant for a while. I’ve now interacted with enough systems that have rigor about representing things as resources that have GET urls and doing writes with POST etc that I don’t think it’s always the ad hoc RPC fest it once was. It may be rare to see according-to-hoyle HATEOAS but REST is definitely no longer in the “nobody actually does this” category.

Reply on news.ycombinator.com