Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature missing: #3

Open
Zibri opened this issue Jul 17, 2021 · 3 comments
Open

feature missing: #3

Zibri opened this issue Jul 17, 2021 · 3 comments

Comments

@Zibri
Copy link

Zibri commented Jul 17, 2021

On localhost.run (a similar service) if I do ssh -R 80:localhost:LOCALPORT, I can reach the same port on https://xxxxx.localhost.run

It would be nice to have this feature since a lot of local services running on localhost use http and not https.

@fasmide
Copy link
Owner

fasmide commented Jul 19, 2021

Hi @Zibri

Thanks for your interest!

I completely agree that remotemoe should be able to rewrite HTTPS to HTTP (At least, that's the feature I think you are asking for). It is annoying to provide real or self-signed certificates to it - and it doesn't even make sense to use HTTPS inside the ssh tunnel...

This is definitely on the list - let's leave this issue open and I will have some more incentive to make it happen :)

btw - I had a go at implementing something like this in the configurable-http-proxy branch but decided against the implementation :)

@fasmide
Copy link
Owner

fasmide commented Nov 3, 2021

So one of the reasons this hasn't happened yet is my first two attempts to fix this ended up way too complex, and very user-unfriendly, kind of like Nginx rewrites (which you may argue are simple, but primarily for people used to work with webservers - my goal is to make it easier, and also less prone to user errors)

At the moment, I'm thinking of 3 solutions:

Implement rewriting
(Nginx/apache style) The user specifies URLs and rewrites them to other URLs (without HTTP) and possibly all other kinds of rewrites. This is kind-of-sort-a implemented in configurable-http-proxy.
I think its too prone to user errors, but it is the most powerful solution

Simple TLS-terminate-flag
Make the setting a simple boolean. When users set this boolean, remotemoe should:

  • Ensure all HTTP requests are redirected to HTTPS
  • When accepting HTTPS traffic, send HTTP traffic upstream

It shouldn't be too error-prone, less powerful but will properly account for everyone's needs

Drop HTTP support entirely
Just don't accept HTTP traffic. This way, there is nothing to configure, and no user-configurable errors should be able to happen
remotemoe should then:

  • Always redirect HTTP requests to HTTPS
  • Always use HTTP for upstream, maybe fall back to unverified HTTPS if HTTP is unavailable for some reason

It's 2021 right? - there's no place for HTTP anymore

@stokito
Copy link

stokito commented Jun 17, 2023

Is the HTTPS tunneling working?
I tried from my router but got 502 timeout error:

# ssh -R 443:192.168.1.1:443 remote.moe
https (443)
https://tzpxe25d3gv4v2wxvjgnv7f35w2ehkogerklztntlffgyhub6zra.remote.moe/

I can open the router's admin panel https://192.168.1.1/ but can't do same with the domain.

I hope that the feature work similarly to the locahost.run:

  • when you establish an http tunnel on local 80 port then you anyway get the https redirection. The service makes TLS termination and pass the raw http to your device over secure SSH.
  • If you establish a tunnel on local 443 port then it assumes that you taking care of the TLS certs yourself and makes TLS pass through and doesn't decode TLS but forwards as is. It determines a domain name by SNI.
    https://localhost.run/docs/tls-passthru-tunnels

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants