"issue" - https?

[y0d4a]

can you add sslstrip in this?

[brannondorsey]

Mitmproxy has an SSLstrip example. I haven't tried it but it certainty seems like it might work. You'd need to be sure to apply new proxy rules to forward all traffic on port 443 to 1337. Basically duplicate this and change 80 to 443. Then, inside the container, kill the current mitmdump process with pkill mitmdump and start a new one that uses the SSLstrip example:

mitmdump -T --host -p 1337 -s path/to/sslstrip.py -w sslstrip.cap 

To view traffic interactively, replace mitmdump with mitmproxy.

[brannondorsey]

Ah, I think I miss-read your question. Was that a feature request? If so yes I'm interested in doing that. I've actually been working on a new "attack mode" that spawns a convincing xfinity captive portal and prompts the user to "download this certificate to securely get online." That certificate is of course the mitmproxy cert which would allow you to actually intercept all https traffic that isn't using certificate pinning. Hoping to add that soon, and I'll consider also adding ssl strip when I do.

[samatt]

I remember the question I had now. Your entrypoint.sh script currently only forwards traffic on port 80 in the iptables. Wondering if there is any reason you didn't do 443 with the -I flag set in mitmproxy (to ignore cert pinning cases). This should enable SNI lookups on https traffic without worrying about breaking traffic that is protected by cert pinning. I am planning to try this out in the upcoming week but wanted to post here now in case I am not considering something that I should be.

[brannondorsey]

@samatt, great question! This tool is intended to be used primarily as a transparent proxy tool, where the target is made completely unaware of its use against them. If I enabled forwarding of port 443, and the target machine didn't have the mitmproxy cert installed on the machine (which would no doubt be the case if the tool were used in the wild), then any modern browser would through a big scary "You are being MITM'd" message for any HTTPS site. For my personal work, targeting my own devices, I actually do add an iptables entry to forward traffic on 443 because I have access to my devices in order to install the mitmproxy cert. But I didn't want that to be the default behavior for mitm-router in general, because I wanted it be as transparent to the victim's devices as possible out-of-the-box. Make sense (or am I overlooking something)?

I'm actually hoping to add a feature to this repo at some point in the next coming weeks that provides a captive portal to a counterfeit XFINITYWIFI login page that prompts a user to download and install the mitmproxy certificate on their device. Replacing the the user/password form with a "Download the secure Xfinity certificate in order to browse the web safely" message. More on that soon 😸...

[username1222]

"soon"

[Kurdz2]

Ah, I think I miss-read your question. Was that a feature request? If so yes I'm interested in doing that. I've actually been working on a new "attack mode" that spawns a convincing xfinity captive portal and prompts the user to "download this certificate to securely get online." That certificate is of course the mitmproxy cert which would allow you to actually intercept all https traffic that isn't using certificate pinning. Hoping to add that soon, and I'll consider also adding ssl strip when I do.

damn so did you do this, or