Mastodawn

🚀 Exciting news from Belgium🇧🇪! 4 days ago, a team of researchers has published a paper on a new implementation of SSH over HTTP/3.

📄 Discover their findings and dive into the technical details here: https://arxiv.org/abs/2312.08396

Find the Go implementation at: https://github.com/francoismichel/ssh3

For all your technical questions the author's emails are in the PDF or directly to @obonaventure , you could also open a Github issue at: https://github.com/francoismichel/ssh3/issues

#SSH #HTTP #Cybersecurity #Innovation #BelgianTech

Towards SSH3: how HTTP/3 improves secure shells

The SSH protocol was designed in the late nineties to cope with the security problems of the telnetf family of protocols. It brought authentication and confidentiality to remote access protocols and is now widely used. Almost 30 years after the initial design, we revisit SSH in the light of recent protocols including QUIC, TLS 1.3 and HTTP/3. We propose, implement and evaluate SSH3, a protocol that provides an enhanced feature set without compromise compared to SSHv2. SSH3 leverages HTTP-based authorization mechanisms to enable new authentication methods in addition to the classical password-based and private/public key pair authentications. SSH3 users can now configure their remote server to be accessed through the identity provider of their organization or using their Google or Github account. Relying on HTTP/3 and the QUIC protocol, SSH3 offers UDP port forwarding in addition to regular TCP forwarding as well as a faster and secure session establishment. We implement SSH3 over quic-go and evaluate its performance.

arXiv.org

@Pol I have some many questions starting with why like why http, why not websocket, why quic, why not mosh and why that:

> Using SSH3, you can avoid the usual stress of scanning and dictionnary attacks against your SSH server.

In my experience if you only use pubkey auth and only turn on some newer ciphers, then this is a very small background noise of things that cannot connect.

Also if you are in a restricted enterprise environment, then you want classic TLS over port 443.

Raito Bezarius Dec 16, 2023

@Pol I'm so happy, francophonie for the win? :D

Morten Linderud Dec 16, 2023

@Pol
Binding host keys to x509 and the CAs seems like a step backwards instead of having local CA/PKI bound to hardware.

Raito Bezarius Dec 17, 2023

@Foxboron @Pol This is a prototype, this is not the focus of this piece of software

Morten Linderud Dec 17, 2023

@raito @Pol
"Prototype" isn't mentioned once in the readme.
It says experimental and even then it makes security claims about the SSH PKI model.

Raito Bezarius Dec 17, 2023

@Foxboron @Pol Right, we can criticize them for not taking the time to write it in their README, I surmise they spend quite the time on the rest and on the paper which contains 8 references of the word prototype. :)

Morten Linderud Dec 17, 2023

@raito @Pol
Can't hide behind "prototype" in the academic paper if your entire README is a product pitch to replace ssh :p

Raito Bezarius Dec 17, 2023

@Foxboron @Pol Well, who never write a marketing cheesy README in anticipation with higher ambition than what the actual project was. :)

I would give them some rest and wait for the dust to settle before going at them relentlessly, weighting every word they use :P.

Raito Bezarius Dec 17, 2023

@Foxboron @Pol But it already replaced SSH for me in almost all of my infrastructure ;)

Raito Bezarius Dec 17, 2023

@Foxboron @Pol I think we can talk about the SSH PKI model from a theoretical standpoint, at least, I can see the interest of what they are saying in the context of the SSHv2 protocol.

Morten Linderud Dec 17, 2023

@raito @Pol
One sentence isn't enough to convince me that the fairly simple model in SSH should be replaced with the eldritch horrors of X509 and system CA stores 🙃

Raito Bezarius Dec 17, 2023

@Foxboron @Pol Conversely, I have no reason to believe that the "fairly simple model in SSH" should be kept as-is and who know how many horrors are lurking in this codebase, which is honestly, in a sad state.

Either case, I'm happy to try something else in that area, I have grown very unsatisfied of SSH for many reasons and I don't trust OpenSSH upstream on security decisions.

Raito Bezarius Dec 17, 2023

@Foxboron @Pol (but we have, as you know well, a lot of people spending their free time on X509 eldritch horrors and trust CA stores and what not, those are things that I believe we came to understand a bit better than SSHv2 protocol, especially in combination with other features.)

Morten Linderud Dec 17, 2023

@raito @Pol
I'm not necessarily talking about OpenSSH though. The entire wire format and everything that goes along with OpenSSH is standardized and have multiple implementations.

Raito Bezarius Dec 17, 2023

@Foxboron @Pol Yes but from a realistic standpoint, I won't run BSD SSH on my system neither Go SSH on my system as a daemon replacement for my sshd. At the time, I am not aware of any realistic replacement of that critical piece of software.

I am well aware that the entire wire format is standardized, I did say SSHv2 multiple times ;).

Nevertheless, I would like to leave SSHv2 where it should stay and benefit from the tremendous efforts spent in TLS in my "secure shell" stack.

Raito Bezarius Dec 17, 2023

@Foxboron @Pol And honestly, all of this does not preclude TOFU if you really want it. And if you don't want X.509, I'm sure you can bring your own container for host keys.

I am not so sure all of that is a "hard point" of this project. (TOFU is definitely already available anyway.)