代理掉包证书：HTTPS 会怎样
You open an HTTPS site through a proxy. The browser shows a padlock, the page loads, there are no errors. A natural question follows: if everything is protected, can the proxy read the traffic? In some configurations, yes.
What actually happens with HTTPS
HTTPS 建立在 TLS 之上。客户端与服务器建立安全连接，并校验其证书。证书把域名与服务器的公钥绑定，并由一条受信任的证书链予以确认。
In the usual arrangement a middleman forwards the encrypted data and does not know the contents of the secure connection.
But picture a different architecture.
Instead of one connection there are two:
client → middleman
and
middleman → target server
The middleman terminates TLS on its side, gains access to the contents, and then opens a separate connection to the original server.
That is the principle of MITM interception.
How a proxy can do this to HTTPS at all
The main obstacle here is trust in the certificate.
如果浏览器期待的是该网站的证书，收到的却是由陌生证书颁发机构签发的证书，它本应向你发出警告。
For an interceptor to work unnoticed, the client has to trust the chain the middleman uses.
One common option is to install its own root certificate on the device. After that the proxy can issue certificates for the domains you visit and the client will trust them. This is how corporate traffic inspection works.
So MITM does not break HTTPS mathematically.
It changes the structure of trust around the connection.
Why the browser may show nothing
This is the most important part of the subject.
People instinctively picture MITM as a situation where the browser is bound to show a big red page.
That is wrong.
If the client trusts the certificate the middleman uses, the TLS connection looks correct to the browser.
The certificate is valid against a trusted chain. The connection is encrypted. The site opens.
But the encryption now happens on two separate legs:
client ↔ middleman
and
middleman ↔ server
The middleman sits between them and can see the decrypted contents. Documentation on corporate TLS interception describes the same arrangement: a trusted client root lets the proxy act as an intermediate party in the connection.
So the absence of a browser error is not proof that there is no interception.
When MITM is normal
MITM is not automatically an attack.
There are entirely legitimate scenarios.
An organisation may control its own devices and use TLS inspection to analyse traffic, detect malicious content or enforce corporate policy.
That assumes the trusted certificate was installed deliberately and the infrastructure belongs to the organisation itself.
Another case is debugging.
开发者可能需要查看应用的请求、复现 TLS 问题，或研究客户端如何与服务器通信。
In those cases interception is a diagnostic tool.
The problem starts when that access exists without the user knowing, or without an expected reason.
Why HTTPS works proves nothing
A successful request proves only that the client and the final server managed to exchange data through the current arrangement.
It does not answer the question:
did the data pass directly between them, or did somebody decrypt it on the way?
With a correctly configured MITM both TLS connections can work perfectly.
Nothing in the application fails.
Which is why looking for the problem by visible symptoms alone is useless.
A successful interception is precisely the one that looks like ordinary working traffic.
What happens to the certificate
In a normal connection the browser receives a certificate tied to the target domain and to a chain of trust.
Under TLS inspection the middleman creates a different certificate for the client.
To the user the domain name looks familiar and the connection stays valid, because the new certificate is signed by an authority the device trusts.
Which leads to an important conclusion:
the presence of a certificate does not show that the certificate belongs to the original server directly.
You need to know who issued it and why your device trusts that authority.
How to tell whether there is interception
There are a few approaches.
The first is to inspect the certificate chain and compare it with the expected one.
If a site normally uses one chain of trust and a different one appears through a particular proxy, that can be a sign of TLS inspection.
But checking certificates by hand scales badly to a large proxy list.
A separate test that judges whether the traffic is altered on the way is simpler here.
That is the MITM test in Proxy Checker. It treats the alteration of traffic as a property of the proxy in its own right, rather than inferring it from whether an HTTPS response arrived.
Not every MITM means compromise
The opposite mistake is to treat every interception found as an attack.
The result of the check says:
the traffic is altered on the way.
The context is the next thing to establish.
A corporate gateway?
An antivirus?
A debugging proxy on your own machine?
Your own infrastructure?
If you know why TLS inspection is in place and you trust the arrangement, the result can be perfectly normal.
如果你用的是别人的代理，不知道由谁运营，又发现 HTTPS 流量正在被改动，那就是完全不同量级的风险。
Why a free proxy is a particularly interesting case
If a middleman controls your HTTPS traffic, it potentially has access to the contents of every connection it successfully intercepts.
So the question to ask about an unknown proxy is not this:
Does it open sites?
Far more important:
What happens to the traffic between me and the site?
Which is why MITM is worth checking separately from availability, latency and the outgoing IP.
常见问题
What is MITM through a proxy?
An arrangement where a middleman sits between client and server and sets up separate secure connections on both sides. In that arrangement the middleman can gain access to the contents of the traffic.
Why might the browser not show a warning?
If the device trusts the certificate authority the middleman uses, the certificate it issues can count as trusted. The absence of an error therefore does not prove the absence of TLS interception.
Can a corporate proxy lawfully intercept HTTPS?
Yes. TLS inspection is used in controlled corporate networks and can be part of a security policy or of diagnostics. The key questions are who runs the device, who owns the infrastructure, and whether that trust was established deliberately.
Does MITM mean a password has necessarily been stolen?
No. Detecting interception shows the architecture of the connection, not which data the middleman used or stored. But such a middleman potentially has access to the contents of every TLS connection it successfully decrypts.
Can MITM be ruled out by the fact that HTTPS works?
No. A successful HTTPS request is consistent both with an ordinary TLS connection and with correctly configured TLS inspection.
How do I check a proxy for MITM?
You need a separate test that checks whether the traffic is altered on the way. In Proxy Checker MITM is a check of its own, so it can be judged independently of availability and the other parameters.