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

181–190 of 437 posts

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

#181

Post by PhilipRoman »

XorNot wrote: post #74
pixl97 wrote: 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…

For catching purposes form content distribution an unencrypted signed protocol would've helped a lot. Every Linux packaging format having to bake one in via GPG is a huge pain.

I think it would be enough to just have a widely supported hash://sha256... protocol with a hint of what host(s) is known to provide the object (falling back to something DHT based maybe). There is https://www.rfc-editor.org/rfc/rfc6920.html but I haven't seen any support for it.

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

#182

Post by folmar »

unscaled wrote: post #96
oneplane wrote: post #15

Earlier quoted context omitted.

I personally don't see the overengineering in JOSE; as you mention, a JWK (and JWKs) is not much more than the RSA key data we already know and love but formatted for Web and HTTP. It doesn't get more reasonable than that. JWTs, same story, it's just JSON data with a standard signature. The spec (well, the RFC anyway) is indeed classically RFC-ish, but the same applies to HTTP or TCP/IP, and I haven't seen the same s…

I would argue that JOSE is complex for the sake of complexity. It's not nearly as bad as old cryptographic standards (X.509 and the PKCS family of standards) and definitely much better than XMLDSig, but it's still a lot more complex than it needs to be. Some examples of gratuitous complexity: 1. Supporting too many goddamn algorithms. Keeping RSA and HMAC-SHA256 for leagcy-compatible stuff, and Ed25519 for XChaChaPol…

`cfssl` shows how easy could getting certificates signed be for the typical use case.

https://github.com/cloudflare/cfssl

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

#183

Post by foobiekr »

kangalioo wrote: post #139
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…

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

Cost.

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

#184

Post by foobiekr »

bigstrat2003 wrote: post #135
g-b-r wrote: post #42

Earlier quoted context omitted.

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

There's no good reason to serve a blog over TLS. You're not handling sensitive data, so unencrypted is just fine.

The reason is to prevent your site from becoming a watering hole where malicious actors use it to inject malware into the browsers of your users.

TLS isn't for you, it's for your readers.

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

#185

Post by foobiekr »

JoshTriplett wrote: post #83
sam_lowry_ wrote: post #63

Earlier quoted context omitted.

How do browsers distrust HTTP, exactly?

They show any site served over HTTP as explicitly not secure in the address bar (making HTTPS the "default" and HTTP the visibly dangerous option), they limit many web APIs to sites served over HTTPS ( https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ) , https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ), they block or upgrade mixed-content by default (HTTPS sites cannot request HTTP-onl…

If browser vendors really cared, they would disable javascript on non-https sites.

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

#186

Post by tialaramex »

donnachangstein wrote: post #131

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.

When I last checked this client is a classic example of OpenBSD philosophy not understanding why security is the way it is.

This client really wants the easy case where the client lives on the machine which owns the name and is running the web server, and then it uses OpenBSD-specific partitioning so that elements of the client can't easily taint one another if they're defective

But, the ACME protocol would allow actual air gapping - the protocol doesn't care whether the machine which needs a certificate, the machine running an ACME client, and the machine controlling the name are three separate machines, that's fine, which means if we do not use this OpenBSD all-in-one client we can have a web server which literally doesn't do ACME at all, an ACME client machine which has no permission to serve web pages or anything like that, and name servers which also know nothing about ACME and yet the whole system works.

That's more effort than "I just install OpenBSD" but it's how this was designed to deliver security rather than putting all our trust in OpenBSD to be bug-free.

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

#187

Post by dan_hawkins »

neuroticnews25 wrote: post #20
skrebbel wrote: post #10

Earlier quoted context omitted.

why? it isn't paywalled or something right?

Author blacklists some ISPs [0]: >I contacted Rachel and she said - and this is my poor paraphrasing from memory - that the IP ban was something she intentionally implemented but I got caught as a false positive [0] https://news.ycombinator.com/item?id=42599359

Yeah, I can't reach out their website from Denmark for some unknown reasons. On top of that the most recent update of their RSS feed server fxxxd up my news reader so I'm even less inclined to see whatever they do because it looks like they're not very competent technology-wise.

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

#188

Post by JackSlateur »

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…

Is this ok ?

  Python 3.13.3 (main, May 21 2025, 07:49:52) [GCC 14.2.0] on linux
  Type "help", "copyright", "credits" or "license" for more 
 information.
  >>> import json
  >>>
 
 json.loads('47234762761726473624762746721647624764380000000000000000000000000000000000000000000')
 47234762761726473624762746721647624764380000000000000000000000000000000000000000000

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

#189

Post by mcpherrinm »

I’m the technical lead for the Let’s Encrypt SRE/infra team. So I spend a lot of time thinking about this.

The salt here is deserved! JSON Web Signatures are a gnarly format, and the ACME API is pretty enthusiastic about being RESTful.

It’s not what I’d design. I think a lot of that came via the IETF wanting to use other IETF standards, and a dash of design-by-committee.

A few libraries (for JWS, JSON and HTTP) go a long way to making it more pleasant but those libraries themselves aren’t always that nice, especially in C.

I’m working on an interactive client and accompanying documentation to help here too, because the RFC language is a bit dense and often refers to other documents too.

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

#190

Post by drob518 »

pixl97 wrote: post #161
drob518 wrote: post #84

Earlier quoted context omitted.

The argument doesn’t even make sense for static content ignoring mitm attacks.

There is no such thing as static content. There is only content. Bits are sent to your browser which it then applies the DOM to. If you want to ensure the bits that were sent from the server to your browser they must be signed in some method.

Right, that’s exactly my point.
Post reply on HN