When using the Internet via WiFi at a public place such as a library or cafe, it is conceivable that the people running the router could be capturing all of your transmissions and therefore could be recording your name, account numbers, etc.
Are there ways to prevent or minimize this hazard?
For example, would it help to use something like Torpark?
What would you recommend?
Just make sure you only send sensitive data when the "Lock" symbol is closed ( If using IE ) which denotes an encrypted transmission using https.
My first recommendation is to not use public WiFi networks to send personally identifiable data.
If you do plan on sending private or personal information from a public WiFi then make sure you are using a secure protocol such as SSL or other. This will insure the data is properly encrypted and only readable on the server holding the certificate.
Tunnel your traffic through a secure SOCKS server.
Do not use public wifi, and if you do, do not send sensitive items over the link.
Seems Torpark will not help on the wireless part at all.
Yep. Or in the Evil Twin attack, someone could set up their own AP and force your pc to attach to it. There is also 'cookie hijacking', whereby if your connection is unencrypted, it is a utility-and-one-click away from being hijacked and someone reading all your emails.
Torpark is now 'Xerobank'
If on your own machine, I've also been using another free VPN service, Anchorfree
rms
Doesn't matter. If they want to know, they'll know. Consider the following:
Police: "Did you call regarding a man exponsing himself?" Librarian: "Yes, it happened right over there at that public terminal." Police: "Do you know who it was or have surveillance tapes?" Librarian: "Yes, but you can't see them." Police: "Why not?" Librarian: "Because we value the privacy of our patrons." Police: "(???) Well, what CAN you tell us?" Librarian: "That you'll have to have a warrant." (pause) Police: "We don't need no stinkin' warrant! (hits librarian with stick) Now you give it up or I'll beat you so hard, you won't be able to lie down!"
Using an encrypted SOCKS proxy is a good solution for securing individual applications, but it has some limitations. In particular: When using SOCKS to protect Web traffic, your HTTP requests and responses themselves will be encrypted as per your web browser's proxy configuration, but DNS requests generally will not. So while nobody on the wireless LAN would be able to directly see the pages you're looking at, they could easily tell precisely which Web servers you visit unless you take extra care to ensure that the browser bypasses the system DNS resolver, querying the SOCKS server instead (e.g., the network.proxy.socks_remote_dns setting in Firefox).
Torpark, now known as xB Browser, also provides HTTP traffic encryption (over the Tor network, which itself uses a SOCKS interface). I'd imagine that it goes the extra step in tunneling DNS traffic by default, but I can't speak from personal experience.
For my part I protect my privacy on untrusted networks with OpenVPN. I have a couple OpenVPN instances on my home network's gateway, one of which is configured to push a local default route and DNS server to clients. So when I connect my laptop to this VPN (using Angelo Laub's excellent Tunnelblick front-end for OS X), none of my Web, DNS, IM, or email traffic is legible to anybody on the wireless LAN. And as an added benefit, I get access to all the file shares and other services behind the NAT on my home network.
If you have a spare old PC lying around and a reasonable amount of experience with Unix systems, I highly recommend setting up an OpenBSD home router with OpenVPN. Not only do you get a secure firewall and VPN solution, but once you have a full-fledged BSD server as your network gateway you'll discover no end of handy uses for the machine, which simply would not have been possible with a Linksys or Netgear from Best Buy.
If you're interested in running your own VPN, I'd be happy to email you the self-reference system configuration manual that I wrote while installing my OpenBSD / OpenVPN gateway. (I'm planning to put it up on my web page eventually, but I haven't yet had the chance to proofread it for spelling and technical errors.) It might sound intimidating, but OpenVPN is in fact fantastically simple to set up if you have any Unix or Linux experience whatsoever.
References:
Great *if you can install a home server*. witopia/anchorfree/etc also use the vpn concept (witopia is built on openvpn i think) but you just install a simple app on the laptop and use their servers for the tunnel.
rms
Use ssh. But the greater danger is taht they have put trojaned files onto the computers. Thus you cannot really trust the puttyssh they installed for example, or even the keyboard, since that could be captured. If it is your own computer, then use ssh, and do not use web browsers.
This doesn't really add anything over a simple SSL connection.
The scenario is using public APs not kiosks. You're using your own software and machine.
As long as you're not foolish enough to disable security warnings, and pay attention to them, there's nothing at all dangerous about using sensitive Internet services from WiFi access points. It's safer than handing your credit card to the flunkie behind the counter when youpay for that double mocha latte. Your local library or Starbucks is no more or less trustworthy than your ISP, and your home broadband connection can be "sniffed" by your neighbors as easily as your wireless connection at the AP in many cases.
That's why end to end encryption exists folks, to make that sniffing an exercise in futility. The only thing a onlooker can learn is where you do your business, and contrary to what someone posted things like Tor not only add a layer of encryption similar to SSL/HTTPS, they also remove that piece of information from the equation. An HTTPS connection made through the Tor network is 100% secure no matter where you are or what you're doing when they're use properly.
Huh?
Then how in the heck are you going to actually do anything?
I think the danger is essentially inversely proportional to the distance between your favorite café and the nearest college of engineering.
Heh! You have a point there for sure. but unless you believe engineering students can break strong encryption the SSL/HTTPS connection makes the class of people who inhabit your favorite public AP irrelevant.
It's public computers you use?
If it's theirs and they will let you reboot the computer you could use live cds with tor.
Incognito, RocKate, Phantomix, ELE, Anonym.OS .
These are Linux and BSD.
Download the ISO, burn to CD, reboot computer. Make sure BIOS is set to boot CD before the hard drive.
Public proxies with encryption. I know of snoopblocker.
library
connection
What "39.99 program" are you talking about?
Any operating system and browser properly configured and maintained is enough to secure the connection between you and whatever on line travel site you use. Assuming of course that site uses HTTPS/SSL, which all reputable sites absolutely do. There's no 39.99 program out there that's going to improve on that sort of end to end strong encryption in any significant way, and even if it could it's an almost sure bet there's something out there that will do an even better job for free. ;)
Just make sure your security settings aren't broken (you haven't turned off warnings about SSL certificates), and pay attention if you're visiting Travelocity/Orbitz/whatever and all of a sudden you get a pop up about the certificate not matching the site or whatever. Don't just click "OK" and keep going.
What simple ssl connection? Wireless access points do not have simple ssl connections.
Fine. That was not clear.
Untrue. The danger is localised then. It is that flunky who could subvert your credit card. You know who he is. In the case of a net break it could be someone in Bulgaria or Tibet. That is absolutely no comeback making the potential cost of buggering you zero in that case, while it is high in th ecase of your flunky.
Not if you run some decent encryption on your home machine.
End to end needs two ends. Most web sites have only one end, yours. The other end is open.
You think people cannot do any thing without web browsers?
If you are jumping out of a plane, do you think a burning parachute is enough or would you advise a burning parachute with a crash helmet.
Nor do they have SSH connections, however either one will make sniffing public access points a fruitless undertaking from the POV of that sort of attacker. The advantage to HTTPS/SSL is that it's end to end, and ultimately available to users with modern software. They don't have to do anything in fact but be attentive to some hard to miss warnings.
SSH on the other hand is normally employed as a "tunnel" for other traffic in this scenario, and that protection end precisely at the point the SSH server converts encrypted traffic to plaintext. Everything between the SSH server and a final destination is 100% out in the open.
You do seem to be confused about connections, access, and which security measures address the various problems associated with "doing business" over the net.
It wasn't only clear, it was specifically stated.
Again, you seem confused regarding the identification of threats and how to mitigate risks. An SSL connection secures traffic between you and a vendor. Only two parties are privy to details like account numbers, names, credit card info passwords, etc. When you physically hand your credit card to a teller you're introducing a third party, so in reality your statement about localization is exactly the opposite of fact because you've increased your potential points of failure by 100%. And that doesn't even take into consideration other casual observers like the other customers in line waiting to pay for their double mocha late fix. ;)
Wrong.
An SSH server or other encrypted "proxy" on your home machine leaves egress traffic twisting in the wind. Everything is secured up to that point, but between your home machine and XYZ-Corp all your data is free for the taking.
Of course the typical scenario is tunneling SSL/encrypted traffic through that encrypted SSH connection to your home server, so the traffic is secure either way. In other words, the SSH/proxy tunnel adds nothing significant to the equation in the context being discussed.
Complete nonsense.
SSL encrypted connections are true end to end encryption. Data is encrypted before it leaves either end, and not decrypted until it reaches its destination, regardless of which way it's flowing.
Please do some basic research.
Of course they can. But here again you're completely ignoring context. A vast majority of net traffic is web based, and almost all of the rest can be easily secured with an "S" version of a given protocol.
SSH is very useful for a lot of things. I use it every single day in fact to administer remote machines, tunnel sensitive traffic into local networks (Webmin, router administration, etc.), and simply proxy traffic that would otherwise be rejected like the connection to the ISP news server I used to read your posts. :) But for secure connections to things like your Citibank or Amazon account for example, it's utterly useless.
None of those types of services run their own SSH servers as far as I'm aware, in fact doing so would constitute an additional security risk. So if you're connecting to those types of services insecurely (non-SSL connections) through an SSH server you're being nothing but a very misguided fool. And if you are tunneling SSL/TLS encrypted traffic through a home SSH server you're not adding any significant security to any transactions you might be making.
The notable and already stated exception of course is the fact that you're obfuscating where you do business from observers at the AP. For most people this isn't any concern at all. It's simply not a State secret that you buy books from Amazon, or bank at Wachovia. If that IS a priority then by all means use the proper tools to mitigate that risk. But don't waste time and/or lull yourself into a false sense of security by misapplying perfectly good tools to the *wrong* job.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.