Live data from Hacker News

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

rachelbythebay.com

151–160 of 437 posts

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

#151

OpenBSD has a dead-simple lightweight ACME client (written in C) as part of the base OS. No need to roll your own. I understand it was created because existing alternatives ARE bloatware and against their Unixy philosophy. Perhaps the author wasn't looking hard enough. It could probably be ported with little effort.

Or uacme [0] - litle bit of C that's been running perfectly since endless battery failures with the LE python client made us look for something that would last longer.

[0] https://github.com/ndilieto/uacme

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

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

But what's wrong with sending the number as a string? `"65537"` instead of `"AQAB"`

Too likely that this would not work because silent conversion to number along the way

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

#153

Earlier quoted context omitted.

> Why? The days of MITM boxes injecting content into HTTP traffic are basically over The reason you don't see many MITM boxes injecting content into HTTP anymore is because of widespread HTTPS adoption and browsers taking steps to distrust HTTP, making MITM injection a near-useless tactic. (This rhymes with the observation that some people now perceive Y2K as overhyped fear-mongering that amounted to nothing, without…

How do browsers distrust HTTP, exactly?

If you try to open anything with just HTTP on an iOS device (e.g. "Hey, look at this thing I made and have served on the public internet! ") it just won't load.

This was my experience sending a link to someone who primarily uses an iPad and is non-technical. They were not going to find/open their Macbook to see the link.

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

#154
post #152

Earlier quoted context omitted.

But what's wrong with sending the number as a string? `"65537"` instead of `"AQAB"`

Too likely that this would not work because silent conversion to number along the way

Then just prefixing it with an underscore or any random letter would've been fine but of course base64 encoding the binary representation in base 64 makes you look so much smarter.

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

#155

Not the main point of the article, but the author’s comments on Gandi made me wonder: What registrar do people recommend in 2025?

I use Cloudflare for everything I can and then currently use Namecheap for anything it doesn't support. I haven't tried Porkbun mostly because I'm okay with what I have already.

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

#157

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.

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

#158
post #50

Earlier quoted context omitted.

> thought static content should just be HTTP Yep, I've seen that argument so many times and it should never make sense to anyone that understands MITM. The only way it could possibly work is if the static content were signed somehow, but then you need another protocol the browser and you need a way to exchange keys securely, for example like signed RPMs. It would be less expensive as the encryption happens once, but…

> Yep, I've seen that argument so many times and it should never make sense to anyone that understands MITM. Rather, it's that most people simply don't need to care about MITM. It's not a relevant attack for most content that can be reasonably served over HTTP. The goal isn't to eliminate every security threat possible, it's to eliminate the ones that are actually a problem for your use case.

MITM is a risk to everyone. End of story.

The browser content model knows nothing if the data it's receiving is static or not.

ISPs had already shown time and again they'd inject content into http streams for their own profit. BGP attacks routed traffic off to random places. Simply put the modern web should be zero trust at all.

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

#159
post #105
post #102

Earlier quoted context omitted.

So a JSON parser that cannot store a 2 is technically compliant? :(

Yep. Or one that parses it into a 7 :)

> Or one that parses it into a 7 :)

if it's known and acceptable that LLMs can hallucinate arguments to an API then i don't see how this isn't perfectly acceptable behavior either.

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

#160
post #50

Earlier quoted context omitted.

> thought static content should just be HTTP Yep, I've seen that argument so many times and it should never make sense to anyone that understands MITM. The only way it could possibly work is if the static content were signed somehow, but then you need another protocol the browser and you need a way to exchange keys securely, for example like signed RPMs. It would be less expensive as the encryption happens once, but…

Well there is the integrity atttribute. https://www.w3schools.com/Tags/att_script_integrity.asp

Pretty useless in this case if I control the stream going to you. The main page defining the integrity would have to be encrypted.

Maybe you could have a mixed use case page in the browser where you had your secure context, then a sub context of unencrypted protected objects, that could possibly increase caching. With that said, looks like another fun hole browser makers would be chasing every year or so.

Post reply on HN