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

Way To Control Our Own HTTPS? #265

Open
LWFlouisa opened this issue May 26, 2024 · 2 comments
Open

Way To Control Our Own HTTPS? #265

LWFlouisa opened this issue May 26, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@LWFlouisa
Copy link

LWFlouisa commented May 26, 2024

Is your feature request related to a problem? Please describe.
It seems like there needs to be a better way to store HTTPS domain than how its currently done, as several people have complained about exploit attempts to try to take down their websites.

Describe the solution you'd like
Either the domains that are created are stored differently, or alternatively a way to secure HTTPS in a more secure format.

Describe alternatives you've considered
I didn't use to have this problem with other tunnel providers like ngrok or other service, this recently started happening after the Jia Tan situations, with people either suspecting China or Russia's involvement in the CVE stuff.

Additional context
Nothing more to add, except having to restart the tunnel extremely frequently is tempting me to switch providers. Also in my analytics I'm getting a lot of traffic from China and Yemen.

@LWFlouisa LWFlouisa added the enhancement New feature or request label May 26, 2024
@0x7f
Copy link
Contributor

0x7f commented May 27, 2024

Hey @LWFlouisa thanks for your enhancement report.

In the past, we had quite a few cases where people were hosting malicious content via loophole. We are informed by our provider about these issues and have to take down the according tunnels then. Our provider is usually informed by companies like netcraft.com about the abuse cases. It is possible that they monitor loophole tunnels for malicious content which might look like exploit attempts. I reached out to Netcraft to get more information.

And at the same time, other (maybe not-so-nice) players can monitor the tunnels and check for exploitable services running behind a loophole tunnel. We can not really protect against that. Every user can do so by protecting their service using basic auth, i.e. username + password (https://loophole.cloud/docs/commands/http#options). We could make basic auth the default and only expose unprotected endpoints when a flag is provided. This makes it more explicit and users would be more aware of it.

Regarding SSL: we rely on Let's Encrypt for SSL certificates. Their infrastructure is public (e.g. via cert.sh. We would have to run our own certificate infrastructure to hide hostnames. Unfortunately, we don't have capacity to build such infrastructure.

Nothing more to add, except having to restart the tunnel extremely frequently is tempting me to switch providers. Also in my analytics I'm getting a lot of traffic from China and Yemen.

Can you provide details on this?

@LWFlouisa
Copy link
Author

LWFlouisa commented Jul 15, 2024

Well to be honest if an author of fantasy and science fiction ( covered by the first amendment in the US ) I'm not sure why that sort of thing would be considered malicious. Unless you mean cases long before the last few months.

Maybe I reach out to fire.org maybe they can resolve the issue?

And yes I'm serious here, it's the same content as on my Github site. i don't write that kind of "exploitation" software, but more than happy to take that up with either Fire and Eu Commition.

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

No branches or pull requests

2 participants