15 ms·

SSH over HTTPS

426 points by jandeboevrie 3y ago

kiririn 3y ago
I have always kept an SSTP VPN server handy after experiencing this exact scenario of hospital WiFi that only allows HTTPS traffic, but this is an interesting alternative
joveian 3y ago
There is often also option 3, put ssh on port 80 and/or 443 on a different host and ProxyJump to the intended destination (and/or use SOCKS to that host to generally get a less filtered internet connection). I use SOCKS and also forward DNS over TLS over the ssh connection via port forwarding. At least several years ago when I first set up my SOCKS proxy and was using wifi quite a bit I never found one that did anything more than check the port, although I have heard they exist and could be more common now (and of course it doesn't matter how common they are if one is in your way).
- askiiart 3y ago
  Back in my freshman year of high school, I was just starting to get into self-hosting. As it turns out, the school blocked websites, but did absolutely nothing about ports. So of course, I just SSH'd over to my server and carried on as normal. Later, I was working on making an archive of Windows .iso files, and since I had some free time, I was downloading them on my laptop and then uploading them to my server with scp. As it turns out, using dozens of gigabytes, in both upload and download, on a port besides 80 and 443, is enough to finally get your traffic inspected, so around lunchtime IT finally blocked port 22. But you know what they didn't block? Every other port! So I just moved SSH to port 443 in my port forwarding and carried on as normal. A long time later, sometime during sophomore year IIRC, the school's IT noticed me SSH-ing over port 443 and put an end to that. They set up some basic traffic analysis to block SSH on ports 80 and 443. But you know what they didn't block? Every other port! Eventually they just ended up blocking my server at the IP level (the IP of my domain), but of course, but you know what they didnt block? Literally every other IP! I could get around it by just ProxyJump-ing with a VPS, but being an early college high school student, after sophomore year I rarely go to the high school, so it's not really worth the effort. But next time I do go, I'll do it, just to prove I can. If they finally block SSH on all ports, then I can just set up SSH over HTTPS on the VPS, of course. There's still more they can do, of course, but I'll come back after I graduate and see what I can do on their guest wifi. Anyways, thanks, Birdville Independent School District IT team, it's been quite fun, though it really would be nice if you'd unblock my site so that I can provide the services the district won't (computers (VMs) actually useful for tech students).
  - jofla_net 3y ago
    It seems like the only way to correctly use the network is to not use it! :/
  - swifthesitation 3y ago
    I enjoyed this story. Thank you for sharing.
tombert 3y ago
Dumb question, but couldn't you just tell the OpenSSH server to use port 80 or port 443 or something and just connect like `ssh me@host -p 80`?
- charcircuit 3y ago
  That just changes the port it uses. It wouldn't change the protocol.
  - tombert 3y ago
    Fair, I guess I was not sure if it was just blocking the port, or doing something to directly block the protocols as well.
    - charcircuit 3y ago
      The author values having a robust solution since he mentions the DPI resistance near the end of the article. If he was going to mask ssh as https, he might as well do it properly.
- hddqsb 3y ago
  Yes, that's likely to work on many firewalls, but: - it means you can't also serve HTTP on those ports (so you'd need a dedicated IP address for SSH), and - as @charcircuit wrote, it won't resist deep packet inspection. (But if DPI is a problem and you have a spare IP address, you could just use SSH over TLS without needing the HTTP CONNECT stuff and Apache.)
j16sdiz 3y ago
You should try httpssh https://pkg.go.dev/github.com/HimbeerserverDE/httpssh https://pkg.go.dev/github.com/HimbeerserverDE/httpssh > httpssh listens for HTTP(S) and SSH connections on the same port and forwards the traffic to the corresponding service.
- hackernudes 3y ago
  The article mentions sslh which works like httpssh. It also possible to achieve this with haproxy like this: frontend https bind *:443 mode tcp tcp-request inspect-delay 2s use_backend https_loopback if { req.ssl_ver gt 0 } default_backend ssh Another option is to use TLS SNI (Server Name Indication) like a virtualhost-style ssh server (https://www.haproxy.com/blog/route-ssh-connections-with-haproxy https://www.haproxy.com/blog/route-ssh-connections-with-hapr...). You can use the 'openssl' command in your ProxyCommand which is pretty readily available.
hackernudes 3y ago
Nice, for some reason I never thought about the CONNECT method like a reverse proxy instead of a forward proxy. However, CONNECT wasn't good enough for me. I did ssh over websocket to bust through a corp proxy (it inspected https connections with a custom CA). I modified socat to serve my ssh server over websocket through apache. I also used it on the client end with openssh's ProxyCommand. I keep meaning to upload that patch, but there are other options around (websocat, for example).
- duhast2020 3y ago
  Sounds like you accidentally reinvented huproxy
- trallnag 3y ago
  Guess that is why many corporate proxies / firewalls block websocket by default...
Gabrys1 3y ago
This is a really nice idea! Excellent encapsulation with minimal setup. You could slap a SOCKS proxy (via -D) on top of that for even more usability (although, oddly I find that these days all I ever need is DNS, HTTPs and SSH...)
dlenski 3y ago
From the article: > Ubiquitous presence of HTTPS allows you to pass your data through very restrictive middle boxes! This is, in fact, why all — or nearly all — proprietary VPN protocols (so-called "SSL VPNs") implement a mode that initiates a tunnel via HTTPS, at least as a fallback if not as the primary mode of operation: precisely in order to have a mode of operation that works with almost any connection to the global Internet. I'm one of the main developers of https://gitlab.com/openconnect/openconnect https://gitlab.com/openconnect/openconnect, which implements many such protocols, and wrote https://github.com/dlenski/what-vpn https://github.com/dlenski/what-vpn, which sniffs or identifies even more flavors of TLS-based VPN servers.
- deleted 3y ago
  [deleted]
- smolder 3y ago
  It is tragic that we can't seem to use ports for their intended purposes because of crude attempts to limit the utility of a connection.
  - iforgotpassword 3y ago
    Exactly this. Continued ossification of the stack. We've practically given up on introducing new protocols on top of IP decades ago because parts of the internet drop everything that's not UDP or TCP. And because NAT. Now we're at the next step where we design protocols not on top of UDP/TCP but on top of HTTPS. You'd think that thanks to TLS this will be the final step but I guess we should never underestimate the idiocy of mankind.
    - judge2020 3y ago
      Thankfully with Encrypted Client Hello (formerly eSNI) we should be pretty future-proofed with middleboxes losing more information on where a HTTPS connection is going. The only thing left is the IP address, which is only a guess and is mostly useless if it's going to a CDN - effectively making all sites unblockable if they use akamai/CF/etc.
teaearlgraycold 3y ago
Why block outbound SSH connections? Inbound I understand. And given how easy it is to tunnel over HTTPS this seems to be targeted an accidental or unsophisticated clients - neither of which seems to be a likely descriptor of an SSH connection.
- quasarj 3y ago
  They just blanket block every port that isn't 80 or 443. I see this everywhere.
  - teaearlgraycold 3y ago
    But why?
    - heinternets 3y ago
      security
- m1keil 3y ago
  This is most likely just a security "best practice" that goes unquestioned. It is pretty much on the same level as blocking ICMP. I remember in the past how I lost couple of hours trying to understand why I can't reach a remote instance via RDP, only to finally figure it was the port blocking on the office firewall. I spent quite a while trying to convince the local sysadmin that this doesn't make any sense. His only explanation was "security" without any actual explanation of what is he securing us from.
  - anilakar 3y ago
    Russian and Chinese ISPs are blocked on out network in the name of "security" as if real attackers would not use AWS or a western VPS provider. It is a pain when you need to download material from your hardware suppliers' web sites.
    - 3y ago
petabyt 3y ago
Reminds me of when I was in high school, I made a port scan script to find unblocked IPs for me to route my server SSH through. I was able to get it working through a port thats supposed to be used for printers. Still have SSH on the same port to this day.
coppsilgold 3y ago
In general, tunneling through HTTP2 turns out to be a great choice. There is an RPC protocol built on top of HTTP2: gRPC[1]. This is because HTTP2 is great at exploiting a TCP connection to transmit and receive multiple data structures concurrently - multiplexing. There may not be a reason to use HTTP3 however, as QUIC already provides multiplexing. I expect that in the future most communications will be over encrypted HTTP2 and QUIC simply because middlebox creators can not resist to discriminate. It may even be necessary to serve some random (perhaps AI generated) HTTP2/HTTP3 content to mitigate active probing[2]. [1] <https://grpc.io https://grpc.io> [2] <https://blog.torproject.org/learning-more-about-gfws-active-probing-system https://blog.torproject.org/learning-more-about-gfws-active-...>
- mgaunard 3y ago
  I never understood the point of layering an RPC protocol on top of HTTP; HTTP is already itself a request/response protocol and can be used for RPC out of the box. Whether it's HTTP 1, 2 or 3, it doesn't really make a difference. The evolutions of that protocol are themselves somewhat dubious, and designed to exploit things you wouldn't need in an RPC setting -- they're really designed for the open Internet, not a local service.
  - znpy 3y ago
    Because http is the new tcp. Nowadays protocols are primarily developed by companies making most of their bucks with http so…
    - mgaunard 3y ago
      Thankfully non-web software companies still exist.
- richardwhiuk 3y ago
  HTTP/2 is still TCP - and thus still suffers TCP head of line blocking. HTTP/3 is over QUIC
- hddqsb 3y ago
lrvick 3y ago
I find simply having openssh listening on port 443 alone bypasses most firewalls in practice.
28304283409234 3y ago
No love for sslh? “ Probes for HTTP, TLS/SSL (including SNI and ALPN), SSH, OpenVPN, tinc, XMPP, SOCKS5, are implemented, and any other protocol that can be tested using a regular expression, can be recognised. A typical use case is to allow serving several services on port 443 (e.g. to connect to SSH from inside a corporate firewall, which almost never block port 443) while still serving HTTPS on that port.” https://www.rutschle.net/tech/sslh/README.html https://www.rutschle.net/tech/sslh/README.html
- kvdveer 3y ago
  The author dedicated the first half of the article to the choice between sslh and full encapsulation. They chose for full encapsulation because: * it's one fewer service to set up * the http server handles the connection, so remote address is correct in the logs * (presumably the hacker spirit favors novel solutions over existing ones)
thomashabets2 3y ago
Nice. My solution involved more code: https://github.com/ThomasHabets/huproxy https://github.com/ThomasHabets/huproxy
debarshri 3y ago
A bit of a shameless plugin here. At Adaptive [1], we are building a data security infrastructure. In one of our products, we do SSH and various other protocols over HTTP3. It allows users to connect to databases, servers, and other resources over an outbound port. Similar to Ngrok and others but can be self-hosted You can access it in a passwordless manner or with temporary credentials, with maker-checker protection. [1] https://adaptive.live/ https://adaptive.live/
- fsckboy 3y ago
  the original shameless plugin was when the wrong guy took over uBlock and sold it out to advertisers. Thankfully, the original author gorhill relaunched the trustworthy uBlock Origin plugin.
  - debarshri 3y ago
    The term "shameless plug" refers to a situation where someone promotes or advertises something, often themselves or their work, in a way that is seen as unabashed or lacking in modesty.
    - scott_w 3y ago
      I suspect they already know, check your original post ;-)
  - debarshri 3y ago
    I get the humour now. It is funny and my bad. It is plug and plugin.
mmzeeman 3y ago
Back in the day, XS4ALL, a Dutch internet provider had exactly this feature. They provided ssh access via port 80. It saved me a couple of time while I was traveling and the only way to get internet access was via hotel WiFi, which blocked everything except port 80. If anybody from XS4ALL is reading this... Thanks!
- pietro72ohboy 3y ago
  XS4ALL was amazing and it’s a genuine shame that KPN corporate decided to dissolve the brand. But I guess, KPN wouldn’t have been comfortable with XS4ALL’s hacker ethos anyways…
- emmelaich 3y ago
  Fellow xs4all user here, it was fantastic, the real spirit of the early internet. Sort of a redo of the pirate radio ethos of the 60s. https://en.wikipedia.org/wiki/Pirate_radio_in_Europe https://en.wikipedia.org/wiki/Pirate_radio_in_Europe
- rahimnathwani 3y ago
  had exactly this feature. They provided ssh access via port 80. OP is describing something different: - different port (443, not 80) - different protocol used on that port (https, not ssh)
  - narag 3y ago
    It seems the same to me: using a port that's open for a commonly used protocol, so http (80) in the 90s, https (443) now. Of course the protocol is different, that's the point!
    - rahimnathwani 3y ago
      It's not the same at all. OP's port 443 is not 'open' in the same sense that GGP's port 80 was 'open'. In the old days, only the port number mattered. Today, DPI means the protocol matters as well.
jinnko 3y ago
I used to use a tool that does exactly this nearly 20 years ago to poke a hole through corporate firewalls, corkscrew[0]. Nice standalone implementation and write up though. 0: https://github.com/bryanpkc/corkscrew https://github.com/bryanpkc/corkscrew
- rahimnathwani 3y ago
  AIUI corkscrew works for a specific use case: 1. you're behind an HTTP proxy, and 2. the HTTP proxy support the CONNECT method Around 20 years ago I did a short contract which had #1 but not #2. Thankfully, there's a tool for this, too. Of course it requires some set up on the server side: https://github.com/larsbrinkhoff/httptunnel https://github.com/larsbrinkhoff/httptunnel
tech101hari 3y ago
This is so useful in India where several cafe hotspots allow only 80 and 443. Currently I use gotty, but I'll give SSH over HTTPS a try.
svilen_dobrev 3y ago
maybe a stupid question: what happens to access to other usual https:// https:// pages on the server? How do i get there if whole https traffic goes to ssh? Or.. just use plain http for those? that is.. can i only route some the.server/go-to-ssh/ endpoint to ssh, and all other stuff stays and is accessible as is?
dspillett 3y ago
> The hospital has free Wi-fi access. The caveat is that hospital blocks most connection types. … But SSH (TCP port 22 or most other custom ports) is blocked completely Last time I was going to be somewhere when SSH as blocked but HTTPS was very open, and I couldn't rely on phone network connectivity, I stood up an instance of shellinabox¹ in case I needed to do remote admin while there. This has the disadvantage of not allowing direct SSH access so I couldn't directly run scripts from local, use SFTP, or tunnel other stuff (like rsync) over SSH, but it's big plus was being able to use it from any machine. Security could be a big issue with the shellinabox method. To mitigate this it ran in is own VM and the only thing I allowed it to do was SSH to a specific host to authenticate with a huge password (typed manually or via usb auto-typer on other machines, via keepass on my own), and then from that host I could SSH elsewhere. There was also some security-via-obscurity with the URL it was available on. Tunneling SSH would definitely have been more secure (allowing key based auth from my machines for a start) but I wanted that option to connect from machines (that were very locked down) other than my own. I took it back down as soon as the need had passed as it didn't feel 100% safe, bit it served a purpose. -- [1] https://github.com/shellinabox/shellinabox https://github.com/shellinabox/shellinabox
- lstodd 3y ago
  Why even bother with ssh/shellinabox? In similar circumstances I just did a straight and simple NAT, and that's it.
  - dspillett 3y ago
    NATing what to what? If simply connecting over a certain port was the answer I could have setup SSH on port 433 and been done without even that. Though I'm happy to be told I missed something obvious, in case I have the same need again in future. Also just thinking about the SSH connection forgets the "want it to work on any machine" extra requirement I had. Being able to run an SSH client directly _at all_ was a concern.
NicolaiS 3y ago
Slightly related, but mostly for fun: You can do valid HTTP & SSH on the same port: https://media.ccc.de/v/bornhack2023-56142-sexy-ssh-hacks#t=497 https://media.ccc.de/v/bornhack2023-56142-sexy-ssh-hacks#t=4... (Without detecting which client connects, it works just like the "valid PNG and ZIP polyglot" trick)
- hddqsb 3y ago
  In fact the article mentions a tool for this (sslh), but rejects it because it hides the source IP from the HTTP backend (and other reasons).
jhatemyjob 3y ago
The title perfectly captures the state of the art. How most people think of the relationship between the two protocols. I am glad I know the truth.
teekert 3y ago
I had the same need to tinker from work, who blocked many ports. I used wireguard on port 21 (ftp). Worked well.
oefrha 3y ago
I use Cloudflare Tunnel to SSH into home from the outside over HTTPS. Advantages: - Can open a shell from any device with a browser, no ssh required; - Works even if home network is behind CGNAT. Disadvantages: - A middleman; - Other people can open a shell if my Cloudflare auth is fully compromised (requires compromising a high security email inbox).
- jgalt212 3y ago
  We used Cloudflare as well. I did not think compromised email would affect this as Cloudflare requires 2FA (and the only way around that are backup codes).
  - oefrha 3y ago
    Cloudflare admin account login and Cloudflare Zero Trust app (including SSH access through Cloudflare tunnel) logins are different. IIRC the only login method I could configure for the web shell on my personal account is one-time PIN via email.
doctor_lollipop 3y ago
Personally I use https://github.com/jpillora/chisel https://github.com/jpillora/chisel as a reverse Proxy through nginx, then connect through it using OpenVPN to bypass a similarly restrictive firewall. But this discussion is filled with other, similar hacks, I may have to try some of them.
- veganjay 3y ago
  I learned about chisel in PEN-200 / preparing for the OSCP. Then I learned about, Ligolo-ng [1] which is a game-changer. I highly recommend checking it out. It is most applicable to a penetration test. It uses TLS so I'm not sure it could be used to address the issue mentioned in the article. [1] https://github.com/nicocha30/ligolo-ng https://github.com/nicocha30/ligolo-ng
imetatroll 3y ago
So if I understand this correctly, apache + the proxy mod is doing the heavy lifting here correct? It receives a request to connect on port 22 to the ssh-server and, apparently, it is smart enough to just know that it needs to establish an ssh connection? I ask because I thought that CONNECT would result in tls connections only. Edit: I should just have looked up the wikipedia example https://en.wikipedia.org/wiki/HTTP_tunnel https://en.wikipedia.org/wiki/HTTP_tunnel
- MadnessASAP 3y ago
  I'm fairly certain it just opens a TCP connection on the clients behalf and proxies the clients data over it. No knowledge of SSH required.
  - imetatroll 3y ago
    Yes I think you are correct. Thanks for clarifying.
- narag 3y ago
  Long ago I used stunnel to establish encrypted connections to remotely access my sockets servers. https://www.stunnel.org/ https://www.stunnel.org/ It didn't really matter what the protocol was, the client and server just see each other. IIRC it was also possible to connect a browser with https to a tunneled http server or viceversa.
d3w4s9 3y ago
I guess you need a valid SSL certificate to do this? So it may not work well if you SSH into an IP instead of a domain -- it is not always possible to get an SSL certificate for an IP address ( https://stackoverflow.com/questions/2043617/is-it-possible-to-have-ssl-certificate-for-ip-address-not-domain-name https://stackoverflow.com/questions/2043617/is-it-possible-t... ). It is probably trivial for people here to get a domain and then point it to the IP, but still, this seems a minor limitation.
- jamespwilliams 3y ago
  You could probably use a self-signed cert, then configure socat either to trust that certificate (with the cafile option) or to disable verification (with the verify option)
- georgyo 3y ago
  There is no need for a valid SSL cert, self signed will do. The ProxyCommand just needs to not validate the cert.
kissgyorgy 3y ago
Funny timing, I just did HTTP over SSH the other day: https://gist.github.com/kissgyorgy/9e58881131aeea51ed0a2c8bbffbdba4 https://gist.github.com/kissgyorgy/9e58881131aeea51ed0a2c8bb...
EVa5I7bHFq9mnYK 3y ago
I used Parallels and a browser to remote desktop to my home Windows machine from behind a very restrictive firewall. Not sure if it works for Linux.
cobbaut 3y ago
I just keep a server (3 euro/month) online that listens to SSH on port 443. From there I can connect to anywhere. I assume that a firewall exists that blocks ssh over 443 while allowing HTTPS, but have not encountered that yet.
dijit 3y ago
FWIW I used to use Anyconnect (OpenConnect for the FOSS version) for this exact reason. Anyconnect VPN looks like HTTPS traffic and is very difficult to block, even with DPI. Worth looking into if you need this commonly. :)
somat 3y ago
I prefer the opposite, http over ssh. Only half joking. I would love to have ssh equivalent identity management baked into a browser. I got all excited when first reading about hobo, which is a proposal for public key http auth. only to find out that not only did a server implementation not exist(i could work around this) but no client(browser) implementation exists(sort of, there is a javascript implementation, but that is not what I wanted.
- upon_drumhead 3y ago
  Isn’t passkeys what you are describing?
  - computerfriend 3y ago
    Passkeys are at the application layer.
- manofmanysmiles 3y ago
  What about HTTPS client certificate? https://techcommunity.microsoft.com/t5/iis-support-blog/client-certificate-authentication-part-1 https://techcommunity.microsoft.com/t5/iis-support-blog/clie... I don't know enough about this to know if it meets your need but I've used them to authenticate to servers in college.
  - justinclift 3y ago
    They seem to work ok in Windows and Linux, but modern macOS seems to screw with them. At least the ones generated by OpenSSL. :(
    - jeroenhd 3y ago
      That's disappointing to hear, what does macOS do to screw with them?
      - justinclift 3y ago
catlifeonmars 3y ago
See also AWS SSM sessions. You can tunnel an SSH session over an SSM session using the ProxyCommand interface.
meitham 3y ago
I’m in a similar shoe. Will be spending few days in hospital next week, though going with a different approach: just added tailscale on my devices, my firewall (pfsense), and few other servers I have in case I can’t get pfsense rules to direct the traffic correctly to anything else.
deleted 3y ago
[deleted]
bevenhall 3y ago
The frequency of posts dealing with "new" solutions like this bothers me. Are none of these guys older than 20yrs or is just AI bots? Staggeringly amateurish.
- jofla_net 3y ago
  I went through an exploratory stage 16 years ago of this. It may be that more and more networks are opting for vendors who do not, in fact, offer 'internet' connections, but rather relayed proxies of various sorts, breaking things. After my bout, it kinda faded as I realized SSH-ing over almost any network was really a shoo-in. Then recently post covid i ran into similar blocks myself, so it may be on the rise with fortinet et al.
salzig 3y ago
Thats what was/is what protonet used/s while marking the boxes available via $randomTLd but also making it accessible for support or „special services“. Always nice to see these kind of „missiues“ ;)
cramjabsyn 3y ago
Didn’t need to invent a new wheel here. IP tunneling exists already over HTTPS so simply set that up and route literally any protocol over HTTPS.
deleted 3y ago
[deleted]

426 points by jandeboevrie 3y ago

I have always kept an SSTP VPN server handy after experiencing this exact scenario of hospital WiFi that only allows HTTPS traffic, but this is an interesting alternative

joveian 3y ago

There is often also option 3, put ssh on port 80 and/or 443 on a different host and ProxyJump to the intended destination (and/or use SOCKS to that host to generally get a less filtered internet connection). I use SOCKS and also forward DNS over TLS over the ssh connection via port forwarding. At least several years ago when I first set up my SOCKS proxy and was using wifi quite a bit I never found one that did anything more than check the port, although I have heard they exist and could be more common now (and of course it doesn't matter how common they are if one is in your way).

askiiart 3y ago
Back in my freshman year of high school, I was just starting to get into self-hosting. As it turns out, the school blocked websites, but did absolutely nothing about ports. So of course, I just SSH'd over to my server and carried on as normal. Later, I was working on making an archive of Windows .iso files, and since I had some free time, I was downloading them on my laptop and then uploading them to my server with scp. As it turns out, using dozens of gigabytes, in both upload and download, on a port besides 80 and 443, is enough to finally get your traffic inspected, so around lunchtime IT finally blocked port 22. But you know what they didn't block? Every other port! So I just moved SSH to port 443 in my port forwarding and carried on as normal. A long time later, sometime during sophomore year IIRC, the school's IT noticed me SSH-ing over port 443 and put an end to that. They set up some basic traffic analysis to block SSH on ports 80 and 443. But you know what they didn't block? Every other port! Eventually they just ended up blocking my server at the IP level (the IP of my domain), but of course, but you know what they didnt block? Literally every other IP! I could get around it by just ProxyJump-ing with a VPS, but being an early college high school student, after sophomore year I rarely go to the high school, so it's not really worth the effort. But next time I do go, I'll do it, just to prove I can. If they finally block SSH on all ports, then I can just set up SSH over HTTPS on the VPS, of course. There's still more they can do, of course, but I'll come back after I graduate and see what I can do on their guest wifi. Anyways, thanks, Birdville Independent School District IT team, it's been quite fun, though it really would be nice if you'd unblock my site so that I can provide the services the district won't (computers (VMs) actually useful for tech students).
- jofla_net 3y ago
  It seems like the only way to correctly use the network is to not use it! :/
- swifthesitation 3y ago
  I enjoyed this story. Thank you for sharing.

tombert 3y ago

Dumb question, but couldn't you just tell the OpenSSH server to use port 80 or port 443 or something and just connect like `ssh me@host -p 80`?

charcircuit 3y ago
That just changes the port it uses. It wouldn't change the protocol.
- tombert 3y ago
  Fair, I guess I was not sure if it was just blocking the port, or doing something to directly block the protocols as well.
  - charcircuit 3y ago
    The author values having a robust solution since he mentions the DPI resistance near the end of the article. If he was going to mask ssh as https, he might as well do it properly.
hddqsb 3y ago
Yes, that's likely to work on many firewalls, but: - it means you can't also serve HTTP on those ports (so you'd need a dedicated IP address for SSH), and - as @charcircuit wrote, it won't resist deep packet inspection. (But if DPI is a problem and you have a spare IP address, you could just use SSH over TLS without needing the HTTP CONNECT stuff and Apache.)

j16sdiz 3y ago

You should try httpssh https://pkg.go.dev/github.com/HimbeerserverDE/httpssh https://pkg.go.dev/github.com/HimbeerserverDE/httpssh > httpssh listens for HTTP(S) and SSH connections on the same port and forwards the traffic to the corresponding service.

hackernudes 3y ago
The article mentions sslh which works like httpssh. It also possible to achieve this with haproxy like this: frontend https bind *:443 mode tcp tcp-request inspect-delay 2s use_backend https_loopback if { req.ssl_ver gt 0 } default_backend ssh Another option is to use TLS SNI (Server Name Indication) like a virtualhost-style ssh server (https://www.haproxy.com/blog/route-ssh-connections-with-haproxy https://www.haproxy.com/blog/route-ssh-connections-with-hapr...). You can use the 'openssl' command in your ProxyCommand which is pretty readily available.

hackernudes 3y ago

Nice, for some reason I never thought about the CONNECT method like a reverse proxy instead of a forward proxy. However, CONNECT wasn't good enough for me. I did ssh over websocket to bust through a corp proxy (it inspected https connections with a custom CA). I modified socat to serve my ssh server over websocket through apache. I also used it on the client end with openssh's ProxyCommand. I keep meaning to upload that patch, but there are other options around (websocat, for example).

duhast2020 3y ago
Sounds like you accidentally reinvented huproxy
trallnag 3y ago
Guess that is why many corporate proxies / firewalls block websocket by default...

Gabrys1 3y ago

This is a really nice idea! Excellent encapsulation with minimal setup. You could slap a SOCKS proxy (via -D) on top of that for even more usability (although, oddly I find that these days all I ever need is DNS, HTTPs and SSH...)

dlenski 3y ago

From the article: > Ubiquitous presence of HTTPS allows you to pass your data through very restrictive middle boxes! This is, in fact, why all — or nearly all — proprietary VPN protocols (so-called "SSL VPNs") implement a mode that initiates a tunnel via HTTPS, at least as a fallback if not as the primary mode of operation: precisely in order to have a mode of operation that works with almost any connection to the global Internet. I'm one of the main developers of https://gitlab.com/openconnect/openconnect https://gitlab.com/openconnect/openconnect, which implements many such protocols, and wrote https://github.com/dlenski/what-vpn https://github.com/dlenski/what-vpn, which sniffs or identifies even more flavors of TLS-based VPN servers.

deleted 3y ago
[deleted]
smolder 3y ago
It is tragic that we can't seem to use ports for their intended purposes because of crude attempts to limit the utility of a connection.
- iforgotpassword 3y ago
  Exactly this. Continued ossification of the stack. We've practically given up on introducing new protocols on top of IP decades ago because parts of the internet drop everything that's not UDP or TCP. And because NAT. Now we're at the next step where we design protocols not on top of UDP/TCP but on top of HTTPS. You'd think that thanks to TLS this will be the final step but I guess we should never underestimate the idiocy of mankind.
  - judge2020 3y ago
    Thankfully with Encrypted Client Hello (formerly eSNI) we should be pretty future-proofed with middleboxes losing more information on where a HTTPS connection is going. The only thing left is the IP address, which is only a guess and is mostly useless if it's going to a CDN - effectively making all sites unblockable if they use akamai/CF/etc.

teaearlgraycold 3y ago

Why block outbound SSH connections? Inbound I understand. And given how easy it is to tunnel over HTTPS this seems to be targeted an accidental or unsophisticated clients - neither of which seems to be a likely descriptor of an SSH connection.

quasarj 3y ago
They just blanket block every port that isn't 80 or 443. I see this everywhere.
- teaearlgraycold 3y ago
  But why?
  - heinternets 3y ago
    security
m1keil 3y ago
This is most likely just a security "best practice" that goes unquestioned. It is pretty much on the same level as blocking ICMP. I remember in the past how I lost couple of hours trying to understand why I can't reach a remote instance via RDP, only to finally figure it was the port blocking on the office firewall. I spent quite a while trying to convince the local sysadmin that this doesn't make any sense. His only explanation was "security" without any actual explanation of what is he securing us from.
- anilakar 3y ago
  Russian and Chinese ISPs are blocked on out network in the name of "security" as if real attackers would not use AWS or a western VPS provider. It is a pain when you need to download material from your hardware suppliers' web sites.
  - 3y ago

petabyt 3y ago

Reminds me of when I was in high school, I made a port scan script to find unblocked IPs for me to route my server SSH through. I was able to get it working through a port thats supposed to be used for printers. Still have SSH on the same port to this day.

coppsilgold 3y ago

In general, tunneling through HTTP2 turns out to be a great choice. There is an RPC protocol built on top of HTTP2: gRPC[1]. This is because HTTP2 is great at exploiting a TCP connection to transmit and receive multiple data structures concurrently - multiplexing. There may not be a reason to use HTTP3 however, as QUIC already provides multiplexing. I expect that in the future most communications will be over encrypted HTTP2 and QUIC simply because middlebox creators can not resist to discriminate. It may even be necessary to serve some random (perhaps AI generated) HTTP2/HTTP3 content to mitigate active probing[2]. [1] <https://grpc.io https://grpc.io> [2] <https://blog.torproject.org/learning-more-about-gfws-active-probing-system https://blog.torproject.org/learning-more-about-gfws-active-...>

mgaunard 3y ago
I never understood the point of layering an RPC protocol on top of HTTP; HTTP is already itself a request/response protocol and can be used for RPC out of the box. Whether it's HTTP 1, 2 or 3, it doesn't really make a difference. The evolutions of that protocol are themselves somewhat dubious, and designed to exploit things you wouldn't need in an RPC setting -- they're really designed for the open Internet, not a local service.
- znpy 3y ago
  Because http is the new tcp. Nowadays protocols are primarily developed by companies making most of their bucks with http so…
  - mgaunard 3y ago
    Thankfully non-web software companies still exist.
richardwhiuk 3y ago
HTTP/2 is still TCP - and thus still suffers TCP head of line blocking. HTTP/3 is over QUIC
hddqsb 3y ago

lrvick 3y ago

I find simply having openssh listening on port 443 alone bypasses most firewalls in practice.

28304283409234 3y ago

No love for sslh? “ Probes for HTTP, TLS/SSL (including SNI and ALPN), SSH, OpenVPN, tinc, XMPP, SOCKS5, are implemented, and any other protocol that can be tested using a regular expression, can be recognised. A typical use case is to allow serving several services on port 443 (e.g. to connect to SSH from inside a corporate firewall, which almost never block port 443) while still serving HTTPS on that port.” https://www.rutschle.net/tech/sslh/README.html https://www.rutschle.net/tech/sslh/README.html

kvdveer 3y ago
The author dedicated the first half of the article to the choice between sslh and full encapsulation. They chose for full encapsulation because: * it's one fewer service to set up * the http server handles the connection, so remote address is correct in the logs * (presumably the hacker spirit favors novel solutions over existing ones)

thomashabets2 3y ago

Nice. My solution involved more code: https://github.com/ThomasHabets/huproxy https://github.com/ThomasHabets/huproxy

debarshri 3y ago

A bit of a shameless plugin here. At Adaptive [1], we are building a data security infrastructure. In one of our products, we do SSH and various other protocols over HTTP3. It allows users to connect to databases, servers, and other resources over an outbound port. Similar to Ngrok and others but can be self-hosted You can access it in a passwordless manner or with temporary credentials, with maker-checker protection. [1] https://adaptive.live/ https://adaptive.live/

fsckboy 3y ago
the original shameless plugin was when the wrong guy took over uBlock and sold it out to advertisers. Thankfully, the original author gorhill relaunched the trustworthy uBlock Origin plugin.
- debarshri 3y ago
  The term "shameless plug" refers to a situation where someone promotes or advertises something, often themselves or their work, in a way that is seen as unabashed or lacking in modesty.
  - scott_w 3y ago
    I suspect they already know, check your original post ;-)
- debarshri 3y ago
  I get the humour now. It is funny and my bad. It is plug and plugin.

mmzeeman 3y ago

Back in the day, XS4ALL, a Dutch internet provider had exactly this feature. They provided ssh access via port 80. It saved me a couple of time while I was traveling and the only way to get internet access was via hotel WiFi, which blocked everything except port 80. If anybody from XS4ALL is reading this... Thanks!

pietro72ohboy 3y ago
XS4ALL was amazing and it’s a genuine shame that KPN corporate decided to dissolve the brand. But I guess, KPN wouldn’t have been comfortable with XS4ALL’s hacker ethos anyways…
emmelaich 3y ago
Fellow xs4all user here, it was fantastic, the real spirit of the early internet. Sort of a redo of the pirate radio ethos of the 60s. https://en.wikipedia.org/wiki/Pirate_radio_in_Europe https://en.wikipedia.org/wiki/Pirate_radio_in_Europe
rahimnathwani 3y ago
had exactly this feature. They provided ssh access via port 80. OP is describing something different: - different port (443, not 80) - different protocol used on that port (https, not ssh)
- narag 3y ago
  It seems the same to me: using a port that's open for a commonly used protocol, so http (80) in the 90s, https (443) now. Of course the protocol is different, that's the point!
  - rahimnathwani 3y ago
    It's not the same at all. OP's port 443 is not 'open' in the same sense that GGP's port 80 was 'open'. In the old days, only the port number mattered. Today, DPI means the protocol matters as well.

jinnko 3y ago

I used to use a tool that does exactly this nearly 20 years ago to poke a hole through corporate firewalls, corkscrew[0]. Nice standalone implementation and write up though. 0: https://github.com/bryanpkc/corkscrew https://github.com/bryanpkc/corkscrew

rahimnathwani 3y ago
AIUI corkscrew works for a specific use case: 1. you're behind an HTTP proxy, and 2. the HTTP proxy support the CONNECT method Around 20 years ago I did a short contract which had #1 but not #2. Thankfully, there's a tool for this, too. Of course it requires some set up on the server side: https://github.com/larsbrinkhoff/httptunnel https://github.com/larsbrinkhoff/httptunnel

tech101hari 3y ago

This is so useful in India where several cafe hotspots allow only 80 and 443. Currently I use gotty, but I'll give SSH over HTTPS a try.

svilen_dobrev 3y ago

maybe a stupid question: what happens to access to other usual https:// https:// pages on the server? How do i get there if whole https traffic goes to ssh? Or.. just use plain http for those? that is.. can i only route some the.server/go-to-ssh/ endpoint to ssh, and all other stuff stays and is accessible as is?

dspillett 3y ago

> The hospital has free Wi-fi access. The caveat is that hospital blocks most connection types. … But SSH (TCP port 22 or most other custom ports) is blocked completely Last time I was going to be somewhere when SSH as blocked but HTTPS was very open, and I couldn't rely on phone network connectivity, I stood up an instance of shellinabox¹ in case I needed to do remote admin while there. This has the disadvantage of not allowing direct SSH access so I couldn't directly run scripts from local, use SFTP, or tunnel other stuff (like rsync) over SSH, but it's big plus was being able to use it from any machine. Security could be a big issue with the shellinabox method. To mitigate this it ran in is own VM and the only thing I allowed it to do was SSH to a specific host to authenticate with a huge password (typed manually or via usb auto-typer on other machines, via keepass on my own), and then from that host I could SSH elsewhere. There was also some security-via-obscurity with the URL it was available on. Tunneling SSH would definitely have been more secure (allowing key based auth from my machines for a start) but I wanted that option to connect from machines (that were very locked down) other than my own. I took it back down as soon as the need had passed as it didn't feel 100% safe, bit it served a purpose. -- [1] https://github.com/shellinabox/shellinabox https://github.com/shellinabox/shellinabox

lstodd 3y ago
Why even bother with ssh/shellinabox? In similar circumstances I just did a straight and simple NAT, and that's it.
- dspillett 3y ago
  NATing what to what? If simply connecting over a certain port was the answer I could have setup SSH on port 433 and been done without even that. Though I'm happy to be told I missed something obvious, in case I have the same need again in future. Also just thinking about the SSH connection forgets the "want it to work on any machine" extra requirement I had. Being able to run an SSH client directly _at all_ was a concern.

NicolaiS 3y ago

Slightly related, but mostly for fun: You can do valid HTTP & SSH on the same port: https://media.ccc.de/v/bornhack2023-56142-sexy-ssh-hacks#t=497 https://media.ccc.de/v/bornhack2023-56142-sexy-ssh-hacks#t=4... (Without detecting which client connects, it works just like the "valid PNG and ZIP polyglot" trick)

hddqsb 3y ago
In fact the article mentions a tool for this (sslh), but rejects it because it hides the source IP from the HTTP backend (and other reasons).

jhatemyjob 3y ago

The title perfectly captures the state of the art. How most people think of the relationship between the two protocols. I am glad I know the truth.

teekert 3y ago

I had the same need to tinker from work, who blocked many ports. I used wireguard on port 21 (ftp). Worked well.

oefrha 3y ago

I use Cloudflare Tunnel to SSH into home from the outside over HTTPS. Advantages: - Can open a shell from any device with a browser, no ssh required; - Works even if home network is behind CGNAT. Disadvantages: - A middleman; - Other people can open a shell if my Cloudflare auth is fully compromised (requires compromising a high security email inbox).

jgalt212 3y ago
We used Cloudflare as well. I did not think compromised email would affect this as Cloudflare requires 2FA (and the only way around that are backup codes).
- oefrha 3y ago
  Cloudflare admin account login and Cloudflare Zero Trust app (including SSH access through Cloudflare tunnel) logins are different. IIRC the only login method I could configure for the web shell on my personal account is one-time PIN via email.

doctor_lollipop 3y ago

Personally I use https://github.com/jpillora/chisel https://github.com/jpillora/chisel as a reverse Proxy through nginx, then connect through it using OpenVPN to bypass a similarly restrictive firewall. But this discussion is filled with other, similar hacks, I may have to try some of them.

veganjay 3y ago
I learned about chisel in PEN-200 / preparing for the OSCP. Then I learned about, Ligolo-ng [1] which is a game-changer. I highly recommend checking it out. It is most applicable to a penetration test. It uses TLS so I'm not sure it could be used to address the issue mentioned in the article. [1] https://github.com/nicocha30/ligolo-ng https://github.com/nicocha30/ligolo-ng

imetatroll 3y ago

So if I understand this correctly, apache + the proxy mod is doing the heavy lifting here correct? It receives a request to connect on port 22 to the ssh-server and, apparently, it is smart enough to just know that it needs to establish an ssh connection? I ask because I thought that CONNECT would result in tls connections only. Edit: I should just have looked up the wikipedia example https://en.wikipedia.org/wiki/HTTP_tunnel https://en.wikipedia.org/wiki/HTTP_tunnel

MadnessASAP 3y ago
I'm fairly certain it just opens a TCP connection on the clients behalf and proxies the clients data over it. No knowledge of SSH required.
- imetatroll 3y ago
  Yes I think you are correct. Thanks for clarifying.
narag 3y ago
Long ago I used stunnel to establish encrypted connections to remotely access my sockets servers. https://www.stunnel.org/ https://www.stunnel.org/ It didn't really matter what the protocol was, the client and server just see each other. IIRC it was also possible to connect a browser with https to a tunneled http server or viceversa.

d3w4s9 3y ago

I guess you need a valid SSL certificate to do this? So it may not work well if you SSH into an IP instead of a domain -- it is not always possible to get an SSL certificate for an IP address ( https://stackoverflow.com/questions/2043617/is-it-possible-to-have-ssl-certificate-for-ip-address-not-domain-name https://stackoverflow.com/questions/2043617/is-it-possible-t... ). It is probably trivial for people here to get a domain and then point it to the IP, but still, this seems a minor limitation.

jamespwilliams 3y ago
You could probably use a self-signed cert, then configure socat either to trust that certificate (with the cafile option) or to disable verification (with the verify option)
georgyo 3y ago
There is no need for a valid SSL cert, self signed will do. The ProxyCommand just needs to not validate the cert.

kissgyorgy 3y ago

Funny timing, I just did HTTP over SSH the other day: https://gist.github.com/kissgyorgy/9e58881131aeea51ed0a2c8bbffbdba4 https://gist.github.com/kissgyorgy/9e58881131aeea51ed0a2c8bb...

EVa5I7bHFq9mnYK 3y ago

I used Parallels and a browser to remote desktop to my home Windows machine from behind a very restrictive firewall. Not sure if it works for Linux.

cobbaut 3y ago

I just keep a server (3 euro/month) online that listens to SSH on port 443. From there I can connect to anywhere. I assume that a firewall exists that blocks ssh over 443 while allowing HTTPS, but have not encountered that yet.

dijit 3y ago

FWIW I used to use Anyconnect (OpenConnect for the FOSS version) for this exact reason. Anyconnect VPN looks like HTTPS traffic and is very difficult to block, even with DPI. Worth looking into if you need this commonly. :)

somat 3y ago

I prefer the opposite, http over ssh. Only half joking. I would love to have ssh equivalent identity management baked into a browser. I got all excited when first reading about hobo, which is a proposal for public key http auth. only to find out that not only did a server implementation not exist(i could work around this) but no client(browser) implementation exists(sort of, there is a javascript implementation, but that is not what I wanted.

upon_drumhead 3y ago
Isn’t passkeys what you are describing?
- computerfriend 3y ago
  Passkeys are at the application layer.
manofmanysmiles 3y ago
What about HTTPS client certificate? https://techcommunity.microsoft.com/t5/iis-support-blog/client-certificate-authentication-part-1 https://techcommunity.microsoft.com/t5/iis-support-blog/clie... I don't know enough about this to know if it meets your need but I've used them to authenticate to servers in college.
- justinclift 3y ago
  They seem to work ok in Windows and Linux, but modern macOS seems to screw with them. At least the ones generated by OpenSSL. :(
  - jeroenhd 3y ago
    That's disappointing to hear, what does macOS do to screw with them?
    - justinclift 3y ago

catlifeonmars 3y ago

See also AWS SSM sessions. You can tunnel an SSH session over an SSM session using the ProxyCommand interface.

meitham 3y ago

I’m in a similar shoe. Will be spending few days in hospital next week, though going with a different approach: just added tailscale on my devices, my firewall (pfsense), and few other servers I have in case I can’t get pfsense rules to direct the traffic correctly to anything else.

deleted 3y ago

[deleted]

bevenhall 3y ago

The frequency of posts dealing with "new" solutions like this bothers me. Are none of these guys older than 20yrs or is just AI bots? Staggeringly amateurish.

jofla_net 3y ago
I went through an exploratory stage 16 years ago of this. It may be that more and more networks are opting for vendors who do not, in fact, offer 'internet' connections, but rather relayed proxies of various sorts, breaking things. After my bout, it kinda faded as I realized SSH-ing over almost any network was really a shoo-in. Then recently post covid i ran into similar blocks myself, so it may be on the rise with fortinet et al.

salzig 3y ago

Thats what was/is what protonet used/s while marking the boxes available via $randomTLd but also making it accessible for support or „special services“. Always nice to see these kind of „missiues“ ;)

cramjabsyn 3y ago

Didn’t need to invent a new wheel here. IP tunneling exists already over HTTPS so simply set that up and route literally any protocol over HTTPS.

deleted 3y ago

[deleted]