On Fri, Dec 26, 2025 at 1:03 AM Andrew via NANOG <[email protected]> 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_proxy_proposal_surfaces_at_ietf/ https://datatracker.ietf.org/doc/html/draft-loreto-httpbis-trusted-proxy20-01 > > 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/[email protected]/message/4GGYOTKHLHEJEIRWN32GEWL7EKSN7OBH/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/MAAQJJMUSGZ2OC6VZZI7T2A5DQSGAMLS/
