search

loophole / cli

Loophole. Instant hosting, right from your local machine. CLI.
https://loophole.cloud
MIT License
166 stars 17 forks source link

Way To Control Our Own HTTPS? #265

Open LWFlouisa opened 4 months ago

LWFlouisa commented 4 months ago

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.

0x7f commented 4 months ago

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 commented 3 months ago

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.