Comcast's RFC (6108) states that it designed the system described therein specifically to not need to use DPI.

Not saying Comcast definitely doesn't use it; rather, that it'd be hilarious to see Comcast lie to everyone's faces yet again.

Of course, to distinguish HTTP traffic from non-HTTP traffic and to intelligently insert the code snippet only where it won't disrupt e.g. API call response or a file download, some basic level of DPI is required.

You don't re-wrap. You just downgrade to HTTP.

This is why TLS1.3 and HSTS exists.

Do you have a link to anything on this? I'm still not clear on how to MITM a TLS transmission sans CA cert.

The attacker needs to generate a new cert that the client trusts. This is easy on a corporate network where you can force users to trust a private CA. Unlikely to happen with a US ISP, but possible if someone hacks the CA (eg DigiNotar) or the CA hands out unconstrained certificates to someone who acts badly (eg CNNIC).

Speaking of which, is there a published list of Root CA fingerprints a specific version of OS or browser is supposed to have that I can compare to? In other words, how can one tell if their browser/OS is not compromised with undesirable Root CAs.

Mozilla and Microsoft publish their lists. Chrome uses the OS's root store. I've seen other open source software use Mozilla's list, but I've never seen a list of what software does that.

https://wiki.mozilla.org/CA/Included_Certificates https://docs.microsoft.com/en-us/security/trusted-root/parti...

What you are describing doesn't seem to be a MITM attack on https traffic, but something else, which is why I stated "sans CA cert".

They're describing what would be required to MITM HTTPS traffic. You're correct that they essentially need to get the cert.

Without a root CA? And without showing up in certificate transparency logs?

Good luck :)

No.