AT&T mobile intercepting TCP sockets?

Mon May 21 20:50:51 UTC 2018

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 at 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 at cmadams.net>
>