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

361–370 of 437 posts

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

#361

Post by justinclift »

eddythompson80 wrote: post #243
eadmund wrote: post #201

Earlier quoted context omitted.

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

> is far easier to read than this (the first JSON in RFC 8555): It's not for me. I'd literally take anything over csexps. Like there is nothing that I'd prefer it to. If it's the only format around, then I'll just roll my own.

> Like there is nothing that I'd prefer it to.

May I suggest perl regex's? :)

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

#362

Post by michaelcampbell »

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…

> is far easier to read than this

Readability is a function of the reader, not the medium.

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

#363

Post by castillar76 »

ndsipa_pomu wrote: post #114
castillar76 wrote: post #69

Earlier quoted context omitted.

Having my ACME client munge my webserver configs to obtain a cert was one of the supreme annoyances about using them — it felt severely constraining on how I structured my configs, and even though it’s a blip, I hated the double restart required to fetch a cert (restart with new config, restart with new cert). Then I discovered the web-root approach people mention here and it made a huge difference. Now I have the HT…

A wrapper function may be overkill when you can do something like this: letsencrypt renew --non-interactive --post-hook "systemctl reload nginx"

Oh definitely, but her point was she didn’t want the ACME client having the rights to frob the webserver — I figured that meant restart-rights too. :)

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

#364

Post by ownedthx »

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 numerical issues here are due to JavaScript, not JSON.

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

#365

Post by castillar76 »

elric wrote: post #127
castillar76 wrote: post #75

Earlier quoted context omitted.

Fortunately that’s only needed if you’re using the DNS validation method — necessary if you’re getting wildcards (but…eek, wildcards). For HTTP-01, no DNS changes are needed unless you want to add CAA records to block out other CAs.

Wildcard Certificates are your friend if you don't want all of your hostnames becoming public knowledge.

You're not wrong: there's definitely evidence, for instance, of savvy attackers watching the CT logs for things like newly-instantiated WordPress servers and then attacking them before the admins have set the initial password on them. (Which is really a WP problem, but I digress.) So there's benefit in not having the internals of your infrastructure writ large in public CT logs.

My problem is with the selected solution: wildcard certificates are a huge compromise waiting to happen. They give an attacker the ability to impersonate _anything_ in my infrastructure for as long as the cert is valid (and even a week is _long_ time for that). Worse, if I'm then distributing the wildcard to everything on my internal network that needs to do anything over HTTPS, that's a lot of potential attack points. (If it's just one TLS-terminating bastion host that's very tightly secured, then...maybe. _Maybe_. But it almost never stays that way.)

To me, it's a much better security tradeoff to accept the hostname problem (or run my own CA internally for stuff that doesn't need a public cert) and avoid wildcards entirely.

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

#366

Post by remram »

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…

This doesn't help with numbers at all, though. Any textual representation of numbers is going to have the same problem as JSON.

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

#367

Post by castillar76 »

g-b-r wrote: post #110
castillar76 wrote: post #82

Earlier quoted context omitted.

They’ve been making it harder and harder to serve things over HTTP-only for a while now. Steps like marking HTTP with big “NOT SECURE” labels and trying to auto-push to HTTP have been pretty effective. (With the exception of certain contexts, I think this is a generally good trend, FWIW.)

I have to change two settings to be able to see plain http things, and luckily I only need to a handful of times a year. If I'm really curious about your plain http site I'll check it out through archive.org, and I'm definitely not going to keep visiting it frequently. It's been easy to live with forced https for at least five years (and for at least the last ten with https first, with confirmations for plain http).

I was genuinely taken aback by visiting a restaurant website last night that was only served over HTTP. (Attempting to hit it with HTTPS generated a cert error because their shared provider didn't have a cert for it.) These days, I'd gotten so used to things just being over HTTPS all the time that the warnings in the browser _actually worked_ to grab my attention.

It's a restaurant that's been here with the same menu since the 1970s, and their website does absolutely nothing besides pass out information (phone number, menu, directions), so they probably put it up in 2002 and haven't changed it since. It was just a startling reminder of how ubiquitous HTTPS has gotten.

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

#368

Post by rmetzler »

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.

A while ago I saw that acme.sh now uses ZeroSSL by default.

https://github.com/acmesh-official/acme.sh/blob/42bbd1b44af4...

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

#369

Post by aapoalas »

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…

It's more a problem of support and backwards compatibility. JSON and parsers for it are so ubiquitous, and the spec completely lacks any versioning support, that adding a feature would be a breaking change of horrible magnitude, on nearly all levels of the modern software infrastructure stack. I wouldn't be surprised if some CPUs might break from that :D

JSON is a victim of its success: it has become too big to fail, and too big to improve.

Post reply on HN