Un proxy que sustituye el certificado: qué le pasa a 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 se apoya en TLS. El cliente abre una conexión segura con el servidor y comprueba su certificado. El certificado liga el nombre de dominio a la clave pública del servidor y lo confirma una cadena de certificación de confianza.
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.
Si el navegador espera el certificado del sitio y en su lugar recibe uno firmado por una autoridad de certificación desconocida, se supone que debe avisarte.
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.
Puede que alguien que programa necesite mirar las peticiones de una aplicación, reproducir problemas de TLS o estudiar cómo habla el cliente con el servidor.
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.
Si cogiste un proxy ajeno, no sabes quién lo gestiona y descubriste que el tráfico HTTPS se altera, eso es un nivel de riesgo completamente distinto.
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.
FAQ
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.