Live data from Hacker News

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

rachelbythebay.com

331–340 of 437 posts

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

#331
post #18
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…

Given that keys probably need to be shared between multiple gateway/ingresses, how common is it to just use some HSM or another mechanism of exchanging the keys with all the instances? The acme client doesn’t have to run on the servers itself.

You could if your domain was that valuable. Most aren't.

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

#332

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…

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.

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

#333
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…

Wouldn't it just solve a whole lot of problems if we could just add optional type declarations to json? It seems so simple and obvious that I'm kinda dumbfounded that this is not a thing yet. Most of the time you would not need it, but it would prevent the parser from making a wrong guess in all those edge cases. Probably there are types not every parser/language can accept, but at least it could throw a meaningful e…

This is actually a deliberate design choice, which the breathtakingly short JSON standard explains quite well [0]. The designers deliberately didn't introduce any semantics and pushes all that to the implementors. I think this is a defensible design goal. If you introduce semantics, you're sure to annoy someone.

There's an element of "worse is better" here [1]. JSON overtook XML exactly because it's so simple and solves for the social element of communication between disparate projects with wildly different philosophies, like UNIX byte-oriented I/O streams, or like the C calling conventions.

---

[0] https://ecma-international.org/publications-and-standards/st...

[1] https://en.wikipedia.org/wiki/Worse_is_better

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

#334

> Make an RSA key of 4096 bits. Call it your personal key. This is bad advice - making a 4096 bit key slows down visitors of your website and only gives you 2048 bits of security (if someone can break a 2048 bit RSA key they'll break the LetsEncrypt intermediate cert and can MITM your site). You should use a 2048 bit leaf certificate here

The key in question is the acme account key though, correct?

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

#336
I was totally horrified at all the acme clients I saw that were a hell of complexity and dependencies, and installing random things from internet until I found the one acme.sh that is a breeze.

You just need bash, no weird dependency, not that much complicated. Easy to manipulate.

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

#337
post #138
post #52

Earlier quoted context omitted.

Pork bun is my favorite.

I've been on Namecheap for years but I'm ready to move just because they refuse to support dynamic AAAA records. How's Porkbun on that front?

Not sure, I use dnsimple for dns and wrote my own little service to update my A record, no ip6 in my corner of the world so have not checked for AAAA record support.

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

#338
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…

The funny thing about this is that JavaScript the language has had support for BigIntegers for many years at this point. You can just write 123n for a bigint of 123.

JSON could easily be extended to support them - but there’s no standards body with the authority to make a change like that. So we’re probably stuck with json as-is forever. I really hope something better comes along that we can all agree on before I die of old age.

While we’re at it, I’d also love a way to embed binary data in json. And a canonical way to represent dates. And comments. And I’d like a sane, consistent way to express sum types. And sets and maps (with non string keys) - which JavaScript also natively supports. Sigh.

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

#339

Earlier quoted context omitted.

> I feel like not understanding why JSON won out is being intentionally obtuse. I didn’t feel like my comment was the right place to shill for an alternative, but rather to complain about JSON. But since you raise it. > JSON can easily be hand written, edited, and read for most data. So can canonical S-expressions! > Canonical S-expressions are not as easy to read and much harder to write by hand; having to prefix ev…

For you, perhaps. For me, the former is denser, but crossing into a "too dense" region. The JSON has indentation which is easy on my poor brain. Also, it's nice to differentiate between lists and objects. But, I mean, they're basically isomorphic with like 2 things exchanges ({} and [] instead of (); implicit vs explicit keys/types).

Yeah. I don’t even blame S-expressions. I think I’ve just been exposed to so much json at this point that my visual system has its own crappy json parser for pretty-printed json.

S expressions may well be better. But I don’t think S expressions are better enough to be able to overcome json’s inertia.

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

#340

Earlier quoted context omitted.

EV can't actually work. It was always about branding for the for-profit CAs so that they have a premium product which helps the line go up. Let me give you a brief history - you did ask. In about 2005, the browser vendors and the Certificate Authorities began meeting to see if they could reach some agreement as neither had what they wanted and both might benefit from changes. This is the creation of the CA/Browser Fo…

Still sounds better than nothing. And gives companies an incentive to register under their actual names.

I'm not convinced on either, the mindless automation is always effective so you just don't need to think about it, whereas for EV you need to intimately understand exactly which transactions you verified and what that means - the login HTML was authentic but you didn't check the Javascript? The entire login page was checked but HTTP POST of your password was not? The redirect to payment.mybank.example wasn't checked? Only the images were checked?

Imagine explaining to my mother how to properly check this, then imagine explaining why the check she just made is wrong now because the bank changed how their login procedure works.

We could have attempted something with better security, although nowhere close to fool proof, but the CAs were focused on a profitable product not on improving security, and I do not expect anyone to have another bite of that cherry.

As to the incentive to register, this is a cart v horse problem. Most businesses do not begin with a single unwavering vision of their eventual product and branding, they iterate, and that means the famous branding will need an expensive corporate change just to make the EV line up properly, that's just not going to happen much of the time, so people get used to seeing the "wrong" name and once that happens this is worthless.

Meanwhile crooks can spend a few bucks to register a similar-sounding name and registration authorities don't care, while the machine sees at a glance the differences between bobs-burgers.example and robs-burgers.example and bobsburgers.example, the analogous business registrations look similar enough that humans would click right past.

Post reply on HN