Live data from Hacker News

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

rachelbythebay.com

111–120 of 437 posts

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

#111
post #99

Earlier quoted context omitted.

> Did browsers ever strictly require a SAN; Yes, all the popular browsers require this. > they certainly didn't even as of ~10 years ago? That's true, ten years ago it was likely that if a browser required this they would see unacceptably high failure rates because CAs were non-compliant and enforcement wasn't good enough. Issuing certs which would fail PKIX was prohibited, but so is speeding and yet people do that e…

You're forgetting that browsers deal with plenty of internal-only CAs. Just because a public CA won't issue a CN only cert doesn't mean an internal CA won't. That is why I'm curious to know if browsers /strictly/ require SANs, yet. Not something I've tested in a long time since I started supporting public-only websites/cloud infra. As you noted about OpenSSL, Windows CertSvr will allow you to do CN only, too.

I mean, no, I'm not forgetting that, of course your private CA can issue whatever nonsense you like, to this day - and indeed several popular CAs are designed to do just that as you noted. Certificates which ignore this rule won't work in a browser though, or in some other modern software.

Chromium published an "intent to remove" and then actually removed the CN parsing in 2017, at that point EnableCommonNameFallbackForLocalAnchors was available for people who were still catching up to policy from ~15 years ago. The policy override flag was removed in 2018, after people had long enough to fix their shit.

Mozilla had already made an equivalent change before that, maybe it worked for a few more years in Safari? I don't have a Mac so no idea.

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

#112

Earlier quoted context omitted.

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…

> they increasingly attempt HTTPS to a site first even if linked/typed as http And can generally be configured by the user not to downgrade to http without an explicit prompt. Honestly I disagree with the refusal to support various APIs over http. Making the (configurable last I checked) prompt mandatory per browser session would have sufficed to push all mainstream sites to strictly https.

> And can generally be configured by the user not to downgrade to http without an explicit prompt.

Absolutely, and this works quite well on the current web.

> Honestly I disagree with the refusal to support various APIs over http.

There are multiple good reasons to do so. Part of it is pushing people to HTTPS; part of it is the observation that if you allow an API over HTTP, you're allowing that API to any attacker.

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

#113
post #42

Earlier quoted context omitted.

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.

You see no reason for privacy, ok

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

#114

Earlier quoted context omitted.

Certbot goes out of its way to be inscrutable about what it’s doing. It munges your web server config (temporarily) to handle http challenges, and for true sysadmins who are used to having to know all the details of what’s going on, that sort of script is a nightmare waiting to happen. I assume certbot is the client she’s alluding to that misinterprets one of the factors in the protocol as hex vs decimal and somehow…

Having my ACME client munge my webserver configs to obtain a cert was one of the supreme annoyances about using them — it felt severely constraining on how I structured my configs, and even though it’s a blip, I hated the double restart required to fetch a cert (restart with new config, restart with new cert). Then I discovered the web-root approach people mention here and it made a huge difference. Now I have the HT…

A wrapper function may be overkill when you can do something like this:

  letsencrypt renew --non-interactive --post-hook "systemctl reload nginx"

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

#115

Earlier quoted context omitted.

Is this a joke? I don't even know where to begin with this comment... It reads like a joke, but I suspect it's not? TCP is just a bunch of bytes... You can't process a bunch of bytes without understanding what they are, and that requires signaling information at a different level (ex - in the bytes themselves as a defined protocol like SSH, SCP, HTTP, etc - or some other pre-shared information between server and clie…

parent mentioned SOAP as an alternative to JSON. I was being glib about the fact that the engineer who wrote this blog post is a highly-regarded sysadmin and SRE who tinkers on things ranging from writing her own build systems to playing with RF equipment.

Sure. Between the two comments, I think the SOAP joke is a lot better.

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

#116
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 someone who started the s-expression task on rosettacode.org, i approve. if you need an s-expression parser for your language, look here https://rosettacode.miraheze.org/wiki/S-expressions (the canonical url is https://rosettacode.org/wiki/S-expressions but they have DNS issues right now)

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

#117
post #77

Earlier quoted context omitted.

Im not a container guru by any means (at least not yet?) but would docker not suffice these concerns?

The issue is that the client needs to access the private key, tell web server where various temporary files are during the certificate generation (unless the client uses DNS mode) and tell the web server about a new certificate to reload. To implement that many clients run as a root. Even if that root is in a docket container, this is needlessly elevated privileges especially given the complexity (again, needless) of…

It's cheap. If the client was done today, it would be based on AI.

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

#118

Earlier quoted context omitted.

> 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 pr…

Im not a container guru by any means (at least not yet?) but would docker not suffice these concerns?

I use docker for the same reasons as the author's reservations - I combine a docker exec with some of my own loose automation around moving & chmod-ing files & directories to obviate the need for the acme client to have unfettered root access to my system.

Whether it's a local binary or a dockerised one, that access still needs to be marshalled either way & it can get complex facilitating that with a docker container. I haven't found it too bad but I'd really rather not need docker for on-demand automations.

I give plenty* of services root access to my system, most of which I haven't written myself & I certainly haven't audited their code line-by-line, but I agree with the author that you do get a sense from experience of the overall hygiene of a project & an ACME client has yet to give me good vibes.

* within reason

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

#119
post #62

Earlier quoted context omitted.

JSON is slow, not particularly comfortable for humans to work with, uses dangerous casts by default, is especially dangerous when it crosses library or language boundaries, has the exponential escaping problem when people try to embed submessages, relies on each client to appropriately validate every field, doesn't have any good solution for binary data, is prone to stack overflow when handling nested structures, etc…

> JSON is [...] What would you suggest instead given all these cons?

Fixing all of those at once might be a bit too much to ask, but I have some quick suggestions. I'd say for a more robust JSON you could try Dhall. If you just want to exchange lumps of data between programs I'd use Protobuf. If you want simple and freeform I'd go with good old sexps.

https://github.com/dhall-lang/dhall-lang

https://protobuf.dev/

https://en.wikipedia.org/wiki/S-expression

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

#120

Earlier quoted context omitted.

> 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 abstr…

There's no easy way to "just" transmit data in a foolproof manner. You practically need to support CSRs as a CA anyway, so you might as well use the existing ASN.1+X509 system to transmit data. ASN.1 and X509 aren't all that bad. It's a comprehensively documented binary format that's efficient and used everywhere, even if it's hidden away in binary protocols you don't look at every day. Unlike what most people seem t…

The described protocol looks like rewording of X509 with json syntax, but you still have X509, as a result you have two X509. Replay nonce is used straightforwardly as serial number, termsOfServiceAgreed can be extension, and CSR is automatically signed in the process of generation.
Post reply on HN