Comcast's "free" wi-fi hotspots are only usable to Comcast customers.
They are not open to everyone. They are free to already paying
customers. If you have not previously connected to an "xfinitywifi"
hotspot before, you will be asked your Comcast login credentials. The
communication is encrypted and the homeowner with the wifi cable modem
cannot see that traffic. The "attwifi" must not be asking for login
credentials to prove you are a customer of theirs to use their network.
For xfinitywifi, you need their app on your phone. When you login the
first time, the app records the login credentials to reuse at other
xfinitywifi hotspots. So that you automatically connect to another
xfinitywifi hotspot means your login credentials encrypted and sent to
Comcast are still valid.
The author of the article never did test an xfinitywifi hotspot. He
based his assumptions on hot attwifi works. Even if they both worked
the same, why aren't you using HTTPS? Someone operating an bogus
attwifi or infinitywifi hotspot still cannot interrogate your encrypted
web traffic because their hotspot is not either of the endpoints (your
client and the site to which you connect) in a connection to an HTTPS
web site. The first and subsequent automatic logins to Comcast are via
HTTPS. Again, the author only made guesses, not actual tests. After
all, when you are home using wired Ethernet to connect to a web site,
there are lots of nodes (hops) in the route between you and the target
site that are not on your ISPs network. If the author thinks a hotspot
is going to steal your login credentials, why couldn't ANY node in the
route between you and any site also steal your login credentials. Hence
the purpose of HTTPS.
The man-in-the-middle attacks the author speaks of must be using HTTP so
the attacker can intercept and actually interpret the non-encrypted web
traffic. For HTTPS, the attacker won't have the site's cert. If the
HTTPS connect results in a warning in your web browser, you cannot be
sure you connected to where you thought you connected.
http://tools.kali.org/information-gathering/sslsplit
"SSLsplit is a tool for man-in-the-middle attacks against SSL/TLS
encrypted network connections. Connections are transparently intercepted
through a network address translation engine and redirected to SSLsplit.
SSLsplit terminates SSL/TLS and initiates a new SSL/TLS connection to
the original destination address, while logging all data transmitted."
Except the attacker's host where they run SSLsplit won't have the target
site's certificate. They do attempt to forge a fake certificate based
on the details of the site's certificate. But that isn't unique to
wifi. ANY host in the route between your end and the target site could
do that. It's not a wi-fi specific attack vector. From an article at:
https://blog.heckel.xyz/2013/08/04/use-sslsplit-to-transparently-sniff-tls-ssl-connections/,
the attacker must have the private key of a CA (certificate authority).
Well, how did they get that? Alas, there are CAs that should never have
been granted permission to operate as a CA. The article mentions the
user must have the attacker's root cert in the user's own cert store
(which is either the OS global cert store or a private store such as the
one that Firefox uses). How did the attacker's root cert get into the
user's local cert store? Malware. Companies do this MITM scheme all
the time so they can monitor HTTPS traffic generated by their employees
(who are supposed to be working, not downloading porn or leaking trade
secrets) by putting the company's root cert in the image they put on
their workstations that their employees use.
That the Internet does not guarantee the nodes between you and the
target host are all trusted (and repeatedly verified as such), there are
dangers in doing anything in the Internet. A VPN might provide better
protection since the tunnelling is supposed to be secure between
endpoints no matter what nodes are in the route. I haven't investigate
VPNs to see if that premise is correct.
Users worry so much about protecting their web traffic and yet they lock
their house with doors having easily punched-out windows that grants an
attacker access to the inside turn knob on the deadbolt, and they lots
of knockouts (aka windows) in their house to grant forced entry. HTTPS
and VPNs add security levels. They don't guarantee 100% secure
communication, just highly likely secure communication.
Did you use HTTPS to make the connection to the web site where you made
a purchase? Doesn't matter whether you use wi-fi or Ethernet. You
should be using HTTPS. VPNs are nice but only if you are afraid of
having someone seeing to where you connect. They do further encrypt the
web traffic but HTTPS should be fine.
play.google.com is a HTTPS site.
Best would be to check with your credit card issuer if they have a safe
card scheme. This lets you create temporary credit card numbers
(assigned onto your real credit card number) where you can specify the
maximum amount that can be charged and how long the temporary number
will survive (its expiration month/year). No one can charge more than
that and after its expiration (usually 2 months is the minimum) no one
can make any charge to that card number. After you use that card
number, and after you are sure the transaction has been completed, you
can even delete that card number so it cannot be used again. Bank of
America calls it ShopSafe.
Tis humorous that folks are so worried about their credit card numbers
when making Internet purchases and yet they gladly hand over their
credit card to some low-wage flunky at a restaurant who disappears from
the table to charge the card. They call Comcast for tech support who
asks for the account number, last 4 digits of the user's social security
number, telephone number, postal address and other customer validation
information. So why couldn't their phone line be tapped, or their
outbound call be intercepted or redirected elsewhere to someone
pretending to be Comcast?