From a9f6d53562b8020b87a8feaba2ac1d16d0d869ee Mon Sep 17 00:00:00 2001 From: Aldo Cortesi Date: Mon, 18 May 2015 12:05:29 +1200 Subject: certificate docs: reorg, wording, tweaks --- doc-src/howmitmproxy.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc-src/howmitmproxy.html') diff --git a/doc-src/howmitmproxy.html b/doc-src/howmitmproxy.html index 94afd522..832a61a8 100644 --- a/doc-src/howmitmproxy.html +++ b/doc-src/howmitmproxy.html @@ -84,7 +84,7 @@ 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")!@). +CA with the device manually](@!urlTo("certinstall.html")!@). ## Complication 1: What's the remote hostname? -- cgit v1.2.3 From 2135bcec61cf346555f8fd1e24bbb9267d002502 Mon Sep 17 00:00:00 2001 From: Aldo Cortesi Date: Sun, 24 May 2015 14:09:51 +1200 Subject: docs: styles now live in www.mitproxy.org repo, make images responsive --- doc-src/howmitmproxy.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'doc-src/howmitmproxy.html') diff --git a/doc-src/howmitmproxy.html b/doc-src/howmitmproxy.html index 832a61a8..f114e145 100644 --- a/doc-src/howmitmproxy.html +++ b/doc-src/howmitmproxy.html @@ -26,7 +26,7 @@ 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. - + @@ -158,7 +158,7 @@ handshake. Luckily, this is almost never an issue in practice. Lets put all of this together into the complete explicitly proxied HTTPS flow. - +
@@ -250,7 +250,7 @@ mitmproxy, this takes the form of a built-in set of that know how to talk to each platform's redirection mechanism. Once we have this information, the process is fairly straight-forward. - +
@@ -296,7 +296,7 @@ transparently proxying HTTP, and explicitly proxying HTTPS. We use the routing mechanism to establish the upstream server address, and then proceed as for explicit HTTPS connections to establish the CN and SANs, and cope with SNI. - +
-- cgit v1.2.3 From fcc15581808859b3d6670829c2d5248483660839 Mon Sep 17 00:00:00 2001 From: Aldo Cortesi Date: Fri, 12 Jun 2015 14:15:26 +1200 Subject: Fix typo in docs - thanks to Jim_Showalter@intuit.com --- doc-src/howmitmproxy.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc-src/howmitmproxy.html') diff --git a/doc-src/howmitmproxy.html b/doc-src/howmitmproxy.html index f114e145..fabd393a 100644 --- a/doc-src/howmitmproxy.html +++ b/doc-src/howmitmproxy.html @@ -120,8 +120,8 @@ Name](http://en.wikipedia.org/wiki/SubjectAltName) field in the SSL certificate that allows an arbitrary number of alternative domains to be specified. If the expected domain matches any of these, the client will proceed, even though the domain doesn't match the certificate Common Name. The answer here is simple: -when extract the CN from the upstream cert, we also extract the SANs, and add -them to the generated dummy certificate. +when we extract the CN from the upstream cert, we also extract the SANs, and +add them to the generated dummy certificate. ## Complication 3: Server Name Indication -- cgit v1.2.3