4 ms·

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

m463 1y ago
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.
chrisfosterelli 1y ago
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.
- xg15 1y ago
  Yeah, building it on top of QUIC is reasonable, but trying to shoehorn SSH into HTTP semantics feels silly.
  - conradludgate 1y ago
    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
    - MrDarcy 1y ago
      Google Cloud’s identity aware proxy underpinning the gcloud compute ssh command works the same way, as an http CONNECT upgrade.
      - hxtk 1y ago
        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.
    - thayne 1y ago
      > 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.
xg15 1y ago
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.
- singpolyma3 1y ago
  Indeed. "Using quic with a handshake that smells like http3" is hardly "using http" imo
fulafel 1y ago
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.
MrDarcy 1y ago
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.
zenmac 1y ago
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.
- Telemakhos 1y ago
  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.
  - zenmac 1y ago
    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?
  - Fnoord 1y ago
    > 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-safe-than-tls-ssl https://serverfault.com/questions/523804/is-starttls-less-sa...
oofbey 1y ago
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.
- temp0826 1y ago
  Humbug. I feel an urge to implement token ring over fiber. Excuse me while I yell at clouds.
attentive 1y ago
quic is more layer 4 or close to tcp reimplementation. Far from http layer 7.
codedokode 1y ago
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.
- doublerabbit 1y ago
  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.
  - codedokode 1y ago
    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.

m463 1y ago

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.

chrisfosterelli 1y ago

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.

xg15 1y ago
Yeah, building it on top of QUIC is reasonable, but trying to shoehorn SSH into HTTP semantics feels silly.
- conradludgate 1y ago
  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
  - MrDarcy 1y ago
    Google Cloud’s identity aware proxy underpinning the gcloud compute ssh command works the same way, as an http CONNECT upgrade.
    - hxtk 1y ago
      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.
  - thayne 1y ago
    > 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.

xg15 1y ago

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.

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

fulafel 1y ago

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.

MrDarcy 1y ago

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.

zenmac 1y ago

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.

Telemakhos 1y ago
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.
- zenmac 1y ago
  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?
- Fnoord 1y ago
  > 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-safe-than-tls-ssl https://serverfault.com/questions/523804/is-starttls-less-sa...

oofbey 1y ago

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.

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

attentive 1y ago

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

codedokode 1y ago

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.

doublerabbit 1y ago
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.
- codedokode 1y ago
  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.