Mitmproxy在反向代理服务器模式下自我签署上游证书

我有几台机器不支持TLS 1.1 & 1.2并且他们应该连接到的服务器正在放弃对旧协议的支持。无论如何，它们都通过中央服务器进行隧道传输。Mitmproxy在反向代理服务器模式下自我签署上游证书

这个想法是在中央服务器上运行mitmdump作为反向代理;客户端发送普通的http请求来反向代理而不是https到远程服务器，然后它通过TLS 1.2与远程服务器通信（请告知如果您认为有更好/更简单的解决方案）。

我在本地测试这个，所以客户端发送http到mitmdump运行的localhost。

这是我如何运行mitmdump：

mitmdump -R https://remotehost:port --port 8844 --upstream-trusted-ca "C:\fullpath\root_ca_pem.cer"

而这就是我得到：

127.0.0.1:54547: clientconnect 
127.0.0.1:54547: POST https://remotehost:someport/ 
<< Certificate Verification Error for remotehost: unable to get issuer certificate (errno: 2, depth: 1) 
127.0.0.1:54547: clientdisconnect

远程服务器使用CA证书和子证书不属于受信任的根证书存储通过默认情况下，虽然我在那里添加它们（是否在Windows上使用mitmdump？）。所以我使用了“--upstream-trusted-ca”，但不幸的是这并没有解决问题。

任何想法我做错了什么？也许我应该包括所有连锁证书;我会怎么做？

来源

2016-11-24 Damir

您可能会遇到到http问题降级HTTPS：如果您有没有被服务器发送中间CA，您可能需要构建你的PEM文件中像这样在他们指定的方案。所以你可能会发现需要让客户端也使用https。如果它只是一个站点，您可以使用类似于TCP插件的东西，使用DNS在TLS上游（和/或下游）使客户端连接到该站点。或者您可以使用完整的http或https检查代理。 – Adrien

远程服务器使用默认情况下不在受信任的根证书存储区中的CA证书和子证书，尽管我在那里添加了它们（在Windows上是否使用mitmdump？）。

我们想使用操作系统商店，但这对于OpenSSL来说并不容易。 Mitmproxy现在使用certifi。正如你所提到的，--upstream-trusted-ca是解决这个问题的正确方法。如果服务器发回了一些完整的URL与HTTPS

-----BEGIN CERTIFICATE----- 
<cert> 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
<intermediary cert (optional)> 
-----END CERTIFICATE-----

来源

2016-11-24 11:39:23

Mitmproxy在反向代理服务器模式下自我签署上游证书

回答

相关问题