I'm trying to capture TCP requests through Burp Suite with this hacky method.

Basically it listens for user selected protocol requests (TCP/UDP) and then forwards them to Burp Suite (or any other tool, if you want to) just like they're HTTP requests. All this by setting a proxy, and Burp Suite will listen to that proxy IP/Port.

However, what I need to do is listening to a website which sends TCP packets, so I should see HTTP/HTTPS requests too. This is what I tried:

sudo python mitm_relay.py -l -p -r tcp:80:example.com:80

where listens to any local interface, proxy listener has been set to and example.com hostname will be converted to his IP address I will send TCP packets to (port set to 80). However, I've set my default Firefox proxy to and when I navigate to example.com I can't see any packet being sniffed under my terminal.

Also this is not an HTTP request, so I've generated my server.pem and server.key just exactly it's been described here:

~/mitm_relay/ $ ls | grep -iE 'ca|ser'

(those are all generated files through those commands).

  1. How can I intercept TCP requests to example.com on port 80?
  2. How can I intercept any domain TCP request on port 80?
  3. What's an example command of intercepting SSL data (like HTTPS) through that script with those generated certificate files?
  4. Is setting Burp to listen to proxy enough for applying the 3 precedent questions?

1 Answer 1


I've set my default Firefox proxy to

You shouldn't do that, the -p argument is there to specify where the Burp proxy is running.

when I navigate to example.com

It doesn't matter where in particular you navigate (though google.com probably wouldn't work because of strict transport security). All requests targeting the port 80/tcp would be intercepted with the script and routed to example.com through Burp proxy.

Note that you may be running something on your port 80 already. I suggest changing the port number, e.g. to tcp:81:example.com:80, and try navigating to to see if it works this way. If the port 81 works and port 80 doesn't, try using ss or netstat to figure out which program is taking over the port 80.

Also this is not an HTTPS request, so I've generated my server.pem and server.key

You don't need them for HTTP requests.

How can I intercept any domain TCP request on port 80?

I don't think this tool is generally well suitable for this task.

You can do it only by setting up a real proxy (like Squid) somewhere on your machine. The -l argument controls what resource do you intercept. The -r argument only controls:

  • The port
  • Where do you forward traffic.

In order for your requests to be handled by the target domain you need a proxy under the -r argument.

What's an example command of intercepting SSL data (like HTTPS) through that script with those generated certificate files?

sudo python mitm_relay.py -l -p -r tcp:443:example.com:443 -c server.pem -k server.key

Note that your browser would display a warning that the connection is untrusted, and google.com inevitably wouldn't work in Chrome. Firefox would be okay as of 12 April, 2020 — though this particular part of the answer probably won't age well.

  • Okay, now I can see. Is it really necessary to visit in order to get it intercept those requests? I'm asking that because I don't really need it to intercept HTTP requests to under terminal. Regarding those SSL certificates, sorry it was a typo. I had to write it was not an HTTP request. Also, how would it work through Google domain?
    – Leon
    Apr 12, 2020 at 17:46
  • Edited my answer to clarify.
    – ximaera
    Apr 12, 2020 at 17:58
  • thank you, I've understood everything. However, I'm intercepting through WireShark the packets I need to modify through Burp if they get repeated under my browser session, and I've seen that source IP address is set to website IP address and destination is set to my private IP address (, in my case). When I run that exact command, I think I'm seeing packets I'm sending to source IP address. Am I right? What if I want to check what that IP address is sending to me since we already have talked about the viceversa?
    – Leon
    Apr 12, 2020 at 18:09
  • 1
    Because mitm_proxy is not a sniffer. It doesn't capture packets as they go. It only streams data extracted from packets. See: github.com/jrmdev/mitm_relay/blob/master/mitm_relay.py#L285
    – ximaera
    Apr 14, 2020 at 4:07
  • 1
    Thanks for clearing my head, I'm accepting your answer. I will make another question in further cases I won't be able to implement it the way that script made for.
    – Leon
    Apr 14, 2020 at 4:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .