Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Would it be possible to MITM for TLS request with its own certificate? #16

X-Ryl669 started this conversation in General
Discussion options

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 getaddrinfo calls (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.com via DoH or DoT, that'll, in turn, answer with some CDN IP (that's hosting both legitimatewebsite.com and evildomain.com) and you'll list it as legitimatewebsite.com, right?

You must be logged in to vote

Replies: 3 comments

Comment options

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, greywall setup will download and install latest greyproxy. You will be able to:

  1. greyproxy cert generate
  2. greyproxy cert install
  3. greyproxy service restart

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 :)

You must be logged in to vote
0 replies
Comment options

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?

You must be logged in to vote
0 replies
Comment options

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.

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants
Converted from issue

This discussion was converted from issue #15 on March 19, 2026 13:57.

AltStyle によって変換されたページ (->オリジナル) /