TL;DR: When trying to use SSH from within a company network that only allows web traffic, is just connecting to an SSH server over port 80/443 "good enough" in 2022?
BACKGROUND: Some networks block all outbound connections except for web traffic (usually port 80/443), so to get SSH clients around this we run the OpenSSH server on those ports. SSH clients can then make connections from within the limited network either directly to the server, or if an HTTP(s) proxy is required, use something like Proxytunnel[1].
However, in modern networks there are content filtering firewalls now filtering at the application layer that looks for SSH traffic (and sometimes specifically proxied traffic). SonicWall[2] does this.
THE QUESTION: In practice, does anyone here ever run into that or does simply running SSH over HTTP ports just work? Is there proxy software that encodes the SSH protocol in a *true* HTTP protocol that would still work where application layer filtering is operating? I'm curious how reality compares to all of the theoretical.
Thanks! -redsun
REFERENCES: [1] Proxytunnel https://proxytunnel.sourceforge.io/
[2] SonicWall SSH Blocking https://www.sonicwall.com/support/knowledge-base/how-to-block-ssh-tunneling-...
I've never had an employer who ran a DPI firewall, thankfully. If I had, iodine (IP over DNS) might be a good option. I'm told that even gets through the captive portals on airplane wifi. Might not be pleasant for interactive SSH but would likely work.
It’s not good enough in the sense that if the company has deliberately chosen to block traffic on SSH ports, then you may be violating a company policy by circumventing this, and if they catch you, they may assume malicious intent and your employment may be at risk.
If you want to SSH at work, it may be safer to bring your own laptop and tether it to your phone.
Sent from my iSeries
On 18 Feb 2022, at 22:27, redsun@tilde.club wrote:
TL;DR: When trying to use SSH from within a company network that only allows web traffic, is just connecting to an SSH server over port 80/443 "good enough" in 2022?
BACKGROUND: Some networks block all outbound connections except for web traffic (usually port 80/443), so to get SSH clients around this we run the OpenSSH server on those ports. SSH clients can then make connections from within the limited network either directly to the server, or if an HTTP(s) proxy is required, use something like Proxytunnel[1].
However, in modern networks there are content filtering firewalls now filtering at the application layer that looks for SSH traffic (and sometimes specifically proxied traffic). SonicWall[2] does this.
THE QUESTION: In practice, does anyone here ever run into that or does simply running SSH over HTTP ports just work? Is there proxy software that encodes the SSH protocol in a *true* HTTP protocol that would still work where application layer filtering is operating? I'm curious how reality compares to all of the theoretical.
Thanks! -redsun
REFERENCES: [1] Proxytunnel https://proxytunnel.sourceforge.io/
[2] SonicWall SSH Blocking https://www.sonicwall.com/support/knowledge-base/how-to-block-ssh-tunneling-...
I agree that doing something that violates company policy can get you into trouble. However, my question was more aimed to see if this is really an issue. Our club server, tilde.club, has SSH running to allow us to connect via those web ports--I was curious if anyone uses that other than something fun to do, or it it helps in anyone's situation.
I was thinking of building something that encapsulates SSH traffic into HTTP, but that's not useful if you can simply comment to SSH over port 443 :)
On Fri, 18 Feb 2022, lab6 wrote:
It’s not good enough in the sense that if the company has deliberately chosen to block traffic on SSH ports, then you may be violating a company policy by circumventing this, and if they catch you, they may assume malicious intent and your employment may be at risk.
If you want to SSH at work, it may be safer to bring your own laptop and tether it to your phone.
Sent from my iSeries
On 18 Feb 2022, at 22:27, redsun@tilde.club wrote:
TL;DR: When trying to use SSH from within a company network that only allows web traffic, is just connecting to an SSH server over port 80/443 "good enough" in 2022?
BACKGROUND: Some networks block all outbound connections except for web traffic (usually port 80/443), so to get SSH clients around this we run the OpenSSH server on those ports. SSH clients can then make connections from within the limited network either directly to the server, or if an HTTP(s) proxy is required, use something like Proxytunnel[1].
However, in modern networks there are content filtering firewalls now filtering at the application layer that looks for SSH traffic (and sometimes specifically proxied traffic). SonicWall[2] does this.
THE QUESTION: In practice, does anyone here ever run into that or does simply running SSH over HTTP ports just work? Is there proxy software that encodes the SSH protocol in a *true* HTTP protocol that would still work where application layer filtering is operating? I'm curious how reality compares to all of the theoretical.
Thanks! -redsun
REFERENCES: [1] Proxytunnel https://proxytunnel.sourceforge.io/
[2] SonicWall SSH Blocking https://www.sonicwall.com/support/knowledge-base/how-to-block-ssh-tunneling-...
Guacamole[0] supports SSH connections[1]. This isn't running SSH over HTTP, but does result in a terminal in a web browser. In my experience while simply changing the listening port does work in general, when a network operators is using DPI or similar, they have typically failed closed. If they're unable to intercept the traffic it's blocked.
[0] https://guacamole.apache.org/ [1] https://guacamole.apache.org/doc/gug/configuring-guacamole.html#ssh
I haven't seen Guacamole--that is an interesting way to do it. I also see it supports Windows, Linux, and Linux terminal. Although it does not support things like SCP or SFTP style traffic for file upload/download, it would be great at supporting remote admin functions (I guess as long as you were using 2FA or something for authentication if your company's DPI was grabbing your credentials.) Thanks JDM
On 2/21/2022 4:07 PM, JDM wrote:
Guacamole[0] supports SSH connections[1]. This isn't running SSH over HTTP, but does result in a terminal in a web browser. In my experience while simply changing the listening port does work in general, when a network operators is using DPI or similar, they have typically failed closed. If they're unable to intercept the traffic it's blocked.
[0] https://guacamole.apache.org/ [1] https://guacamole.apache.org/doc/gug/configuring-guacamole.html#ssh
tildeclub@lists.tildeverse.org
-
JDM -
lab6 -
redsun -
redsun＠tilde.club
-
wgreenhouse