ISP网站封禁方式解析及HTTPS下伪造301 redirect可行性问询

Hey there! Let's break down your questions about ISP blocking methods and whether ISPs can forge 301 redirects over HTTPS.

Additional ISP Blocking Methods You Might Not Know About #

Beyond DNS tampering, fake HTTP 301s, and forged RST packets for HTTPS, ISPs use several other tactics:

• SNI-Based DPI Blocking: Even with HTTPS, the Server Name Indication (SNI) field in the TLS handshake is sent in plaintext. ISPs can use Deep Packet Inspection (DPI) to read this field, identify the target domain, and drop or block the connection before it completes.
• IP Address Blacklisting: ISPs maintain lists of IP addresses associated with restricted sites. Any traffic to these IPs is either dropped entirely or returns an ICMP "destination unreachable" error, regardless of the protocol used.
• Certificate Hijacking (MITM for HTTPS): If an ISP can get a user's device to trust their self-signed root certificate, they can act as a man-in-the-middle. They decrypt HTTPS traffic, inspect its content, and either block it outright or modify it before re-encrypting and sending it to the user.
• Bandwidth Throttling: Instead of full blocking, ISPs may intentionally slow down traffic to specific sites (like streaming platforms or P2P services) to make them unusable. This is often done by prioritizing other traffic types over the restricted ones.
• Port Blocking: ISPs can block non-standard ports commonly used by alternative services. For example, blocking port 8443 (a common alternative HTTPS port) would prevent access to sites using it, even if the main HTTPS port 443 is open.
• Session Resetting for Established Connections: Beyond sending forged RST packets during connection setup, some ISPs monitor active HTTPS sessions and inject RST packets to terminate them abruptly, disrupting ongoing access.

Can ISPs Forge 301 Redirects Over HTTPS? #

The short answer: Only if they perform a man-in-the-middle (MITM) attack using certificate hijacking. Here's why and how:

Why Standard HTTPS Prevents Fake 301s #

HTTPS encrypts the entire HTTP payload (including status codes like 301 and redirect URLs) using TLS. If an ISP tries to modify the encrypted response without the proper keys, the browser will detect a mismatch in the message authentication code (MAC) and throw a security error (e.g., "Your connection is not private"). Users won't be redirected—they'll see a warning page instead.

How Certificate Hijacking Makes Fake 301s Possible #

If an ISP can get your device to trust their root certificate (often done via forced installation, network prompts, or exploiting unpatched devices), they can intercept and modify HTTPS traffic:

1. Intercept the User's Request: When you send an HTTPS request to a restricted site, the ISP captures the TLS handshake before it reaches the target server.
2. Establish MITM Connections: The ISP uses its own forged certificate (matching the target domain) to create a secure connection with your browser. At the same time, it creates a separate secure connection with the real target server using the server's legitimate certificate.
3. Modify the Response: The ISP receives the real HTTPS response from the target server, decrypts it, changes the status code to 301, and updates the redirect URL to point to their blocking page.
4. Re-Encrypt and Send to User: The ISP re-encrypts the modified response using its forged certificate and sends it to your browser. Since your device trusts the ISP's root certificate, the browser accepts the response as valid and follows the fake 301 redirect to the blocking page.

It's worth noting that modern browsers are increasingly strict about untrusted certificates, so this method only works if the user has explicitly trusted the ISP's certificate or if the device is configured to do so (common in some corporate or restricted network environments).

内容的提问来源于stack exchange，提问作者Johhn d0ee