aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat
-rw-r--r--README.mkd28
-rw-r--r--doc-src/howmitmproxy.html139
-rw-r--r--doc-src/transparent.html12
-rw-r--r--doc-src/transparent/osx.html13
-rw-r--r--examples/redirect_requests.py19
-rw-r--r--libmproxy/app.py7
-rw-r--r--libmproxy/cmdline.py9
-rw-r--r--libmproxy/console/contentview.py39
-rw-r--r--libmproxy/console/flowview.py10
-rw-r--r--libmproxy/console/help.py6
-rw-r--r--libmproxy/flow.py12
-rw-r--r--libmproxy/proxy.py24
-rw-r--r--libmproxy/utils.py2
-rw-r--r--test/data/protobuf012
-rw-r--r--test/test_console_contentview.py12
-rw-r--r--test/test_flow.py2
-rw-r--r--test/test_server.py12
-rw-r--r--test/tservers.py15
18 files changed, 217 insertions, 146 deletions
diff --git a/README.mkd b/README.mkd
index a763fcac..dcb67811 100644
--- a/README.mkd
+++ b/README.mkd
@@ -5,8 +5,9 @@ __mitmdump__ is the command-line version of mitmproxy. Think tcpdump for HTTP.
__libmproxy__ is the library that mitmproxy and mitmdump are built on.
-Complete documentation and a set of practical tutorials is included in the
-distribution package, and is also available at
+Documentation, tutorials and distribution packages can be found on the
+mitmproxy.org website:
+
[mitmproxy.org](http://mitmproxy.org).
@@ -23,28 +24,6 @@ Features
- SSL certificates for interception are generated on the fly.
- And much, much more.
-Download
---------
-
-Releases and documentation can be found on the mitmproxy website:
-
-[mitmproxy.org](http://mitmproxy.org)
-
-Source is hosted on github:
-
-[github.com/cortesi/mitmproxy](http://github.com/cortesi/mitmproxy)
-
-
-Community
----------
-
-Come join us in the #mitmproxy channel on the OFTC IRC network
-(irc://irc.oftc.net:6667).
-
-We also have a mailing list, hosted here:
-
-[groups.google.com/group/mitmproxy](http://groups.google.com/group/mitmproxy)
-
Requirements
------------
@@ -69,3 +48,4 @@ The following components are needed if you plan to hack on mitmproxy:
* The test suite uses the [nose](http://readthedocs.org/docs/nose/en/latest/) unit testing
framework and requires [pathod](http://pathod.org) and [flask](http://flask.pocoo.org/).
* Rendering the documentation requires [countershape](http://github.com/cortesi/countershape).
+
diff --git a/doc-src/howmitmproxy.html b/doc-src/howmitmproxy.html
index a3335094..a95bdac6 100644
--- a/doc-src/howmitmproxy.html
+++ b/doc-src/howmitmproxy.html
@@ -17,13 +17,13 @@ and most reliable way to intercept traffic. The proxy protocol is codified in
the [HTTP RFC](http://www.ietf.org/rfc/rfc2068.txt), so the behaviour of both
the client and the server is well defined, and usually reliable. In the
simplest possible interaction with mitmproxy, a client connects directly to the
-proxy, and makes a request that looks like this:
+proxy, and makes a request that looks like this:
+
+<pre>GET http://example.com/index.html HTTP/1.1</pre>
-<pre>GET http://example.com/index.html HTTP/1.1</pre>
-
This is a proxy GET request - an extended form of the vanilla HTTP GET request
that includes a schema and host specification, and it includes all the
-information mitmproxy needs to proceed.
+information mitmproxy needs to proceed.
<img src="explicit.png"/>
@@ -39,7 +39,7 @@ information mitmproxy needs to proceed.
<tr>
- <td><b>2</b></td>
+ <td><b>2</b></td>
<td>Mitmproxy connects to the upstream server and simply forwards
the request on.</td>
@@ -67,49 +67,17 @@ flow of requests and responses are completely opaque to the proxy.
## The MITM in mitmproxy
-This is where mitmproxy's fundamental trick comes into play. The MITM in its
-name stands for Man-In-The-Middle - a reference to the process we use to
-intercept and interfere with these theoretially opaque data streams. The basic
-idea is to pretend to be the server to the client, and pretend to be the client
-to the server, while we sit in the middle decoding traffic from both sides. The
-tricky part is that the [Certificate
-Authority](http://en.wikipedia.org/wiki/Certificate_authority) system is
-designed to prevent exactly this attack, by allowing a trusted third-party to
-cryptographically sign a server's SSL certificates to verify that they are
-legit. If this signature is from a non-trusted party, a secure client will
-simply drop the connection and refuse to proceed. Despite the many shortcomings
-of the CA system as it exists today, this is usually fatal to attempts to MITM
-an SSL connection for analysis.
-
-Our answer to this conundrum is to become a trusted Certificate Authority
-ourselves. Mitmproxy includes a full CA implementation that generates
-interception certificates on the fly. To get the client to trust these
-certificates, we [register mitmproxy as a trusted CA with the device
-manually](@!urlTo("ssl.html")!@).
-
-## Complication 1: What's the remote hostname?
-
-To proceed with this plan, we need to know the domain name to use in the
-interception certificate - the client will verify that the certificate is for
-the domain it's connecting to, and abort if this is not the case. At first
-blush, it seems that the CONNECT request above gives us all we need - in this
-example, both of these values are "example.com". But what if the client had
-initiated the connection as follows:
+This is where mitmproxy's fundamental trick comes into play. The MITM in its name stands for Man-In-The-Middle - a reference to the process we use to intercept and interfere with these theoretially opaque data streams. The basic idea is to pretend to be the server to the client, and pretend to be the client to the server, while we sit in the middle decoding traffic from both sides. The tricky part is that the [Certificate Authority](http://en.wikipedia.org/wiki/Certificate_authority) system is designed to prevent exactly this attack, by allowing a trusted third-party to cryptographically sign a server's SSL certificates to verify that they are legit. If this signature doesn't match or is from a non-trusted party, a secure client will simply drop the connection and refuse to proceed. Despite the many shortcomings of the CA system as it exists today, this is usually fatal to attempts to MITM an SSL connection for analysis. Our answer to this conundrum is to become a trusted Certificate Authority ourselves. Mitmproxy includes a full CA implementation that generates interception certificates on the fly. To get the client to trust these certificates, we [register mitmproxy as a trusted CA with the device manually](@!urlTo("ssl.html")!@).
+
+## Complication 1: What's the remote hostname?
+
+To proceed with this plan, we need to know the domain name to use in the interception certificate - the client will verify that the certificate is for the domain it's connecting to, and abort if this is not the case. At first blush, it seems that the CONNECT request above gives us all we need - in this example, both of these values are "example.com". But what if the client had initiated the connection as follows:
<pre>CONNECT 10.1.1.1:443 HTTP/1.1</pre>
-Using the IP address is perfectly legitimate because it gives us enough
-information to initiate the pipe, even though it doesn't reveal the remote
-hostname.
+Using the IP address is perfectly legitimate because it gives us enough information to initiate the pipe, even though it doesn't reveal the remote hostname.
-Mitmproxy has a cunning mechanism that smooths this over - [upstream
-certificate sniffing](@!urlTo("features/upstreamcerts.html")!@). As soon as we
-see the CONNECT request, we pause the client part of the conversation, and
-initiate a simultaneous connection to the server. We complete the SSL handshake
-with the server, and inspect the certificates it used. Now, we use the Common
-Name in the upstream SSL certificates to generate the dummy certificate for the
-client. Voila, we have the correct hostname to present to the client, even if
-it was never specified.
+Mitmproxy has a cunning mechanism that smooths this over - [upstream certificate sniffing](@!urlTo("features/upstreamcerts.html")!@). As soon as we see the CONNECT request, we pause the client part of the conversation, and initiate a simultaneous connection to the server. We complete the SSL handshake with the server, and inspect the certificates it used. Now, we use the Common Name in the upstream SSL certificates to generate the dummy certificate for the client. Voila, we have the correct hostname to present to the client, even if it was never specified.
## Complication 2: Subject Alternative Name
@@ -127,56 +95,33 @@ them to the generated dummy certificate.
## Complication 3: Server Name Indication
-One of the big limitations of conventional SSL is that each certificate
-requires its own IP address. This means that you couldn't do virtual hosting
-where multiple domains with independent certificates share the same IP address.
-In a world with a rapidly shrinking IPv4 address pool this is a problem, and we
-have a solution in the form of the [Server Name
-Indication](http://en.wikipedia.org/wiki/Server_Name_Indication) extension to
-the SSL and TLS protocols. This lets the client specify the remote server name
-at the start of the SSL handshake, which then lets the server select the right
-certificate to complete the process.
-
-SNI breaks our upstream certificate sniffing process, because when we connect
-without using SNI, we get served a default certificate that may have nothing to
-do with the certificate expected by the client. The solution is another tricky
-complication to the client connection process. After the client connects, we
-allow the SSL handshake to continue until just _after_ the SNI value has been
-passed to us. Now we can pause the conversation, and initiate an upstream
-connection using the correct SNI value, which then serves us the correct
-upstream certificate, from which we can extract the expected CN and SANs.
-
-There's another wrinkle here. Due to a limitation of the SSL library mitmproxy
-uses, we can't detect that a connection _hasn't_ sent an SNI request until it's
-too late for upstream certificate sniffing. In practice, we therefore make a
-vanilla SSL connection upstream to sniff non-SNI certificates, and then discard
-the connection if the client sends an SNI notification. If you're watching your
-traffic with a packet sniffer, you'll see two connections to the server when an
-SNI request is made, the first of which is immediately closed after the SSL
-handshake. Luckily, this is almost never an issue in practice.
+One of the big limitations of vanilla SSL is that each certificate requires its own IP address. This means that you couldn't do virtual hosting where multiple domains with independent certificates share the same IP address. In a world with a rapidly shrinking IPv4 address pool this is a problem, and we have a solution in the form of the [Server Name Indication](http://en.wikipedia.org/wiki/Server_Name_Indication) extension to the SSL and TLS protocols. This lets the client specify the remote server name at the start of the SSL handshake, which then lets the server select the right certificate to complete the process.
+SNI breaks our upstream certificate sniffing process, because when we connect without using SNI, we get served a default certificate that may have nothing to do with the certificate expected by the client. The solution is another tricky complication to the client connection process. After the client connects, we allow the SSL handshake to continue until just _after_ the SNI value has been passed to us. Now we can pause the conversation, and initiate an upstream connection using the correct SNI value, which then serves us the correct upstream certificate, from which we can extract the expected CN and SANs.
+
+There's another wrinkle here. Due to a limitation of the SSL library mitmproxy uses, we can't detect that a connection _hasn't_ sent an SNI request until it's too late for upstream certificate sniffing. In practice, we therefore make a vanilla SSL connection upstream to sniff non-SNI certificates, and then discard the connection if the client sends an SNI notification. If you're watching your traffic with a packet sniffer, you'll see two connections to the server when an SNI request is made, the first of which is immediately closed after the SSL handshake. Luckily, this is almost never an issue in practice.
## Putting it all together
-Lets put all of this together into the complete explicitly proxied HTTPS flow.
+Lets put all of this together into the complete explicitly proxied HTTPS flow.
<img src="explicit_https.png"/>
<table class="table">
<tbody>
<tr>
- <td><b>1</b></td>
+ <td><b>1</b></td>
<td>The client makes a connection to mitmproxy, and issues an HTTP
CONNECT request.</td>
</tr>
<tr>
- <td><b>2</b></td>
+ <td><b>2</b></td>
<td>Mitmproxy responds with a 200 Connection Established, as if it
has set up the CONNECT pipe.</td>
</tr>
<tr>
- <td><b>3</b></td>
+ <td><b>3</b></td>
<td>The client believes it's talking to the remote server, and
initiates the SSL connection. It uses SNI to indicate the hostname
@@ -184,33 +129,33 @@ Lets put all of this together into the complete explicitly proxied HTTPS flow.
</tr>
<tr>
- <td><b>4</b></td>
+ <td><b>4</b></td>
<td>Mitmproxy connects to the server, and establishes an SSL
connection using the SNI hostname indicated by the client.</td>
-
+
</tr>
<tr>
- <td><b>5</b></td>
+ <td><b>5</b></td>
<td>The server responds with the matching SSL certificate, which
contains the CN and SAN values needed to generate the interception
certificate.</td>
</tr>
<tr>
- <td><b>6</b></td>
+ <td><b>6</b></td>
<td>Mitmproxy generates the interception cert, and continues the
client SSL handshake paused in step 3.</td>
</tr>
<tr>
- <td><b>7</b></td>
+ <td><b>7</b></td>
<td>The client sends the request over the established SSL
connection.</td>
</tr>
<tr>
- <td><b>7</b></td>
+ <td><b>7</b></td>
<td>Mitmproxy passes the request on to the server over the SSL
connection initiated in step 4.</td>
@@ -234,11 +179,11 @@ redirection mechanism that transparently reroutes a TCP connection destined for
a server on the Internet to a listening proxy server. This usually takes the
form of a firewall on the same host as the proxy server -
[iptables](http://www.netfilter.org/) on Linux or
-[pf](http://en.wikipedia.org/wiki/PF_(firewall)) on OSX. Once the client has
+[pf](http://en.wikipedia.org/wiki/PF_\(firewall\)) on OSX. Once the client has
initiated the connection, it makes a vanilla HTTP request, which might look
something like this:
-<pre>GET /index.html HTTP/1.1</pre>
+<pre>GET /index.html HTTP/1.1</pre>
Note that this request differs from the explicit proxy variation, in that it
omits the scheme and hostname. How, then, do we know which upstream host to
@@ -258,11 +203,11 @@ this information, the process is fairly straight-forward.
<table class="table">
<tbody>
<tr>
- <td><b>1</b></td>
+ <td><b>1</b></td>
<td>The client makes a connection to the server.</td>
</tr>
<tr>
- <td><b>2</b></td>
+ <td><b>2</b></td>
<td>The router redirects the connection to mitmproxy, which is
typically listening on a local port of the same host. Mitmproxy
@@ -270,16 +215,16 @@ this information, the process is fairly straight-forward.
destination was.</td>
</tr>
<tr>
- <td><b>3</b></td>
+ <td><b>3</b></td>
<td>Now, we simply read the client's request...</td>
</tr>
<tr>
- <td><b>4</b></td>
+ <td><b>4</b></td>
<td>... and forward it upstream.</td>
-
+
</tr>
</tbody>
</table>
@@ -300,11 +245,11 @@ and cope with SNI.
<table class="table">
<tbody>
<tr>
- <td><b>1</b></td>
+ <td><b>1</b></td>
<td>The client makes a connection to the server.</td>
</tr>
<tr>
- <td><b>2</b></td>
+ <td><b>2</b></td>
<td>The router redirects the connection to mitmproxy, which is
typically listening on a local port of the same host. Mitmproxy
@@ -312,7 +257,7 @@ and cope with SNI.
destination was.</td>
</tr>
<tr>
- <td><b>3</b></td>
+ <td><b>3</b></td>
<td>The client believes it's talking to the remote server, and
initiates the SSL connection. It uses SNI to indicate the hostname
@@ -320,33 +265,33 @@ and cope with SNI.
</tr>
<tr>
- <td><b>4</b></td>
+ <td><b>4</b></td>
<td>Mitmproxy connects to the server, and establishes an SSL
connection using the SNI hostname indicated by the client.</td>
-
+
</tr>
<tr>
- <td><b>5</b></td>
+ <td><b>5</b></td>
<td>The server responds with the matching SSL certificate, which
contains the CN and SAN values needed to generate the interception
certificate.</td>
</tr>
<tr>
- <td><b>6</b></td>
+ <td><b>6</b></td>
<td>Mitmproxy generates the interception cert, and continues the
client SSL handshake paused in step 3.</td>
</tr>
<tr>
- <td><b>7</b></td>
+ <td><b>7</b></td>
<td>The client sends the request over the established SSL
connection.</td>
</tr>
<tr>
- <td><b>7</b></td>
+ <td><b>7</b></td>
<td>Mitmproxy passes the request on to the server over the SSL
connection initiated in step 4.</td>
diff --git a/doc-src/transparent.html b/doc-src/transparent.html
index b28b04f6..689a2842 100644
--- a/doc-src/transparent.html
+++ b/doc-src/transparent.html
@@ -1,3 +1,15 @@
+When a transparent proxy is used, traffic is redirected into a proxy at the network layer, without
+any client configuration being required. This makes transparent proxying ideal for those situations
+where you can't change client behaviour - proxy-oblivious Android applications being a common
+example.
+To set up transparent proxying, we need two new components. The first is a
+redirection mechanism that transparently reroutes a TCP connection destined for
+a server on the Internet to a listening proxy server. This usually takes the
+form of a firewall on the same host as the proxy server -
+[iptables](http://www.netfilter.org/) on Linux or
+[pf](http://en.wikipedia.org/wiki/PF_\(firewall\)) on OSX. When the proxy receives a redirected connection, it sees a vanilla HTTP request, without a host specification. This is where the second new component comes in - a host module that allows us to query the redirector for the original destination of the TCP connection.
+
+At the moment, mitmproxy supports transparent proxying on OSX Lion and above, and all current flavors of Linux.kkkkk \ No newline at end of file
diff --git a/doc-src/transparent/osx.html b/doc-src/transparent/osx.html
index 20158873..77eea63b 100644
--- a/doc-src/transparent/osx.html
+++ b/doc-src/transparent/osx.html
@@ -20,7 +20,7 @@ OSX.
<pre class="terminal">rdr on en2 inet proto tcp to any port 80 -&gt; 127.0.0.1 port 8080
rdr on en2 inet proto tcp to any port 443 -&gt; 127.0.0.1 port 8080
</pre>
-
+
These rules tell pf to redirect all traffic destined for port 80 or 443
to the local mitmproxy instance running on port 8080. You should
replace <b>en2</b> with the interface on which your test device will
@@ -28,7 +28,7 @@ rdr on en2 inet proto tcp to any port 443 -&gt; 127.0.0.1 port 8080
</li>
- <li> Configure pf with the rules:
+ <li> Configure pf with the rules:
<pre class="terminal">sudo pfctl -f pf.conf</pre>
@@ -40,9 +40,6 @@ rdr on en2 inet proto tcp to any port 443 -&gt; 127.0.0.1 port 8080
</li>
- <li> Configure your test device to use the host on which mitmproxy is
- running as the default gateway.</li>
-
<li> Configure sudoers to allow mitmproxy to access pfctl. Edit the file
<b>/etc/sudoers</b> on your system as root. Add the following line to the end
of the file:
@@ -55,7 +52,7 @@ rdr on en2 inet proto tcp to any port 443 -&gt; 127.0.0.1 port 8080
you're special feel free to tighten the restriction up to the user running
mitmproxy.</li>
- <li> Finally, fire up mitmproxy. You probably want a command like this:
+ <li> Fire up mitmproxy. You probably want a command like this:
<pre class="terminal">mitmproxy -T --host</pre>
@@ -65,4 +62,8 @@ rdr on en2 inet proto tcp to any port 443 -&gt; 127.0.0.1 port 8080
</li>
+ <li> Finally, configure your test device to use the host on which mitmproxy is
+ running as the default gateway.</li>
+
+
</ol>
diff --git a/examples/redirect_requests.py b/examples/redirect_requests.py
new file mode 100644
index 00000000..3a3ad300
--- /dev/null
+++ b/examples/redirect_requests.py
@@ -0,0 +1,19 @@
+from libmproxy.flow import Response
+from netlib.odict import ODictCaseless
+
+"""
+This example shows two ways to redirect flows to other destinations.
+"""
+
+def request(context, flow):
+ if flow.request.host.endswith("example.com"):
+ resp = Response(flow.request,
+ [1,1],
+ 200, "OK",
+ ODictCaseless([["Content-Type","text/html"]]),
+ "helloworld",
+ None)
+ flow.request.reply(resp)
+ if flow.request.host.endswith("example.org"):
+ flow.request.host = "mitmproxy.org"
+ flow.request.headers["Host"] = ["mitmproxy.org"]
diff --git a/libmproxy/app.py b/libmproxy/app.py
new file mode 100644
index 00000000..18d78b3e
--- /dev/null
+++ b/libmproxy/app.py
@@ -0,0 +1,7 @@
+import flask
+
+mapp = flask.Flask(__name__)
+
+@mapp.route("/")
+def hello():
+ return "mitmproxy"
diff --git a/libmproxy/cmdline.py b/libmproxy/cmdline.py
index 1d5902a9..b76792cf 100644
--- a/libmproxy/cmdline.py
+++ b/libmproxy/cmdline.py
@@ -163,7 +163,7 @@ def get_common_options(options):
def common_options(parser):
parser.add_argument(
- "-a",
+ "-b",
action="store", type = str, dest="addr", default='',
help = "Address to bind proxy to (defaults to all interfaces)"
)
@@ -261,6 +261,13 @@ def common_options(parser):
help="Don't connect to upstream server to look up certificate details."
)
+ group = parser.add_argument_group("Web App")
+ group.add_argument(
+ "-a",
+ action="store_true", dest="app", default=False,
+ help="Enable the mitmproxy web app."
+ )
+
group = parser.add_argument_group("Client Replay")
group.add_argument(
"-c",
diff --git a/libmproxy/console/contentview.py b/libmproxy/console/contentview.py
index 2b46064a..53841c73 100644
--- a/libmproxy/console/contentview.py
+++ b/libmproxy/console/contentview.py
@@ -12,7 +12,7 @@ import netlib.utils
import common
from .. import utils, encoding, flow
from ..contrib import jsbeautifier, html2text
-
+import subprocess
try:
import pyamf
from pyamf import remoting, flex
@@ -137,7 +137,7 @@ class ViewXML:
class ViewJSON:
name = "JSON"
- prompt = ("json", "j")
+ prompt = ("json", "s")
content_types = ["application/json"]
def __call__(self, hdrs, content, limit):
lines = utils.pretty_json(content)
@@ -364,6 +364,38 @@ class ViewImage:
)
return "%s image"%img.format, fmt
+class ViewProtobuf:
+ """Human friendly view of protocol buffers
+ The view uses the protoc compiler to decode the binary
+ """
+
+ name = "Protocol Buffer"
+ prompt = ("protobuf", "p")
+ content_types = ["application/x-protobuf"]
+
+ @staticmethod
+ def is_available():
+ try:
+ p = subprocess.Popen(["protoc", "--version"], stdout=subprocess.PIPE)
+ out, _ = p.communicate()
+ return out.startswith("libprotoc")
+ except:
+ return False
+
+ def decode_protobuf(self, content):
+ # if Popen raises OSError, it will be caught in
+ # get_content_view and fall back to Raw
+ p = subprocess.Popen(['protoc', '--decode_raw'],
+ stdin=subprocess.PIPE,
+ stdout=subprocess.PIPE,
+ stderr=subprocess.PIPE)
+ out, _ = p.communicate(input=content)
+ return out
+
+ def __call__(self, hdrs, content, limit):
+ decoded = self.decode_protobuf(content)
+ txt = _view_text(decoded[:limit], len(decoded), limit)
+ return "Protobuf", txt
views = [
ViewAuto(),
@@ -381,6 +413,9 @@ views = [
if pyamf:
views.append(ViewAMF())
+if ViewProtobuf.is_available():
+ views.append(ViewProtobuf())
+
content_types_map = {}
for i in views:
for ct in i.content_types:
diff --git a/libmproxy/console/flowview.py b/libmproxy/console/flowview.py
index 9bec7bc6..8932b912 100644
--- a/libmproxy/console/flowview.py
+++ b/libmproxy/console/flowview.py
@@ -34,10 +34,14 @@ def _mkhelp():
[("text", ": automatic detection")]
),
(None,
- common.highlight_key("hex", "h") +
+ common.highlight_key("hex", "e") +
[("text", ": Hex")]
),
(None,
+ common.highlight_key("html", "h") +
+ [("text", ": HTML")]
+ ),
+ (None,
common.highlight_key("image", "i") +
[("text", ": Image")]
),
@@ -201,7 +205,7 @@ class FlowView(common.WWrap):
def wrap_body(self, active, body):
parts = []
- if self.flow.intercepting and not self.flow.request.acked:
+ if self.flow.intercepting and not self.flow.request.reply.acked:
qt = "Request intercepted"
else:
qt = "Request"
@@ -210,7 +214,7 @@ class FlowView(common.WWrap):
else:
parts.append(self._tab(qt, "heading_inactive"))
- if self.flow.intercepting and self.flow.response and not self.flow.response.acked:
+ if self.flow.intercepting and self.flow.response and not self.flow.response.reply.acked:
st = "Response intercepted"
else:
st = "Response"
diff --git a/libmproxy/console/help.py b/libmproxy/console/help.py
index 40f81955..de373083 100644
--- a/libmproxy/console/help.py
+++ b/libmproxy/console/help.py
@@ -57,10 +57,14 @@ class HelpView(urwid.ListBox):
[("text", ": automatic detection")]
),
(None,
- common.highlight_key("hex", "h") +
+ common.highlight_key("hex", "e") +
[("text", ": Hex")]
),
(None,
+ common.highlight_key("html", "h") +
+ [("text", ": HTML")]
+ ),
+ (None,
common.highlight_key("image", "i") +
[("text", ": Image")]
),
diff --git a/libmproxy/flow.py b/libmproxy/flow.py
index c318aac8..50b30fe1 100644
--- a/libmproxy/flow.py
+++ b/libmproxy/flow.py
@@ -23,6 +23,7 @@ import tnetstring, filt, script, utils, encoding, proxy
from email.utils import parsedate_tz, formatdate, mktime_tz
from netlib import odict, http, certutils
import controller, version
+import app
HDR_FORM_URLENCODED = "application/x-www-form-urlencoded"
CONTENT_MISSING = 0
@@ -42,13 +43,13 @@ class ReplaceHooks:
def add(self, fpatt, rex, s):
"""
- Add a replacement hook.
+ add a replacement hook.
- fpatt: A string specifying a filter pattern.
- rex: A regular expression.
- s: The replacement string
+ fpatt: a string specifying a filter pattern.
+ rex: a regular expression.
+ s: the replacement string
- Returns True if hook was added, False if the pattern could not be
+ returns true if hook was added, false if the pattern could not be
parsed.
"""
cpatt = filt.parse(fpatt)
@@ -1372,6 +1373,7 @@ class FlowMaster(controller.Master):
self.setheaders = SetHeaders()
self.stream = None
+ app.mapp.config["PMASTER"] = self
def add_event(self, e, level="info"):
"""
diff --git a/libmproxy/proxy.py b/libmproxy/proxy.py
index 0de1c2e2..283072ab 100644
--- a/libmproxy/proxy.py
+++ b/libmproxy/proxy.py
@@ -17,8 +17,11 @@ import shutil, tempfile, threading
import SocketServer
from OpenSSL import SSL
from netlib import odict, tcp, http, wsgi, certutils, http_status, http_auth
-import utils, flow, version, platform, controller
+import utils, flow, version, platform, controller, app
+
+APP_DOMAIN = "mitm"
+APP_IP = "1.1.1.1"
KILL = 0
@@ -36,8 +39,8 @@ class Log:
class ProxyConfig:
- def __init__(self, certfile = None, cacert = None, clientcerts = None, no_upstream_cert=False, body_size_limit = None, reverse_proxy=None, transparent_proxy=None, certdir = None, authenticator=None):
- assert not (reverse_proxy and transparent_proxy)
+ def __init__(self, app=False, certfile = None, cacert = None, clientcerts = None, no_upstream_cert=False, body_size_limit = None, reverse_proxy=None, transparent_proxy=None, certdir = None, authenticator=None):
+ self.app = app
self.certfile = certfile
self.cacert = cacert
self.clientcerts = clientcerts
@@ -90,6 +93,7 @@ class ServerConnection(tcp.TCPClient):
pass
+
class RequestReplayThread(threading.Thread):
def __init__(self, config, flow, masterq):
self.config, self.flow, self.channel = config, flow, controller.Channel(masterq)
@@ -330,6 +334,8 @@ class ProxyHandler(tcp.BaseHandler):
orig = self.config.transparent_proxy["resolver"].original_addr(self.connection)
if not orig:
raise ProxyError(502, "Transparent mode failure: could not resolve original destination.")
+ self.log(client_conn, "transparent to %s:%s"%orig)
+
host, port = orig
if port in self.config.transparent_proxy["sslports"]:
scheme = "https"
@@ -503,6 +509,17 @@ class ProxyServer(tcp.TCPServer):
raise ProxyServerError('Error starting proxy server: ' + v.strerror)
self.channel = None
self.apps = AppRegistry()
+ if config.app:
+ self.apps.add(
+ app.mapp,
+ APP_DOMAIN,
+ 80
+ )
+ self.apps.add(
+ app.mapp,
+ APP_IP,
+ 80
+ )
def start_slave(self, klass, channel):
slave = klass(channel, self)
@@ -635,6 +652,7 @@ def process_proxy_options(parser, options):
authenticator = http_auth.NullProxyAuth(None)
return ProxyConfig(
+ app = options.app,
certfile = options.cert,
cacert = cacert,
clientcerts = options.clientcerts,
diff --git a/libmproxy/utils.py b/libmproxy/utils.py
index 6e804887..b2258b15 100644
--- a/libmproxy/utils.py
+++ b/libmproxy/utils.py
@@ -67,7 +67,7 @@ def urldecode(s):
"""
Takes a urlencoded string and returns a list of (key, value) tuples.
"""
- return cgi.parse_qsl(s)
+ return cgi.parse_qsl(s, keep_blank_values=True)
def urlencode(s):
diff --git a/test/data/protobuf01 b/test/data/protobuf01
new file mode 100644
index 00000000..fbfdbff3
--- /dev/null
+++ b/test/data/protobuf01
@@ -0,0 +1,2 @@
+
+$3bbc333c-e61c-433b-819a-0b9a8cc103b8 \ No newline at end of file
diff --git a/test/test_console_contentview.py b/test/test_console_contentview.py
index 8a5dabb8..1798ce85 100644
--- a/test/test_console_contentview.py
+++ b/test/test_console_contentview.py
@@ -58,7 +58,9 @@ class TestContentView:
d = utils.urlencode([("one", "two"), ("three", "four")])
v = cv.ViewURLEncoded()
assert v([], d, 100)
- assert not v([], "foo", 100)
+ d = utils.urlencode([("adsfa", "")])
+ v = cv.ViewURLEncoded()
+ assert v([], d, 100)
def test_view_html(self):
v = cv.ViewHTML()
@@ -232,6 +234,14 @@ if pyamf:
p = tutils.test_data.path("data/amf03")
assert v([], file(p).read(), sys.maxint)
+if cv.ViewProtobuf.is_available():
+ def test_view_protobuf_request():
+ v = cv.ViewProtobuf()
+
+ p = tutils.test_data.path("data/protobuf01")
+ content_type, output = v([], file(p).read(), sys.maxint)
+ assert content_type == "Protobuf"
+ assert output[0].text == '1: "3bbc333c-e61c-433b-819a-0b9a8cc103b8"'
def test_get_by_shortcut():
assert cv.get_by_shortcut("h")
diff --git a/test/test_flow.py b/test/test_flow.py
index fce4e98a..4ad692bc 100644
--- a/test/test_flow.py
+++ b/test/test_flow.py
@@ -841,7 +841,7 @@ class TestRequest:
r = flow.Request(None, (1, 1), "host", 22, "https", "GET", "/?adsfa", h, "content")
q = r.get_query()
- assert not q
+ assert q.lst == [("adsfa", "")]
r = flow.Request(None, (1, 1), "host", 22, "https", "GET", "/foo?x=y&a=b", h, "content")
assert r.get_query()
diff --git a/test/test_server.py b/test/test_server.py
index fbd5af39..6a88578c 100644
--- a/test/test_server.py
+++ b/test/test_server.py
@@ -53,7 +53,16 @@ class CommonMixin:
assert "Bad Request" in t.rfile.readline()
-class TestHTTP(tservers.HTTPProxTest, CommonMixin):
+
+class AppMixin:
+ def test_app(self):
+ ret = self.app("/")
+ assert ret.status_code == 200
+ assert "mitmproxy" in ret.content
+
+
+
+class TestHTTP(tservers.HTTPProxTest, CommonMixin, AppMixin):
def test_app_err(self):
p = self.pathoc()
ret = p.request("get:'http://errapp/'")
@@ -135,6 +144,7 @@ class TestHTTP(tservers.HTTPProxTest, CommonMixin):
assert req.status_code == 400
+
class TestHTTPAuth(tservers.HTTPProxTest):
authenticator = http_auth.BasicProxyAuth(http_auth.PassManSingleUser("test", "test"), "realm")
def test_auth(self):
diff --git a/test/tservers.py b/test/tservers.py
index 0c2f8c2f..91ce4dc0 100644
--- a/test/tservers.py
+++ b/test/tservers.py
@@ -84,6 +84,7 @@ class ProxTestBase:
no_upstream_cert = cls.no_upstream_cert,
cacert = tutils.test_data.path("data/serverkey.pem"),
authenticator = cls.authenticator,
+ app = True,
**pconf
)
tmaster = cls.masterclass(cls.tqueue, config)
@@ -156,6 +157,17 @@ class HTTPProxTest(ProxTestBase):
q = "get:'%s/p/%s'"%(self.server.urlbase, spec)
return p.request(q)
+ def app(self, page):
+ if self.ssl:
+ p = libpathod.pathoc.Pathoc("127.0.0.1", self.proxy.port, True)
+ print "PRE"
+ p.connect((proxy.APP_IP, 80))
+ print "POST"
+ return p.request("get:'/%s'"%page)
+ else:
+ p = self.pathoc()
+ return p.request("get:'http://%s/%s'"%(proxy.APP_DOMAIN, page))
+
class TResolver:
def __init__(self, port):
@@ -234,3 +246,6 @@ class ReverseProxTest(ProxTestBase):
q = "get:'/p/%s'"%spec
return p.request(q)
+
+
+
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-05 12:05:32 +0000