HTTPS interception (a “TLS-inspecting” or “Man in the Middle” proxy) allows a network administrator to intercept and decrypt HTTPS traffic between a local network user and the secure HTTPS sites visited on the wider Internet. It does this by using a “Man in the Middle” security certificate on the local server. In short, when a user visits usbank.com, its request is first processed on the local network where it is decrypted with the local network certificate and inspected. Then the request is encrypted with US Bank’s certificate and sent to US Bank. When the response comes back, it decrypts the response, inspects it, re-encrypts it with the local certificate, and sends it to the user. The process is all transparent to the user who is typically unaware that their otherwise securely encrypted Internet traffic is being intercepted en route.
This has legitimate purposes, for instance in schools where IT staff are required to limit access to prohibited sites. But it could also be used on a public Wi-Fi network to intercept a user’s login credentials for sites they visit. For HTTPS Interception to work without browser warnings, the CA has to be installed on your machine, so on a guest network you’d normally see certificate errors rather than silent interception. Here are ways to check to see if the network you’re on is using HTTPS Interception.
1. Look at the certificate issuer in your browser
Visit a site like https://www.google.com or https://github.com, click the padlock, and view the certificate. Check the Issuer. For Google it should be something like “Google Trust Services (WR2)”; for GitHub, “Sectigo” or “DigiCert”. If you see a firewall vendor (Fortinet, Palo Alto, Cisco Umbrella, Zscaler, Sophos, etc.), or something generic like “Gateway CA,” you’re being intercepted.
2. Use a pinning-style check site
Grc.com’s “HTTPS Fingerprints” page (https://www.grc.com/fingerprints.htm) shows the fingerprints it sees for a given site from its own perspective, so you can compare them to what your browser shows. Of course, if the network is intercepting, it could also intercept that page, so the command-line comparison against a trusted network is stronger.
3. Compare fingerprints against a network you trust
Fingerprints are the most reliable check because the issuer name can be spoofed but the fingerprint of a real certificate can’t.
On the local Wi-Fi network:
bash
openssl s_client -connect www.google.com:443 -servername www.google.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -fingerprint -sha256Then run the same command from a trusted network (home, or a smartphone) and compare. Different fingerprints mean something in the middle is re-signing. Note that big sites like Google can legitimately serve different certs from different edge servers, so repeat on a couple of sites, or compare the issuer chain too. Better still, use a site you control, where the cert should be identical everywhere.
PowerShell alternative on Windows:
powershell
$tcp = New-Object Net.Sockets.TcpClient("www.google.com",443)
$ssl = New-Object Net.Security.SslStream($tcp.GetStream())
$ssl.AuthenticateAsClient("www.google.com")
$ssl.RemoteCertificate | Format-List Issuer,Subject4. Check your system’s trusted root CAs
If the public Wi-Fi had you install a “certificate” or “profile” to use the WiFi, that’s the giveaway. Look for unfamiliar root CAs:
- Windows:
certmgr.msc→ Trusted Root Certification Authorities - macOS: Keychain Access → System / System Roots
- Linux:
/etc/ssl/certsor/usr/local/share/ca-certificates
If you never installed anything, interception of most sites would show up as browser warnings (NET::ERR_CERT_AUTHORITY_INVALID), so no warnings is a good sign.
5. Things that point to interception
- Certificate errors on many sites at once
- A captive portal asking you to download/install a cert or app
- Sites with HSTS or certificate pinning (banking apps, some Google/Microsoft services) failing while others work, because those resist interception