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

281–290 of 437 posts

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

#281

Post by tsimionescu »

reichstein wrote: post #178
matja wrote: post #102

Earlier quoted context omitted.

So a JSON parser that cannot store a 2 is technically compliant? :(

JSON is a text format. A parser must recognize the text `2` as a valid production of the JSON number grammar. Converting that text to _any_ kind of numerical value is outside the scope of the specification. (At least the JSON.org specification, the RFC tries to say more.) As a textural format, when you use it for data interchange between different platforms, you should ensure that the endpoints agree on the _interpre…

A JSON parser has to check if a numeric value is actually numeric - the JSON {"a" : 123456789} is valid, but {"a" : 12345678f} is not. Per the RFC, a standards-compliant JSON parser can also refuse {"a": 123456789} if it considers the number is too large.

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

#282

Post by nickf »

jchw wrote: post #214
belorn wrote: post #207

Earlier quoted context omitted.

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

FWIW, it is ZeroSSL. I want there to be more major ACME providers than just LE, but I'm not sure about ZeroSSL, personally. It seems to have the same parent company as IdenTrust (HID Global Corporation). Probably a step up from Honest Achmed but recently I recall people complaining that their EV code signing certificates were not actually trusted by Windows which is... Interesting.

ZeroSSL is owned by Identrust, but the infra is operated by another CA. Also Microsoft killed EV codesigning early last year - not stopping it working, just making it identical to ‘normal’ codesigning certs.

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

#283

Post by schoen »

mschuster91 wrote: post #226
schoen wrote: post #220

Earlier quoted context omitted.

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

Yikes. Guessed as much. Thanks for your explanation. As for oooold devices - doesn't LetsEncrypt demand key lengths and hash algorithms nowadays that simply weren't implemented back then?

Yes, I guess 2000 would actually be an exaggeration these days, as you can't use SHA-1 or 1024-bit RSA subject keys. So you could maintain compatibility with oold devices, but not with oooold devices.

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

#284

Post by bostik »

tialaramex wrote: post #200
GoblinSlayer wrote: post #141

Earlier quoted context omitted.

>ASN.1 and X.509 are devilishly complex Most of it is unused though, only CN, SANs and public key are used.

You really shouldn't need CN (but it's convenient for humans) however there are a bunch of other interesting things in the X.509 certificate, lets look at the one for this site: Issuer: We need to know who issued this cert, then we can check whether we trust them and whether the signature on the certificate is indeed from them, and potentially repeat this process - this cert was issued by Let's Encrypt's E5 intermedi…

> You really shouldn't need CN (but it's convenient for humans)

Is this finally the case now? About 5 years back IIS would fail to load a certificate without a CN, despite the field being deprecated since 2000.

And who would run IIS? A bunch of janky/dodgy/shady marketing affiliates, at least. Quite common in the gambling industry.

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

#285

Post by mnahkies »

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…

I'm still haunted by a bug caused by the JSON serializer our C# apps were using emitting bigints as JSON numbers, only for the JavaScript consumers to mangle them silently.

Kinda blows my mind that the accepted behavior is to just overflow and not raise an exception.

I try to stick to strings for anything that's not a 32 bit int now.

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

#286

Post by dingaling »

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…

> the session key cannot be recovered

Of course it can, but only for that specific session.

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

#287

Post by deepsun »

tsimionescu wrote: post #276
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…

This seems like a just-so story. Your explanation could make some sense if we were comparing {"e" : "AQAB"} to {"e" : 65537}, but there is no reason why that should be the alternative. The JSON {"e" : "65537"} will be read precisely the same way by any JSON parser out there. Converting the string "65537" to the number 65537 is exactly as easy (or hard), but certainly unambiguous, as converting the string "AQAB" to th…

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

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

#288

Post by deepsun »

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"`

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

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

#290

Post by paul_h »

lucideer wrote: post #118
giancarlostoro wrote: post #51

Earlier quoted context omitted.

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

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 fork.
Post reply on HN