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

351–360 of 437 posts

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

#351

Post by eadmund »

ncruces wrote: post #134
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…

Go can decode numbers losslessly as strings: https://pkg.go.dev/encoding/json#Number json.Number is (almost) my “favorite” arbitrary decimal: https://github.com/ncruces/decimal?tab=readme-ov-file#decima... I'm half joking, but I'm not sure why S-expressions would be better here. There are LISPs that don't do arbitrary precision math.

> Go can decode numbers losslessly as strings: https://pkg.go.dev/encoding/json#Number

Yup, and if you’re using JSON in Go you really do need to be using Number exclusively. Anything else will lead to pain.

> I'm half joking, but I'm not sure why S-expressions would be better here. There are LISPs that don't do arbitrary precision math.

Sure, but I’m referring specifically to https://www.ietf.org/archive/id/draft-rivest-sexp-13.html, which only has lists and bytes, and so number are always just strings and it’s up to the program to interpret them.

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

#352

Post by alterom »

kens wrote: post #166
matja wrote: post #72

Earlier quoted context omitted.

Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float? It's a shame JSON parsers usually default to performance rather than correctness, by using bignums for numbers.

> Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float? That sentence has four negations and I honestly can't figure out what it means.

>> Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float?

>That sentence has four negations and I honestly can't figure out what it means.

This example is halfway as bad as the one Orwell gives in my favorite essay, "Politics the the English Language"¹.

Compare and contrast:

>I am not, indeed, sure whether it is not true to say that the Milton who once seemed not unlike a seventeenth-century Shelley had not become, out of an experience ever more bitter in each year, more alien (sic) to the founder of that Jesuit sect which nothing could induce him to tolerate.

Orwell has much to say about either.

_____

¹https://www.orwellfoundation.com/the-orwell-foundation/orwel...

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

#353

Post by upofadown »

nothrabannosir wrote: post #246
arkadiyt wrote: post #245

> 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

Amateur question: does a 4096 not give you more security against passive capture and future decrypting? Or is the intermediate also a factor in such an async attack?

The certificate is for authentication of the server. It has nothing to do with the encryption of the data.

Basically forward secrecy is where both the sender and receiver throw away the key after the data is decrypted. That way the key is not available for an attacker to get access to later. If the attacker can find some way other than access to the key to decrypt the data then forward secrecy has no benefit.

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

#354

Post by gethly »

I too am not a fan of ACME and LE. I'd rather manually buy and activate the certificate once per year rather than deal with the "automation" that everyone is constantly overjoyed with. And that was the case for Gethly.com since the beginning. But the prices of certificates are not cheap and they provide ZERO advantage over the free LE certificates. Especially the wildcard certificates, which are the only types that make any sense whatsoever anyway. So a decisions was made to switch to LE with DNS challenge, which is the only type that supports wildcard certificates. Long story short, DNS provider had this built-in and so now it is a 50:50 automation and manual work. DNS provider sends a notification when certificate is going to expire and to get the new one and that is about it. A matter of two minutes of manual labour to sign into DNS provider's interface, copy the certificate and paste it into actively running application that then simply distributes it to all services. Longer story - doing the DNS challenge with DNS provider's API was doable, but ACME failed to detect updated records so luckily, instead of wasting time trying to get it working, DNS provider got us covered from the get-go.

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

#357

Post by ddtaylor »

> Random side note: while looking at existing ACME clients, I found that at least one of them screws up their encoding of the publicExponent and ends up interpreting it as hex instead of decimal. That is, instead of 65537, aka 0x10001, it reads it as 0x65537, aka 415031! > > Somehow, this anomaly exists and apparently doesn't break anything? I haven't actually run the client in question, but I imagine people are using it since it's in apt.

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

#358

Post by antonvs »

eadmund wrote: post #348
thayne wrote: post #249

Earlier quoted context omitted.

Your example uses s-expressions, not canonical s-expressions. Canonical s expressions[1] is basically a binary format. Each atom/string is prefixed by a decimal length of the string and a colon. It's advantage over regular s expressions is that there is no need to escape or quote strings with whitespace, and there is only a single possible representation for a given data structure. The disadvantage is it is much hard…

> 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 authoring and reading, which doesn't address transport at all. The name is short, pronounceable (vs. "spikky" perhaps?), and clearly refers to one thing - there's no ambiguity about whether you might be talking about a transport encoding instead,

I'm not saying these are good reasons to adopt JSON over SPKI, just that there's a level of ambition in Rivest's proposal which is a poor match for how adoption tends to work in the real world.

There are several mechanism for JSON transport encoding - including plain old gzip, but also more specific formats like MessagePack. There isn't one single standard for it, but as it turns out that really isn't that important.

Arguably there's a kind of violation of separation of concerns happening in a proposal that tries to define all these things at once: "a canonical form ... two transport representations, and ... an advanced format".

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

#359

Post by amiga386 »

ipdashc wrote: post #167
tptacek wrote: post #132

Earlier quoted context omitted.

Non-ACME certs are basically over. The writing has been on the wall for a long time. I understand people being squeamish about it; we fear change. But I think it's a hopeful thing: the Web PKI is evolving. This is what that looks like: you can't evolve and retain everyone's prior workflows, and that has been a pathology across basically all Internet security standards work for decades.

ACME is cool (compared to what came before it), but I'm kind of sad that EV certs never seemed to pan out at all. I feel like they're a neat concept, and had the potential to mitigate a lot of scams or phishing websites in an ideal world. (That said, discriminating between "big companies" and "everyone else who can't afford it" would definitely have some obvious downsides.) Does anyone know why they never took off?

Because they actively thwarted security.

https://arstechnica.com/information-technology/2017/12/nope-...

https://web.archive.org/web/20191220215533/https://stripe.ia...

> this site uses an EV certificate for "Stripe, Inc", that was legitimately issued by Comodo. However, when you hear "Stripe, Inc", you are probably thinking of the payment processor incorporated in Delaware. Here, though, you are talking to the "Stripe, Inc" incorporated in Kentucky.

There's a lot of validation that's difficult to get around in DV (Domain Validation) and in DNS generally. Unless you go to every legal jurisdiction in the world and open businesses and file and have granted trademarks, you _cannot_ guarantee that no other person will have the same visible EV identity as you.

It's up to visitors to know that apple.com is where you buy Apple stuff, while apple.net, applecart.com, 4ppl3.com, аррlе.сом, ., example.com/https://apple.com are not. But if they can manage that, they can trust apple.com more than they could any URL with an "Apple, Inc." EV certificate. When browsers show the URL bar tend to highlight the top-level domain prominently, and they reject DNS names with mixed script, to avoid scammers fooling you. It's working better than EV.

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

#360

Post by kevin_thibedeau »

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…

> clearly refers to one thing

Great, this looks like JSON. Is it JSON5? Does it expect bigint support? Can I use escape chars?

Post reply on HN