The authors of the original paper  identified that the set of client cipher suites advertised by each browser can be used to fingerprint and identify a browser.
Caddy records the cipher suite advertised by the client during the TLS handshake and then later examines the client's user agent. Using the fingerprinting techniques mentioned in the paper, Caddy then determines whether or not the advertised user-agent is compatible with the user-agent that it inferred through the client cipher suites.
TLS interception proxies establish their own TLS connection to the server. Depending on what underlying TLS library the proxy uses, it also has its own unique fingerprint. When the TLS proxy forwards the user's request, Caddy detects the mismatch and flags it as a MITM.
> I don't think that's the correct interpretation of this document. A better title would be "Most TLS Proxies Considered Harmful", not TLS interception as a whole.
This is the usual reaction to this I see everywhere. It doesn't match with reality. Read the complete paper by Halderman et al .
It says pretty clearly that all existing products lower the security in one way or another: "Our grading scale focuses on the security of the TLS handshake and does not account for the additional HTTPS validation checks present in many browsers, such as HSTS, HPKP, OneCRL/CRLSets, certificate transparency validation, and OCSP must-staple. None of the products we tested supported these features."
TLS Interception that doesn't degrade security is a myth that exists only in some parallel world fantasy. It's also not very surprising. Browser vendors have extremely qualified security teams that are involved in many ways in the development of stronger TLS protections. Nothing like that can be said about any of the vendors of interception products.
There was a paper posted on HN a few weeks back by some pretty serious security researchers on the security risks of SSL MITM boxes.
How do you fix this when you're naught but a humble employee? Well, a friend of mine worked at a fairly large tech company where a salesguy for these boxes had convinced the CTO they had to have them. Every tech-person "on the floor" hated the idea, so before the boxes were installed they conspired on their free time to write some scripts that ran lots of legitimate HTTPS traffic, effectively DDOSing the boxes and bringing the company's internet to a crawl for the day, like Google would take ten seconds to open. Then obviously everyone (including the non-tech people) started calling the IT helpdesk complaining that the internet was broken. MITM box salesguy then had to come up with a revised solution, costing 20x more than his first offer, and that was the end of that.
If you already are suffering under MITM boxes, a similar strategy with a slow ramp-up in traffic might work.
We recently published a paper on this exact issue and quantify the degree to which AV / corporate middlebox systems degrade the security of HTTPS connections. The tl;dr is that we find an alarming amount of MITM on the public internet (5-10%), mostly due to AV/middleboxes, and they almost always degrade the security of the connection.