Why I no longer have an old-school cert on my HTTPS site • Hacker News Board

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

#301

Post by lucideer » Sat, May 24, 2025, 8:26 AM UTC

paul_h wrote: post #290

lucideer wrote: post #118

Earlier quoted context omitted.

I use docker for the same reasons as the author's reservations - I combine a docker exec with some of my own loose automation around moving & chmod-ing files & directories to obviate the need for the acme client to have unfettered root access to my system. Whether it's a local binary or a dockerised one, that access still needs to be marshalled either way & it can get complex facilitating that with a docker container…

Copilot suggests: docker run --rm \ -v /srv/mywebsite/certs:/acme.sh/certs \ -v /srv/mywebsite/public/.well-known/acme- challenge:/acme-challenge \ neilpang/acme.sh --issue \ --webroot /acme-challenge \ -d yourdomain.com \ --cert-file /acme.sh/certs/cert.pem \ --key-file /acme.sh/certs/key.pem \ --fullchain-file /acme.sh/certs/fullchain.pem I don't know why it's suggesting `neilpang` though, as he no longer has a for…

Yeah I'm not running anything llms spit at me in a security-sensitive context.

That example is not so bad - you've already pointed out the main obvious supply-chain attack vector in referencing a random ephemeral fork, but otherwise it's certonly (presumably neil's default) so it's the simplest case. Many clients have more... intrusive defaults that prioritise first-run cert onboarding which is opening more surface area for write error.

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

#302

Post by dmwilcox » Sat, May 24, 2025, 8:38 AM UTC

horsawlarway wrote: post #70

codeduck wrote: post #56

Earlier quoted context omitted.

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

__attribute__(packed) structs with an enum at the front indicating their type. The receivers use a switch to figure out which sub-message to interpret the strict as...

It isn't pretty and you better be able to control the rollout of both sides because backwards compatibility will not be a thing. But I'll take it over a giant pile of code generation in many circumstances

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

#303

Post by mras0 » Sat, May 24, 2025, 8:42 AM UTC

anonymousiam wrote: post #277

aaronmdjones wrote: post #223

Earlier quoted context omitted.

If the leading bit is set, it could be interpreted as a signed negative number. Prepending 00 guarantees that this doesn't happen.

Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't. I don't really buy this explanation. It's a very large unsigned number. Everyone knows this. Is there some arbitrary precision library in use that forces large integers to be signed? Even if it were signed, or had the MSB set, it wouldn't change any of the bits, so the key would still be the same. So why would we care about the…

The standard format for RSA private keys is ASN.1 (https://www.rfc-editor.org/rfc/rfc8017#appendix-C) with the components encoded as INTEGERs. An INTEGER is always signed in ASN.1, so you need the leading 0 byte if the MSB of your positive number is set.

OpenSSL is just dumping the raw bytes comprising the value. Tools that don't show a leading zero in this case are doing a bit more interpretation (or just treating it as an unsigned value) to show you the number you expect.

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

#304

Post by shiandow » Sat, May 24, 2025, 8:43 AM UTC

kangalioo wrote: post #139

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…

But what's wrong with sending the number as a string? `"65537"` instead of `"AQAB"`

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.

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

#305

Post by GoblinSlayer » Sat, May 24, 2025, 8:44 AM UTC

foobiekr wrote: post #185

JoshTriplett wrote: post #83

Earlier quoted context omitted.

They show any site served over HTTP as explicitly not secure in the address bar (making HTTPS the "default" and HTTP the visibly dangerous option), they limit many web APIs to sites served over HTTPS ( https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ) , https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ), they block or upgrade mixed-content by default (HTTPS sites cannot request HTTP-onl…

If browser vendors really cared, they would disable javascript on non-https sites.

https://googleprojectzero.blogspot.com/2025/03/blasting-past...

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

#306

Post by fulafel » Sat, May 24, 2025, 8:54 AM UTC

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…

Is the correct number implementation really the exception? The first 2 json decoders I just tried (Python & Clojure) worked correctly with that example.

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

#307

Post by aaronmdjones » Sat, May 24, 2025, 9:02 AM UTC

anonymousiam wrote: post #277

aaronmdjones wrote: post #223

Earlier quoted context omitted.

If the leading bit is set, it could be interpreted as a signed negative number. Prepending 00 guarantees that this doesn't happen.

Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't. I don't really buy this explanation. It's a very large unsigned number. Everyone knows this. Is there some arbitrary precision library in use that forces large integers to be signed? Even if it were signed, or had the MSB set, it wouldn't change any of the bits, so the key would still be the same. So why would we care about the…

> Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't.

This is probably a bug (where an unsigned integer with its high bit set is not printed with a leading 00) and should be reported.

Note that RSA key moduli generated by OpenSSL will always have the high bit set, and so will always have 00 prepended when you ask it to print them. The same is not necessarily true of other integers.

This is trivial to demonstrate:

    $ while true ; do openssl genrsa 1024 2>/dev/null | openssl rsa -text 2>/dev/null | grep -A1 modulus | tail -n1 | egrep -v '^\s*00:[89abcdef]' ; done

> I don't really buy this explanation. It's a very large unsigned number. Everyone knows this.

Everyone knows that an RSA modulus is a very large unsigned number yes. Not everyone knows that every number is unsigned.

> Is there some arbitrary precision library in use that forces large integers to be signed?

OpenSSL's own BN (BigNum) library, which tests if the high bit is set in the input (line 482):

https://github.com/openssl/openssl/blob/a0d1af6574ae6a0e3872...

> Even if it were signed, or had the MSB set, it wouldn't change any of the bits, so the key would still be the same. So why would we care about the sign?

Because the encoding doesn't care about the context. RFC 3279 specifies that the modulus and exponent are encoded as INTEGERs:

https://datatracker.ietf.org/doc/html/rfc3279#section-2.3.1

... and INTEGERs are signed (which means OpenSSL has to use signedness == SIGNED):

https://learn.microsoft.com/en-us/windows/win32/seccertenrol...

    Integer values are encoded into a TLV triplet that begins with a Tag
    value of 0x02.  The Value field of the TLV triplet contains the encoded
    integer if it is positive, or its two's complement if it is negative.
    If the integer is positive but the high order bit is set to 1, a leading
    0x00 is added to the content to indicate that the number is not negative.

See also the canonical specification (page 15, section 8.3): https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-...

This is exactly the same way that signed integers are represented in e.g. x86 (minus the leading tag and length fields) -- if the leading bit is set, the number is negative.

You're right that it wouldn't change any of the key's bits, but it would change the math performed on them, in a manner that would break it.

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

#308

Post by imtringued » Sat, May 24, 2025, 9:20 AM UTC

thayne wrote: post #254

lucideer wrote: post #38

Earlier quoted context omitted.

> I don't understand the tone of aggression against ACME and their plethora of clients. > ACME idea good, ACME implementation bad. Maybe I'm misreading but it sounds like you're on a similar page to the author. As they said at the top of the article: > Many of the existing clients are also scary code, and I was not about to run any of them on my machines. They haven't earned the right to run with privileges for my pr…

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?

This is exactly the impression I got here.

I would have had sympathy for the disdain for certbot, but certbot wasn't called out and that isn't what the blog post is about at all.

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

#309

Post by rendaw » Sat, May 24, 2025, 9:20 AM UTC

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 don't have an object/mapping type, which means you can't have generic tooling unambiguously perform certain common operations like data merges.

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

#310

Post by elric » Sat, May 24, 2025, 9:23 AM UTC

12_throw_away wrote: post #136

elric wrote: post #127

Earlier quoted context omitted.

Wildcard Certificates are your friend if you don't want all of your hostnames becoming public knowledge.

Having tried it myself, I can highly recommend a security posture that doesn't depend on the secrecy of any particular URL :)

Ah yes, that old chestnut again. Because there's only ever one way to secure anything, and defense in depth is apparently meaningless. Comments like this are not helpful.