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

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

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.

> 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 every atom with a length makes is very tedious to write by hand.

Which is why the advanced representation exists. I contend that this:

    (urn:ietf:params:acme:error:malformed
     (detail "Some of the identifiers requested were rejected")
     (subproblems ((urn:ietf:params:acme:error:malformed
                    (detail "Invalid underscore in DNS name \"_example.org\"")
                    (identifier (dns _example.org)))
                   (urn:ietf:params:acme:error:rejectedIdentifier
                    (detail "This CA will not issue for \"example.net\"")
                    (identifier (dns example.net))))))

    {
        "type": "urn:ietf:params:acme:error:malformed",
        "detail": "Some of the identifiers requested were rejected",
        "subproblems": [
            {
                "type": "urn:ietf:params:acme:error:malformed",
                "detail": "Invalid underscore in DNS name \"_example.org\"",
                "identifier": {
                    "type": "dns",
                    "value": "_example.org"
                }
            },
            {
                "type": "urn:ietf:params:acme:error:rejectedIdentifier",
                "detail": "This CA will not issue for \"example.net\"",
                "identifier": {
                    "type": "dns",
                    "value": "example.net"
                }
            }
        ]
    }

As you can see, no you do not.

> Canonical S-expressions are not as easy to read and much harder to write by hand

You don't do that, any more than you read or write machine code in binary. You read and write regular S-expressions (or assembly code) and you translate that into and out of canonical S expressions (or machine code) with a tool (an assembler/disassembler).

you can use a program to convert between s-expressions and a more readable format. In a world where canonical s-expressions rule, this "more readable format" would probably be an ordinary s-expression

For very big numbers (that could appear in these fields), generating and parsing a base 10 decimal representation is way more cumbersome than using their binary representation.

The DER encoding used in the TLS certificates uses the big endian binary format. OpenSSL API wants the big endian binary too.

The format used by this protocol is a simple one.

It's almost exactly the format that is needed to use these numbers, except JSON can't store binary data directly. Converting binary to base 64 is a simple operation (just bit twiddling, no division), and it's easier than converting arbitrarily large numbers between base 2 and base 10. The 17-bit value happens to be an easy one, but other values may need thousands of bits.

It would be silly for the sender and recipient to need to use a BigNum library when the sender has the bytes and the recipient wants the bytes, and neither has use for a decimal number.

Some parsers, like PHP, may treat 65537 and "65537" the same. Room for vulnerability.

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

For actual SERDES, JSON becomes very brittle. It's better to use something like protobuf or cap'n'proto for such cases.

Because canonical S-expressions don’t have numbers, just atoms (i.e., byte sequences) and lists. It is up to the using code to interpret "34" as the string "34" or the number 34 or the number 13,108 or the number 13,363, which is part of the protocol being used. In most instances, the byte sequence is probably a decimal number.

Now, S-expressions as used for programming languages such as Lisp do have numbers, but again Lisp has bignums. As for parsers of Lisp S-expressions written in other languages: if they want to comply with the standard, they need to support bignums.

I think they mean that Common Lisp has bigints by default

It's more a problem of support and backwards compatibility. JSON and parsers for it are so ubiquitous, and the spec completely lacks any versioning support, that adding a feature would be a breaking change of horrible magnitude, on nearly all levels of the modern software infrastructure stack. I wouldn't be surprised if some CPUs might break from that :D

JSON is a victim of its success: it has become too big to fail, and too big to improve.

There are easy workarounds to getting bigints in JSON: https://github.com/GoogleChromeLabs/jsbi/issues/30#issuecomm...

The question is how best to send the modulus, which is a much larger integer. For the reasons below, I'd argue that base64 is better. And if you're sending the modulus in base64, you may as well use the same approach for the exponent sent along with it.

For RSA-4096, the modulus is 4096 bits = 512 bytes in binary, which (for my test key) is 684 characters in base64 or 1233 characters in decimal. So the base64 version is much smaller.

Base64 is also more efficient to deal with. An RSA implementation will typically work with the numbers in binary form, so for the base64 encoding you just need to convert the bytes, which is a simple O(n) transformation. Converting the number between binary and decimal, on the other hand, is O(n^2) if done naively, or O(some complicated expression bigger than n log n) if done optimally.

Besides computational complexity, there's also implementation complexity. Base conversion is an algorithm that you normally don't have to implement as part of an RSA implementation. You might argue that it's not hard to find some library to do base conversion for you. Some programming languages even have built-in bigint types. But you typically want to avoid using general-purpose bigint implementations for cryptography. You want to stick to cryptographic libraries, which typically aim to make all operations constant-time to avoid timing side channels. Indeed, the apparent ease-of-use of decimal would arguably be a bad thing since it would encourage implementors to just use a standard bigint type to carry the values around.

You could argue that the same concern applies to base64, but it should be relatively safe to use a naive implementation of base64, since it's going to be a straightforward linear scan over the bytes with less room for timing side channels (though not none).

Converting large integers to decimal is nontrivial, especially when you don't trust languages to handle large numbers.

Why you wouldn't just use the hexadecimal that everyone else seems to use I don't know. There seems to be a rather arbitrary cutoff where people prefer base64 to hexadecimal.

This sounds like an XY problem to me. There is already an alternative that is at least as secure and only requires a single base-64 string: Ed25519.

PHP (at least old versions I worked with) treats "65537" and 65537 similarly.

Cost.

Too likely that this would not work because silent conversion to number along the way

I prefer

  >> import json, decimal
  >> j = "47234762761726473624762746721647624764380000000000000000000000000000000000000000000"
  >> json.loads(j, parse_float=decimal.Decimal, parse_int=decimal.Decimal)
  Decimal('47234762761726473624762746721647624764380000000000000000000000000000000000000000000')

  >> import json
  >> j = "0.47234762761726473624762746721647624764380000000000000000000000000000000000000000000"
  >> json.loads(j)
  0.47234762761726473

  >> import json, decimal
  >> j = "0.47234762761726473624762746721647624764380000000000000000000000000000000000000000000"
  >> json.loads(j, parse_float=decimal.Decimal, parse_int=decimal.Decimal)
  Decimal('0.47234762761726473624762746721647624764380000000000000000000000000000000000000000000')

Just cross your fingers and hope for the best if your data is at any point decoded by a json library that doesn’t support bigints? Python’s ability to handle them is beside the point of they get mangled into ieee754 doubles along the way.

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

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.

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.

to quote the article (or rather, the 2023 article which is the one mentioning the number 3).

"Somehow, a couple of weeks ago, I found this other site which claimed to be better than LE and which used relatively simple HTTP requests without a bunch of funny data types."

"This is when the fine print finally appeared. This service only lets you mint 90 day certificates on the free tier. Also, you can only do three of them. Then you're done. 270 days for one domain or 3 domains for 90 days, and then you're screwed. Isn't that great? "

She don't mention what this "other site" is.

Everything is an object, identified by a URL. You start from a single URL (the directory), and you can find all the rest of the resources from URLs provided from there.

ACME models everything as JSON objects, each of which is identified by URL. You can GET them, and they link to other objects with Location and Link headers.

To quote from the blog post:

> Dig around in the headers of the response, looking for one named "Location". Don't follow it like a redirection. Why would you ever follow a Location header in a HTTP header, right? Nope, that's your user account's identifier! Yes, you are a URL now.

I don't know if it's the pure ideal of HATEOS, but it's about as close as I've seen in use.

It has the classic failing though: it’s used by scripts which know exactly what they want to do (get a cert), so the clients still hardcode the actions they need. It just adds a layer of indirection as they need to keep track of URLs.

I would have preferred if it was just an RPC-over-HTTP/JSON with fixed endpoints and numeric object IDs.

REST has for a long long time meant "rpc via json over http". HATEOAS is a mythical beast nobody has ever seen in the wild.

No the author seems opposed to the idea specification of ACME, not just the implementation of the clients.

And a lot of the complaints ultimately boil down to not liking JWS. And I'm not really sure what she would have preferred there. ASN.1, which is even more complicated? Some bespoke format where implementations can't make use of existing libraries?

I disagree, the author is overcomplicating and overthinking things.

She doesn't "trust" tooling that basically the entire Internet including major security-conscious organizations are using, essentially letting perfect get in the way of good.

I think if she were a less capable engineer she would just set that shit up using the easiest way possible and forget about it like everyone else, and nothing bad would happen. Download nginx proxy manager, click click click, boom I have a wilcard cert, who cares?

I mean, this is her https site, which seems to just be a blog? What type of risk is she mitigating here?

Essentially the author is so skilled that she's letting perfect get in the way of good.

I haven't thought about certificates for years because it's not worth my time. I don't really care about the tooling, it's not my problem, and it's never caused a security issue. Put your shit behind a load balancer and you don't even need to run any ACME software on your own server.

This is the same author that threw everyone into a panic about atop and turned out to not really have found anything.

Im not a container guru by any means (at least not yet?) but would docker not suffice these concerns?

> Some people don't want to be forced to run a bunch of stuff they don't understand on the server

It's not just about not understanding, it's that more complex stuff is inherently more prone to security vulnerabilities, however well you think you reviewed its code.

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.

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

There are a number of shell-based ACME clients whose prerequisites are: OpenSSL and cURL. You're probably already relying on OpenSSL and cURL for a bunch of things already.

If you can read shell code you can step through the logic and understand what they're doing. Some of them (e.g., acme.sh) often run as a service user (e.g., default install from FreeBSD ports) so the code runs unprivileged: just add a sudo (or doas) config to allow it to restart Apache/nginx.

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.

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

Honest question:

* Do you understand OS syscalls in detail?

* Do you understand how your BIOS initializes your hardware?

* Do you understand how modern filesystems work?

* Do you understand the finer details of HTTP or TCP?

Because... I don't. But I know enough about them that I'm quite convinced each of them is a lot more difficult to understand than ACME. And all of them and a lot more stuff are required if you want to run a web server.

Nice thanks! I’ve been wanted to learn it as dealing with cert expirations every year is a pain. My guess is that we will have 24 hour certs at some point.

Looks like a good class; is it only available to enrolled students? videos seem to be behind a log-in wall.

Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.

Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

https://news.ycombinator.com/newsguidelines.html

So instead of designing simpler protocols (like HTTP/1.1 is), we do not care and let AI figure it out? Sounds great to me... /s

I said it was dead-simple and you delivered a treatise describing the most complex use case possible. Then maybe it's not for you.

Most software in the OpenBSD base system lacks features on purpose. Their dev team frequently rejects patches and feature requests without compelling reasons to exist. Less features means less places for things to go wrong means less chance of security bugs.

It exists so their simple webserver (also in the base system) has ACME support working out of the box. No third party software to install, no bullshit to configure, everything just works as part of a super compact OS. Which to this day still fits on a single CD-ROM.

Most of all no stupid Rust compiler needed so it works on i386 (Rust cannot self-host on i386 because it's so bloated it runs out of memory, which is why Rust tools are not included in i386).

If your needs exceed this or you adore complexity then feel free to look elsewhere.

There's no easy way to "just" transmit data in a foolproof manner. You practically need to support CSRs as a CA anyway, so you might as well use the existing ASN.1+X509 system to transmit data.

ASN.1 and X509 aren't all that bad. It's a comprehensively documented binary format that's efficient and used everywhere, even if it's hidden away in binary protocols you don't look at every day.

Unlike what most people seem to think, ACME isn't something invented just for Let's Encrypt. Let's Encrypt was certainly the first high-profile CA to implement the protocol, but various CAs (free and paid) have their own ACME servers and have had them for ages now. It's a generic protocol for certificate authorities to securely do domain validation and certificate provisioning that Let's Encrypt implemented first.

The unnecessarily complex parts of the protocol when writing a from-the-ground-up client are complex because ACME didn't reinvent the wheel, and reused existing standard protocols instead. Unfortunately, that means having to deal with JWS, but on the other hand, it means most people don't need to write their own ACME-JWS-replacement-protocol parsers. All the other parts are complex because the problem ACME is solving is actually quite complex.

The author wrote [another post](https://rachelbythebay.com/w/2023/01/03/ssl/) about the time they fell for the lies of a CA that promised an "easier" solution. That solution is pretty much ACME, but with more manual steps (like registering an account, entering domain names).

I personally think that for this (and for many other protocols, to be honest) XML would've been a better fit as its parsers are more resilient against weird data, but these days talking about XML will make people look at you like you're proposing COBOL. Hell, I even exchanging raw, binary ASN.1 messages would probably have gone over pretty well, as you need ASN.1 to generate the CSR and request the certificate anyway. But, people chose "modern" JSON instead, so now we're base64 encoding values that JSON parsers will inevitably fuck up instead.

Yes, we actually considered the "have the protocol transmit all of the required math values in a decent form and get an x.509 cert back" version, but some people who were interested in using Let's Encrypt were apparently very keen on being able to use an existing external CSR. So that became mandatory in order not to have two totally separate code paths for X.509-based requests and non-X.509-based requests.

An argument for this is that it makes it theoretically possible for devices that have no knowledge of anything about PKI since the year 2000, and/or no additional programmability, to use Let's Encrypt certs (obtained on their behalf by an external client application). I have, in fact, subsequently gotten something like that to work as a consultant.

> does a 4096 not give you more security against passive capture and future decrypting?

If the server was using a key exchange that did not support forward secrecy then yes. But:

    % echo | openssl s_client -connect rachelbythebay.com:443 2>/dev/null | grep Cipher
    New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384

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.

Does this only work if LE can reach port 443 on one of your servers/proxies?

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

With the HTTP implementation that's true, but the DNS implementation of certbot's certificate request plugins don't touch your server config. As an added bonus, you can use that to also obtain wildcard certificates for your subdomains so different applications can share the same certificate (so you only need one single ACME client).

You can configure certbot to write in a directory directly and it won't touch your web server config.

> It munges your web server config (temporarily) to handle http challenges

I run it in "webroot" mode on NgINX servers so it's just a matter of including the relevant config file in your HTTP sections (likely before redirecting to HTTPS) so that "/.well-known/acme-challenge/" works correctly. Then when you do run certbot, it can put the challenge file into the webroot and NgINX will automatically serve it. This allows certbot to do its thing without needing to do anything with NgINX.

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

I only started using it after the default was ZeroSSL, but it's easy to specify LetsEncrypt instead

There's no good reason to serve a blog over TLS. You're not handling sensitive data, so unencrypted is just fine.

Why? I can understand the argument that you don’t want an ISP or a middlebox injecting ads or scripts (valid I think even if I’ve never encountered it to my knowledge), but otherwise you’re publishing content intended for the world. There’s presumably nothing especially sensitive that you need to hide on the wire.

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.