Live data from Hacker News

We need better support for SSH host certificates

mjg59.dreamwidth.org

141–150 of 161 posts

Re: We need better support for SSH host certificates

#141

Earlier quoted context omitted.

I'm going to skip the long part, but what you're basically requesting is that everyone must trust the countries operating their ccTLDs. Does that sound reasonable? I don't think so.

Don't we already implicitly have that sort of trust at the moment with TLS certs considering that proof of ownership via DNS is quite common? Actually, any domain-based validationi, i.e., also HTTP-01, is going to be flawed if you don't trust the registries.

Kind-of, but not really. Multipath validation exists and you can not trust most (if not all) of DNS during issuance technically. Even if that goes wrong, we have Certificate Transparency to detect misissuance, this doesn't exist with DNSSEC.

Re: We need better support for SSH host certificates

#142

Earlier quoted context omitted.

You really never ssh from one remote server to another?

SSHing from one remote server to another won’t be possible in a lot of environments due to network segmentation. For example, it shouldn’t be possible to hop from one host to another via SSH in a prod network supporting a SaaS service. Network access controls in that type of environment should limit network access to only what’s needed for the services to run.

I've seen the exact opposite configuration where it's not possible to avoid SSHing from one remote server to another due to network segmentation, as on the network level it's impossible to access any production system directly via SSH but only through a jumphost, which obviously does not have a browser installed.

Re: We need better support for SSH host certificates

#143

Earlier quoted context omitted.

I'm going to skip the long part, but what you're basically requesting is that everyone must trust the countries operating their ccTLDs. Does that sound reasonable? I don't think so.

Trusting the country that operates the ccTLD of your website is a much better situation than having to trust all the countries that have CAs operate in them. A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design. Moreover, no one is required to use a ccTLD, and th…

> A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design.

Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator.

> Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could even run one yourself if necessary.

This is bypassing a dangerous design, at best.

Re: We need better support for SSH host certificates

#144
post #79

Anyone else relying on GSSAPI key exchange & authentication instead?

I assume that means Kerberos, as opposed to GSSAPI mechanisms like (the moribund?) ABFAB, (now rightly deprecated?) Globus GSI, or even NTLM. I've used Kerberos GSSAPI with ssh long ago, but no longer can at work. Incidentally, people arguing for X.509 might consider why GSI is such a dirty word in the research computing circles I know! I think it's still widely used in HEP, and even the US Access system, though.

Re: We need better support for SSH host certificates

#145
post #122
post #113

Earlier quoted context omitted.

The CA system is just multiple points of failure instead of one. One is better.

No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.

So? If an authoritative DNS server operator is broken, only the domains below that operator (in the DNS hierarchy) could be impacted.

Re: We need better support for SSH host certificates

#146
post #144
post #79

Anyone else relying on GSSAPI key exchange & authentication instead?

I assume that means Kerberos, as opposed to GSSAPI mechanisms like (the moribund?) ABFAB, (now rightly deprecated?) Globus GSI, or even NTLM. I've used Kerberos GSSAPI with ssh long ago, but no longer can at work. Incidentally, people arguing for X.509 might consider why GSI is such a dirty word in the research computing circles I know! I think it's still widely used in HEP, and even the US Access system, though.

Yeah, Kerberos. Don't think I've ever seen the GSSAPI used for anything else!

Re: We need better support for SSH host certificates

#147
post #131

Earlier quoted context omitted.

At work, we switched to Step CA [1] about 2 years ago. The workflow for our developers looks like: 1. `ssh client-hosts-01` 2. Browser window opens prompting for AzureAD login 3. SSH connection is accepted How is that simple, compared to `ssh -i .ssh/my-cert.rsa someone@destination --> connection is accepted, here's your prompt` ?

What if you're ssh-ing from a headless client, like a raspberry pi or a VPS?

Then it doesn’t work but their developers are ssh-ing from their work laptops so it doesn’t matter. Something doesn’t have to be a solution for all use cases to be a good solution.

Re: We need better support for SSH host certificates

#148
post #145
post #122

Earlier quoted context omitted.

No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.

So? If an authoritative DNS server operator is broken, only the domains below that operator (in the DNS hierarchy) could be impacted.

DNSSEC relies on a hierarchy of trust, with a single root zone at the top. If the root zone has issues, the whole system breaks down.

In contrast, there is no unique "root CA" that can fail.

Re: We need better support for SSH host certificates

#149
post #122
post #113

Earlier quoted context omitted.

The CA system is just multiple points of failure instead of one. One is better.

No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.

A CA can sign for any site. I'd say a single CA compromise breaks the entire system until it is revoked.

DNS root key compromise breaks the entire system until it is replaced.

Not seeing a huge difference.

Re: We need better support for SSH host certificates

#150
post #122

Earlier quoted context omitted.

No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.

A CA can sign for any site. I'd say a single CA compromise breaks the entire system until it is revoked. DNS root key compromise breaks the entire system until it is replaced. Not seeing a huge difference.

There are multiple "root" CAs. CA compromises happen all the time, and it has always been dealt with because the fact that multiple "roots" exists means each one has to be kept in check. It's also possible for you (or more realistically for a company) to have their own CA, with their own certificates for all the sites you need. Not being unique applies pressure on each member to behave correctly because it is possible to get rid of them.

It is not possible to revoke the DNS root, and there are no widely deployed alternatives. The incentive to do the right thing isn't as hard: it's just "good" guys doing the right stuff. If something wrong happens, where will you go ? Nowhere else.

Post reply on HN