jrmdev / mitm_relay

Hackish way to intercept and modify non-HTTP protocols through Burp & others.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

SSL and TLS issues

zur250 opened this issue · comments

Hi There,
i am tring to use the following flag with mitm_relay script :
-c , --cert
Certificate file to use for SSL/TLS interception
-k , --key
Private key file to use for SSL/TLS interception
i did the whole guide on creating the relevant certificate and key.
I can see everything encrypted within burp suite.
Any ideas?

Hello,

It sounds like mitm_relay is unable to capture the SSL/TLS handshake and therefore unable to break the SSL layer. What sort of protocol are you trying to intercept? Are you certain the encryption is really SSL/TLS?

i am tring to use it with a normal HTTPS site at the moment. but still not working

python mitm_relay.py -l 172.16.1.49 -p 127.0.0.1:8080 -r tcp:443:192.30.253.112:443 -c ../server.pem -k ../server.key

this is the command i am using, where -c and -k are exactly as you explain in the configuration guidew

I tried your command with the target IP you provided, It works except that the server is returning a status code 400. It is likely that you need to configure Burp to rewrite the Host header correctly, as I assume you are connecting to https://localhost after you run the script.

i was able to solve it somehow.
now i am struggling with new issue.
i am not able to create an iptables rule to get packets in the internal network.
for example:
my destination is 192.168.29.29
my thick client is in 192.168.29.2
the mitm application is in the same machine as the thich client. i cant create a rule to solve it at the moment. any ideas?

zur250, do you know what you changed in your configuration? I'm currently experiencing the same issue. I've tried following the setup a few times but I'm still seeing encrypted traffic within Burp.

My target host is using HTTPS so nothing out of the ordinary there but they're using server-side events which makes standard proxying with Burp not possible from what I've experienced so far. With mitm_relay I'm seeing responses at a frequency I'm expecting.