| ▲ | mcpherrinm 2 months ago |
| 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. |
|
| ▲ | cryptonector 2 months ago | parent | next [-] |
| > 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. |
| |
| ▲ | mcpherrinm 2 months ago | parent | next [-] | | 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. | | |
| ▲ | cryptonector 2 months ago | parent [-] | | 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! |
| |
| ▲ | asimops 2 months ago | parent | prev [-] | | 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. | | |
| ▲ | cryptonector 2 months ago | parent [-] | | > 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. |
|
|
|
| ▲ | dwedge 2 months ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | belorn 2 months ago | parent | next [-] | | 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. | | |
| ▲ | jchw 2 months ago | parent [-] | | 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. | | |
| ▲ | killjoywashere 2 months ago | parent | next [-] | | 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. | |
| ▲ | AStonesThrow 2 months ago | parent | prev | next [-] | | > 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 | | |
| ▲ | jchw 2 months ago | parent [-] | | I'm glad to give you an xkcd 1053 moment. Honest Achmed is one for the books. |
| |
| ▲ | arccy 2 months ago | parent | prev | next [-] | | Google's CA offers them for free via ACME https://pki.goog/ | | |
| ▲ | jchw 2 months ago | parent [-] | | 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. |
| |
| ▲ | birktj 2 months ago | parent | prev | next [-] | | 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... | |
| ▲ | rmetzler 2 months ago | parent | prev | next [-] | | A while ago I saw that acme.sh now uses ZeroSSL by default. https://github.com/acmesh-official/acme.sh/blob/42bbd1b44af4... | | |
| ▲ | _hyn3 2 months ago | parent [-] | | "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. | | |
| ▲ | rsync 2 months ago | parent [-] | | 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 ? |
|
| |
| ▲ | nickf 2 months ago | parent | prev [-] | | 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. | | |
| ▲ | mkup 2 months ago | parent [-] | | 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? | | |
|
|
| |
| ▲ | 2 months ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | tasuki 2 months ago | parent | prev [-] |
| > 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"? |
| |
| ▲ | mcpherrinm 2 months ago | parent | next [-] | | 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. | | |
| ▲ | tasuki 2 months ago | parent [-] | | That's pretty good! Better than 99% claims of REST for sure! Thanks for the long reply. |
| |
| ▲ | peanut-walrus 2 months ago | parent | prev [-] | | 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. | | |
| ▲ | hamburglar 2 months ago | parent [-] | | 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. |
|
|
