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

31–40 of 437 posts

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

#31

Post by sussmannbaka »

hannob wrote: post #23
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, and I agree with them. Honest question: * Do you understand OS syscalls in detail? * Do you understand how your BIOS initializes your hardware? * Do you understand how modern filesystems work? * Do you understand the finer details of HTTP or TCP? Because... I don't. But I know enough about them that I'm quite convince…

This point is so tired. I don’t understand how a thought forms in my neurons, eventually matures into a decision and how the wires in my head translate this into electrical pulses to my finger muscles to type this post so I guess I can’t have opinions about complexity.

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

#33

Post by liampulles »

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 another brick in the wall.

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

#34

Post by tialaramex »

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 wheels and this standard for certificates already existed so they used it in their new "Secure Sockets" technology but it has no Internet names so at first they just put names in plain text. However, X.500 was intended to be infinitely extensible, so we can just invent an alternative naming scheme, and that's what the SANs are, which is why they're mandatory for certificates in the Web PKI today - these are the Internet's names for things, so they're mandatory when talking about the Internet, they're described in detail in PKIX, the IETF document standardising the use of X.500 for the Internet.

There are several types of name we can express as SANs but in a certificate the two you'll commonly see are dnsName - the same ASCII names you'd see in URLs like "news.ycombinator.com" or "www.google.com" and ipAddress - a 32-bit integer typically spelled as four dotted decimals 10.20.30.40 [yes or an IPv6 128-bit integer will work here, don't worry]

Because the SANs aren't just free text a machine can reliably parse them which would doubtless meet Rachel's approval. The browser can mindlessly compare the bytes in the certificate "news.ycombinator.com" with the bytes in the actual DNS name it looked up "news.ycombinator.com" and those match so this cert is for this site.

With free text in a CN field like a 1990s SSL certificate (or, sadly, many certificates well into the 2010s because it was difficult to get issuers to comply properly with the rules and stop spewing nonsense into CN) it's entirely possible to see a certificate for " 10.200.300.400" which well, what's that for? Is that leading space significant? Is that an IP address? But those numbers don't even fit in one byte each I hope our parser copes!

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

#35

Post by amiga386 »

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 currently says I should click here to enter my bank details, and I should download new cursors, and oddly doesn't include any of his own content at all. Bit weird, but of course I can trust he didn't modify his page, and it's just a silly unnecessary imposition on him that I would like him to use HTTPS)

Unfortunately for those rugged individuals, you're in a worldwide community of people who want themselves, and you, to be dependent on someone else. We're still going with "trust the CAs" as our security model. But with certificate transparency and mandatory stapling from multiple verifiers, we're going with "trust but verify the CAs".

Maximum acceptable durations for certificates are coming down, down, down. You have to get new ones sooner, sooner, sooner. This is to limit the harm a rogue CA or a naive mis-issuing CA can do, as CRLs just don't work.

The only way that can happen is with automation, and being required to prove you still own a domain and/or a web-server on that domain, to a CA, on a regular basis. No "deal with this once a year" anymore. That's gone and it's not coming back.

It's good to know the whole protocol, and yes certbot can be overbearing, but Debian's python3-certbot + python3-certbot-apache integrates perfectly with how Debian has set up apache2. It shouldn't be a hardship.

And if you don't like certbot, there are lots of other ACME clients.

And if you don't like Let's Encrypt, there are other entities offering certificates via the ACME protocol (YMMV, do you trust them enough to vouch for you?)

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

#36

Post by diggan »

1a527dd5 wrote: post #9

I don't understand the tone of aggression against ACME and their plethora of clients. I know it isn't a skill issue because of who the author is. So I can only imagine it is some sort of personal opinion that they dislike ACME as a concept or the tooling around ACME in general. We've been using LE for a while (since 2019 I think) for handful of sites, and the best nonsense client _for us_ was https://github.com/do-kn…

> I don't understand the tone of aggression against ACME and their plethora of clients.

The older posts on the same website provided a bit more context for me to understand today's post better:

- "Why I still have an old-school cert on my https site" - January 3, 2023 - https://rachelbythebay.com/w/2023/01/03/ssl/

- "Another look at the steps for issuing a cert" - January 4, 2023 - https://rachelbythebay.com/w/2023/01/04/cert/

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

#37

Post by projektfu »

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.

You can proxy it, which for a small server might be the best way to avoid heavy traffic, through caching at the proxy.

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

#38

Post by lucideer »

1a527dd5 wrote: post #9

I don't understand the tone of aggression against ACME and their plethora of clients. I know it isn't a skill issue because of who the author is. So I can only imagine it is some sort of personal opinion that they dislike ACME as a concept or the tooling around ACME in general. We've been using LE for a while (since 2019 I think) for handful of sites, and the best nonsense client _for us_ was https://github.com/do-kn…

> I don't understand the tone of aggression against ACME and their plethora of clients.

> ACME idea good, ACME implementation bad.

Maybe I'm misreading but it sounds like you're on a similar page to the author.

As they said at the top of the article:

> Many of the existing clients are also scary code, and I was not about to run any of them on my machines. They haven't earned the right to run with privileges for my private keys and/or ability to frob the web server (as root!) with their careless ways.

This might seem harsh but when I think it's a pretty fair perspective to have when running security-sensitive processes.

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

#39

Post by g-b-r »

immibis wrote: post #12
1a527dd5 wrote: post #9

I don't understand the tone of aggression against ACME and their plethora of clients. I know it isn't a skill issue because of who the author is. So I can only imagine it is some sort of personal opinion that they dislike ACME as a concept or the tooling around ACME in general. We've been using LE for a while (since 2019 I think) for handful of sites, and the best nonsense client _for us_ was https://github.com/do-kn…

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.

Post reply on HN