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

#261

Post by nothrabannosir » Sat, May 24, 2025, 4:16 AM UTC

dangus wrote: post #215

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…

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

Sometimes I wonder how y’all became programmers. I learned basically everything by SRE-larping on my shitty nobody-cares-home-server for years and suddenly got paid to do it for real.

Who do you think they hire to manage those LBs for you? People who never ran any ACME software, or people who have a blog post turning over every byte of JSON in the protocol in excruciating detail?

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

#262

Post by lmz » Sat, May 24, 2025, 4:23 AM UTC

oneplane wrote: post #107

lmz wrote: post #46

Earlier quoted context omitted.

Imagine coming from JWK and having to encode that public key into a CSR or something with that attitude.

Imagine writing your own security software when there are proven systems that just take that problem out of your hands so you don't need to complain about it.

I'm agreeing with you that the author is complaining too much. Going the other way they would probably go "and then we have to somehow encode the numbers '1 2 840 113549 1 1' somehow to mark the key type".

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

#263

Post by petre » Sat, May 24, 2025, 4:28 AM UTC

ryukafalz wrote: post #175

01HNNWZ0MV43FF wrote: post #143

Earlier quoted context omitted.

I think they mean that Common Lisp has bigints by default

As do Scheme and most other Lisps I'm familiar with, and integers/floats are typically specified to be distinct. I think we'd all be better off if that were true of JSON as well. I'd be happy to use s-expressions instead :) Though to GP's point, I suppose we might then end up with JS s-expression parsers that still treat ints and floats interchangeably.

And in addition to that are unable to distingush between a string "42" and a number 42.

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

#264

Post by arkadiyt » Sat, May 24, 2025, 4:28 AM UTC

nothrabannosir wrote: post #258

arkadiyt wrote: post #251

Earlier quoted context omitted.

> 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 ^ they're using ECDHE (elliptic curve diffie hellman), which is prov…

I thought FS only protected other sessions from leak of your current session key. How does it protect against passive recording of the session and later attacking of the recorded session in the future?

If using a non-FS key exchange (like RSA) then the value that the session key is derived from (the pre-master secret) is sent over the wire encrypted using the server's public key. If that session is recorded and in the future the server's private key is obtained, it can be used to decrypt the pre-master secret, derive the session key, and decrypt the entire session.

If on the other hand you use a FS key exchange (like ECDHE), and the session is recorded, and the server's private key is obtained, the session key cannot be recovered (that's a property of ECDHE or any forward-secure key exchange), and none of the traffic is decryptable.

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

#265

Post by akerl_ » Sat, May 24, 2025, 4:30 AM UTC

bandrami wrote: post #260

ipdashc wrote: post #167

Earlier quoted context omitted.

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?

Phishers also got EV certs. The big problem with PKI is that there are known bad (or at least sketchy) actors on the big CA lists that realistically can't be taken off that list.

What's an example?

We're in an era where browsers have forced certificate transparency and removed major vendor CAs when they've issued certificates in violation of the browsers' requirements.

The concern about bad/sketchy CAs in the list feels dated.

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

#266

Post by lifthrasiir » Sat, May 24, 2025, 4:37 AM UTC

faresahmed wrote: post #244

jazzyjackson wrote: post #193

Earlier quoted context omitted.

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…

This should be interpreted as a stop-gap measure before a subquadratic algorithm can be adopted. Take a look at _pylong.py in new enough CPython.

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

#267

Post by dietr1ch » Sat, May 24, 2025, 4:40 AM UTC

thayne wrote: post #249

eadmund wrote: post #201

Earlier quoted context omitted.

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

The length thing sounds like an editor problem, but we have wasted too much time in coming up with syntax that pleases personal preferences without admitting we would be better off moving away from text.

927 can be avoided, but it's way harder than it seems, which is why we have the proliferation of standards that fail to become universal.

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

#268

Post by nothrabannosir » Sat, May 24, 2025, 4:44 AM UTC

arkadiyt wrote: post #264

nothrabannosir wrote: post #258

Earlier quoted context omitted.

I thought FS only protected other sessions from leak of your current session key. How does it protect against passive recording of the session and later attacking of the recorded session in the future?

If using a non-FS key exchange (like RSA) then the value that the session key is derived from (the pre-master secret) is sent over the wire encrypted using the server's public key. If that session is recorded and in the future the server's private key is obtained, it can be used to decrypt the pre-master secret, derive the session key, and decrypt the entire session. If on the other hand you use a FS key exchange (li…

Thanks I think I understand better now!

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

#269

Post by toast0 » Sat, May 24, 2025, 5:15 AM UTC

tialaramex wrote: post #231

fpoling wrote: post #77

Earlier quoted context omitted.

The issue is that the client needs to access the private key, tell web server where various temporary files are during the certificate generation (unless the client uses DNS mode) and tell the web server about a new certificate to reload. To implement that many clients run as a root. Even if that root is in a docket container, this is needlessly elevated privileges especially given the complexity (again, needless) of…

But the requirements you listed aren't actually requirements of ACME, they're lazy choices you could make but they aren't necessary. Some clients do better. For example the client needs a Certificate Signing Request, one way to achieve that is to either have the client choose the private keys or give it access to a chosen key, but the whole point of a CSR is that you don't need the private key, the CSR can be made by…

I don't know that it's accurate, but at the beginning, it felt like using certbot was the only supported way to use ACME/LE, and it really wanted to do stuff as root and restart your webserver whenever.

Or you could run Caddy which had a built in ACME client, but then you're running an extra daemon.

apache_mod_md eventually came along which works for me, but it's also got some lazy things (it mostly just manages requesting certs, you've got to have a frequent enough reload to pick them up; I guess that's ok because I don't think public Apache ever learned to periodically check if it needs to reopen access logs when they're rotated, so you probably reload Apache from time to time anyway)

Before that was workable, I did need some certs and used acme.sh by hand, and it was nicer than trusting a big thing running in a cron and restarting things, but it was also inconvenient becsause I had to remember to go do it.

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

#270

Post by solatic » Sat, May 24, 2025, 5:19 AM UTC

bandrami wrote: post #260

ipdashc wrote: post #167

Earlier quoted context omitted.

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?

Phishers also got EV certs. The big problem with PKI is that there are known bad (or at least sketchy) actors on the big CA lists that realistically can't be taken off that list.

How big of a problem is it really, with CAA records and FIDO2 or passkeys?

CAA makes sure only one CA signs the cert for the real domain. FIDO2 prevents phising on a similar-looking domain. EV would force a phisher to get a similar-looking corporate name, but it's beside the main FIDO2 protection.