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

271–280 of 437 posts

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

#271

Post by agarren »

mastazi wrote: post #257

> About six months ago, I realized that it was probably time to get away from Gandi as a registrar and also SSL provider (reseller). I've recently heard similar takes about Gandi but I am out of the loop, can someone explain the controversy? Currently using it for one of my domains and I'd like to know more. EDIT: tried googling but results are about people whose name is either Gandi or Ghandi, could not find much ab…

I’m seeing a lot about price hikes, new service charges, and bad customer service since the acquisition. I noticed the price hike with one of my domains through them, I paid it but was close to reconsidering. Thinking I’ll try transferring it now.

https://techrights.org/n/2023/12/14/_Video_Lessons_to_be_Lea...

https://blog.cogitactive.com/website/gandi-outrageous-price/

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

#272

Post by notherhack »

ndsipa_pomu wrote: post #4

I was amazed by them having so much distrust of the various clients. Certbot is typically in the repositories for things like Debian/Ubuntu. My favourite client is probably https://github.com/acmesh-official/acme.sh If you use a DNS service provider that supports it, you can use the DNS-01 challenge to get a certificate - that means that you can have the acme.sh running on a completely different server which should h…

I feel like acme.sh is the kind of client she's ranting about. 8000 lines of shell code in acme.sh and more in dozens of user-contributed hook scripts, and over 1000 open issues on github?

Personally I like https://github.com/dehydrated-io/dehydrated. Same concept as acme.sh but only 2500 lines of shell and 54 open issues. You do have to roll your own hook script though.

Curiously, first commits for both acme.sh and dehydrated were in December 2015. Maybe they both took a security class at uni that fall.

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

#273

Post by agarren »

g-b-r wrote: post #42
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.

For god's sake, however complex ACME might be it's better than not supporting TLS

Why? I can understand the argument that you don’t want an ISP or a middlebox injecting ads or scripts (valid I think even if I’ve never encountered it to my knowledge), but otherwise you’re publishing content intended for the world. There’s presumably nothing especially sensitive that you need to hide on the wire.

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

#274

Post by supermatt »

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…

As you said - it’s not really a problem with the JSON structure and format itself, but the underlying parser, which is specifically designed to map to the initial js types. There are parsers that don’t have this problem, but then the JSON itself is not portable.

The problem with your solution is that it’s also not portable for the same reason (it’s not part of the standard), and the reason that it wasn’t done that way in the first place is because it wouldn’t map to those initial js types!

FYI, you can easily work around this by using replacer and revivers that are part of the standards for stringify and parse and treat numbers differently. But again, the json isn’t portable to places without those replacer/revivers.

I.e, the real problem is treating something that looks like json as json by using standards compliant json parsers - not the apparent structure of the format itself. You could fix this problem in an instant by calling it something other than JSON, but people will see it and still use a JSON parser because it looks like JSON, not because it is JSON.

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

#275

Post by oasisaimlessly »

jongjong wrote: post #248

The whole DNS and TLS system is overcomplicated and was designed to allow a small number of orgs to dominate the internet. I've been thinking of using a Blockchain to register domain name-to-IP-address mappings in a cryptographically secure way and then writing a Chrome extension which connects to the Blockchain (to any known peer IP; it would start from a few hardcoded seed node IPs and discover more peers as is sta…

See also: Namecoin [1], the first altcoin.

[1]: https://en.wikipedia.org/wiki/Namecoin

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

#276

Post by tsimionescu »

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…

This seems like a just-so story. Your explanation could make some sense if we were comparing {"e" : "AQAB"} to {"e" : 65537}, but there is no reason why that should be the alternative. The JSON {"e" : "65537"} will be read precisely the same way by any JSON parser out there. Converting the string "65537" to the number 65537 is exactly as easy (or hard), but certainly unambiguous, as converting the string "AQAB" to the same number.

Of course, if you're doing this in JS and have reasons to think the resulting number may be larger than the precision of a double, you have a huge problem either way. Just as you would if you were writing this in C and thought the number may be larger than what can fit in a long long. But that's true regardless of how you represent it in JSON.

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

#277

Post by anonymousiam »

aaronmdjones wrote: post #223
anonymousiam wrote: post #163

"Skip the first 00 for some inexplicable reason" is something that caught me a few months ago. I was comparing keys in a script and they did not match because of the leading 00. Does anyone know why they're there?

If the leading bit is set, it could be interpreted as a signed negative number. Prepending 00 guarantees that this doesn't happen.

Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't.

I don't really buy this explanation. It's a very large unsigned number. Everyone knows this. Is there some arbitrary precision library in use that forces large integers to be signed? Even if it were signed, or had the MSB set, it wouldn't change any of the bits, so the key would still be the same. So why would we care about the sign?

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

#278

Post by AStonesThrow »

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.

> 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

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

#279

Post by chrisandchris »

charcircuit wrote: post #157
liampulles wrote: post #33

I appreciate the author calling this stuff out. The increasing complexity of the protocols that the web is built on is not a problem for developers who simply need to find a tool or client to use the protocol, but it is a kind of regulatory capture that ensures only established players will be the ones able to meet the spec required to run the internet. I know ACME alone is not insurmountably complex, but it is anoth…

These protocols all have open source implementations. And as AI gets stronger this barrier will get smaller and smaller.

So instead of designing simpler protocols (like HTTP/1.1 is), we do not care and let AI figure it out? Sounds great to me... /s

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

#280

Post by tsimionescu »

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…

You can write JSON that exclusively uses strings, so this is not really relevant. Sure, maybe it can be considered an advantage that s-expressions force you to do that, though it can also be seen just as easily as a disadvantage. It certainly hurts readability of the format, which is not a 0-cost thing. This is also why all Lisps use more than plain sexps to represent their code: having different syntax for different types helps.
Post reply on HN