Live data from Hacker News

SSL certificate requirements are becoming obnoxious

chrislockard.net

191–200 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#191

Not mentioned - especially for smaller or short-staffed org's, it may be a non-trivial effort to automate, then secure/document/maintain the automation. Vs. shoving httpS proxy services in front of insecure backends is often easy.

That is my standard approach when I deploy something. My application shouldn't deal with TLS unless it needs to.

Usually fronting a service with Traefik or NGINX fits all the business needs.

I do recall a setup in Kubernetes where nearly all traffic had to be encrypted, even within the cluster. The boundary was the pod. Within a pod you are guaranteed that all containers run on the same node. And since a node is a physical boundary (it's either a physical machine or a vm on a physical machine) you're guaranteed that that traffic never goes over a network cable.

The solution then is to deploy something like LinkerD which ensures that traffic between pods is encrypted transparently. We could've eased the policy that traffic between pods on the same node shouldn't be encrypted, but then we introduced more variables in the process, and it wasn't worth it.

Re: SSL certificate requirements are becoming obnoxious

#192

Earlier quoted context omitted.

This is what fascinated me too. FWIW the idea of inspecting the certificate "for typos" or similar doesn't make sense. What you're getting from the CA wasn't really the certificate but the act of signing it, which they've already done. Except in some very niche situations your certificate is always already publicly available when you receive it, what you've got back is in some sense a courtesy copy. So it's too late…

It's possible that this was just a slight imprecision of language, and the thing being inspected is the CSR rather than the actual certificate. (But the point about individual certificates/CSRs being unworthy of human attention is totally right.)

That's true, although inspecting a CSR is also daft because much of the CSR is actually ignored by the CA so you can "check" it but if it was "wrong" that makes absolutely no difference to anything.

The CA is going to look at the requested names (to check they were authorized) and they'll also copy the requested public key, this combination is what's certified. But if your antiquated gear spits out a CSR which also gives a (possibly bogus) company name and an (maybe invalid) street address "checking" that won't matter because the CA will just throw it away, the certificate they issue you isn't allowed to contain information they didn't check, so that part of your CSR is just tossed away without reading it.

Re: SSL certificate requirements are becoming obnoxious

#193

The one complaint that I think is valid is that automating wildcard certificates at the moment is really tricky. And that really is because most of the DNS providers do not have proper APIs for it.`

Most? https://registry.terraform.io/search/providers?q=dns seems to be a pretty healthy list, and https://registry.terraform.io/providers/hashicorp/dns/latest will work for any one that honors https://datatracker.ietf.org/doc/html/rfc2136 (although "honoring standards" is probably the very problem you were citing)

Re: SSL certificate requirements are becoming obnoxious

#194
post #145

Earlier quoted context omitted.

And yet, I am a bit worried that now, most of the web depends on LetsEncrypt. That's a single point of failure. Sure, they are "good guys", really, but remember that Google used to be "good guys" too. And this is a US-based organization, dependent on US rules, which is not so bad, but alternatives would be nice. And yes, there are alternatives, but everything is made so that LetsEncrypt is the only reasonable choice.…

How would you propose things should work instead?

The idea would be the ability for a certificate to accept multiple signatures, making it more of a "web-of-trust" system. So you still have your LetsEncrypt certificate, but maybe augmented by another signature from an similar authority located in another country, or some other reputable organization that has your best interests in mind.

Maybe there are problems with that, but I never really understood the limit of a single signature for certificates. Is it because of bandwidth and performance requirements? Is it really a problem nowadays? especially with ECDSA making public keys much smaller.

Re: SSL certificate requirements are becoming obnoxious

#195
post #3

I understand OP's frustration, but the alternate view is that mandating better practices is a forcing function for businesses that otherwise don't give a shit about users or their privacy or security. For all the annoyance of SOC2 audits, it sure does make my manager actually spend time and money on following the rules. Without any kind of external pressure I (as a security-minded engineer) would struggle to convince…

Why is a month's expiration better than a year or two years? Why wouldn't you go with a week or a day? isn't that better than a whole month? Why isn't it instead just a minute? or a few seconds? Wouldn't that be better? Why not have certificates dynamically generated constantly and have it so every single request is serviced by a new one and then destroyed after the session is over? Maybe the problem isn't that certi…

As the limit approaches zero you re-invent Kerberos.

Re: SSL certificate requirements are becoming obnoxious

#196

Since the advent of LetsEncrypt, ACME, and Caddy I haven't thought about SSL/TLS for more than about an hour per year, and that's only because I forget the steps required to setup auto-renewal. I pay nothing, I spend a tiny amount of time dealing with it, and it works brilliantly. I'm not sure why many people are still dealing with legacy manual certificate renewal. Maybe some regulatory requirements? I even have a w…

Speaking as someone who has worked in tightly regulated environment, certificates are kind of a nasty problem and there are a couple of requirements that are in conflict for going to full automation of certificates.

- Rotation of all certificates and authentication material must be renewed at regular intervals (no conflict here, this is the goal)

- All infrastructure changes need to have the commands executed and contents of files inspected and approved in writing by the change control board before being applied to the environment

That explicit approval of any changes being made within the environment go against these being automated in any way shape or form. These boards usually meet monthly or ad-hoc for time-sensitive security updates and usually have very long lists of changes to review causing the agenda to constantly overflow to the next meeting.

You could probably still make it work as a priority standing agenda idea but its going to still involve manual process and review every month. I wouldn't want to manually rotate and approve certificates every month and many of these requirements have been signed into law (at least in the US).

Starting to see another round of modernization initiatives so maybe in the next few years something could be done...

Re: SSL certificate requirements are becoming obnoxious

#197

Earlier quoted context omitted.

Certs are free. All you need is a domain name and letsencrypt.

Slippery slope. Who controls the domain name system? Who controls how certs are handled by browsers and which ones are trusted? All of these things we take for granted can change. You're watching it happen right now.

The domain system needs at least some central control at the top, or it literally won't work. Do you remember the various "alternate root" projects in the 90's? I've stopped following them.

The cert situation has vastly improved over the past 30 years. I remember paying $100's of dollars for certificates in the 90's, faxing in forms, etc.

Re: SSL certificate requirements are becoming obnoxious

#198
post #173

Earlier quoted context omitted.

As someone on the other side of the fence who lives primarily in IT land, this is far from a solved problem. Not every device supports SSH for copying certs across the network, some devices have arbitrary requirements for the certs themselves (like timelines, lack of SANs, specific cryptography requirements, etc), and signing things internally (so that they’re only valid within the intranet, not on the internet) does…

I feel like a lot of these requirements need to be really solved from first principles. What do you need these certificates for -- specifically, TLS certificates? If the biggest issue is "we want to encrypt traffic" then the answer really should be something more automated. To put it another way, TLS certificates used to convey a lot of things. We had basic certs that said "you are communicating with the rightful own…

What do I need these certificates for? I need them because browsers have started equating a vanilla http server to a malware-infested North Korean honeypot

Re: SSL certificate requirements are becoming obnoxious

#199
post #11

Earlier quoted context omitted.

>Automated renewal is... probably about a decade or two from being supported well enough to be an actual answer. ??? All my servers use certbot and it works fine. There's also no shortage of SaaS/PaaS that offer free ssl with their service, and presumably they've got that automated as well.

Out of about three dozen places I need a certificate, I believe one recently added support for ACME. Tell me you aren't in enterprise IT without telling me you aren't in enterprise IT. ;) It may help you to understand that it is not an assumption any given product even supports HTTPS well in the first place, and a lot of vendors look at you weird when you express that you intend to enable it. One piece of software re…

Put a reverse proxy in front of it. Write a script. Use RPA for the really obnoxious ones. There are lots of workarounds.

Re: SSL certificate requirements are becoming obnoxious

#200
I've only put maybe 2 seconds of thought into this so it is probably stupid, but why don't we have an alternative that does not require third party certificate authorities?

For example why not allow an organization to have its own self-signed certificate authority, and allow it to publish its self-signed root certificate through DNS, and make browsers accept that root for use with that domain?

I see two objections offhand.

Objection #1. It doesn't provide any validation that the certificates were actually made by the legal entity that they claim to be for. It just shows that whoever made the CA had write access to the domain's DNS records. It can't replace EV certificates or OV certificates.

Retort #1. So? Those sites that need EV of OV certificates can keep using the current approach. But a very large number of sites don't need EV or OV certificates. This can be seen by the success of Let's Encrypt which only issues DV certificates. Even some large sites use DV certificates, such as Amazon.

Objection #2. If someone gets write access to your DNS records they can replace your CA!

Retort #2. So? If someone gets write access to your DNS records they can make Let's Encrypt certificates for your domain.

What have I overlooked?

Post reply on HN