-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
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.
Can you provide details on this? |
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. |
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.
The text was updated successfully, but these errors were encountered: