141–150 of 206 posts
Why is there http/3 in the middle? SSH over QUIC makes a lot of sense and was something I thought about before. The SSH protocol is designed to multiplex many “channels” over an encrypted tcp socket. Over each channel you can run things like a shell or SFTP. It would need some engineering but you could keep the same SSH features but replace the multiplexing channels over tcp with QUIC channels over udp. Where does HT…
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
Ok, I've put SSHv2 in the title to make that clearer. If there's a better way, we can change it again.
I don’t think this is SSHv2 though the GitHub talks about reimplementation on HTTP semantics, and the paper illustrates SSHv2 vs SSH3 as being extremely different for session setup. In naming; Francois also explains SSH3 is a concatenation of SSH and HTTP/3 — we can not like that here on HN (due seemingly to the lack of IETF involvement?) but it’s what the project creators picked.
What if you already run a web server which uses port 443? Strange that the readme doesn't mention that scenario because it's extremely common. Presumably you'd choose a different port but then it'd be pretty obvious you're running something if your server has a random HTTPS server exposed on port 444 or whatever.
Earlier quoted context omitted.
Odd, surely SSHv2 already suffers from inability to inspect on the wire.
From the Github: SSH3 is a complete revisit of the SSH protocol, mapping its semantics on top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for secure channel establishment and the HTTP Authorization mechanisms for user authentication. So, it has nothing to do with SSH2; more about HTTP/3-QUIC security theater: hostname is still being sent over TLS/1.3 negotiation.
But I don't see how this is worse than SSHv2. In both cases retrieving the hostname / IP is obviously trivial since you just instrument DNS for the hostname and, of course, the IP is cleartext.
- SSH3 is a bad name: this isn't a successor to SSHv2 and will only cause confusion
- The authors don't seem to understand that SSHv2 predates all of their chosen technologies, and provides "robust and time-tested mechanisms" they claim to be adding
- How is "hiding your server behind a secret link" a feature? This is, at best, security through obscurity, which can be layered on any network protocol (e.g. https://en.wikipedia.org/wiki/Port_knocking); this implies that the authors don't have much of a security background...?
- ...Which explains why they think something as complicated as OpenID Connect is a good thing to add to SSH (i.e. https://security.stackexchange.com/questions/148292/why-is-o...)
- The abstract in the linked paper seems to conflate SSHv1 and SSHv2; I couldn't really bring myself to read much past that
In summary: this seems bad.
Earlier quoted context omitted.
“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.
Earlier quoted context omitted.
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.