TLS connections are tunnelled through proxies directly to the endpoint (HTTP CONNECT method) rather than the "client request to proxy" followed by "proxy request to endpoint" method of proxying.
This remote interception then involves turning a CONNECT back into the classic proxy connection. First a TLS session from your client to the proxy, then a TLS session from the proxy to the real endpoint.
The proxy needs to present itself to the client as valid for the real endpoint of the TLS connection. This is usually done by adding your own CA into the clients trust so you can sign any certificates required for the client -> proxy half. As you note, the connection from proxy -> endpoint is normally the easy part of that as it works like a normal client.
Two examples of not "tolerating" that interception are certificate pinning and client certificates.
Certificate pinning - The client validates extra information about the presented certificate beyond CA trust. Usually the x509 SHA-256 digest presented to the client. In this case the external entity doesn't enforce anything, you could modify the client to work.
Client certificates - Client cert authentication includes verification of the server certificate, so the forged proxy certificate will not be valid for the client cert. They are a pair. This would require a forged client cert for client -> proxy. Then the real client cert for proxy -> endpoint half.
So it's more convincing the client to tolerate the interception rather than the external endpoint.
This remote interception then involves turning a CONNECT back into the classic proxy connection. First a TLS session from your client to the proxy, then a TLS session from the proxy to the real endpoint.
The proxy needs to present itself to the client as valid for the real endpoint of the TLS connection. This is usually done by adding your own CA into the clients trust so you can sign any certificates required for the client -> proxy half. As you note, the connection from proxy -> endpoint is normally the easy part of that as it works like a normal client.
Two examples of not "tolerating" that interception are certificate pinning and client certificates.
Certificate pinning - The client validates extra information about the presented certificate beyond CA trust. Usually the x509 SHA-256 digest presented to the client. In this case the external entity doesn't enforce anything, you could modify the client to work.
Client certificates - Client cert authentication includes verification of the server certificate, so the forged proxy certificate will not be valid for the client cert. They are a pair. This would require a forged client cert for client -> proxy. Then the real client cert for proxy -> endpoint half.
So it's more convincing the client to tolerate the interception rather than the external endpoint.