Replies: 3 comments
-
|
So yesterday i just shipped MITM :) But the latest release does not fully work on OSX (we don't have beta channel, we need one). If you're on linux,
And you'll have TLS interception for HTTP + reconstruction of LLM conversation (for anthropic /v1/response only for now) As for the dns, i didn't tried an app with DoH/DoT resolution, and so at the moment i think it would just turn some IP (and if they rotate, you would need to accept them all, which is a shame). This part need to be improved, and if there is TLS negociation, i could, if i don't have the DNS resolution for that connection, use the domain OR the host in the HTTP request if there is. I think this should be discussion, not ticket, but happy to answer any questions :) |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks! Right, maybe you should enable the discussion tab in that case so you can move the issue to a discussion. The issue with DoH/DoT is not a problem if you have TLS MITM, since you can still decode the DNS A/CNAME answers. Without MITM it's not possible to solve, IMHO. Also, but I guess an agent doesn't do that, any kind of VPN/Wireguard or whatever non-TLS connection will go off. But since Greyproxy is deny by default, I think it's safe in that case, you'd never allow a random UDP or TCP connection containing random bytes as payload to a direct IP somewhere on the internet, right? |
Beta Was this translation helpful? Give feedback.
-
|
VPN/Wireguard won't pass the rules of the sandbox (unsure if i fully understood this part). So yes no random UDP/TCP can get out by rules. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
My goal is to be able to capture the content of the request, not only the metadata (source & dest IP:port, DNS resolution).
If I understand correctly, this happens at IP level, so it should be possible to intercept TLS handshake and provide a MITM TLS proxy in between.
When TLS is detected, the MITM would capture the TLS key negotiation, swap with its own CA's provided key negotation, then decrypt and encrypt the communication on each side. There are go modules (like mitm-go) doing this, although I don't know if it would apply here.
This would allow a finer granularity to the agent's allow/deny rules (like allowing GET from github.com/some_repo but not POST or deny GET to github.com/* except for repo X and so on).
Also, what prevent an agent to start using DoH or DoT to escape the proxying rules currently? I guess the tool is tracking the
getaddrinfocalls (and /or DNS query) per connection and report those to figure the domain name it's displaying. But as soon as the agent uses TLS for DNS, you can't do that, right?Imagine the agent is querying
legitimatewebsite.com, that you'll allow.Then it can query
evildomain.comvia DoH or DoT, that'll, in turn, answer with some CDN IP (that's hosting bothlegitimatewebsite.comandevildomain.com) and you'll list it aslegitimatewebsite.com, right?Beta Was this translation helpful? Give feedback.
All reactions