I just realized that SSL man-in-the-middle attacks are far more common than I thought, especially in corporate environments. I've heard about and seen myself several enterprises which have a transparent SSL proxy server in place. All clients are configured to trust this proxy's certificate. This basically means that the employer theoretically can intercept even SSL encrypted traffic without any warnings in the browser popping up. As mentioned above, the clients come with the certificate being trusted. This can only be revealed by manually validating the certificate which is being used.
To me, it appears as if the employer utilizes his superior position to spy on the employee's SSL traffic. For me, this renders the whole concept of SSL untrustworthy. I have successfully tested a similar setup myself using mitmproxy and was able to read the communication between client and my electronic banking server. This is information that shouldn't be revealed to anybody.
Thus, my question is rather simple: How can I validate the chain of trust on server side? I want to make sure the client uses my server's certificate and only one chain of trust. I wonder if this can be achieved by Apache's SSL configuration? This would be convenient as it could be applied to many applications easily. If this is not possible, does anyone know of a way to do this in PHP? Or do you have any other suggestions?
Best Answer
I think this question would be more appropriate for security.stackexchange.com where the topic of MITM is discussed in many question. But anyway:
Validation of the server certificate is only done at the client and cannot be moved somehow to the server since the point of validating the certificate at the client is, that the clients needs to make sure that it is talking to the correct server and cannot trust the (untrusted) server to make this decision for the client.
In case of SSL interception the TLS client from the perspective of the server is the SSL intercepting firewall/AV. Thus the problem at the server side is to detect if it is talking to the expected client (the browser) or not (the firewall/AV). The safest way to do this is to use client certificates to authenticate the client - and in fact SSL interception will not work if client authentication is used, i.e. the TLS handshake will fail since the MITM is not able to provide the expected client certificate.
Only, client certificates are rarely used. Also, a failing TLS handshake would not mean that the client can communicate to the server without SSL interception but that the client cannot communicate with the server at all. An alternative way would be to use some heuristics to detect the kind of TLS client based on the fingerprint of the TLS handshake, i.e. kind and order of ciphers, use of specific extensions... While a SSL intercepting proxy could in theory emulate the original ClientHello perfectly most don't. See also Detect man-in-the-middle on server side for HTTPS or the section III TLS Implementation Heuristics in The Security Impact of HTTPS Interception.