0

A brief schema of a TLS intercepting proxy - the Client connects to the Host via the Proxy in a way which allows the Proxy to perform a (consensual) MITM.

[Client]  ->  [Proxy]  ->  [Host]

It's my understanding reading references online that implementing a TLS intercepting proxy requires you to:

  1. create your own CA signing key
  2. have the client trust your own CA
  3. the proxy can now basically establish two SSL sessions - Client<->Proxy and Proxy<->Host

This is one way to do this and projects like https://github.com/abhinavsingh/proxy.py use this approach as well as the employer of the author of How can my employer be a man-in-the-middle when I connect to Gmail?.


Question: is this the only way? Does a TLS intercepting proxy necessarily require a self-signed certificate? If so, can you explain why this is the only way?

1
  • 3
    It requires a certificate with "certificate signing" listed in the usage. That certificate does not need to be self-signed; it can be signed by some other CA instead of itself. Eventually there will be a self-signed "root", but that's true of every certificate chain, not only malicious ones.
    – Ben Voigt
    Jan 16 at 18:19

3 Answers 3

3

Something in the client has to be changed so that it continous to connect even though the proxy does not present a valid certificate.

Normally, when the client sets up a TLS connection to Host, it expects Host to present a valid certificate signed by its private key. When Proxy is in between, it accepts the connection instead. But since Proxy does not have Host's private key, it can't present the Host certificate. It can create its own certificate using a its own CA certificate.

In the end its up to the client to determine whether they trust the certificate. This can be done by installing the Proxy's CA certificate as trusted. Another method is to disable certificate verification in the client.

Alternatively, the Proxy can pass through the connection directly to Host. However, in that case it's not an intercepting proxy, as it can not view the data that is being transmitted.

3

In general yes you need your "own" CA (often at an enterprise or organizational level) but there have been a few cases where publicly-trusted CAs improperly issued (intermediate-CA) certs to interceptors, notably Turktrust 2012 and Trustwave/ANSSI 2013. There have also been cases where public CAs (or their RAs etc) were tricked or hacked to issue fraudulent certs, but (AFAIK) these were for specific domains, useful for impersonating a specific site but not for intercepting all (or even much) outgoing traffic. See (to start):
How feasible is it for a CA to be hacked? Which default trusted root certificates should I remove?
Does https prevent man in the middle attacks by proxy server?
Man-in-the-middle scenario for TLS

-1

No, it is not possible to MITM a well configured TLS session

Yes, the whole point of TLS is to prevent MITM attacks of any kind. As long as you use properly configured TLS, the proxy will not be able to intercept the traffic.

So how TLS Intercepting Proxies work?

The way "TLS Intercepting Proxies" work is that they create host certificates on the fly and sign them with a self-signed certificate. If this self-signed certificate is trusted by the client - then this will be a valid TLS connection and no warnings will be issued by the browser.

So how do we make the client trust a self-signed certificate? There are three options:

  1. a threat actor on the client computer installed it
  2. the system administrator installed it (ie corporate tls interceptors)
  3. a trusted CA has been tricked into signing the server certificate

If you can't do any of the above - then the client will issue an error or a warning when attempting a TLS handshake.

Conclusion

"TLS Interception" is just a fancy way to call a MITM attack.

The way this works is that you create and trust a self-signed certificate so you can fake that every site on the internet is signed by your self signed certificate - literally making the certificates on the fly, on each SSL handshake.

So yes - "TLS Interception" - requires you to have a self-signed certificate that is trusted by the clients that use the proxy.

3
  • This doesn't answer your question... this is a tangent...
    – schroeder
    Feb 7 at 14:57
  • @schroeder fixed, hopefully! Maybe it is more clear now
    – bbozo
    Feb 21 at 8:57
  • Still wrong. Doesn't have to be self-signed as everyone else has tried to explain. and what do you mean by "As long as you use properly configured TLS, the proxy will not be able to intercept the traffic."? You can have a "properly configured TLS" and still intercept.
    – schroeder
    Feb 21 at 9:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .