Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We need better support for SSH host certificates

mjg59.dreamwidth.org

Post reply on HN
Print view View original

111–120 of 161 posts

Re: We need better support for SSH host certificates

#111

Post by dane-pgp »

Avamander wrote: post #77
xurukefi wrote: post #20

Earlier quoted context omitted.

This is such a nice and pragmatic solution. And yet for some reason people would rather prefer the CA madness we know in the HTTPS ecosystem to be established in the SSH world. I understand that DANE was ahead of its time which is why we settled with CAs for SSL certificates but can we please take a different route this time for SSH?

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 there are hundreds of gTLDs to choose from, or you could even run one yourself if necessary.

Re: We need better support for SSH host certificates

#112

Post by teddyh »

wallmountedtv wrote: post #57
captn3m0 wrote: post #21

Earlier quoted context omitted.

I’d been wanting to use this for a while, but support is lacking for most DNS providers. Maybe it should go the way of SPF and reuse TXT instead. CloudFlare added support in 2018: https://blog.cloudflare.com/additional-record-types-availabl... AWS still doesn’t support it: http://web.archive.org/web/20210429183447/https://forums.aws... Namecheap doesn’t: https://www.namecheap.com/support/knowledgebase/article.aspx...…

It specifically needed to be its own record as the record requires DNSSEC to verify that the returned SSH key is trusted. Using TXT would be ridiculously insecure as it cannot force the DNSSEC verification step that SSHFP as a unique record gives. Definitely annoying, but does ensure that the returned SSH key is always correct and not from a forged record.

What are you talking about? DNSSEC can sign TXT records perfectly well, just as any other RR type. Of course, it’s much cleaner, design-wise, to have its own RR type, and any resolvers which cannot tolerate unknown types are seriously obsolete and should be replaced.

Re: We need better support for SSH host certificates

#113

Post by teddyh »

rakoo wrote: post #83
bawolff wrote: post #33

Earlier quoted context omitted.

The usual counter-argument for https, is that the eggs are already in that basket since anyone with control of dns can just get a new certificate. For ssh that doesn't really apply as clearly though.

The issue with DANE is that now the DNS becomes a new point of failure, which means higher attention to details, more scrutiny, heavier and more secure processes for the root signing ceremonies that require more activity. It recentralizes everything and makes "failing" easier.

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

Re: We need better support for SSH host certificates

#114

Post by lxgr »

throwawaaarrgh wrote: post #109
lxgr wrote: post #101

Earlier quoted context omitted.

If TLS/HTTPS supported self-signed client certificates I could sympathize a bit more with this viewpoint. As it is, I‘d argue that straightforward protocol layer client public key authentication is one of the biggest benefits of using SSH, although I do wish X509/PKI server authentication could optionally be used with it.

> straightforward protocol layer client public key authentication is one of the biggest benefits of using SSH I disagree, it seems not straightforward at all. First as a user you have to generate a key. You need to install software and look up a manual. Then you have to give a server admin your public key, which for many users is often confused for the private key and thus defeats the purpose. Then when you connect t…

Agreed on all points about self-signed key server authentication being clunky, but my point is that SSH is doing client authentication better than HTTPS, which is orthogonal to it doing server authentication worse.

I think an ideal solution would offer some hybrid of TOFU and PKI for server authentication, and self-signed keys for client authentication (like FIDO and WebAuthN, for example), but at the protocol level.

HTTPS really falls short here and means that everybody has to implement something custom on top of it, and too often that is a login form driving OAuth.

Re: We need better support for SSH host certificates

#115

Post by jerf »

When we looked into it at work, one major problem we had with SSH certificates is that a cert can sign a key, but that's it. You can't have a cert that signs a cert that signs a key. So, the one and only cert that can sign keys still ends up having to be out there in a relatively live position, signing new keys as new machines come up and such. We really wanted to be able to create a cert, put it into super-cold storage, then sign a cert or possibly a number of other certs that could be used to sign keys. Then if one of those was compromised we could handle that particular cert, but the root cert could still be trusted by everything without breaking everything.

We ended up assessing the current host certificate situation as bringing some benefit, but it was difficult to assert that the benefits were commensurate with the costs, especially considering the many other quirks, and we judged it as distinctly possible that if we did try to roll them out we'd find some other "quirk" was actually a significant stopper.

It's not the same scale, but it's a very similar problem to what would happen if TLS could only sign at one degree of remove like that. If you occasionally take the time to poke through the padlock icon in your browser, you'll find the bare minimum trust chain you'll ever find is three; a root cert in your browser trust store, some signing cert, then the cert for the domain. I've seen some with more layers than that, but 3 is fairly common. Those 3 would be 2 in the SSH context since the last one would be the key rather than a cert. Can you imagine how much rougher it would be on the web if you could only have two levels, if a root cert could sign your site but that was it?

Re: We need better support for SSH host certificates

#116

Post by DarkCrusader2 »

> (It's actually possible to glue the general PKI infrastructure into SSH certificates. Please do not do this)

Can someone elaborate why? We are already depending on lists of known good CAs for everything (even banking). Why not leverage the same for SSH as well?

Re: We need better support for SSH host certificates

#117

Post by dane-pgp »

j16sdiz wrote: post #49
9dev wrote: post #34

Earlier quoted context omitted.

I don’t believe in the forbidden fruit ideology. If it’s stupid and works well, it isn’t stupid. People have been using DNS for all kinds of configuration for decades now, with great success. So what, other than a pedantic and grumpy programmer’s perspective, should keep us from using DNS for configuration records?

1. DNS is insecure.... DNSSEC, despite all the effort goes it, still does not work in most TLD and registers. 2. Cache. People are caching DNS aggressively. Often more aggressive than what the TTL allows. You don't want to save the fingerprint in a stale, insecure database like that.

> DNSSEC, ... still does not work in most TLD and registers.

I'd be interested to know where you get your data from. By my count, there are 142 ccTLDs that support it and 106 that don't, out of 248 ccTLDs.[0]

That's already more than half, but if you include the gTLDs then the number of TLDs signed in the DNS root goes up to 92% according to the best data I can find.[1]

[0] https://www.statdns.com/cctlds/

[1] http://rick.eng.br/dnssecstat/

Re: We need better support for SSH host certificates

#118

Post by mynameisvlad »

simiones wrote: post #82
rhco wrote: post #8

Yes! SSH certificates are awesome, both for host- and client-verification. Avoiding Trust on First Use is potentially a big benefit, but the workflow improvements for developers, and especially non-technical people, is a huge win too. 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 co…

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` ?

It’s the exact same command as a regular SSH prompt and it generates and uses the cert. that seems very simple.

Your command is disingenuous in that it only works if the certificate has already been issued to you. If you were to include issuance, your command would very much turn non-simple.

Re: We need better support for SSH host certificates

#119

Post by wkat4242 »

throwaway892238 wrote: post #17
est wrote: post #15

Earlier quoted context omitted.

> you need to abolish SSH. It's an incredibly limiting protocol that does not support modern computing needs Yes! Please invent something else, and leave SSH alone.

I meant the protocol, not the program. A secure shell is still useful, but the old protocol is like a unix neckbeard that doesn't wanna learn containers. (And while we're on the subject, SSHD should support an HTTPS port and either serve a javascript client or accept websocket connections, because it is 2023 and that's what everyone wants anyway)

Unix has had containers before Linux ever had them, and certainly before the cloud hipsters embraced docker.

Re: We need better support for SSH host certificates

#120

Post by wkat4242 »

throwaway892238 wrote: post #14

No, you need to abolish SSH. It's an incredibly limiting protocol that does not support modern computing needs. Hacks and add-ons solve some but never all of its many problems. Wire-level network protocols like Wireguard are somewhat useful, but largely a large step away from the modern best practices. We need more Zero Trust, Federated Identity, Fine-grained Access Control, and Least Privilege. Those solutions exist…

SSH is used for a lot more than just git. And for those usecases it's really good. Federated auth is also possible if needed, we use it at work.

SSHv1 is indeed an outdated protocol but nobody uses it anymore.

Post reply on HN