diff options
Diffstat (limited to 'doc-src')
| -rw-r--r-- | doc-src/features/reverseproxy.html | 17 | ||||
| -rw-r--r-- | doc-src/howmitmproxy.html | 9 | ||||
| -rw-r--r-- | doc-src/modes.html | 14 |
3 files changed, 13 insertions, 27 deletions
diff --git a/doc-src/features/reverseproxy.html b/doc-src/features/reverseproxy.html index 5ef4efc5..af5a5c53 100644 --- a/doc-src/features/reverseproxy.html +++ b/doc-src/features/reverseproxy.html @@ -7,22 +7,17 @@ mitmproxy forwards HTTP proxy requests to an upstream proxy server. <table class="table"> <tbody> <tr> - <th width="20%">command-line</th> <td>-R <i>schema</i>://hostname[:port]</td> + <th width="20%">command-line</th> <td>-R <i>scheme</i>://hostname[:port]</td> </tr> </tbody> </table> -Here, **schema** is one of http, https, http2https or https2http. The latter -two extended schema specifications control the use of HTTP and HTTPS on -mitmproxy and the upstream server. You can indicate that mitmproxy should use -HTTP, and the upstream server uses HTTPS like this: +Here, **scheme** signifies if the proxy should use TLS to connect to the server. +mitmproxy accepts both encrypted and unencrypted requests and transforms them to what the server +expects. - http2https://hostname:port - -And you can indicate that mitmproxy should use HTTPS while the upstream -service uses HTTP like this: - - https2http://hostname:port + mitmdump -R https://httpbin.org -p 80 + mitmdump -R https://httpbin.org -p 443 ### Host Header diff --git a/doc-src/howmitmproxy.html b/doc-src/howmitmproxy.html index fabd393a..16b5f722 100644 --- a/doc-src/howmitmproxy.html +++ b/doc-src/howmitmproxy.html @@ -145,15 +145,6 @@ 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. diff --git a/doc-src/modes.html b/doc-src/modes.html index b5a38696..6bd92167 100644 --- a/doc-src/modes.html +++ b/doc-src/modes.html @@ -149,7 +149,7 @@ this: <h1>Reverse Proxy</h1> </div> -Mitmproxy is usually used with a client that uses the proxy to access the +mitmproxy is usually used with a client that uses the proxy to access the Internet. Using reverse proxy mode, you can use mitmproxy to act like a normal HTTP server: @@ -173,15 +173,15 @@ on port 80. You can test your app on the example.com domain and get all requests recorded in mitmproxy. - Say you have some toy project that should get SSL support. Simply set up -mitmproxy with SSL termination and you're done (<code>mitmdump -p 443 -R -https2http://localhost:80/</code>). There are better tools for this specific -task, but mitmproxy is very quick and simple way to set up an SSL-speaking -server. +mitmproxy as a reverse proxy on port 443 and you're done (<code>mitmdump -p 443 -R +http://localhost:80/</code>). mitmproxy auto-detects TLS traffic and intercepts it dynamically. +There are better tools for this specific task, but mitmproxy is very quick and simple way to +set up an SSL-speaking server. - Want to add a non-SSL-capable compression proxy in front of your server? You -could even spawn a mitmproxy instance that terminates SSL (https2http://...), +could even spawn a mitmproxy instance that terminates SSL (-R http://...), point it to the compression proxy and let the compression proxy point to a -SSL-initiating mitmproxy (http2https://...), which then points to the real +SSL-initiating mitmproxy (-R https://...), which then points to the real server. As you see, it's a fairly flexible thing. Note that mitmproxy supports either an HTTP or an HTTPS upstream server, not |