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

371–380 of 437 posts

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

#371

Post by llm_nerd »

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…

>JSON is better than XML

JSON is still hack garbage compared to XML from the turn of the millennia. Like most dominant tech standards, JSON took hold purely because many developers are intellectually lazy and it was easier to slam some sloppy JSON together than to understand XML.

XML with XSD, XPath and XQuery is simply a glorious combination.

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

#372

Post by cryptonector »

asimops wrote: post #332
cryptonector wrote: post #203

Earlier quoted context omitted.

> 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 n…

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.

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

#373

Post by wat10000 »

antonvs wrote: post #358
eadmund wrote: post #348

Earlier quoted context omitted.

> Your example uses s-expressions, not canonical s-expressions. I’ve always used ‘canonical S-expressions’ to refer to Rivest’s S-expressions proposal: https://www.ietf.org/archive/id/draft-rivest-sexp-13.html , a proposal which has canonical, basic transport & advanced transport representations which are all equivalent to one another (i.e., every advanced transport representation has a single canonical representatio…

That Rivest draft defines canonical S-expressions to be the format in which every token is preceded by its length, so it's confusing to use "canonical" to describe the whole proposal, or use it as a synonym for the "advanced" S-expressions that the draft describes. But that perhaps hints at some reasons that formats like JSON tend to win popularity contests over formats like Rivest's. JSON is a single format for auth…

JSON also had the major advantage of having an enormous ecosystem from day 1. It was ugly and kind of insecure, but the fact that every JavaScript implementation could already parse and emit JSON out of the box was a huge boost. It’s hard to beat that even if you have the best format in the world.

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

#374

Post by motorest »

cortesoft wrote: post #192
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…

> Canonical S-expressions would have been far preferable, but for whatever reason the world didn’t go that way. I feel like not understanding why JSON won out is being intentionally obtuse. JSON can easily be hand written, edited, and read for most data. Canonical S-expressions are not as easy to read and much harder to write by hand; having to prefix every atom with a length makes is very tedious to write by hand. I…

> I feel like not understanding why JSON won out is being intentionally obtuse. JSON can easily be hand written, edited, and read for most data.

You are going way out of your way to try to come up with ways to rationalize why JSON was a success. The ugly truth is far simpler than what you're trying to sell: it was valid JavaScript. JavaScript WebApps could parse JSON with a call to eval(). No deserialization madness like XML, no need to import a parser. Just fetch a file, pass it to eval(), and you're done.

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

#375

Post by tasuki »

mcpherrinm wrote: post #189

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…

> 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"?

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

#376

Post by anonymousiam »

aaronmdjones wrote: post #307
anonymousiam wrote: post #277

Earlier quoted context omitted.

Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't. I don't really buy this explanation. It's a very large unsigned number. Everyone knows this. Is there some arbitrary precision library in use that forces large integers to be signed? Even if it were signed, or had the MSB set, it wouldn't change any of the bits, so the key would still be the same. So why would we care about the…

> Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't. This is probably a bug (where an unsigned integer with its high bit set is not printed with a leading 00) and should be reported. Note that RSA key moduli generated by OpenSSL will always have the high bit set, and so will always have 00 prepended when you ask it to print them. The same is not necessarily true of other integer…

Excellent reply. Thank you!

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

#377

Post by jchw »

arccy wrote: post #347
jchw wrote: post #214

Earlier quoted context omitted.

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.

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.

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

#378

Post by wlonkly »

benlivengood wrote: post #237

Apache (is anyone else still using that?) now ships with an official ACME module, which is nice. Professionally it's been cert-manager. I haven't paid for a TLS certificate in almost a decade I guess.

The Caddy[1] webserver also has built-in ACME. It has all the problems Rachel mentioned, of course, because now it's an ACME client embedded in an even bigger piece of software, but it's handy for sure!

I don't know much about Caddy scalability but it's worked great for my personal sites.

[1] https://caddyserver.com/

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

#379

Post by antonvs »

kevin_thibedeau wrote: post #360
antonvs wrote: post #358

Earlier quoted context omitted.

That Rivest draft defines canonical S-expressions to be the format in which every token is preceded by its length, so it's confusing to use "canonical" to describe the whole proposal, or use it as a synonym for the "advanced" S-expressions that the draft describes. But that perhaps hints at some reasons that formats like JSON tend to win popularity contests over formats like Rivest's. JSON is a single format for auth…

> clearly refers to one thing Great, this looks like JSON. Is it JSON5? Does it expect bigint support? Can I use escape chars?

You're providing an example of my point. People don't, in general, care about any of that, so "solving" those "problems" isn't likely to help adoption.

To your specific points:

1. JSON5 didn't exist when JSON adoption occurred, and in any case they're pretty easy to tell apart, because JSON requires keys to be quoted. This is a non-problem. Why do you think it might matter? Not to mention that the existence of some other format that resembles JSON is hardly a reflection on JSON itself, except perhaps as a compliment to its perceived usefulness.

2. Bigint support is not a requirement that most people have. It makes no difference to adoption.

3. Escape character handling is pretty well defined in ECMA 404. Your point is so obscure I don't even know specifically what you might be referring to.

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

#380

Post by mcpherrinm »

cryptonector wrote: post #203
mcpherrinm wrote: post #189

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…

> 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 n…

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.

Post reply on HN