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

61–70 of 437 posts

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

#61

Post by eadmund »

> 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 63-bit integer, or a float, probably or if you’re very lucky emit an error (a good JSON decoder written in a sane language like Common Lisp would of course just return the number, but few of us are so lucky).

So the only way to reliably get large integers into and out of JSON is to encode them as something else. Base64-encoded big-endian bytes is not a terrible choice. Silently doing the wrong thing is the root of many security errors, so it not wrong to treat every number in the protocol this way. Of course, then one loses the readability of JSON.

JSON is better than XML, but it really isn’t great. Canonical S-expressions would have been far preferable, but for whatever reason the world didn’t go that way.

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

#62

Post by hansvm »

egorfine wrote: post #32

> import JSON (something I use as little as possible) This makes me wonder what world of development she is in. Does she prefer SOAP?

JSON is slow, not particularly comfortable for humans to work with, uses dangerous casts by default, is especially dangerous when it crosses library or language boundaries, has the exponential escaping problem when people try to embed submessages, relies on each client to appropriately validate every field, doesn't have any good solution for binary data, is prone to stack overflow when handling nested structures, etc.

If the author says they dislike JSON, especially given the tone of this article with respect to nonsensical protocols, I highly doubt they approve of SOAP.

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

#63

Post by sam_lowry_ »

JoshTriplett wrote: post #53
sam_lowry_ wrote: post #49

Earlier quoted context omitted.

Why? The days of MITM boxes injecting content into HTTP traffic are basically over, and frankly they never were a thing in my part of the world. I see no other reason to serve content over HTTPS.

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

How do browsers distrust HTTP, exactly?

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

#64

Post by castillar76 »

Bender wrote: post #25
christina97 wrote: post #8

Earlier quoted context omitted.

I used to like them, then they somehow sold out to zerossl and switched the default there from LE after an update. Pinned to an old version and looking for a replacement right now.

That annoyed me as well given the wording on the ZeroSSL site suggested one has to create an account which is not true. I had hit an error using DNS-01 at the time. They have an entirely different page for ACME clients but it is not or was not linked from anywhere on the main page. If anyone else ran into that it's just a matter of adding --server letsencrypt

You can also permanently change your default to LE — acme.sh actually has instructions for doing so in their wiki.

I rather liked using ZeroSSL for a long time (perhaps just out of knee-jerk resistance to the “Just drink the Koolaid^W^W^Wuse Let’s Encrypt! C’mon man, everyone’s doing it!” nature of LE usage), but of late ZeroSSL has gotten so unreliable that I’ve rolled my eyes and started swapping things back to LE.

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

#65

Post by memset »

orion138 wrote: post #47

Not the main point of the article, but the author’s comments on Gandi made me wonder: What registrar do people recommend in 2025?

I have moved to porkbun.

I have built a registrar in the past and have a lot of arcane knowledge about how they work. Just need to figure out a way to monetize!

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

#66

Post by JoshTriplett »

ndsipa_pomu wrote: post #4

I was amazed by them having so much distrust of the various clients. Certbot is typically in the repositories for things like Debian/Ubuntu. My favourite client is probably https://github.com/acmesh-official/acme.sh If you use a DNS service provider that supports it, you can use the DNS-01 challenge to get a certificate - that means that you can have the acme.sh running on a completely different server which should h…

Certbot is definitely one of the strongest arguments against ACME and Let's Encrypt.

Personally, I find that tls-alpn-01 is even nicer than dns-01. You can run a web server (or reverse proxy) that listens to port 443, and nothing else, and have it automatically obtain and renew TLS certificates, with the challenges being sent via TLS ALPN over the same port you're already listening on. Several web servers and reverse proxies have support for it built in, so you just configure your domain name and the email address you want to use for your Let's Encrypt account, and you get working TLS.

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

#67

Post by egorfine »

hansvm wrote: post #62
egorfine wrote: post #32

> import JSON (something I use as little as possible) This makes me wonder what world of development she is in. Does she prefer SOAP?

JSON is slow, not particularly comfortable for humans to work with, uses dangerous casts by default, is especially dangerous when it crosses library or language boundaries, has the exponential escaping problem when people try to embed submessages, relies on each client to appropriately validate every field, doesn't have any good solution for binary data, is prone to stack overflow when handling nested structures, etc…

> JSON is [...]

What would you suggest instead given all these cons?

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

#68

Post by drob518 »

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…

Seems like a large integer can always be communicated as a vector of byte values in some specific endian order, which is easier to deal with than Base64 since a JSON parser will at least convert the byte value from text to binary for you.

But yea, as a Clojure guy sexprs or EDN would be much better.

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

#69

Post by castillar76 »

skywhopper wrote: post #7
ndsipa_pomu wrote: post #4

I was amazed by them having so much distrust of the various clients. Certbot is typically in the repositories for things like Debian/Ubuntu. My favourite client is probably https://github.com/acmesh-official/acme.sh If you use a DNS service provider that supports it, you can use the DNS-01 challenge to get a certificate - that means that you can have the acme.sh running on a completely different server which should h…

Certbot goes out of its way to be inscrutable about what it’s doing. It munges your web server config (temporarily) to handle http challenges, and for true sysadmins who are used to having to know all the details of what’s going on, that sort of script is a nightmare waiting to happen. I assume certbot is the client she’s alluding to that misinterprets one of the factors in the protocol as hex vs decimal and somehow…

Having my ACME client munge my webserver configs to obtain a cert was one of the supreme annoyances about using them — it felt severely constraining on how I structured my configs, and even though it’s a blip, I hated the double restart required to fetch a cert (restart with new config, restart with new cert).

Then I discovered the web-root approach people mention here and it made a huge difference. Now I have the HTTP snippet in my server set to serve up ACME challenges from a static directory and push everything else to HTTPS, and the ACME client just needs write permission to that directory. I can dynamically include that snippet in all of the sites my server handles and be done.

If I really felt like it, I could even write a wrapper function so the ACME client doesn’t even need restart permissions on the web-server (for me, probably too much to bother with, but for someone like Rachel perhaps worthwhile).

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

#70

Post by horsawlarway »

codeduck wrote: post #56
egorfine wrote: post #32

> import JSON (something I use as little as possible) This makes me wonder what world of development she is in. Does she prefer SOAP?

Given her experience and work history, it's much more likely that she views any text-based protocol as an unnecessary abstraction over simply processing raw TCP.

Is this a joke? I don't even know where to begin with this comment... It reads like a joke, but I suspect it's not?

TCP is just a bunch of bytes... You can't process a bunch of bytes without understanding what they are, and that requires signaling information at a different level (ex - in the bytes themselves as a defined protocol like SSH, SCP, HTTP, etc - or some other pre-shared information between server and client [the worst of protocols - custom bullshit]).

Post reply on HN