Here's what I wrote last time this was posted (<a href="https://news.ycombinator.com/item?id=8457167" rel="nofollow">https://news.ycombinator.com/item?id=8457167</a>), with some edits to respond to other comments made in this thread:<p>An interesting read, but sparse enough on details to be basically useless. Additionally, there's nothing that I can discern to be new here. The following is demonstrated, all of which are known (and in fact obvious) to people with even an elementary understanding of how wifi and TLS work:<p>* That wifi probes are public<p>* That wifi devices, by default, expose reasonably reliable evidence about their type and origin via their MAC address<p>* That many OS's automatically connect to 'trusted' wifi networks, regardless of their apparent physical location<p>* That many websites don't have TLS by default (or at all)<p>* That, if a user connects to a network you control and requests a URL not beginning with "https," it is trivial to present them with a fake page looking like the one to which they thought they were browsing (of course they won't see a lock) --(note: if the website has HTTP Strict Transport Security enabled and the user has previous visited that website with a supporting browser, then this part is non-trivial)<p>* That, if a user transmits unencrypted plain text over a wifi network to which you have access, it's trivial to glean the content of their transmission.<p>None of this is news, and it's all that this article seems to point out. Even more bizarre is that, almost without exception, it merely leaves these items implied, failing to describe the mechanism of action.
How was the hacker able to get Facebook credentials? Facebook uses HTTPS and so does Live.com. Even if I'm connected to a malicious router, only me and Facebook know about the data we're sending each other.<p>Am I missing something or should the author of this article provide more evidence on the type of attack?
Most people don't understand the WPA PSK security model and its insufficiency for anything but private networks where every device is trusted. When you give someone the PSK, you give them the capability to impersonate the access point.<p>That being said, is there any better solution for public networks? One where giving someone a password doesn't let them impersonate you. I'm not sure how good support for EAP-TLS is on common client devices. To actually make it secure the device would not only need to support it but also validate the AP's public key some way.
Interesting but dated info for techies. I was hoping for something more along the lines of how retailers triangulate & track your movements inside their brick & mortar sites. Or how public providers scrape your browsing habits whilst on their net. I was even more interested in learning what other tricks they employ that I am not yet aware of.<p>With the ubiquity of broadband mobile I recommend avoiding public wifi whenever possible because the items listed in TFA are ubiquitous at most Starbucks, airports and other hi-profile public spots. I also highly recommend disabling any equipments' wifi by default, the world is full of liars, cheats & thieves smarter than myself. When you go for "free", what you get never is.
Hm. So are there any 802.11_ proposals for cryptographically "signed" SSIDs? Using public key cryptography, this is surely doable in a way that is "anonymous" too, right? (i.e. doesn't reveal the identity of the AP you're probing for)
Login into a public WiFi and turn on your VPN. Problem solved.<p>VPN accounts are cheaper than ever before. You can also install one on a cheap DO box.
I see a lot of comments here presenting HSTS as some kind of silver bullet for preventing MITM attacks. While it does help, it's not impenetrable. If a website hasn't been preloaded into the STS preloaded list, then the HSTS header can be stripped on the first visit and the client will never upgrade to SSL.<p>The only foolproof way to make sure you're not being MITMd is to visually verify that the domain checks out and that you are indeed connected using SSL.
Don't like your MAC? get a new one...<p>import random<p>import os<p>mac=''<p># os.system('/etc/init.d/networking stop')<p>os.system('ifconfig wlan1 down')<p>os.system('ifconfig eth1 down')<p>for i in range(0,3):<p>r=random.randint(16, 256)<p>mac=mac+":"+str(hex(r))[2:]<p>mac="00:07:E9"+mac<p>print mac<p>os.system('ifconfig wlan1 hw ether '+mac)<p>os.system('ifconfig eth1 hw ether '+mac)<p>os.system('ifconfig wlan1 up')<p>os.system('ifconfig eth1 up')<p># os.system('/etc/init.d/networking stop')<p>os.system('/etc/init.d/networking start')<p>os.system('ifconfig')<p>print "echo 'MAC changed..."<p>print "new random MAC "+mac
I've read about this kind of thing before, so when I'm in public, or even at school I prefer to fire up my phone's personal hotspot instead of using any public wifi available.
why aren't 'know networks' gps-geofenced on smartphones? You have GPS, if your previous 'known network' (say, home) was in location X, it should not automatically connect (or even <i>try</i> to connect) to it at X + 20 miles.<p>This way you should be able to keep your phone from connecting automatically to (or even looking for) a network that shouldn't be there in that location in the first place, and if you always tether to it it would work for your laptop too...
I wonder if it's true that iOS 8 only randomizes device's MAC when the SIM cart is not installed[0]. Was stoked to learn about this feature, too bad it apparently doesn't work as you'd expect it to.<p>[0] <a href="http://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/" rel="nofollow">http://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac...</a>