Comment by adontz | Hacker News Reader

Comment by adontz | Hacker News Reader

I believe security models for HTTP and SSH are pretty different. HTTP is usually public and anonymous, SSH is usually private and authenticated. While QUIC is definitely a great technology for HTTP use case, I'm not so sure about SSH. Not saying it's not, just it's something to reason about.

For example x509 seems to be a disadvantage to me. I do not want anyone with a cheap DigiCert certificate be able to log in to my server, even as a result of some fat finger misconfiguration. OAuth assumes that both client and service provider can reach identity provider. Is it so for most serves? I am used to see pretty restricted setups, where many servers have no internet access and only update from a private package repository.

From one side, I really like the idea of reusing HTTP. Who does new protocols these days? Everything is JSON or XML over HTTP. And it's good enough for most cases. But is it good enough for SSH? WinRM works over HTTP, but it uses Kerberos for authentication.

Are there any significant real practical advantages? I don't see any. Are there any vulnerabilities, possibilities for misconfiguration, architectural flaws? Quite possible.

I don't see anything about using an X.509 certificate for logging in, just for a client authenticating the remote server. And, even then, TLS has support for mutual authentication so someone with a cheap DigiCert certificate logging into your server is not really a problem if you could configure mTLS on the server side to accept only certificates in a certain chain.

“cheap DigiCert certificate” is already possible with misconfiguration of SSH’s TrustedUserCAKeys and without any out of tree patches. https://smallstep.com/blog/use-ssh-certificates/

SSH Certs are not related to x509 PKI certs. SSH certs are created with ssh-keygen and is the result of one key signing another. The public portion of the signing key (ie. the “cert”) needs to be distributed separately.

Did you follow the link? The point was exactly setting up X.509 PKI for SSH authentication. Yes, it can be used with SSH, that was the GP's point.

you can disable X.509 for SSH

I’m replying to parent not the overall post.

The link talks about setting up a ssh ca, not x509?

> For our part, the most recent release of step & step-ca (v0.12.0) adds basic SSH certificate support. In other words:

> step-ca is now an SSH CA (in addition to being an X.509 CA)

> step makes it easy for users and hosts to get certificates from step-ca

It's a tool that do x509 ca for x509 things and ssh ca for ssh.

You can already use certificates to login via SSH. Usually you setup your own certificate authority and sign your own certs because they need special attributes.

SSH certificates (I encourage using them!) are not x509, absolutely incompatible.

It’s same general principle and same security model just different way of going about it. It supports CAs and extensions just like x509

No. For instance SSH certificates are one level only, do not support trust chains, cross signing, and a lot of other x509 complexity.

You're thinking of SSH keys, which are not certificates. SSH certificates are indeed x.509: https://datatracker.ietf.org/doc/html/rfc6187

No, I'm thinking of SSH certificates.

Here is the description of file format, it's nothing like x509

https://github.com/openssh/openssh-portable/blob/master/PROT...

> Who does new protocols these days?

My business brain understands why, but my engineer’s heart laments.

QUIC is damn good though! Its minimal header has a very tiny overhead, and the protocol gives us so much for free. What’s to lament? The userspace impl?

QUIC is indeed impressive and one of the developments that excite me.

I meant, I wish there were more application-layer protocols (like a new IRC, NNTP, rather than say Matrix or ActivityPub which is just JSON shunting over HTTP), the rest of the OSI stack gives us plenty of choice already :)

Yeah those filthy cheap DigiCert certs plebs pshh gasp. Only expensive Verisign golden batch certs get to log into my computers snobbynose

SCNR, I know it's HN which is short for "Humor? No we don't understand humor".

> OAuth assumes that both client and service provider can reach identity provider.

You could use client credentials flow with a certificate. Then all you need is to register the public key with the server, much like good old SSH.

Reply on news.ycombinator.com