CTO material right there.

Deep packet inspection by definition requires the ability to see inside the packet, which if using HTTPS wouldn’t be possible for your ISP.

They can still see the destination IP, return IP, and port number, but that’s it. It would take a ton of storage to log all of that packet data though, and it’d be difficult to come up with a way not to double count it if it’s going through multiple hops on the ISP network.

Logging DNS requests on the DNS server would be a much easier way of collecting that data if they wanted it. I know cloudflare collects aggregate DNS query data through their public DNS server, and Google likely does too.

I’m familiar. Other than key exchange for encrypted connections, the whole point of HTTPS/TLS is establishing who you’re connecting with is who they say they are and preventing man in the middle attacks just like you described.

If your traffic was being intercepted by something like Zscaler it wouldn’t be able to provide the proper signed certificate of that web address and your browser would throw a mismatch error. IT departments using such intermediaries for https traffic inspection only get around this by installing the intermediaries’ root CA on your system so it’s not flagged by your browser or whatever you’re using for TLS traffic.

The only way someone could intercept your TLS traffic and then pass it onto you without you knowing is by having that website’s private key to sign the traffic with, which is a major security breach. As soon as something like that is discovered the certificate is revoked and a new one is issued with a different private key.

So, again, that’s just not how TLS works.

https://en.m.wikipedia.org/wiki/Public_key_infrastructure

Yup. An ISP could potentially gain some information based on the IPs you’re hitting and the number/frequency of packets sent and received, but that would take serious logging and analysis on their part. It’s much easier to collect data through DNS requests.

Yeah… that’s not how TLS works.