SSH3: Faster and rich secure shell using HTTP/3

I don't know why it makes me a little sad that every application layer protocol is being absorbed into http.

It feels a little like a kludge as long as we keep calling it http. The premise makes sense -- best practices for connection initialization have become very complex and a lot of protocols need the same building blocks, so its beneficial to piggyback on the approach taken by one of the most battle tested protocols -- but it's not really hypertext we're using it to transfer anymore so it feels funny.

Yeah, building it on top of QUIC is reasonable, but trying to shoehorn SSH into HTTP semantics feels silly.

If this were really the case, it would indeed be sad, as the standard HTTP request/response model is both too restrictive and too overengineered for many usecases.

But both HTTP/2 and QUIC (the "transport layer" of HTTP/3) are so general-purpose that I'm not sure the HTTP part really has a lot of meaning anymore. At least QUIC is relatively openly promoted as an alternative to TCP, with HTTP its primary usecase.

Is there some indication that this is going to be adopted? The linked ietf submission is an expired individual draft (which anyone can send in) and not from the ssh spec working group, sounds like this is from some reseachers that used SSH3 as an optimistic name.

It’s a necessary evil resulting from misguided corporate security teams blocking and intercepting everything else.

Looking at you, teams who run Zscaler with tls man in the middle attack mode enabled.

Yeah we got those good old network ppl or their corporate (don't knows much about tech) overlord to thank for that.

If you ever using wifi in the airport or even some hotel with work suite unit around the world, you will notice that Apple Mail can't send or receive emails. It is probably some company wide policy to first block port 25 (that is even the case with some hosting providers) all in the name of fighting SPAM. Pretty soon, 143, 587, 993, 995.... are all blocked. Guess 80 and 443 are the only ones that can go through any firewalls now days. It is a shame really. Hopefully v6 will do better.

So there you go. And know EU wants to do ChatControl!!!! Please stop this none-sense, listen to the people who actually knows tech.

It's on top of HTTP CONNECT, which is intended for converting an existing request (QUIC stream) into a transparent byte stream. This removes the need to deal with request/response semantics.

The reasons states to use http3 and not QUIC directly makes sense with littlest downside - you can run it behind any standard http3 reverse proxy, under some subdomain or path of your choosing, without standing out to port scanners. While security through obscurity is not security, there's no doubt that it reduces the CPU overhead that many scanners might incur if they discover your SSH server and try a bunch of login attempts.

Running over HTTP3 has an additional benefit. It becomes harder to block. If your ssh traffic just looks like you're on some website with lots of network traffic, eg google meet, then it becomes a lot harder to block it without blocking all web traffic over http3. Even if you do that, you could likely still get a working but suboptimal emulation over http1 CONNECT

Port 25 is insecure and unencrypted; EU doesn't even need ChatControl to hoover up that data, and you'd better believe anything going through an airport wifi router unencrypted is being hoovered by someone no matter what jurisdiction you're in. Apple mail prefers 587 for secure SMTP and 993 for secure IMAP.

People were (wisely) blocking port 25 twenty years ago.

Indeed. "Using quic with a handshake that smells like http3" is hardly "using http" imo

Ah thanks for the correction. Just changed my post above to 587. What I mean is why block all the ports, just keep it open let the user decide if they want to use it. And linux people can always use ufw on their side to be safe. Back in the dot com days, there were people also using telnet, but that got changed to ssh.

Is it because it is hard to detect what type of the request that is being sent? Stream vs Non Stream etc?

I hear you that it feels like something is off. The lack of diversity feels like we're losing robustness in the ecosystem. But it can be a good thing too. A lot of security issues are concentrated into one stack that is very well maintained. So that means everything built on top of it shares the same attack surface. Which yes means it can all come crashing down at once, but also that there are many eyes looking for vulnerabilities and they'll get fixed quickly. Similarly perf optimizations are all shared, and when thing get this popular can get pushed down into hardware even.

It's not like we see a lot of downsides that the world collectively agreed on TCP/IP over IPX/SPX or DECNet or X.25. Or that the linux kernel is everywhere.

Google Cloud’s identity aware proxy underpinning the gcloud compute ssh command works the same way, as an http CONNECT upgrade.

> People were (wisely) blocking port 25 twenty years ago.

20 years ago (2005) STARTTLS was still widely in use. Clients can be configured to call it when STARTTLS isn't available. But clients can also be served bogus or snake oil TLS certs. Certificate pinning wasn't widely in use for SMTP in 2005.

Seems STARTTLS is deprecated since 2018 [1]

Quote: For email in particular, in January 2018 RFC 8314 was released, which explicitly recommends that "Implicit TLS" be used in preference to the STARTTLS mechanism for IMAP, POP3, and SMTP submissions.

[1] https://serverfault.com/questions/523804/is-starttls-less-sa...

Humbug. I feel an urge to implement token ring over fiber. Excuse me while I yell at clouds.

> you can run it behind any standard http3 reverse proxy

As long as said proxy supports a http CONNECT to a bi-directional connection. Which most I know of do, but may require additional configuration.

Another advantage of using http/3 is it makes it easier to authenticate using something like oauth 2, oidc, saml, etc. since it can use the normal http flow instead of needing to copy a token from the http flow to a different flow.

quic is more layer 4 or close to tcp reimplementation. Far from http layer 7.

This is actually good because every protocol ideally must look the same to make traffic shaping and censorship harder. Either random stream of bytes or HTTP.

If you are designing a protocol, unless you have a secret deal with telcos, I suggest you masquerade it as something like HTTP so that it is more difficult to slow down your traffic.

Having all protocol look the same makes traffic shaping harder. If you develop a new protocol, do not make your protocol stand out, you won't win anything from it. Ideally all protocols should look like stream of random bytes without any distinctive features.

It also gives you two authenticated protocol layers, which helps them because most standard protocols don’t support multiple authenticated identities. Their zero trust model uses it to authenticate each time you make a connection that your machine has authorization to connect to that endpoint via a client certificate, and then the next protocol layer authenticates the user.

It's been known they throttle HTTP too.

So your super speedy HTTP SSH connection then ends up being slower than if you just used ssh. Especially if your http traffic looks rogue.

At least when its its own protocol you can come up with strategies to work around the censorship.

The main problem with port 25 isn't that it's unencrypted, but rather that it's mixing two two concerns: (Often unauthenticated) server-to-server mail forwarding, and (hopefully always authenticated, these days) client-to-server mail submission.

A network admin can reasonably want to have the users of their network not run mail servers on it (as that gets IPs flagged very quickly if they end up sending or forwarding spam), while still allowing mail submission to their servers.

Blocking outbound port 25 is completely reasonable, just like blocking inbound port 80 or 443 would be (if inbound connections even were an option, which they aren't in most networks, at least for IPv4).

Blocking ports 587, 993, 995 etc. is indeed silly.

Port 25, which you call insecure and unencrypted, is using the same protocol as port 587, which you call secure - SMTP with STARTTLS.

No. If you masquerade as HTTPS you can set your SNI to trump.example.com or republicans.example.com and nobody would dare to slow down this traffic. If you have a custom, detectable protocol then you already lost the game.

There is not only censorship, but traffic shaping when some apps are given a slow lane to speed up other apps. By making your protocol identifiable you gain nothing good.

also, would someone need to have rights to ssh to call it ssh version 3?

kind of like if a random person created an (unaffiliated) hacker news 2.0 website.