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

41–50 of 437 posts

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

#41

Post by mschuster91 »

jeroenhd wrote: post #11

There's something to be said for implementing stuff like this manually for the experience of having done it yourself, but the author's tone makes it sound like she hates the protocol and all the extra work she needs to do to make the Let's Encrypt setup work. Kind of makes me wonder what kind of stack her website is running on that something like a lightweight ACME library ( https://github.com/jmccl/acme-lw comes to…

> but the author's tone makes it sound like she hates the protocol and all the extra work she needs to do to make the Let's Encrypt setup work.

The problem is, SSL is a fucking hot, ossified mess. Many of the noted core issues, especially the weirdnesses around encoding and bitfields, are due to historical baggage of ASN.1/X.509. It's not fun to deal with it, at all... the math alone is bad enough, but the old abstractions to store all the various things for the math are simply constrained by the technological capabilities of the late '80s.

There would have been a chance to at least partially reduce the mess with the introduction of LetsEncrypt - basically, have the protocol transmit all of the required math values in a decent form and get an x.509 cert back - and HTTP/2, but that wasn't done because it would have required redeveloping a bunch of stuff from scratch whereas one can build an ACME CA with, essentially, a few lines of shell script, OpenSSL and six crates of high proof alcohol to drink away one's frustrations of dealing with OpenSSL, and integrate this with all software and libraries that exist there.

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

#43

Post by Avamander »

g-b-r wrote: post #39
immibis wrote: post #12

Earlier quoted context omitted.

Some people don't want to be forced to run a bunch of stuff they don't understand on the server, and I agree with them. Sadly, security is a cat and mouse game, which means it's always evolving and you're forced to keep up - and it's inherent by the nature of the field, so we can't really blame anyone (unlike, say, being forced to integrate with the latest Google services to be allowed on the Play Store). At least yo…

> Some people don't want to be forced to run a bunch of stuff they don't understand on the server It's not just about not understanding, it's that more complex stuff is inherently more prone to security vulnerabilities, however well you think you reviewed its code.

> It's that more complex stuff is inherently more prone to security vulnerabilities

That's overly simplifying it and ignores the part where the simple stuff is not secure to begin with.

In the current context you could take a HTTP client with a formally verified TLS stack, would you really say it's inherently more vulnerable than a barebones HTTP client talking to a server over an unencrypted connection? I'd say there's a lot more exposed in that barebones client.

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

#45

Post by p_ing »

tialaramex wrote: post #34

One of the things this gestures at might as well get a brief refresher here: Subject Alternative Name (SAN) is not an alternative in the sense that it's an alias, SANs exist because the X.509 certificate standard is, as its name might suggest, intended for the X.500 directory system, a system from the 20th century which was never actually deployed. Mozilla (back then the Netscape Corporation) didn't like re-inventing…

Did browsers ever strictly require a SAN; they certainly didn't even as of ~10 years ago? Yes, it is "required", but CN only has worked for quite some time. I find this tricks up some IT admins who are still used to only supplying a CN and don't know what a SAN is.

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

#46

Post by lmz »

oneplane wrote: post #15
tux3 wrote: post #6

JOSE/JWK is indeed some galactically overengineered piece of spec, but the rest seems.. fine? There are private keys and hash functions involved. But base64url and json aren't the worst web crimes to have been inflicted upon us. It's not _that_ bad, is it?

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…

Imagine coming from JWK and having to encode that public key into a CSR or something with that attitude.

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

#48

Post by tialaramex »

spockz wrote: post #18
immibis wrote: post #12

Earlier quoted context omitted.

Some people don't want to be forced to run a bunch of stuff they don't understand on the server, and I agree with them. Sadly, security is a cat and mouse game, which means it's always evolving and you're forced to keep up - and it's inherent by the nature of the field, so we can't really blame anyone (unlike, say, being forced to integrate with the latest Google services to be allowed on the Play Store). At least yo…

Given that keys probably need to be shared between multiple gateway/ingresses, how common is it to just use some HSM or another mechanism of exchanging the keys with all the instances? The acme client doesn’t have to run on the servers itself.

> The acme client doesn’t have to run on the servers itself.

This is really important to understand if you care about either: Actually engineering security at some scale or knowing what's actually going on in order to model it properly in your head.

If you just want to make a web site so you can put up a blog about your new kitten, any of the tools is fine, you don't care, click click click, done.

For somebody like Rachel or many HN readers, knowing enough of the technology to understand that the ACME client needn't run on your web servers is crucial. It also means you know that when some particular client you're evaluating needs to run on the web server that it's a limitation of that client not of the protocol - birds can't all fly, but flying is totally one of the options for birds, we should try an eagle not an emu if we want flying.

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

#49

Post by sam_lowry_ »

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? The days of MITM boxes injecting content into HTTP traffic are basically over, and frankly they never were a thing in my part of the world.

I see no other reason to serve content over HTTPS.

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

#50

Post by pixl97 »

amiga386 wrote: post #35

Things change over time. Part of not wanting to let go is the sunk cost fallacy. Part of it is being suspicious of being (more) dependent on someone else (than you are already dependent on a different someone else). (As an aside, the n-gate guy who ranted against HTTPS in general and thought static content should just be HTTP also thought like that. Unfortunately, as I'm at a sketchy cafe using their wifi, his page c…

> 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 is it worth having yet another implementation?

Post reply on HN