AT&T mobile intercepting TCP sockets?
I ran into an odd issue with access to a website I manage from AT&T mobile devices this weekend. The website worked for everybody not on AT&T mobile, and AT&T mobile users could access other sites; the problem was just this combination. Android and iOS phones, as well as a Linux system tethered to an Android phone, all had the same problem. On the Linux system, I disabled IPv6 in Firefox, and it could then connect. Browsers got various "connection reset" type errors; on Linux, I could telnet to port 80 or 443, and it would connect and immediately close. The site does have an IPv6 address, but I had missed getting the webserver to listen on IPv6 (my mistake). Adding that looks to have solved the problem. When I ran tcpdump on the server and had someone try to connect from their AT&T mobile iPhone, I saw three connection attempts a few tenths of a second apart (all refused by the server). My question is this: is AT&T mobile intercepting the TCP socket (and not handling "connection refused" correctly)? Is that a known thing? -- Chris Adams <cma@cmadams.net>
On May 21, 2018, at 3:35 PM, Chris Adams <cma@cmadams.net> wrote:
I ran into an odd issue with access to a website I manage from AT&T mobile devices this weekend. The website worked for everybody not on AT&T mobile, and AT&T mobile users could access other sites; the problem was just this combination.
Android and iOS phones, as well as a Linux system tethered to an Android phone, all had the same problem. On the Linux system, I disabled IPv6 in Firefox, and it could then connect. Browsers got various "connection reset" type errors; on Linux, I could telnet to port 80 or 443, and it would connect and immediately close.
The site does have an IPv6 address, but I had missed getting the webserver to listen on IPv6 (my mistake). Adding that looks to have solved the problem.
When I ran tcpdump on the server and had someone try to connect from their AT&T mobile iPhone, I saw three connection attempts a few tenths of a second apart (all refused by the server).
My question is this: is AT&T mobile intercepting the TCP socket (and not handling "connection refused" correctly)? Is that a known thing?
Yes they are. You can see this in test-ipv6.com it will report the proxy/Via Header addition. - jared
IME ATT has intercepted virtually everything on mobile (this is on a hotspot) - If I curl a HTTP vs HTTPS site, I get a different IP on each (one is obviously a shared web proxy); if I download images, they won't match md5-wise with the original version, etc. I have trouble connecting to VPNs that aren't standard SSL VPNs. They appear to MITM all web traffic they can. Using third party DNS servers has questionable results. On Mon, May 21, 2018, at 12:35 PM, Chris Adams wrote:
I ran into an odd issue with access to a website I manage from AT&T mobile devices this weekend. The website worked for everybody not on AT&T mobile, and AT&T mobile users could access other sites; the problem was just this combination.
Android and iOS phones, as well as a Linux system tethered to an Android phone, all had the same problem. On the Linux system, I disabled IPv6 in Firefox, and it could then connect. Browsers got various "connection reset" type errors; on Linux, I could telnet to port 80 or 443, and it would connect and immediately close.
The site does have an IPv6 address, but I had missed getting the webserver to listen on IPv6 (my mistake). Adding that looks to have solved the problem.
When I ran tcpdump on the server and had someone try to connect from their AT&T mobile iPhone, I saw three connection attempts a few tenths of a second apart (all refused by the server).
My question is this: is AT&T mobile intercepting the TCP socket (and not handling "connection refused" correctly)? Is that a known thing?
-- Chris Adams <cma@cmadams.net>
On Mon, May 21, 2018 at 1:11 PM <lists@as23738.net> wrote:
IME ATT has intercepted virtually everything on mobile (this is on a hotspot) -
If I curl a HTTP vs HTTPS site, I get a different IP on each (one is obviously a shared web proxy); if I download images, they won't match md5-wise with the original version, etc. I have trouble connecting to VPNs that aren't standard SSL VPNs. They appear to MITM all web traffic they can. Using third party DNS servers has questionable results.
AT&Fee is also a key player in undermining http2 security with their “trusted proxy” https://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01
On Mon, May 21, 2018, at 12:35 PM, Chris Adams wrote:
I ran into an odd issue with access to a website I manage from AT&T mobile devices this weekend. The website worked for everybody not on AT&T mobile, and AT&T mobile users could access other sites; the problem was just this combination.
Android and iOS phones, as well as a Linux system tethered to an Android phone, all had the same problem. On the Linux system, I disabled IPv6 in Firefox, and it could then connect. Browsers got various "connection reset" type errors; on Linux, I could telnet to port 80 or 443, and it would connect and immediately close.
The site does have an IPv6 address, but I had missed getting the webserver to listen on IPv6 (my mistake). Adding that looks to have solved the problem.
When I ran tcpdump on the server and had someone try to connect from their AT&T mobile iPhone, I saw three connection attempts a few tenths of a second apart (all refused by the server).
My question is this: is AT&T mobile intercepting the TCP socket (and not handling "connection refused" correctly)? Is that a known thing?
-- Chris Adams <cma@cmadams.net>
Oh, I'm sure that'll never be abused by any hostile nation-state-owned monopoly telecom that likes to block/ban/MITM traffic, ever! On Mon, May 21, 2018 at 1:53 PM, Ca By <cb.list6@gmail.com> wrote:
On Mon, May 21, 2018 at 1:11 PM <lists@as23738.net> wrote:
IME ATT has intercepted virtually everything on mobile (this is on a hotspot) -
If I curl a HTTP vs HTTPS site, I get a different IP on each (one is obviously a shared web proxy); if I download images, they won't match md5-wise with the original version, etc. I have trouble connecting to VPNs that aren't standard SSL VPNs. They appear to MITM all web traffic they can. Using third party DNS servers has questionable results.
AT&Fee is also a key player in undermining http2 security with their “trusted proxy”
https://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01
On Mon, May 21, 2018, at 12:35 PM, Chris Adams wrote:
I ran into an odd issue with access to a website I manage from AT&T mobile devices this weekend. The website worked for everybody not on AT&T mobile, and AT&T mobile users could access other sites; the
problem
was just this combination.
Android and iOS phones, as well as a Linux system tethered to an Android phone, all had the same problem. On the Linux system, I disabled IPv6 in Firefox, and it could then connect. Browsers got various "connection reset" type errors; on Linux, I could telnet to port 80 or 443, and it would connect and immediately close.
The site does have an IPv6 address, but I had missed getting the webserver to listen on IPv6 (my mistake). Adding that looks to have solved the problem.
When I ran tcpdump on the server and had someone try to connect from their AT&T mobile iPhone, I saw three connection attempts a few tenths of a second apart (all refused by the server).
My question is this: is AT&T mobile intercepting the TCP socket (and not handling "connection refused" correctly)? Is that a known thing?
-- Chris Adams <cma@cmadams.net>
The short answer is, yes. This is a strong argument in favor of three things: a) Redirect all http trafifc on webservers you control to https , such as the following apache2 configuration file snippet for a virtualhost RewriteEngine on RewriteCond %{SERVER_NAME} =domainname.com [OR] RewriteCond %{SERVER_NAME} =www.domainname.com RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent] b) Force TLS1.2 on all connections, the population of web browsers that do not understand TLS1.2 is now less than 1% by market share. c) Use HTTPS strict transport security On Mon, May 21, 2018 at 12:35 PM, Chris Adams <cma@cmadams.net> wrote:
I ran into an odd issue with access to a website I manage from AT&T mobile devices this weekend. The website worked for everybody not on AT&T mobile, and AT&T mobile users could access other sites; the problem was just this combination.
Android and iOS phones, as well as a Linux system tethered to an Android phone, all had the same problem. On the Linux system, I disabled IPv6 in Firefox, and it could then connect. Browsers got various "connection reset" type errors; on Linux, I could telnet to port 80 or 443, and it would connect and immediately close.
The site does have an IPv6 address, but I had missed getting the webserver to listen on IPv6 (my mistake). Adding that looks to have solved the problem.
When I ran tcpdump on the server and had someone try to connect from their AT&T mobile iPhone, I saw three connection attempts a few tenths of a second apart (all refused by the server).
My question is this: is AT&T mobile intercepting the TCP socket (and not handling "connection refused" correctly)? Is that a known thing?
-- Chris Adams <cma@cmadams.net>
participants (5)
-
Ca By -
Chris Adams -
Eric Kuhnke -
Jared Mauch -
lists＠as23738.net