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

381–390 of 437 posts

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

#381

Post by NooneAtAll3 »

eadmund wrote: post #201
cortesoft wrote: post #192

Earlier quoted context omitted.

> Canonical S-expressions would have been far preferable, but for whatever reason the world didn’t go that way. 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. 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. I…

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

> I contend that this is far easier to read than this

oh boi, that's some Lisp-like vs C-like level of holywar you just uncovered there

and wooow my opinion is opposite of yours

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

#382

Post by jchw »

AStonesThrow wrote: post #278
jchw wrote: post #214

Earlier quoted context omitted.

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.

> Honest Achmed I had to stop and Google that, wondering if it was a pastiche of “Akbar & Jeff’s Certificate Hut”... https://bugzilla.mozilla.org/show_bug.cgi?id=647959

I'm glad to give you an xkcd 1053 moment. Honest Achmed is one for the books.

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

#383

Post by antonvs »

wat10000 wrote: post #373
antonvs wrote: post #358

Earlier quoted context omitted.

That Rivest draft defines canonical S-expressions to be the format in which every token is preceded by its length, so it's confusing to use "canonical" to describe the whole proposal, or use it as a synonym for the "advanced" S-expressions that the draft describes. But that perhaps hints at some reasons that formats like JSON tend to win popularity contests over formats like Rivest's. JSON is a single format for auth…

JSON also had the major advantage of having an enormous ecosystem from day 1. It was ugly and kind of insecure, but the fact that every JavaScript implementation could already parse and emit JSON out of the box was a huge boost. It’s hard to beat that even if you have the best format in the world.

Haha yes, that does probably dwarf any other factors.

But still, I think if the original JSON spec had been longer and more comprehensive, along the lines of Rivest's, that could have limited JSON's popularity, or resulted in people just ignoring parts of it and focusing on the parts they found useful.

The original JSON RFC-4627 was about 1/3rd the size of the original Rivest draft (a body of 260 lines vs. 750); it defines a single representation instead of four; and e.g. the section on "Encoding" is just 3 sentences. Here it is, for reference: https://www.ietf.org/rfc/rfc4627.txt

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

#384

Post by ipdashc »

tialaramex wrote: post #239
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?

EV can't actually work. It was always about branding for the for-profit CAs so that they have a premium product which helps the line go up. Let me give you a brief history - you did ask. In about 2005, the browser vendors and the Certificate Authorities began meeting to see if they could reach some agreement as neither had what they wanted and both might benefit from changes. This is the creation of the CA/Browser Fo…

This was a fun read. Thanks for the explanation!

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

#385

Post by KAMSPioneer »

dingaling wrote: post #286
arkadiyt wrote: post #264

Earlier quoted context omitted.

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.

No, my GP is correct: if the server's RSA private key is compromised it does not allow decryption of any previously-recorded sessions.

You would need to compromise the _ephemeral session key_ which is difficult because it is discarded by both parties when the session is closed.

Compromising the RSA key backing the certificate allows _future_ impersonations of the server, which is a different attack altogether.

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

#386

Post by NooneAtAll3 »

kens wrote: post #166
matja wrote: post #72

Earlier quoted context omitted.

Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float? It's a shame JSON parsers usually default to performance rather than correctness, by using bignums for numbers.

> Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float? That sentence has four negations and I honestly can't figure out what it means.

Aren't {X}? -> isn't it true that {X}?

{X} = JSON parsers technically [are] not following the standard if {reason}

{reason} = [JSON parsers] don't reliably store a number that {what kind of number?}

{what kind of number} = number that is not representable by a IEEE754 double precision float

seems simple

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

#387

Post by _hyn3 »

rmetzler wrote: post #368
jchw wrote: post #214

Earlier quoted context omitted.

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.

A while ago I saw that acme.sh now uses ZeroSSL by default. https://github.com/acmesh-official/acme.sh/blob/42bbd1b44af4...

"We now have another confirmation on Twitter that remote code is executed and a glimpse into what the script is... it appears to be benign."

https://github.com/acmesh-official/acme.sh/issues/4659

It was not. Don't use acme.sh.

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

#388

Post by motorest »

eadmund wrote: post #194
marcosdumay wrote: post #126

Earlier quoted context omitted.

What I don't understand is why you (and a lot of other people) just expect S-expression parsers to not have the exact same problems.

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

> Because canonical S-expressions don’t have numbers, just atoms (i.e., byte sequences) and lists.

If types other than string and a list bother you, why don't you stick with those types in JSON?

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

#389

Post by beeflet »

cortesoft wrote: post #192
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 would have been far preferable, but for whatever reason the world didn’t go that way. 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. 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. I…

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

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

#390

Post by motorest »

rr808 wrote: post #313
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…

> JSON is better than XML hard disagree on that one.

[flagged]
Post reply on HN