Re: What do you consider acceptable packet / session modification for a network operator?
Glad everyone agrees ISPs should not be doing this! Most of these things are currently being done by a US national wireless ISP to their ~100M customers. I’m sure you can guess who it is, there are only 3 choices. I spent an afternoon hand-crafting packets on their network to a remote cloud VPS to try to understand wtf their network is doing. I did all of this over IPv6 to avoid CGNAT. The first clue to me is that a ‘what is my IP’ website does not report the same IPv6 as the device. Obviously we should never be using NAT in IPv6, so clearly this ISP is doing something suspicious, and the ‘what is my IP’ IPv6 ends in ::8 which is also suspiciously manually generated. I eventually concluded that all traffic with a TCP or UDP destination port of 443 was being NATed via this ::8 address, while a random high numbered destination port was coming from the device’s IPv6 as expected. I drilled down into the behavior of this port 443 proxy and concluded: - The proxy responds to all TCP SYNs with a SYN ACK and establishes a connection - After the connection is established, it will then dial the remote side, so if I never send the ACK it will never dial the remote side - If the remote side rejects the connection, the proxy will ‘eat’ all of the bytes which have already been sent and then close the connection without any error on the client side - The proxy will still pass arbitrary bytes after the connection is established, even if they are not TLS traffic, it also does not appear to impact TLS traffic in any way that I could detect - The proxy re-negotiates all of the TCP options, so setting MSS manually on either side does not get passed through. Congestion control will also be impacted by this. The proxy seems to choose 1370 as its preferred MSS on both sides. I cannot understand a legitimate use case for an ISP to run such a proxy on port 443, and the resources required to proxy essentially all of the TLS traffic for 100M customers must be enormous. I then tried to scan all ports with TCP SYNs to see if any proxy responded with a SYN ACK, but hit some sort of rate limit on new connections and got unreliable responses (this could have been in my handset, which is acting as a hotspot). I limited my search to the first 1024 ports and found similar behavior on ports 21, 80, 443, and 554. All four proxies each have their own public IP, and it is different for each (so ‘what is my ip’ on port 80 is different than on 443). Digging in to the port 80 proxy, when connecting over HTTP to any destiatnation on port 80, the proxy adds a ‘Via:’ header to the HTTP request. This includes a seemingly random but never changing ID which is formatted as a DNS name, although the specific subdomain does not exist. I suspect this is a unique identifier which identifies me as a subscriber uniquely for advertising purposes. It's also found that sending a valid HTTP response with an invalid HTTP status code number will cause the proxy to return an HTML page which says 503 Service Unavailable. I was not able to detect any modification of data, but again I have no idea if it may be modifying only certain sites / … Again, this is not my network, I am trying to understand why a network operator would interfere with their users in this way. Andrew
On Fri, Dec 26, 2025 at 1:03 AM Andrew via NANOG <nanog@lists.nanog.org> wrote:
Glad everyone agrees ISPs should not be doing this!
😂
Most of these things are currently being done by a US national wireless ISP to their ~100M customers. I’m sure you can guess who it is, there are only 3 choices.
Only at&t does this IPv6 address change, no ?
I spent an afternoon hand-crafting packets on their network to a remote cloud VPS to try to understand wtf their network is doing. I did all of this over IPv6 to avoid CGNAT.
Many have already done this research But at&t laid out a version of their plan here https://www.theregister.com/2014/02/24/saving_private_spying_cryptobusting_p... https://datatracker.ietf.org/doc/html/draft-loreto-httpbis-trusted-proxy20-0...
The first clue to me is that a ‘what is my IP’ website does not report the same IPv6 as the device. Obviously we should never be using NAT in IPv6, so clearly this ISP is doing something suspicious, and the ‘what is my IP’ IPv6 ends in ::8 which is also suspiciously manually generated. I eventually concluded that all traffic with a TCP or UDP destination port of 443 was being NATed via this ::8 address, while a random high numbered destination port was coming from the device’s IPv6 as expected.
I drilled down into the behavior of this port 443 proxy and concluded: - The proxy responds to all TCP SYNs with a SYN ACK and establishes a connection - After the connection is established, it will then dial the remote side, so if I never send the ACK it will never dial the remote side - If the remote side rejects the connection, the proxy will ‘eat’ all of the bytes which have already been sent and then close the connection without any error on the client side - The proxy will still pass arbitrary bytes after the connection is established, even if they are not TLS traffic, it also does not appear to impact TLS traffic in any way that I could detect - The proxy re-negotiates all of the TCP options, so setting MSS manually on either side does not get passed through. Congestion control will also be impacted by this. The proxy seems to choose 1370 as its preferred MSS on both sides.
I cannot understand a legitimate use case for an ISP to run such a proxy on port 443, and the resources required to proxy essentially all of the TLS traffic for 100M customers must be enormous.
I then tried to scan all ports with TCP SYNs to see if any proxy responded with a SYN ACK, but hit some sort of rate limit on new connections and got unreliable responses (this could have been in my handset, which is acting as a hotspot). I limited my search to the first 1024 ports and found similar behavior on ports 21, 80, 443, and 554. All four proxies each have their own public IP, and it is different for each (so ‘what is my ip’ on port 80 is different than on 443).
Digging in to the port 80 proxy, when connecting over HTTP to any destiatnation on port 80, the proxy adds a ‘Via:’ header to the HTTP request. This includes a seemingly random but never changing ID which is formatted as a DNS name, although the specific subdomain does not exist. I suspect this is a unique identifier which identifies me as a subscriber uniquely for advertising purposes. It's also found that sending a valid HTTP response with an invalid HTTP status code number will cause the proxy to return an HTML page which says 503 Service Unavailable. I was not able to detect any modification of data, but again I have no idea if it may be modifying only certain sites / …
Again, this is not my network, I am trying to understand why a network operator would interfere with their users in this way.
Andrew _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4GGYOTKH...
participants (2)
-
Andrew -
Ca By