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

241–250 of 437 posts

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

#241

Post by pharrington »

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…

The entire reason ACME exists is because you are never writing or reading the CSR by hand.

So of course, ACME is based around a format whose entire reason d'etre is being written and read by hand.

It's weird.

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

#242

Post by JoshTriplett »

schoen wrote: post #224
JoshTriplett wrote: post #53

Earlier quoted context omitted.

> Why? The days of MITM boxes injecting content into HTTP traffic are basically over The reason you don't see many MITM boxes injecting content into HTTP anymore is because of widespread HTTPS adoption and browsers taking steps to distrust HTTP, making MITM injection a near-useless tactic. (This rhymes with the observation that some people now perceive Y2K as overhyped fear-mongering that amounted to nothing, without…

https://en.wikipedia.org/wiki/Preparedness_paradox

Thank you!

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

#243

Post by eddythompson80 »

eadmund wrote: post #201
cortesoft wrote: post #192

Earlier quoted context omitted.

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

> is far easier to read than this (the first JSON in RFC 8555):

It's not for me. I'd literally take anything over csexps. Like there is nothing that I'd prefer it to. If it's the only format around, then I'll just roll my own.

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

#244

Post by faresahmed »

jazzyjackson wrote: post #193
JackSlateur wrote: post #188

Earlier quoted context omitted.

Is this ok ? Python 3.13.3 (main, May 21 2025, 07:49:52) [GCC 14.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> json.loads('47234762761726473624762746721647624764380000000000000000000000000000000000000000000') 47234762761726473624762746721647624764380000000000000000000000000000000000000000000

yes, python falls into the sane language category with arbitrary-precision arithmetic

Not so much,

    >>> s="1"+"0"*4300
    >>> json.loads(s)
    ...
    ValueError: Exceeds the limit (4300 digits) for integer string conversion: 
    value has 4301 digits; use sys.set_int_max_str_digits() to increase the limit
This was done to prevent DoS attacks 3 years ago and have been backported to at least CPython 3.9 as it was considered a CVE.

Relevant discussion: https://news.ycombinator.com/item?id=32753235

Your sibling comment suggests using decimal.Decimal which handles parsing >4300 digit numbers (by default).

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

#245

Post by arkadiyt »

> 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

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

#246

Post by nothrabannosir »

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?

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

#247

Post by pixl97 »

drob518 wrote: post #190
pixl97 wrote: post #161

Earlier quoted context omitted.

There is no such thing as static content. There is only content. Bits are sent to your browser which it then applies the DOM to. If you want to ensure the bits that were sent from the server to your browser they must be signed in some method.

Right, that’s exactly my point.

Oh sorry I misunderstood your statement, yes, that's correct.

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

#248

Post by jongjong »

The whole DNS and TLS system is overcomplicated and was designed to allow a small number of orgs to dominate the internet.

I've been thinking of using a Blockchain to register domain name-to-IP-address mappings in a cryptographically secure way and then writing a Chrome extension which connects to the Blockchain (to any known peer IP; it would start from a few hardcoded seed node IPs and discover more peers as is standard for most Blockchains and P2P protocols; or you could host your own blockchain node locally and use it as your personal DNS service) and then the extension can do DNS lookups on-chain. The Chrome extension could act as an alternative address bar; type the address in there and it would read the Blockchain to figure out the IP address, completely bypassing the whole mess of a DNS system and the current centralized mess of an internet... We could then store all the certs on-chain in a similar way, just make it support the bare minimum necessary to get the browser to shut up and accept the cert whilst maintaining the essential cryptographic security guarantees.

It's kind of ridiculous how easy it would be, technically, to create an alternative internet and DNS system. I think there are already similar solutions like Brave browser supporting a parallel internet with .eth domains but they don't seem to get much attention. There needs to be search engines for these alternative internets to get things going.

Surely once the current internet gets spammed into oblivion and becomes devoid of opportunities, there should be an incentive use create an alternative system from scratch. Surely there is a point when a network of scarce data is better than one of abundant spam data.

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

#249

Post by thayne »

eadmund wrote: post #201
cortesoft wrote: post #192

Earlier quoted context omitted.

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

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 harder to write and read by humans.

As for s-expressions vs json, there are pros and cons to each. S-expressions don't have any way to encode type information in the data itself, you need a schema to know if a certain value should be treated as a number or a string. And it's subjective which is more readable.

[1]: https://en.m.wikipedia.org/wiki/Canonical_S-expressions

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

#250

Post by thayne »

pharrington wrote: post #241
cortesoft wrote: post #192

Earlier quoted context omitted.

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

The entire reason ACME exists is because you are never writing or reading the CSR by hand. So of course, ACME is based around a format whose entire reason d'etre is being written and read by hand. It's weird.

The reason json is a good format for ACME isn't that it is easy to read and write by hand[1], but that most languages have at least one decent json implementation available, so it is easier to implement clients in many different languages.

[1]: although being easy to read by humans is an advantage when debugging why something isn't working.

Post reply on HN