Hacker News Reader

Comment by Matt3o12_ | Hacker News Reader

> debugProxy is a HTTP/S hosted proxy server that lets you interact with the traffic passing through it, using a web based dashboard.

So, when I use your proxy you can see and store my http and https traffic (assuming I install the certificate in my device). Furthermore, all the traffic from the my pc to your proxy is also transmitted unencrypted so everyone who sits between my device and your proxy can see my traffic as well.

While this interface looks really cool and it is probably feature rich, I will pass using it because of those privacy concerns. If anyone is interested in a local http(s) proxy, check out mitmproxy[0] which is open source, runs locally and is easy to install (I’m not affiliated with them, i use use mitmproxy occasionally when Reverse Engineering am API).

[0]: https://mitmproxy.org

View on HN

> So, when I use your proxy you can see and store my http and https traffic (assuming I install the certificate in my device).

Yes. Requests more than 20 minutes old are permanently deleted.

> Furthermore, all the traffic from the my pc to your proxy is also transmitted unencrypted so everyone who sits between my device and your proxy can see my traffic as well.

No, if you make HTTPS requests they are tunneled over TLS.

> While this interface looks really cool and it is probably feature rich,

Thanks. It isn't feature rich though, it's quite minimal.

> If anyone is interested in a local http(a) proxy, check out mitmproxy[0] which is open source, runs locally and is easy to install (I’m not affiliated with them, i use use mitmproxy occasionally when Reverse Engineering am API).

mitmproxy is indeed great, in fact, this service is build on mitmproxy instances :)

> mitmproxy is indeed great, in fact, this service is build on mitmproxy instances :)

I can appreciate this. Pre-configured / zero config open source software as a service is a useful thing. Not everyone wants to install, configure, and deal with command line tools.

Are there tradeoffs? Sure. Would I personally make those tradeoffs? No. But I am sure some people will.

This is my thoughts too. I wouldn't think it is very useful to most mitmproxy/fiddler/charles power users.

But not having to install something, find your IP address, open your firewall etc, allows some users who don't want to do all this to start using a debugging proxy without having to. I'm not sure how many of these users exist though, we will see!

>So, when I use your proxy you can see and store my http and https traffic (assuming I install the certificate in my device)

Not just see and store, but obviously also tamper with if you want to be thorough in a risk statement.

For years I've done presentations and whatnot to top notch web developers where I've invited them to connect to my proxy in order to demonstrate security flaws - rarely asking them to install my root CA. No matter how many warnings and disclaimers I provide, I always see sensitive traffic through my proxy because someone always connects, despite my advisement against it, with the machine they use for work as opposed to a test VM. Further, weeks after a presentation, I'll still have people connecting through my proxy because they forgot to clear out the settings. Be very, very, very cautious about using this service and do so on a machine that's not configured with email or anything else you care about or will be in the future. Even if you don't install the root CA, there are enough serious flaws in enough non-browser clients (email, chat, and whatnot) as well as sites we tend to use frequently that you should consider that even proxy exposure of HTTP traffic could be a security issue.

This is a good comment and touches a lot of concerns I have with the service.

On debugProxy, username and password "sessions" are disabled after 20 minutes of inactivity. This was implemented, in part, to combat the issue of people forgetting they were still connected to the proxy.

Also, I don't want to, nor do I have a enough disk space to store things for long. So body data over 20 minutes old is periodically permanently removed. Header data lasts a bit longer, but is also periodically permanently removed.

This will not prevent users sending private credentials over the proxy, but it's hard to prevent that as you say, so hopefully this mitigates the problem a bit.

Of course you still have to trust the service, for some people that will be totally unacceptable, which is fine.

Also consider Charles, which is pretty nifty https://www.charlesproxy.com

Don't forget about Surge: https://nssurge.com

We built a similar proxy at https://wrapapi.com/proxy to allow users to record and replay network requests when turning webpages into an API. I think it's possible to have an end-to-end secure and never-written-to-disk pipeline, provided you trust the provider is doing what they're saying.

The secure pipeline we ended up using involves:

1. Having a HTTPS endpoint for the proxy

2. Forwarding the captures to you immediately via listening WebSocket instances

Note that because the server upon receiving a request can immediately push it to WebSockets instead of relying on polling, no storage is needed

WrapAPI looks neat. Thanks for posting the link, I couldn't find any similar services when we started building debugProxy, although I assumed some must exist.

Reply on news.ycombinator.com