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

401–410 of 437 posts

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

#401

Post by deepsun »

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…

The more a format restricts, the more useful it is. E.g. if a format allows pretty much anything and it's up to parsers to accept or reject it, we may as well say "any text file" (or even "any data file") -- it would allow for anything.

Similarly to a "schema-less" DBMS -- you will still have a schema, it will just be in your application code, not enforced by the DBMS.

JSON is a nice balance between convenience and restrictions, but it's still a compromise.

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

#402

Post by thayne »

antonvs wrote: post #379
kevin_thibedeau wrote: post #360

Earlier quoted context omitted.

> clearly refers to one thing Great, this looks like JSON. Is it JSON5? Does it expect bigint support? Can I use escape chars?

You're providing an example of my point. People don't, in general, care about any of that, so "solving" those "problems" isn't likely to help adoption. To your specific points: 1. JSON5 didn't exist when JSON adoption occurred, and in any case they're pretty easy to tell apart, because JSON requires keys to be quoted. This is a non-problem. Why do you think it might matter? Not to mention that the existence of some o…

I agree with most of what you said, but json's numbers are problematic. For one thing, many languages have 64-bit integers, which can't be precisely represented as a double, so serializing such a value can lead to subtle bug if it is deserialized by a parser that only supports doubles. And deserializing in languages that have multiple numeric types is complicated, since the parser often doesn't have enough context to know what the best numeric type to use is.

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

#403

Post by tasuki »

mcpherrinm wrote: post #396
tasuki wrote: post #375

Earlier quoted context omitted.

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

That's pretty good! Better than 99% claims of REST for sure! Thanks for the long reply.

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

#404

Post by lisper »

cortesoft wrote: post #400
lisper wrote: post #393

Earlier quoted context omitted.

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

I think there may be a terminological disconnect here. S-expressions and canonical S-expressions are not the same thing. S-expressions (non-canonical) are a comparable to JSON, intended to be read and written by humans, and actually much easier to read and write than JSON because it uses less punctuation.

https://en.wikipedia.org/wiki/S-expression

A canonical S-expression is a binary format, intended to be both generated and parsed by machines, not humans:

https://en.wikipedia.org/wiki/Canonical_S-expressions

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

#405

Post by rsync »

_hyn3 wrote: post #387
rmetzler wrote: post #368

Earlier quoted context omitted.

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.

I went down the acme/HiCA/RCE rabbit hole a year or so ago and, while I don't remember the specifics, my feeling was that the RCE was not that dangerous and was put into place by greedy scammers thwarting the rules of cert (re)selling and not by shadowy actors trying to infiltrate sensitive infra ...

Is there new information ? Was my impression wrong ?

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

#406

Post by hamburglar »

peanut-walrus wrote: post #394
tasuki wrote: post #375

Earlier quoted context omitted.

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

Eh, I think that’s what it meant for a while. I’ve now interacted with enough systems that have rigor about representing things as resources that have GET urls and doing writes with POST etc that I don’t think it’s always the ad hoc RPC fest it once was. It may be rare to see according-to-hoyle HATEOAS but REST is definitely no longer in the “nobody actually does this” category.

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

#407

Post by Sammi »

josephg wrote: post #338
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…

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

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

#408

Post by birktj »

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.

Buypass provides ACME certificates as well [1]. The usage limits are not quite as generous as LE, but they work pretty well in my experience.

[1] https://www.buypass.com/products/tls-ssl-certificates/read-m...

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

#409

Post by nickf »

mkup wrote: post #325
nickf wrote: post #282

Earlier quoted context omitted.

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.

Could you please provide more info on this topic, e.g. a link? I intended to buy EV code signing certificate as a sole proprietor to fix long-standing problem with my software when Windows Defender pops up every time I release a new version. Is EV code signing certificate no longer a viable solution to this problem? Is there no longer a difference between EV and non-EV code signing certificate?

Sure: https://learn.microsoft.com/en-us/security/trusted-root/prog...

3.D.3 covers the details about EV CS.

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

#410

Post by cryptonector »

mcpherrinm wrote: post #380
cryptonector wrote: post #203

Earlier quoted context omitted.

> JSON Web Signatures are a gnarly format They are?? As someone who wallows in ASN.1, Kerberos, and PKI, I don't find JWS so "gnarly". Even if you're open-coding a JSON Web Signature it will be easier than to open-code S/MIME, CMS, Kerberos, etc. Can you explain what is so gnarly about JWS? Mind you, there are problems with JWT. Mainly that HTTP user-agents don't know how to fetch the darned things because there is n…

I'd take ASN.1/DER over JWS any day :) It's the weekend and I don't feel I have the energy to launch a full roast of JWS, but to give some flavour, I'll link https://auth0.com/blog/critical-vulnerabilities-in-json-web-... Implementations can be written securely, but it's too easy to make mistakes. Yeah, there's worse stuff from the 90s around, but JOSE and ACME is newer than that - we could have done better! Alas, it…

The whole not validating the signatures thing is a problem, yes. That can happen with PKI certificates too, but those have been around longer and -perhaps because one needed an ASN.1 stack- only people with more experience wrote PKI stacks than we see in the case of JWS?

I think Protocol Buffers is a disaster. Its syntax is worse than ASN.1 because you're required to write in tags, and it is a TLV encoding very similar to DER so... why _why_ does PB exist? Don't tell me it's because there were no ASN.1 tools around -- there were no PB tools around either!

Post reply on HN