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

391–400 of 437 posts

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

#391

Post by NooneAtAll3 »

alterom wrote: post #352
kens wrote: post #166

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? That sentence has four negations and I honestly can't figure out what it means.

>> 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. This example is halfway as bad as the one Orwell gives in my favorite essay, "Politics the the English Language"¹. Compare and contrast: >I am not, indeed, sure whether it is n…

that Orwell quote can be saved a lot by proper punctuation

I am not, indeed, sure*,* whether it is not true to say that the Milton *(*who once seemed not unlike a seventeenth-century Shelley*)* had not become *-* out of an experience *-* ever more bitter in each year, more alien (sic) to the founder of that Jesuit sect*,* which nothing could induce him to tolerate.

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

#392

Post by wat10000 »

antonvs wrote: post #383
wat10000 wrote: post #373

Earlier quoted context omitted.

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

We already see that a little bit. JSON in theory allows arbitrary decimal numbers, but in practice it’s almost always limited to numbers that are representable as an IEEE-754 double. It used to allow UTF-16 and UTF-32, but in practice only UTF-8 was widely accepted, and that eventually got reflected in the spec.

I’m sure you’re right. If even this simple spec exceeded what people would actually use as a real standard, surely anything beyond that would also be left by the wayside.

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

#393

Post by lisper »

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…

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

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

#394

Post by peanut-walrus »

tasuki wrote: post #375
mcpherrinm wrote: post #189

I’m the technical lead for the Let’s Encrypt SRE/infra team. So I spend a lot of time thinking about this. The salt here is deserved! JSON Web Signatures are a gnarly format, and the ACME API is pretty enthusiastic about being RESTful. It’s not what I’d design. I think a lot of that came via the IETF wanting to use other IETF standards, and a dash of design-by-committee. A few libraries (for JWS, JSON and HTTP) go a…

> and the ACME API is pretty enthusiastic about being RESTful Without looking at it, are you sure about that? I once used to know what REST meant. Are you doing REST as in HATEOAS or as in "we expose some http endpoints"?

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.

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

#395

Post by amne »

motorest wrote: post #374
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. 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…

it's in the name after all: [j]ava[s]cript [o]bject [n]otation

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

#396

Post by mcpherrinm »

tasuki wrote: post #375
mcpherrinm wrote: post #189

I’m the technical lead for the Let’s Encrypt SRE/infra team. So I spend a lot of time thinking about this. The salt here is deserved! JSON Web Signatures are a gnarly format, and the ACME API is pretty enthusiastic about being RESTful. It’s not what I’d design. I think a lot of that came via the IETF wanting to use other IETF standards, and a dash of design-by-committee. A few libraries (for JWS, JSON and HTTP) go a…

> and the ACME API is pretty enthusiastic about being RESTful Without looking at it, are you sure about that? I once used to know what REST meant. Are you doing REST as in HATEOAS or as in "we expose some http endpoints"?

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.

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

#397

Post by pornel »

sam_lowry_ wrote: post #21

I am running an HTTP-only blog and it's getting harder every year not to switch to HTTPS. For instance, Whatsapp can not open HTTP links anymore.

You're making a mistake assuming that the push for HTTPS-only Web is about protecting the content of your site.

The problem is that mere existence of HTTP is a vulnerability. Users following any insecure link to anywhere allow MITM attackers to inject any content, and redirect to any URL.

These can be targeted attacks against vulnerabilities in the browser. These can be turning browsers into a botnet like the Great Cannon. These can be redirects, popunders, or other sneaky tab manipulation for opening phishing pages for other domains (unrelated to yours) that do have important content.

Your server probably won't even be contacted during such attack. Insecure URLs to your site are the vulnerability. Don't spread URLs that disable network-level security.

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

#398

Post by deepsun »

mindcrime wrote: post #232
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, but it really isn’t great. JSON doesn't even support comments, c'mon. I mean, it's handy for some things, but I don't know if I'd say "JSON is better than XML" in any universal sense. I still go by the old saw "use the right tool for the job at hand". In some cases maybe it's JSON. In others XML. In others S-Exprs encoded in EBCDIC or something. Whatever works...

Yup, imagine if HTML was JSON-like, not XML-like.

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

#400

Post by cortesoft »

lisper wrote: post #393
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…

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

I have written by hand and read JSON hundreds of times. You can tell me I shouldn’t, but I am telling you I do. Messing around with an API with curl, tweaking a request object slightly for testing something, etc.

Reading happens even more times. I am constantly printing out API responses when I am coding, verifying what I am seeing matches what I am expecting, or trying to get an idea of the structure of something. Sure, you can tell me I shouldn’t do this and I should just read a spec, but in my experience it is often much faster just to read the JSON directly. Sometimes the spec is outdated, just plain wrong, or doesn’t exist. Being able to read the JSON is a regular part of my day.

Post reply on HN