Slashdot Mirror
Sophos Researcher Suggests Password 'Free' to Spur Wi-Fi Encryption
An anonymous reader writes "In the wake of concerns about FireSheep sniffing credentials from people using unencrypted public WiFi hotspots, a security researcher has proposed that the problem does not just lie with big websites like Facebook, but also with those who provide free wireless internet access. Chet Wisniewski, a researcher at security firm Sophos, proposes that all free WiFi hotspots should be encrypted — with the password 'free.' ''I propose standard adoption of WPA2 and a default password of "free." Whenever you wish to connect to complimentary WiFi, you select "Courtyard Marriott" or "Starbucks" like you always have, but you are then prompted for a password. Just type "free". It's not hard. In fact, operating system vendors could even program your PC to automatically try the password "free" before prompting you for a password on the assumption that you might be selecting a free service.'"
... just keep in mind that with WPA, the initial password is just used for connecting to the network, after which a session password is shared (right? pretty sure I'm right about that). So, technically, it would prevent someone from stealing your interwebs as long as you were already connected. Now, the guy who got to Starbucks before you and started sniffing before you did, he definitely has your personal information now, and this is a stupid idea.
Maybe he hasn't noticed that wireshark can decrypt WPA2 traffic so long as the network is being sniffed when the client originally connects.
I don't like the sound of "standard default password." That's just asking for all sorts of trouble. How about changing the SSID to something like, "Starbux Network Password: freenet" This way the password is available without having to post signs, etc., and you don't have to worry about involving default passwords of any sort. However, this is still a band-aid over the real problem. Facebook and the like should just get on the ball and enforce TLS.
"`Ford, you're turning into a penguin. Stop it.'" -Douglas Adams, THHGTTG
... is 8 characters.
That's not entirely true. WPA2 will prevent Firesheep from working provided the WPA2 traffic isn't being decrypted.
"`Ford, you're turning into a penguin. Stop it.'" -Douglas Adams, THHGTTG
One important caveat: this would be useless if the access point is using WEP, which uses the same key to encrypt each client's traffic. It would be trivial to modify Firesheep or any other tool to be able to overcome this. My understating is that WPA is somewhat better since it uses the pre-shared key + a per-session key, though that per-session key could still be sniffed if the attacker captured the handshake when the target first connects. So neither option is secure but WEP would just be snake oil and little better than clear-text.
No.
I'm not familiar with firesheep in particular, but wouldn't the OS be decrypting the traffic for you (since you are connected to the network) and then firesheep simply captures it? or does firesheep work on a lower layer, bypassing that part of the OS's networking?
capitals matter. and don't WPA2 phrases have to be at least 8 characters?
That a security research doesn't know better than this. Encryption with a PSK is useless as far as sidejacking is concerned. There is no decent client to client encryption unless you use WPA/2 Enterprise.
To suggest otherwise is bullshit, and he should be blaming the websites who are the problem.
If you ignore ACs because they are anonymous - you're an idiot.
In English punctuation is supposed to go before closing quotation marks, so it is never "free", but instead "free." Now granted that's completely stupid, but it is correct English and the sensible thing you are advocating is incorrect English.
Except when you're signifying an explicit string that will need to be readable by a computer. I would tend to err on the side of caution lest someone mistake my correct English punctuation for some sort of design intent.
My SSID at home advertises the WPA2 key, that is my SSID is keyissomestring . Im happy to share my bandwidth, but I don't want to share my data.
-- Experience is a wonderful thing. It enables you to recognize a mistake when you make it again.
Uhmm, maybe Sophos should invest in security training of their staff before they start selling supposed security products.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
I'm afraid it is not that simple. You should always be wary of assuming that the rules used in your locality are universal. There are two styles in general use regarding punctuation and quotation marks. See the wikipedia entry on the subject:
In the U.S., the standard style is called American style, typesetters' rules, printers' rules, typographical usage, or traditional punctuation, whereby commas and periods are almost always placed inside closing quotation marks. This style of punctuation is common in the U.S., Canada, and in the U.K. in fiction and journalism.
The other standard style--called British style or logical punctuation--is to include within quotation marks only those punctuation marks that appeared in the quoted material, but otherwise to place punctuation outside the closing quotation marks.
Using the British style is less ambiguous in this case.
Watch out! I tried typed in "Free" instead of of "free" like the Sophos Dude recommends and it wiped out all my time machine backups.
Well, at least that's what happened after I hard crashed my computer in the middle of a back up. But I'm sure it was sophos to blame.
Some drink at the fountain of knowledge. Others just gargle.
Yes it does. Although you start out your session by connecting to the network with one password for everyone, your computer then negotiates an individual password for your connection to the wireless router. This means that you cannot see other people's traffic.
Me too. Isn't this an example of a "mesh network", a la OLPC?
"Tongue tied and twisted, just an Earth bound misfit
The logical extension of this is that for paid wifi, we can always use the password "paid" right?
There's no -1 for "I don't get it."
And the 'Free' in the title as well.
If I have nothing to hide, don't search me
I quite like the idea of the password being the SSID name rather than 'free'. I think it's easier to adhere to (don't need to worry about capitalisation) and more likely to be adhered to as a 'standard' by all the random coffee shops who are out of their depth as it is.
That's amazing! I've got the same password on my luggage!
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
1. Bring laptop with extra WiFi dongle into a public area.
2. Connect to Free WiFi spot using internal nic.
3. Act as an Access Point on second nic with a cooler sounding SSID.
4. NAT traffic to first WiFi net and grab everything of interest.
5. ???
6. Profit!!!1!!ONE!
There are so many ways this suggestion is wrong, it is not even funny.
TFA says WPA2 negotiates unique encryption keys with every computer that connects to it. This means you and I cannot spy on one another's traffic even when sharing access on the same access point. That's true, but anyone who can listen to the exchange and know the shared key will be able to learn the key. Plus, there is a very neat man in the middle attack.
Suppose that I am an evil sheep herder near a Starbuck cafe. Nothing prevents me from broadcasting a Wi-Fi beacon that announces that I am running a Starbuck access point. Here comes the sheep, who is really happyto see that the connection is secure. Hey, he used WPA2 and the "free" password, his packets are encrypted. Except they are all coming to my laptop. Oops!
This proposal has a ton of flaws that have already been highlighted in other comments (4 characters is too short, summary screws up "Free" vs "free.", the session is still easily hijacked to anyone present during the handshake, an so forth).
However, the real benefit to this kind of proposal, in my mind, is that it brings more public attention to the fact that unencrypted wifi is security madness.I've said to people before that I think that it needs to be illegal to sell an access point capable of unencrypted operation.
But it brings attention to our desperate need for a solution allowing businesses offering "free public wifi" to be able to ensure users' authenticated sessions aren't shared with each other. This is a reasonable expectation of privacy equivalent to non-electronic forms of communication, for example where somebody can't see you filling out a paper form unless they're standing right there looking over your shoulder.
Currently we have a Wifi security mode that is unencrypted and unauthenticated (open) and several that are encrypted and authenticated (wep, wpa1, wpa2 etc) There is a need for a Wifi security mode that is encrypted but not authenticated. Which is essentially what this proposal is getting at. Of course the actual proposal fails miserably because WPA is not secure against attackers who know the shared secret. So we need a new security mode that fills this role in a secure manner.
Now anyone who travels abroad frequently will have to learn the local equivalent of 'free' in every location. Horrible for people who airport-hop internationally :)
(It's bad enough to try to figure out Google's language settings)
The client has the keys only to decrypt traffic targeted to the client, not to other clients.
It is easy to bypass though by capturing a four-way handshake. A fake authentication can be used in order to have a client go though it again.
I've suggested this before a few times: http://it.slashdot.org/comments.pl?sid=457132&cid=22455074
Thing is he left out the part where there are two different modes of WPA2.
One (WPA2 PSK) where if everyone has the same password, it's still not secure (know the same key, sniff a session's 4 way handshake, and you can decrypt that session's traffic).
And one (the other WPA2) where it's supposedly more secure, but apparently still has problems: http://wifinetnews.com/archives/2010/07/researchers_hints_8021x_wpa2_flaw.html
Yeah, not so simple for Starbucks to get right...
Basically the WiFi standards bunch screwed up. So I actually blame them for a lot of the problems. So many years and they still haven't got WiFi to the level of TLS/HTTPS.
HTTPS doesn't solve the "stupid user problem", or the "browsers not warning users of changed CAs", but at least the tech/standard isn't that crap, it's more a people problem.
will still get you arrested for illegal breach into a seemingly closed system. The attempt (even if performed by the system) is still your legal responsibility. The only possible caveat being that this workaround somehow becomes part of the next wireless standard, in which case its assumed that you are offering your services for all to consume. Having an automatic attempt to connect using 'free' as a colloquial solution to WPA2's flaws are the wrong approach.
Bye!
That's just silly to require a password with the goal being encryption when the password isn't even what is used to encrypt the data. The 802.1X standard uses public key encryption so the solution is to move towards 802.1X and away from 802.11.
It's not at the game level, it is at the device level. The Nintendo DS only supports WEP.
A house divided against itself cannot stand.
Uhmm, maybe Sophos should invest in security training of their staff before they start selling supposed security products.
He's neither a researcher (someone who works in the virus labs) nor an engineer (someone involved in development of our endpoint or management products). He's in sales. Nothing to see here people, move along.
Posting anonymously because I work there.
I've always wondered .. in an encrypted wifi network you can not just sniff if your connected to that net work can you ??????
... well that's just a bump in a road, because all the protection that encryption (for wifi that is) provides ceases to exists once the traffic hits the access point (otherwise no internet at all),
if you can manage to direct let's say all traffic through your laptop what would happen (one very handy tool to do that is good old ettercap)??? I'm guessing back to square one.
So in any case the solution to the problem (this particular one) is between the hands of the web site (USE SSL) not the end user.
If the answer to that question is no you can sniff this doesn't solve the problem does it, if the answer is of course you can not just sniff
Iplayed arround with this at the university found one workaround: (that works with facebook) LOGOUT. I'm guessing that invalidates the session cookie and no more possible access. Though it doesn't work with hotmail -- whether you logout or not the attacker (me for instance) still has access -- Gmail on the other hand is not affected at all (to my knowledge). The other not so easy solution is to get access to a vpn.
If this firm had any integrity before this article, they can comfortable assume they have zero right now. What kind of "researcher" at a Security Firm doesn't know WPA2 is minimum 8 characters?
How the heck do you even know you are connecting to starbucks hotspot and not my credential-grabbing Linux laptop? If you need security, you need it all the way to your destination, as in https://www.facebook.com/. If SSL doesn't scale, let's develop a lightweight replacement that may be susceptible to pattern analysis or stream corruption but not theft of data transmitted in regular use. Even HTTP digest authentication would do more good than known password sent to an unknown wireless service for many sites.
I suggest the keyword "Sophos" to mark advertisements for snake oil sold as computer expertise disguised as interesting article submissions.
Yep, having a VPN at home also allows you to access your home computers from anywhere you have Internet access. It can be combined with Windows's Remote Desktop, for example.
It's computationally heavy.
A friend got Skype on his smartphone. WPA2 works. Skype works. Skype over WPA2 doesn't work - hiccups, pauses - the ~400MHz CPU is too weak to perform voice encoding and WPA2 encryption together. WEP is fine though.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
It's also perhaps worth noting that punctuation style is nothing at all to do with correct English. Punctuation is there to help understand the text, not to be part of it, and anyone who has ever trained as a copy editor knows that there are endless arguments over its proper use. If putting a full stop inside a quote means someone would naturally consider it part of the quoted material, it is clearly wrong.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
In what way is using a key that everybody knows any more secure than using no encryption at all?
A better idea is to have open wifi still negotiate a password with everybody who uses it, and use that just to encrypt the communication. No hassle at all, yet your communication is as secure as the wifi-owner wants.
If you put the password in the SSID so it's obvious, people won't have to guess if you're following that convention, or the convention that the password is "guest" or whatever.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Christopher Byrd has a simple modification to EAP-TLS that disables client certificate validation to provide more secure open wi-fi:
http://riosec.com/open-secure-wireless
This would require modifying only the Authenticator and the Supplicant, and it would be a simple modification to both.
Most of the Wifi systems are negotiating a random session key and using the password to authenticate it, so that's doing pretty much what you want.
However, they were mostly designed with the assumption that the objective is to prevent unauthorized access, not to protect the contents of the communications from eavesdropping, so the only way you can get encrypted sessions is to have password control, which is too bad.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
that doesn't mean they're not useful for encrypting traffic
That certainly depends on where you want your encrypted traffic to go.
Suppose you have (you'll never guess the names) Alice connected to Eve who is connected to Bob. Alice would like to send Bob a secret message.
She asks Eve for Bob's key. She gets back a self-signed key. She encrypts her message with this key and gives it to Eve.
Bob sees this: I'm asked for my self-signed key, so I give it out. Then I receive an encrypted message.
Eve does this: when Alice asks her for Bob's key, she asks Bob for his key. Then she gives Alice her own (Eve's) self-signed key. Then she gets an encrypted message from Alice. She decrypts it and reads it. Then she gives Bob her own (Eve's) new and different message, encrypted with Bob's key.
It requires Eve to be present when the session is initiated, but if she is the self-signed keys offer nothing. You can trust me because I made a certificate that says I'm an expert ;-)
What we really need is for tcpcrypt to be widely deployed. That would make the cost negligible.
An attacker doesn't need to sniff anything. Why bother? Just fire up your own hotspot, name it "Courtyard Marriott" or "Starbucks", and trawl away.
Think about it every time you connect to a free public hotspot.
Mind you, you say that the "American style" is used in UK fiction and journalism and I'd argue that they comprise the vast majority of UK literature anyway, so could be argued to be the "British style" too.
Still, I guess that Wikipedia must know best. It's not like it can just be edited by anyone...
Computer programmer, are you?
GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
Actually, this depends a lot on which set of style guidelines you read. In English, it's quite common to have punctuation outside quotes, although the Oxford and Cambridge style guidelines disagree on this. In American, you always put the punctuation inside the quotes even when that makes the sentence completely nonsense.
I am TheRaven on Soylent News
It's not at the game level, it is at the device level. The Nintendo DS only supports WEP.
Nope, apparently it is at the game level. The DSi supports WPA but only on DSi games. DS games don't support it because the network drivers are bundled with the game or something equally daft.
Still, I guess that Wikipedia must know best. It's not like it can just be edited by anyone...
It has sources cited. What's your source besides your 30 year old education? I just looked at an online UK newspaper and saw the following:
Last November, he was arrested by the police and then charged in March with "creating a disturbance".
Gee, logging into slashdot to post, it is difficult not to observe that it is a straight low security non-SSL login. Oh no! I could be hot mutton at any minute! Perhaps, in fact, this isn't even me posting this reply (an interesting existential dilemma).
There are several fairly obvious solutions to the security problem. Obviously any solutions involving the setting of a common password are muttonheaded -- that's just like setting no password at all, sort of like the people who buy a WiFi and leave the default admin password set to "admin". MitM attacks become straightforward if nothing else. Requiring the registration of any open WiFi with a certificate authority and using SSL would work, but is expensive and relies on small cafe's and restaurants and bookstores having somebody who is not an idiot setting up their network, which is both expensive and unlikely. Solutions have to be idiot proof and robust, meaning that either one of the well-known robust solutions has to be implemented damn the expense by the access point provider (allowing idiot clients to connect safely) or a well-known robust solution has to be implemented by the client (allowing them to safely connect to an idiot provider). No solution exists to cover the part of the space where both the owner of the open access point and the connecting client are idiots, because you can't fix stupid (at least not without mandates from a higher level authority and greater expense, such as toplevel registration of all IP numbers in the web universe with a certificate authority so all web connections are secure by law, something that makes my head ache just to think about).
Solution one: Get organizations such as facebook and slashdot(!) to change their logins to https; "encourage" all social website providers to use encrypted connections as standard/best practice. Cost: moderate -- most social sites are text-mostly traffic, which means that the efficiency penalty of encryption is likely not so great that it will bring either servers or the network backbone to its knees -- graphics and movies and music are a different matter, but even there one can easily maintain a reasonably authenticated connection and pass large items (interceptible) out of band unencrypted. The good thing is this solution is idiot proof everywhere but at the level of the social network provider involved, and a social mechanism exists (inventing firesheep for example and then publicizing the ease of embarrassing the clients of the service) for forcing the desired change without the need for laws or regulations. The marketplace doth provide.
Solution two: SSL Proxies. Companies such as B&N and/or Starbucks can easily enough set up their networks (and often do) so that you have to pass through one of their SSL-authed servers to reach the internet. Or, use a (usually paid) SSL-based proxy provider. This has the dual advantage of encrypting your point to point traffic and hiding your IP number when you go snooping around top secret government installations or cruising for porn. Google, in its business plan of taking over the world, could offer this solution to pretty much everybody almost overnight and instantly close its already crushing fist on the gonads of Microsoft and its other competitors still further, and probably do it for free for those users. Cost: Typically an annual fee, although a really large core provider e.g. Google might be able to provide it for free on the user side and still make money in the process. It also requires that you trust the proxy provider not to be a honeypot or the FBI in disguise, and remember those lovely no-warrant wiretap provisions and court decisions post-"Patriot" act. Basically, you can't REALLY trust your provider (including Google) if you are engaging in illegal activity or the (any) government doesn't "like" you for some reason, but a commercial/corporate ssl proxy provider is still fairly robust once the not-a-complete-idiot user has it set up.
Solution three: Don't be a
Even when the experts all agree, they may well be mistaken. --- Bertrand Russell.
It's better to just accept any password.
Religion is what happens when nature strikes and groupthink goes wrong.
IMO most security experts who spout garbage like this suggestion from Sophos should be taken outside, placed against a wall and subjected to a fire power demonstration using a range of handguns.
Idiots like this give the IT security field a bad name as being made up of charlatans and snake-oil sales men. More cowboys in this field now than the Wild West used to boast... and more bullshit generated than all the bulls in the wildwest used to ;)
--- Users are like bacteria -> Each one causing a thousand tiny crises until the host finally gives up and dies.
...as should be obvious from all the security-by-obscurity failures.
Firesheep works by stealing cookies. When you connect to www.whatever.com your browser sends all the cookies it has for that domain as part of the HTTP header (that's how cookies work).
Sites like facebook keep you logged in via a cookie. If somebody can grab that cookie they can log onto facebook as you without even knowing your password. A packet sniffer can steal cookies.
Moral: Set your bookmark to "https://www.facebook.com" so that the cookie is sent via a secure connection.
No sig today...
Still, I guess that Wikipedia must know best. It's not like it can just be edited by anyone...
What is it about lazy people who can't believe that they're wrong.
Can't dispute the fact, well lets just attack wikipedia because you've got a stick firmly up your ass.
Follow the fucking citation.
Hyde, Grant Milnor. Handbook for Newspaper Workers. D. Appleton and company, 1921, p. 38
http://www.amazon.com/Newspaper-Punctuation-Journalistic-Structure-Typographical/dp/1150066504
"Free"...Damn,.... I am going to have to change my neighbours w/lan password again otherwise everyone will be uisng it.
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
... here ... except ... the password is "open".
now we need to go OSS in diesel cars
But then isn't all traffic encrypted using "free" then? So, all you have to do is decrypt the traffic and you still have the same info. Or am I missing something?
Nevermind, read more posts and my question was answered.
Idiots like this give the IT security field a bad name as being made up of charlatans and snake-oil sales men.
Sadly, in my experience, it mostly is made up of charlatans, snake-oil salesmen and incompetents. Good security people are really rare.
First thing I noticed too!
WPA2 passwords are case sensitive, Mr Headline Writer.
On a WPA2 network, a user cannot eavesdrop on another user despite having the same key, because a unique handshake is performed when each user connects. Without the data that was passed in the handshake, an eavesdropper has no way of decrypting your traffic.
They can, however, force your connection to be reset, and when you reconnect they can capture the handshake. With the data that was passed in the handshake, they can decrypt all of your traffic.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
I know they is an overhead to small devices being forced into using SSL but wouldn't WPA2 cause the same sort of overhead? I prefer to just connect then use a VPN as they are loads of them around but it is true that your going to need a bigger passphrase then just "Free" due to the limit.. If people used the firefox plugin that forces SSL from EFF.org.. https://www.eff.org/deeplinks/2010/06/encrypt-web-https-everywhere-firefox-extension then most the top sites would be more secure but of course problems will still occur.. Last option freeradius but again could be a config nightmare. Personally I would promote SSL or just get people used to a VPN provider... Open Wireless in the UK like BTFON or BTOpenZone do give the user the option of free VPN software.. traced the VPN server to somewhere in London but it was very slow last time I tried it. Here... http://www.btopenzone.com/help/security/vpn-software.jsp I agree the solution needs to be tackled by the FreeWireless supplier more so then the end user.
The best solution, if it could be managed gracefully, would be IPSEC with Opportunistic Encryption. It's been tried and it apparently failed, at least it doesn't seem like you can just install a package and go. You could for a while and then there was some security fail or something, I'm too lazy to figure it out which is why it has to be easy. That's why it's called Opportunistic.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
http://www.zdnet.com/blog/ou/a-secure-wireless-lan-hotspot-for-anonymous-users/587
It doesn't even need a password. It could be a blank username and blank password or any username/password combo for that matter. The point is that it will facilitate wire equivalent security on Wi-Fi networks. Of course we'll have to combat gratuitous ARP to prevent man-in-the-middle attacks on the "wire equivalent".
You could also just put the password in the name your wireless connection, e.g. "Starbucks:Use Password XXX"
I honestly can not tell if you are trolling here or not. Do you really think Facebook cares about an extra hundred of thousand or even ten thousand dollars / month on their bandwidth bill?
A company like Facebook has monthly revenues and expenses in the tens of millions of dollars. This is total chump change.
The idea of SSL adding cost overhead for any company is completely nonsensical.
So do we get to take a run at it again when dnssec comes around again? Does it work better with IPv6?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
One (WPA2 PSK) where if everyone has the same password, it's still not secure (know the same key, sniff a session's 4 way handshake, and you can decrypt that session's traffic).
I keep seeing this posted and I don't understand. Listening to the handshake should not allow an attacker to decrypt the session. This is what key exchange algorithms are for. Why would this not be the case with WPA2?
Fiction is an exception to "British style".
$ make available
Basically the WiFi standards bunch screwed up. So I actually blame them for a lot of the problems. So many years and they still haven't got WiFi to the level of TLS/HTTPS.
So use TLS/HTTPS over wifi. Why should the Wifi standard solve a problem that's already been solved? Wifi only has to be as secure as a wired network, at which point we can use all the protocols we use to keep our systems secure on the public internet.
Give me Classic Slashdot or give me death!
The British style is always less ambiguous. Putting punctuation inside quotes that are not part of the original quote is wrong. Any style manual that recommends it is wrong. Nesting matters.
Reasonable people can disagree on things like the Oxford comma. There is no sane argument whatsoever for breaking the meaning of quotation marks just because you like the way it looks.
Give me Classic Slashdot or give me death!
If only there were some sort of encryption standard that individual websites could implement which would cause the browser and server to encrypt the data between them. Some sort of socket layer which is secured via encryption. That would readily solve these problems. Oh computer gods, why hast thou forsaken us?
Check out my lame java blog at www.javachopshop.com
It's not at the game level, it is at the device level. The Nintendo DS only supports WEP.
Nope, apparently it is at the game level. The DSi supports WPA but only on DSi games. DS games don't support it because the network drivers are bundled with the game or something equally daft.
DS games don't support it because the DS hardware doesn't support it. The DSi is different hardware
A house divided against itself cannot stand.
The DSi can play DS games. However, even on a DSi, DS games only support WEP, despite the system supporting WPA/WPA2.
In other words, the WiFi configuration tool is bundled with the game, not the system.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Um,
That doesn't really solve the problem. If I want to snarf people at a starbucks, I'm going to get on their public network, encrypted or not, and snarf that data the same as I always have. This doesn't solve anything other than authenticating that I'm actually connecting to starbucks and not my evil network with transparent proxy.
A better solution is to enable wireless isolation so that your wifi behaves more like a switch and is not as easily sniffable. DD-WRT, for example, provides this option.
The PSK is supposed to protect against man-in-the-middle attacks. If the PSK is compromised, you can get in there and pretend to be both the AP and the client.
In WPA-enterprise you generally do not have this problem because the AAA server presents a certificate which is verified by the client against it's trust chain before connecting (unless you stupidly turn off verification.)
Which is why the OP won't work. While you can configure WPA-enterprise so that the clients do not need to have certificates manually installed (using PEAP-MSCHAPv2 or EAP-TTLS) you have to buy a certificate for your AAA server from one of the CAs that are in the default trust store. Marriot or Starbucks might be willing to do that. A mom and pop coffee shop isn't going to want to shell out that kind of cash for a string of bits every several years.
Moreover any statement that begins with "operating system vendors could" is suspect. They could, but they won't, or it will take them a decade at least.
As it stands this is a problem for institutions trying to manage visitor WiFi access. The default behavior of the operating system is not conducive to auto-discovering AAA protocols used in WPA-enterprise. You have to click through a lot of menus to set up the connection. If even they all defaulted the same (to either EAP-TTLS or PEAP-MSCHAPv2) then it might be workable. As it stands most institutions just punt and use WPA2-PSK.
Someone had to do it.
Basically the WiFi standards bunch screwed up. So I actually blame them for a lot of the problems. So many years and they still haven't got WiFi to the level of TLS/HTTPS.
My thought as well. My mail server will encrypt opportunistically, no pre-shared key required - the fundamental problems are already solved.
We're not going to fix the standards committee or replace all the gear in the field. Perhaps the better place to focus is on a community-built standard for communicating securely with the access point. For instance, figure out some sort of flag to put into the handshake that can indicate an OpenVPN capability on the access point (or named IP, for bridging access points), and have OpenWRT, DD-WRT, and Tomato support that. Bake it into NetworkManager. Teach OpenVPN how to accept any cert on a given interface, if it can't already.
If it's any good Apple might pick it up for iOS 6 (the combined desktop/mobile version).
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Yeah, Open Mesh has had this capability for quite a while with some extra bells and whistles.
So use TLS/HTTPS over wifi. Why should the Wifi standard solve a problem that's already been solved
Solved already? Really? The last I checked "zillions" of sites don't support https. Slashdot for instance.
Some people can tunnel or VPN everything to a trusted gateway, but how many cafe users can do that? So the problem is NOT solved.
I hope you can figure out for yourself the difference between someone sniffing/exploiting traffic at a cafe, and someone doing it at the ISP or peering level.
Wifi only has to be as secure as a wired network
Yes, but it's _far_ from as secure at the moment. So they have failed.
1) It's harder to "sniff" a wired network that a wireless one. You need a free port for the former and you need to do stuff like mac-flooding (which can be detected). Or you need super duper Tempest stuff.
2) It's easier to set up a wired network where devices plugged into one port cannot snoop traffic from devices in another port. You could do this by either using what Cisco calls "port security" (other vendors have their own terms for it), or do "per port VLANs".
I was in the "hotel internet" line for a while, and we configured our switches so that guests plugged into a port could only talk to our gateway server. So guests using the wired connections were protected from other guests. They might not be protected from the NSA/CIA/KGB/FBI once their traffic leaves our control, but that's arguably beyond our responsibility.
Whereas wireless connections didn't allow us to protect guests from each other (at least while making it easy for guests to still use the system).
I am well aware that wireless connections can be DoSed more easily than wired connections, so no matter how much crypto you have, it's still jammable, but that would be a different threat level. Guests could still plug in to the wired port, lose the convenience, but still do their stuff.
FWIW: if a guest plugs into a wired port and intentionally/unintentionally tries to mess with the system we can usually figure out where that guest is, call the guest up and usually resolve things, even if we are in a different continent.
That's why after the WEP fiasco they should've handed the problem off to somebody competent. WEP was pretty much always a joke, because you really do need a lot more security when things are going over the air than you do when they're going over the wire. At least when things are going over the wire you need some access to the equipment relaying the messages. With wireless you don't even need that.
No this is the dumbest idea ever. Encryption U Key == Plaintext. Now we'll just have sniffers automatically trying the WPA key 'free' to decrypt-- oh that works. Cool. Even if everyone gets a session key, you just wait for someone to re-authenticate and listen in on the handshake; or someone new to come along at least. You now have a smaller attack window-- or you can de-authenticate someone somehow, which is doable.
Support my political activism on Patreon.
Because they screwed up: http://wiki.wireshark.org/HowToDecrypt802.11
"WPA and WPA2 use keys derived from an EAPOL handshake to encrypt traffic. Unless all four handshake packets are present for the session you're trying to decrypt, Wireshark won't be able to decrypt the traffic. You can use the display filter eapol to locate EAPOL packets in your capture. "
So if all four handshake packets are there (there are ways to help ensure you see them ;) ), you can crack WPA2 PSK, today with wireshark.
And both the PSK and "Enterprise" mode are apparently vulnerable to this: http://www.airtightnetworks.com/wpa2-hole196
So Mr "Senior Security Advisor at Sophos Canada" doesn't know what he's talking about. It's not so simple as just typing "free" (since no username is mentioned, I think he means the very broken PSK modes and not the less broken Enterprise modes).
I blame the WiFi standards bunch.
Instead it is the responsibility of those that wish to charge to make it clear that their product is NOT FREE.
You can not leave your crappy junk all over the street and then get upset when people pick it up.
Similarly, if you are so stupid as to leave your wireless network open without a password, there is NOTHING illegal with other people assuming your wireless network is a free network and using it to connect to the internet. Note, I am not condoning people hacking into your servers, just using your open network to access the regular internet.
Morons should NOT be allowed to take our rights and force charities to bear the responsibilities that business owners have failed to live up to.
excitingthingstodo.blogspot.com
"Correct English" is just convention, and it's only convention because it was adopted in response to particular modes of transmission/distribution. Specifically in the case of the quotation rule, I've always been told that it was to prevent punctuation from disappearing visually into the whitespace at the edges of a typeset newspaper column. It's an obsolete rule kept alive by people who care more about convention than clarity.
What you're espousing is nothing more than tradition for the sake of tradition. Unlike spelling or grammar-nazism, which at least are defensible since they make communication easier by reducing ambiguity, universally enforcing the punctuation-inside-quotes rule actually causes confusion. The British or logical-punctuation style is better by virtually any measure in effectively communicating the author's meaning.
Unless you're hand-setting type, it's a silly anachronism. It's time to let it go.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
You can capture the handshake w/ WPA but not WPA2.
Or more technically sniffing the WPA2 handshake will not allow you to decrypt the traffic.
Of course TKIP is flawed and was only really included to allow backwards comptibility. WPA2 AES should be the only option.
Basically the WiFi standards bunch screwed up. So I actually blame them for a lot of the problems. So many years and they still haven't got WiFi to the level of TLS/HTTPS.
To be fair, TLS/SSL has been around for a lot longer - 15 or so years. Additionally, the Wifi 'standards' have largely been spear-headed by commercial interests, not a standards body (though they've been involved, too). In reality, there's no reason why TLS/SSL couldn't have been implemented as the security mechanism for wireless - except it wasn't for various political and financial reasons. I doubt it has anything to do with technical prowess.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
You fail to understand how WPA2 works
The passphrase is no the ecnryption key. The passphrase is simply used to ID valid users.
Each session generates a unique session key. If you and I are connected to same wifi hotspot w/ WPA2 and "free" as the passphrase you can't decrypt my traffic and I can't decrypt yours.
Technically the "Free" passphrase isn't needed however WPA2 requires SOME passphrase. It would have been smart to allow encrypted traffic w/o identification but we are stuck w/ current system (at least until WPA3).
So to get encrypted per session streams you need a passphrase ANY passphrase. To simplify deployment if all public hotspots uses the same passphrase the OS could be designed to always try that before prompting the user.
Wrong.
While WPA2 uses a shared passphrase it doesn't use a shared encryption key.
All connected clients to the access point have unique session keys. If you know the passphrase you can connected and decrypt YOUR OWN TRAFFIC but that doesn't enable you to decrypt any OTHER CLIENTS because they will be using different session keys.
Great idea and does not cost anything, except for all router companies to add this tidbit for encryption default management,
and all OS developers to add this tidbit in their OS network card management, of course it could be done easily by patches, but how many update their firmware on their routers, and how many update their OS, some do not even have legal copies, but is very great idea though.
Solved already? Really? The last I checked "zillions" of sites don't support https. Slashdot for instance.
Slashdot supports https for subscribers. Try it sometime.
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.
The last I checked "zillions" of sites don't support https. Slashdot for instance.
True. And I've learned a lot of the reasons this might be true. The main one is the difficulty of keeping both your "http" and "https" site up to date and functioning. It seems that every 2nd or 3rd time there's an apache upgrade, the https site stops working. So we have to dig in and discover what slight tweak has broken our config this time, and then ask questions on forums until we find the trivial-looking change to httpd.conf that will make it work again.
Right now, I have a site that I want to update to the latest release, but in my test setup, once again the https version doesn't work, and there are no error messages saying what's wrong.
Years ago, I remember stumbling across a version in which all I had to do was:
Listen 80
Listen 443
and it Just Worked. But that problem was fixed in the next release. Anyway, I now once again have a lot of browser windows in the background that are showing various pages that might explain why the latest release silently fails for SSL in our test setup, and the public 80/443 site is still running an older version. Maybe I'll stumble across the fix today, maybe it'll be next week, and maybe it'll be after the next update is released.
It's even worse with the several other servers that I've tried out. Maybe some day, someone will figure out a way to make SSL "Just Work" out of the box, and keep working through upgrades. Until then, it'll continue to be a major PITA, and many people will just throw up their hands at the opaqueness of it all.
Unless, of course, you decide to not install any updates, and just go with a release that you managed to get working. But of course people will jump all over me for suggesting that people might be doing that for good reason ...
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
The PSK is supposed to protect against man-in-the-middle attacks. If the PSK is compromised, you can get in there and pretend to be both the AP and the client.
I get that. A MITM attack could intercept the traffic. But that isn't what I keep seeing posted. What was stated was:
know the same key, sniff a session's 4 way handshake, and you can decrypt that session's traffic.
I think that is a false statement. You cannot simply listen to the traffic and get the key. You must perform a MITM attack. That is much harder to do.
Good suggestions and am with you on self-signed certs.
For 1 there is the Perspectives plugin (FF). Close to what you want. Basically it polss SSL sites and their certs from several locations and throws up a warning, if the cert presented to your session is not what they have seen the past few weeks or so. (If I understand it correctly)
For 2 you will love the CertificatePatrol plugin. Does exactly what you want. Even throws a big warning, if just the CA changed.
Such things should be in the browser proper, IMHO. But then...by way of plugin perhaps it makes it there.
To be honest, even a wired network isn't perfect either. ARP poisoning can be done both over wireless and over wired networks, and in fact Hole196 just provide another way to broadcast the necessary packets that bypasses any wired IPSes.
To be fair, TLS/SSL has been around for a lot longer - 15 or so years.
I know, that's what makes it even more damning, and why I'm so disgusted by the state of "wifi security".
In English punctuation is supposed to go before closing quotation marks, ...
Careful; you're likely to get some grammar Nazi criticising you for saying "English" when you mean "American". ;-)
Actually, the replies that already explain this distinction are wrong, too. In reality, the rule - when there is one - is really determined by editors and publishers, not by countries or language peevers. Various publishers, especially newspapers and the like, have their own standards that they enforce, and it has only a little to do with which country their headquarters are in.
Also, it's common for people involved with computers to use the rule "only punctuation that's part of the quote belongs inside the quote. This makes it easy to write software that does it correctly. It also allows one to write sentences like:
Joe asked "Is Bill there?".
In this case, the '?' belongs inside the quote, because it's part of the question. The '.' doesn't, because the sentence as a whole isn't a question. It's a statement of fact about what Joe said, so it should end with a period.
But nested logic like that is far too complex for the typical human brain, I suppose. And a century from now, we'll still be reading silly complaints about such things.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Theirs are a points to conventionals, examples of thissss ist thats you probabilty objectes to thes santenca. By your argument I should start writing like that if I believe English would be a better language for using those spellings. I'm not sure I agree with that, but even if we grant that you are right about that, you are still objecting to something other than what I wrote in that I didn't say that people must use correct English, my objection was that correcting people for using correct English is a bit silly, even if you'd like English to work some other way, and that's what the poster I responded to did.
The passphrase is no the ecnryption key. The passphrase is simply used to ID valid users.
Each session generates a unique session key. If you and I are connected to same wifi hotspot w/ WPA2 and "free" as the passphrase you can't decrypt my traffic and I can't decrypt yours.
How is that session key exchanged? What secret key is already known between Alice and Bob (Authenticating Client and Hotspot) that isn't known by Eve (third party eavesdropper) to do the initial set-up? Exchanging an RSA public key first is not secure; see EtheRape for examples of shit that makes you talk to it instead of the hot spot, MitM style.
Support my political activism on Patreon.
Agreed. There is no secret key known. I mistaken on how handshake in WPA2 works.
However that doesn't mean that future protocol (say WPA3) couldn't use public key securely.
Essentially imagine an SSL like implementation to authenticate and securely exchange keys but for AP instead.
Client requests session from AP.
AP returns public key cert (could be self signed but also could be CA signed for an organization like starbucks).
For self signed certs you woudld still have the issue of MitM. For CA signed certs the client verifies the AP cert if valid and signed by a trusted CA. Thus client has at least some assurance it is talking to the "real" starbucks AP.
Client creates a random session key and also a public/private keypair.
Client encrypts everything w/ AP public key and transmits to AP.
Now all traffic is encrypted w/ securely shared session key.
However that would require something beyond what the article indicates. I was mistaken on the keyshare in WPA2. With Eve knowing passphrase it would be very simple to force a session disconnect and then capture the handshake.
Slashdot supports https for subscribers. Try it sometime.
$ wget -S 'https://slashdot.org/'
Connecting to slashdot.org|216.34.181.45|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 302 Found
Location: http://slashdot.org/
(irrelevant headers suppressed)
Supporting HTTPS by redirecting to HTTP. LOL
Solved already? Really? The last I checked "zillions" of sites don't support https. Slashdot for instance.
Yes, and you should treat everything you send to such sites as potentially compromised. A false sense of security is worse than none at all.
Give me Classic Slashdot or give me death!
I think it's just fine to update to WPA2. I've got no problem with people throwing on more encryption to the access point.
My problem is with anyone viewing that as a serious solution to anything. If the stuff that WPA2 is encrypting isn't already ciphertext and being sent to an already-authenticated endpoint, then you haven't solved anything. Remember in the first paragraph, when I said the access point? Wait a minute .. which access point? If you have just made an encrypted connection (using "test" as a the password) to the N900 in the pocket of guy at the next table, then you're still trusting arbitrary random people with your plaintext, so what was the point of encrypting?
And even if it's really Starbucks' access point, you're trusting them. And you're trusting Starbucks' ISP, and you're trusting whoever is on that mysterious floor in the AT&T building, and you're trusting the ISP of whoever is providing the service you're connecting to. Wow, good thing you encrypted one little link in the chain.
Upgrade your fucking applications and set 'em to use TLS (*). And upgrade your server to work with that. End-to-end encryption doesn't mean each router needs to decrypt and re-encrypt (although that's fine to do!); it means the client and server are encrypting with keys only known to those two points. Do it right, and then throw on more depth if that makes you feel better. Wifi is the wrong place to start working on your problem.
(*) Oh, and if you're updating your software to use TLS, consider GNU TLS so that you can upgrade to better trust models like OpenPGP. If you're going to encrypt things, you might as well reduce dependencies on centralized too-easily-coercible single-point-of-failure CAs, so that the MitM risks can be lowered. X.509 is a joke. Which of these two questions is more worrysome?
where each path was compromised years ago (before they signed), and every single one of them kept it under their hat all these years, in anticipation of the day that I would finally connect to this server?
One threat is common sense and already known to be happening, and the other threat requires batshit insane paranoia. I say: require paranoia before you get worried. Don't let them get you, unless everyone is (and always has been) out to get you. ;-)
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
someone sees the 'https' and thinks it's secure
Chrome does it right, with three different indicators in the URL bar: nothing for HTTP, a struck-out HTTPS for a self-signed certificate, or a plain HTTPS for a commercial certificate. But you still need an IPv4 address because downlevel clients won't send the SNI.
...apart from using HTTPS for everything, which is the least likely to happen in the short term.
This guy who wrote TFA should be encouraging router manufacturers to distribute easy-setup home VPNs. You could have the router monitor the home email address and notify the client when it changes.
Once you've got a home VPN, all of this free wifi security stuff is moot.
As I said, it supports it for subscribers. Try it with a logged in and subscribed account through a regular web browser. I'm posting this over ssl through https://slashdot.org/
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.
Not with WPA's 4-way handshake... it isn't a dh or RSA key exchange algorithm, it's more basic. If WPA-PSK used a dh exchange, then yes you'd be right, but it is really a hack where the PMK that is normally (in WPA-enterprise mode, that is) negotiated between the client and AP is replaced by a PSK-derived value. The nonces are sent in the clear.
Someone had to do it.
Moral: Set your bookmark to "https://www.facebook.com" so that the cookie is sent via a secure connection.
That may not prevent the cookie from being allowed to be sent via an insecure connection. In which case, all the attacker has to do is pretend to be facebook and ask for it.
If the cookie can only be sent via a secure connection, they can’t do that, since the SSL certificate ensures that the server you’re talking to is actually facebook. But just because the connection is secured doesn’t mean the “secure connections only” bit in the cookie gets set.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
Maybe because, in the real world, you're more likely to be inconvenienced by some kid at a coffeeshop hacking your facebook account than by the NSA reading your email in a massive datacenter?
You're special forces then? That's great! I just love your olympics!
Okay, thanks for that explanation, that makes sense. Any idea why they did it that way?
A ubiquitous password that everyone is trained to use without even thinking about it will make it easy for someone to set up a rogue wireless hotspot which supports that password. Not all users will notice that they are connecting to the wrong hotspot.
Once you're routing through the rogue, your traffic can be sniffed by the rogue.
Moreover, if this convention catches on, the dumb end users will try "free" against any wireless hotspot, anywhere without caring what they are connecting to. The rogues won't have to bother learning about the password of a public hotspot in order to replicate it. Just set up your gear, all set up with the "free" password, and off you go.
This ubiquitous password can only work as intended for security-conscious, Wi-Fi savvy users who understand that it's important to know that you are connecting to the right station, and can tell whether this is the case.
Public hotspots should have a true password, and should change it regularly. (At least once a day).
Another problem is that even if you use this password and connect to the correct access point, that does not mean you are secure! The encryption stops at the access point. Sniffing could be going on upstream.
There is no substitute for end-to-end encryption: VPNs, SSL, etc.
If your session is not secured at the appropriate level, you can't band-aid the problem with a "free" password everywhere.
Dumb, dumb, dumb.
The way they figured it, a PSK network that could not control distribution of their PSK "should just use WPA-enterprise." I'd put that in the "attitude problem" category.
The part where they left de-auths vulnerable to replay attacks, that was more in the "mistake" catagory.
Someone had to do it.
Free is good, but what if APs will accept any password the user enter?
Instead of having people connect to wifi spots with one password, have a unique passcode printed on every receipt for a business that's good for a day.
You'll be done with your coffee before you manage to get internet access. We're talking about Starbucks and McDonalds here.
1. I'm British, and I was never taught the US style. Thank fuck, too, as it's clearly illogical. I've only seen it used in material originating from the US.
2. Wikipedia cites sources. If you read something on there, and the source is not cited or reliable, ignore it. That's how it's always worked. It's strange you don't know that.
We're talking about a language that has been used for centuries, and you're squabbling over a 90-year-old source that accurately describes a very fundamental aspect of said language?
Just curious does that mean you can only get the Slashdot login form via http? If that's true, it's funny :).
My point still stands: "zillions" of sites don't support https.
And a number of the ones that do, like Slashdot, do it half-assed.