How can I Instruct a browser to reject proxy MITM certificate for my website

Question

Is there any way for my website to tell a browser, such as Chrome, to disallow a substitute MITM certificate like those used by corporate proxy servers? e.g. see Question 61056: Is there any way for my ISP or LAN admin to learn my Gmail address as a result of me logging into Gmail's web interface through via their network?

I understand the normal way this is supposed to work, and I understand that generally, control of the browser by the corporate group can control it how they like, but I'm wondering if, perhaps, under instruction from the website, Chrome has a way to defeat that, or, at least, make it more obvious when that's happening. (e.g. Perhaps through an alternate verification path?)

(I figure mine must be a dup question, but I can't find another, right now. — DN)

Answer 1

[new answer based on improved understanding of question based on OP comments to first, now deleted, answer]

Is there any way for my website to tell a browser to disallow a substitute MITM certificate like those used by corporate proxy servers?

There are, although they are solutions designed to prevent the damage caused by certificates that were incorrectly issued to malicious parties by a CA. Two such solutions are HPKP and DANE. However, these are waning in support as other, different solutions (which don't help your use case) come into play.

HTTP Public Key Pinning (HPKP) involves the server communicating which certificates are valid to the browser within the HTTP headers. It has been deprecated, however, "because of its complexity and dangerous side-effects." But it's worth noting particularly because, pertinent to your question,

Most browsers disable pinning for certificate chains with private root certificates to enable various corporate content inspection scanners and web debugging tools (such as mitmproxy or Fiddler). The RFC 7469 standard recommends disabling pinning violation reports for "user-defined" root certificates, where it is "acceptable" for the browser to disable pin validation.

In other words - there are hooks to permit Corporate MITM in HPKP, as well.

DNS-based Authentication of Named Entities (DANE) does something similar, placing information about acceptable certificates into DNS entries. It doesn't appear to have very good browser support, however, and if the Corporate Overlords are imposing MITM at the proxy, they're also capable of blackholing the necessary DNS queries.

Newer solutions to the problem of "bogus" certificates have shifted away from the browser, and as such aren't useful for your purposes. DNS Certification Authority Authorization (CAA) allows server admins to publish a DNS record identifying the correct CA they use; however, this is used by other CAs as a check to avoid malicious requests for certificates from someone other than the domain owner. Browsers do not use this record to verify anything.

Likewise, Certificate Transparency (CT) requires CAs to publish the certificates they've issued, allowing subjects and third parties to look for malicious certificates. However, this isn't something browsers use, either.

---

Theoretically, if you wanted to get creative and roll your own, you could use the Forge JavaScript TLS Implementation to open a TLS session from the user's browser to your server for the purposes of inspecting the certificate. If the certificate isn't yours, there's MITM going on! Then you could take actions on the client side (e.g., pop up a warning) or the server side (e.g., abort the login or, if already logged in, log the user out). It might be difficult to discern the proxy the browser is configured to use, though...

Answer 2

You can't. As a website operator, the browser is not under your control, therefore you can't expect it to cooperate in your attempt to get it to distrust a certificate that the computer's owner has already decided to trust.

That said, you might be able to guess whether a user is visiting your site through a MITM proxy using various heuristics, such as by comparing the cryptographic parameters used during the TLS handshake with known values for popular browsers, as described in the paper The Security Impact of HTTPS Interception. The web server Caddy has this feature built-in.

Once you've detected that a proxy is in use, you can reject the connection from your end. Beware however that there is a significant risk of false positives. Also note that while this technique may be sufficient to detect corporate proxies, it won't work against an adversary who is aware of this method and is trying to evade detection.