Apache: Validate SSL chain of trust to prevent MITM-attacks?
Solution 1:
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
The problem is not in the concept of SSL nor in the technical implementation, but rather that somebody else has full control over one end-point of the connection, i.e. your workstation.
That is the root of the actual security risk...
From a security perspective it is your workstation that is compromised which breaks the chain of trust that in normal circumstances prevents a MITM from succeeding.
How can I validate the chain of trust on server side?
You can't. That is done client side.
Depending on your use case what you can do is RFC 7469 HTTP Public Key Pinning in which you sent an additional header to the client with a list (hashes of) your actual SSL certificates or the CA's that you use.
Solution 2:
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.
Solution 3:
That's the wrong way. Not the server checks the chain of trust. It is the Client. So the reason why company use this way is to secure the company env and check what the employee is doing in his working time.
Solution 4:
You COULD (kind of), but the real question is whether you SHOULD.
But beware, it is nowhere as simple as changing a flag in apache.conf.
Also, as the "attacker" (eg. employer) controls the client computer, they can always foil your attempts if they are inclined to invest enough effort (on the bright side, unless you are very big fish, they most probably aren't inclined, so you will accomplish your goal that your users won't be able to connect to you unless it is secure) )
you could reimplement TLS in javascript, and do your checking there if certificate the client is connected is the certificate of your website.
if you are lucky, the user might be using browser where client-side Javascript can get info about remote certificate used (and thus easily verify it against hardcoded value of your server's certificate).
you could use JavaScript to run your custom encryption. So even when the company's evil TLS MiTM succeeded, it would still not give it access to your data. Of course, if there are sufficiently interested (and since they control the client), they could just on-the-fly replace your secure javascript with their own which also logs (or changes) all the information in transit.
Also, since businesses that employ TLS MiTM proxies also usually control the client computer completely, they could as easily install screen and keylogger to simply record video of everything the user sees, and record all keystrokes (and mouse movements) that user types. As you can see, when attacker IS the client, there is no absolutely secure way to fool him. It is really just a question how much are they going to bother... And some of solutions above might be good enough for you.