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

411–420 of 437 posts

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

#411

Post by jaapz »

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…

But also, all the other reasons written by the person you replied to

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

#413

Post by codewiz »

> I'm talking about wrapping jansson (a C library that handles JSON) so that it made sense in my C++ world and I could import JSON

Why not just use JsonCpp then?

https://github.com/open-source-parsers/jsoncpp

It's a native C++ parser which is mature, actively maintained, and likely safer than a low-level C parser implementing its own string buffers.

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

#414

Post by skissane »

tialaramex wrote: post #34

One of the things this gestures at might as well get a brief refresher here: Subject Alternative Name (SAN) is not an alternative in the sense that it's an alias, SANs exist because the X.509 certificate standard is, as its name might suggest, intended for the X.500 directory system, a system from the 20th century which was never actually deployed. Mozilla (back then the Netscape Corporation) didn't like re-inventing…

> the X.500 directory system, a system from the 20th century which was never actually deployed

X.500 really was deployed – never at the scale the designers originally intended, as a single global directory system – but, as an enterprise directory system, yes it was – and it still survives in that role today, albeit as a legacy niche.

LDAP is a direct descendant of X.500 – it was basically taking the X.500 Directory Access Protocol (DAP, X.511), simplifying it somewhat, and porting it to run on top of TCP instead of OSI TP. Many early LDAP servers were just X.500 DAP servers with LDAP support added as an additional feature–and if you read the LDAP RFCs, large parts of them were written with that assumption, and don't make much sense unless you understanding the X.500 underpinnings

Nowadays, the most popular LDAP servers never implemented X.500, and few bother to implement the full set of X.500 semantics which LDAP supports – although one of the infuriating things about LDAP is that every implementation is a slightly different subset of the X.500 feature set.

X.400 survives in some applications–it is the basis of the NATO standard Military Message Handling System (MMHS) and also the Aeronautical Message Handling System (AMHS) used by commercial aircraft – and X.400 and X.500 were designed to be used together. I know vendors like Thales Group still sell X.500 directory servers for use with AMHS (and probably MMHS too)

Isode still sells M-Vault which supports both LDAP and X.500 DAP (X.511) – primarily for military applications

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

#415

Post by dangus »

nothrabannosir wrote: post #261
dangus wrote: post #215

Earlier quoted context omitted.

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?

Our backgrounds sound similar. I just don’t sweat all those details when I set things up.

I’m not advocating for the use of cloud services necessarily, not saying we all need to allow someone else to abstract away everything. And I realize that someone on an ops team has to actually set that up at a low level at some point.

What I am saying is that there’s a lot of open source software that has already invented the wheel for you. You can run it easily and be reasonably assured that it’s safe enough to be exposed to the internet.

I gave the example of nginx proxy manager. It may be basic software but for a personal blog it’ll get the job done and you can set it up almost entirely in a GUI following a simple YouTube tutorial. It’ll get you an wildcard certificate automatically, and it’ll be secure enough.

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

#416

Post by nextaccountic »

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…

In other words, the thing that made JSON initially succeed was also a giant security hole

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

#417

Post by motorest »

jaapz wrote: post #411
motorest wrote: post #374

Earlier quoted context omitted.

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

But also, all the other reasons written by the person you replied to

> But also, all the other reasons written by the person you replied to

Not really. JSON's mass adoption is tied to JavaScript's mass adoption, where sheer convenience and practicality dictates it's whole history most of the current state. Sending JavaScript fragments from the backend is a technique that didn't really stopped being used just because someone rolled out a JSON parser.

I think some people feel compelled to retroactively make this whole thing more refined and elegant because for some the ugly truth is hard to swallow.

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

#418

Post by motorest »

nextaccountic wrote: post #416
motorest wrote: post #374

Earlier quoted context omitted.

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

In other words, the thing that made JSON initially succeed was also a giant security hole

> In other words, the thing that made JSON initially succeed was also a giant security hole

Perhaps, but it's not a major concern when you control both the JavaScript frontend and whatever backend it consumes. In fact, arguably this technique is still pretty much in use today with the way WebApps get a hold of CSRF tokens. In this scenario security is a lesser concern than, say, input validation.

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

#419

Post by int_19h »

hiciu wrote: post #297
int_19h wrote: post #292

Earlier quoted context omitted.

Why would they do so? It's semantically distinct JSON, even JS itself treats it differently?

It's PHP. Handling numbers in PHP is complicated enough that a reasonable person would not trust it by default. https://www.php.net/manual/en/language.types.numeric-strings...

I know that PHP will treat a string as if it were a number if you try to use it in a context where number is expected; JS does the same thing. But why would that affect JSON deserialization in a way that makes numbers and strings indistinguishable in principle (causing the loss of precision as described here)?

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

#420

Post by josephg »

Sammi wrote: post #407
josephg wrote: post #338

Earlier quoted context omitted.

The funny thing about this is that JavaScript the language has had support for BigIntegers for many years at this point. You can just write 123n for a bigint of 123. JSON could easily be extended to support them - but there’s no standards body with the authority to make a change like that. So we’re probably stuck with json as-is forever. I really hope something better comes along that we can all agree on before I die…

There are easy workarounds to getting bigints in JSON: https://github.com/GoogleChromeLabs/jsbi/issues/30#issuecomm...

Sure; and I can encode maps and sets as entry lists. Binary data as strings and so on. But I don’t want to. I shouldn’t have to.

The fact remains that json doesn’t have native support for any of this stuff. I want something json-like which supports all this stuff natively. I don’t want to have to figure out if some binary data is base64 encoded or hex encoded or whatever, and hack around jackson or serde or javascript to encode and decode my objects properly. Features like this should be built in.

Post reply on HN