|
|
|
|
|
by tsimionescu
2005 days ago
|
|
ISPs can't deeply inspect TLS traffic. Employers of course can, because they can insert their own trusted certificates on their own boxes. Now, if by 'inspect' or MITM in this case you are talking about inspecting the TLS headers, that's possible, and based on the other comments it is exactly what this ISP was doing - checking the SNI of the TLS requests and blocking based on those. But an ISP that hasn't somehow broken TLS isn't in a position to check the encrypted contents of your packets (e.g. HTTP headers, bodies etc). Your employer can very well have installed a TLS MITM device that is trusted by your company-issued device to actually inspect the contents of your encrypted packets (by acting as a proxy - you actually have a TLS tunnel with the MITM device, and it has a separate tunnel with the TLS server). Certificate pinning can block even these types of employer MITM inspection, and it can also protect from rogue CAs issuing ilicit certs. But if your ISP is in possession of PKI certs for google.com and outlook.com, then the CA that issued them will soon be removed from the trusted list. |
|
The device does not always need to have a special trust relationship with the client browser, since a trust relationship can already exist with FTU.