Is your argument that it shouldn't be possible for a user to intercept t.co in this way? Seems like a perfectly valid use case (sidecar process to unwrap 9 layers of redirects from an anonymous browsing context). If the sidecar is validating the original t.co certs and you trust it then what's the problem?

> Is your argument that it shouldn't be possible for a user to intercept t.co in this way?

Not necessarily; the argument is that it's indistinguishable from a malicious MiTM. I think this is a great and legitimate use, but it's also probably something that website providers should be able to make themselves resilient against (or, at the least, be able to audit when it happens).

If I configure my computer that I own to use my CA and proxy certain traffic, I don't see how that's any website's business. They have as much right to audit how I've set up my computers as I do theirs.

There are different models here: for every person like you who's trying to reasonably proxy their local traffic, there's a nation state, overbearing educational software provider, &c. who's trying to get access to sensitive and potentially life-affecting communications. When it comes to things like finances, private chats, &c.

I think there's a reasonable argument to be made that it's in the website's (and my!) interests to be able to detect and prevent these kinds of man-in-the-middling.

The problem is that in practice, at least in the US, the most realistic threats are from websites you visit delivering drive-by malware (e.g. spyware and adware), which they actually do constantly. It's such a common practice that it's not even usually phrased that way, but just imagine if you exploited eBay's web servers to port scan their internal network, which is exactly what they did to customers. The responsible employees should be criminally charged for that.

It doesn't matter if it's in the websites interests. The client computer does not belong to them, and it's definitely not in the owner's interests to let others "audit" them just like it's not in web hosts interests to let us "audit" their nginx configs.

IIRC comcast and friends used to intercept plaintext HTTP connections and add advertising to them, so I don’t see why you’d consider this scenario uncommon.

I think you're setting up a false dichotomy here: I believe strongly in client filtering and in empowering users to do whatever they need to do to flush out the junk that comes with the modern online experience. I do it on my own devices, though both browser extensions and a local DNS server. I'd even consider doing it with a root CA, if it came to that (but so far it hasn't).

When I say "audit," I mean in the sense that existing ecosystems like CT already provide automatic auditability of certificate issuance. We're not talking about a private company sleuthing through your computer; we're talking about a way to enforce the stated security model that most users expect when a connection is described as "encrypted."

OCSP stapling should help in situations where the website provider wants to ensure clients are not being MITMed. Some SAAS providers are actively using it from experience (enterprise SSL inspection products play havok with it).

One thing I'd neglected to mention in the post is the sidecar uses a public DNS resolver to get the actual t.co link, but it's making the assumption that Go's stdlib enforces this: https://github.com/djhworld/theunwrapper/blob/main/unwrap/un... and doesn't fallback to the system one.

So there is that issue....I guess one way to mitigate it would be to run the sidecar out of the network, or at least have a clean DNS config and not have my custom CA in the root store...i.e. you'd want to be double sure you're going to the real thing and only accepting trusted certs signed by a trusted root.