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.'"
This is actually a pretty good idea.
"free" and "free." are not the same.
I'm afraid this does not work the way you think it does. If everyone knows the password, then anyone can still view all traffic on the network, no?
... 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.
Why does it keep returning "free"??
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 want free LOVE, man. Where is the free love?
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.
The problem with WPA2 is that in my experience some portable devices don't support WPA2.
Example: Nintendo DS doesn't have any games that support WPA2(or any type of WPA as far as I know). WEP is the highest that it supports. (Now this may be wrong, but my understanding is that the network stuff is linked into the game, so older games will never be able to support anything better than WEP)
And there is a Web Browser for it, there is the official Opera cart. It also only supports up to WEP.
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.
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?
All it takes is one password, and you're fine. Doesn't matter that you're connecting to a network with no authentication, no security, and no way to really protect yourself in the event of being compromised.
How about we get some better way to test credentials??
That would require connecting to all available networks just to find out if any are accessible. The status of a network must be announced in the broadcast. If you wanted to have encryption enabled on public hotspots, then you'd have to standardize something that's in the beacon frames to declare public availability, for example an SSID prefix. Standard shared secrets are also not useful because they don't prevent attackers from sniffing or MITMing and decrypting the whole session. It's that "encryption without authentication" thing. Mr. Sophos researcher, keep working on the anti-virus snake-oil and let professionals handle encryption.
ARP poisoning apparently means nothing to this "security researcher"
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.
I never understood what value people see in encrypting just the edge when the rest of the network is no more trust worthy. I never understood why people think using an open hotspot is any more of a security risk than using the Internet. Neither can be trusted and both should be assumed to be hostile.
WRT using a well known secret to connect -- This only works if the server has a certificate and the client validates it. Not realistic for free hotspots because it requires the owner to pay for essentially an SSL certificate (EAP-TTLS or EAP-PEAP). This approach would offer the same security between the user and access point as https access to your favorite banking web site.
If however there is no MITM protection (Server uses a self-signed cert or none at all) using a well known password does raise the bar over open wifi but not by much. The channel would be secure against passive easedropping only and would provide zero protection against attackers operating a proxy server...
This is esentially the problem... You see a free wifi advertised and connect to it.. You have no prior relationship, no reason to trust the owner... No technological encryption solution will help provide security if there is no morsal of trust to build on.
My advise is to use end-end encryption technology if you have anything important to do. It makes life much easier and actually has tangable value from a security perspective.
This is a good idea in theory, it at least keeps the air-sniffing under control (Which is insanely easy to do.)
However what really needs to happen is that people need to have their home wireless router have a VPN end-point that it always connects to, even if it's the local network. When it goes roaming, it then needs to connect again to this VPN endpoint so that it's traffic is again secure. It wastes double the bandwidth of your home connection, but at least you're not being snooped on.
More technically inclined people can simply SSH a socks proxy of any machine they know, to use it as a ad-hoc VPN. Again, wastes their bandwidth but it's as safe as the end point network is.
A better solution is in whatever replaces 802.11a/b/g/n is to have open-encrypted mode that basically operates as a "randomly generated password" on the connection, and the hardware that runs the access point only throws an instruction page if connected un-encrypted that allows for a one-time password key.
Or even better yet, roll out IPv6 and the ability to hijack sessions will go away because IPv4 NAT that is responsible for this problem will then go away.
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!
Why do you need to type in a password to have encryption? Access control and confidentiality are different things. The access point and the client should both autogenerate their own key pairs, use those to establish a strong symmetric session key, and encrypt all further transmissions with that. By default. Completely transparent to the user, because the keys are autogenerated (e.g., from /dev/rand).
Man-in-the-middle would not work either, because the would-be attacker would have to set up his own access point and then the end user would see two access points in the "Connect to" list and would notice the "fake" AP. And since the connection handshake is encrypted with the public key of the real AP, the attacker can't get inbetween.
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.
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."
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.
This mind you about how The Pew Research Center is touting a relatively new form of poll bias called the “<a title="Election 2010 and the Cell phone Impact" href=" http://personalmoneystore.com/moneyblog/2010/11/02/cell-phone-effect-election-2010/">cell phone impact</a>,” and based on the New York Times, it will impact Election 2010. As the NY Times puts it, about a quarter of American adults use mobile phones exclusively. As many poll individuals don't call cell phones, Pew believes that the results could be skewed by as much as four points.
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.
Firesheep resides on the attackers computer, it forges the session cookie so that the attacker can access any site that you are logged in to. To forge your session cookie it monitors the traffic on the unencrypted wifi-network. If you have an encrypted connection the attacker first has to decrypt your connection before forging your cookie.
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.
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.
a) WPA passphrases must be between 8 and 63 chars long. So "free" doesn't work.
b) WPA PSK (pre-shared key) traffic can be decrypted if you sniffed the handshake (because you then know the temporal key of the client). This handshake can easily be re-triggered by sending a DeAuth packet (this is how aircrack works) -- so you don't even need to be there before your target...
So this "solution" is barely better than unencrypted WiFi, it would just require a bit of extra code in firesheep. IMO, said "security expert" should go back to school before saying silly things :-/
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.
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.
...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...
"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
Knowing the password for all free wifi networks will still allow people to do man in the middle attacks and I think that each network should have a password and display it (i.e. A business providing free wifi should encrypt, but have a sign within the business displaying the password).
Looks like we have a problem already...
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.
DH is pointless in the case you point out because it would be trivial to operate as you point out a middle man to circumvent. For a "This is screwy" response to be possible it would require some prior knowledge to establish a trust relationship between systems.
Not if you use something like (EAP-)SRP which, while based on DH principles, is a zero-knowledge password proof.
If the WiFi Alliance ever revises their "WPA2" requirements (or creates a "WPA3"), SRP should definitely be a necessity for conformity.
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.
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
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.
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)
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.
And I've wanted this forever...
1) a decentralized "Key counter" where browsers with a plugin can submit the keys being provided by a site, and whether or not they're valid (along with the CA path they're using).
[relevant to your suggestion]
2) Just let my browser use the self signed cert. Your color suggestions are fine. Just give me a big huge giant fucking warning WHEN THE CERT CHANGES. Certs are small, and can be cached/saved...effectively forever on modern drives. It isn't about educating users--people hitting google should come from a CA trust. When I connect to my home server, I am my trust. The key is matched, and it's really only interesting if for some reason the key changes.
As you mentioned, security is not an all or nothing game. 90% of the time, I'm probably connecting in a "safe" environment. The cert I got in my living room or on the corporate LAN, if it matched what I get for google at starbucks is probably just fine.
#1 in conjunction with #2 would provide a good way to see if anybody anywhere is trying anything hinky on the web, and start to force a bit of accountability--especially when you inevitably start catching CA's issuing things for domains they don't own at behest of uncle sam.
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
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.
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.
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.
arp spoof + iptables nat/fwd+ dnsiff + tcpdump = no reason to turn encryption on.
You can redirect packets anyway there's no added security.
Unless these coffee shops are running arp watch... which they aren't.
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.
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.
Great I just label my laptop wi-fi or Mi-Fi device to Starbucks, password 'free' and then using a proxy I capture all peoples mail and web data as it goes through the proxy as they try to use my free wi-fi!
Wonderful idea.