Using a browser in incognito mode does none of the sort. You can still enter your password into it and it can be stolen just as easily. The true solution is to only browse over HTTPS, connect to a VPN or not use untrusted networks.
Note that if I can spoof an IP address, I can send you bogus DNS replies, and send you to a web server that impersonates Google/Facebook/etc. but does not require HTTPS (unless they use the strict security header). In this case you do not get a warning, just the absence of a tiny green icon.
Only if you explicitly go to https://<site> - if you type <site> directly into the address bar you might end up at http://<site> which usually redirects you to https://<site> - but if you are on a compromised network you could get an incorrect response for the address of <site> from the DNS request and therefore go to a server that servces http://<site> with a redirect to https://<something-very-similar-to-site>. If you are not paying close attention you might just assume the green highlight in the relevant part of the address bar means all is well, where you are in fact accessing something you were not expecting but which looks like what you were expecting long enough to collect some useful details (such as your account credentials) from you.
While I can't get a cert signed for facebook.com (at least not without very expensive bribes or other human factors engineering) but I could get one for faceboolc.com easily enough and if you aren't looking closely that might fool the eye. It wouldn't catch everyone, anyone going direct to https://<site> would be warned as you suggest, but it could catch some out.
Heh, well what's the fun in that? Plus their remarks make it seem that it can somehow prevent passwords from being seen which is what got me to comment in the first place.
"If you have saved your login data on any plain-HTTP site that the attacker knows of, he can use his JS shell in the news site to load the site with the login form in an iframe, then inject another JS shell into the iframe and use that to read the password that the browser fills in."
As far as I know incognito mode wont autofill those saved credentials. I think that was the point how incognito mode prevents this kind of attack.
In this attack the user doesn't have to access those HTTP sites with stored credentials by themselves while being connected to the evil network, because the injected script does that for you behind the scenes.
You are right, I wasn't. However, the solution to this is to not use passwords with plain-HTTP sites. Incognito mode will prevent a small surface of drive-by attacks, but the bigger problem if plaintext passwords in cleartext on the wire are also terrible.
How easy is it to fully automate VPN only computer usage so that everything I do comes out of a machine at Amazon EC2 for example?
Startup idea! Make a tool that automatically tunnels your connection when you are on a public wifi. Make it open source and offer a hosted service. Also interesting if you are in a country which censors the internet. The dropbox of VPNs. For marketing you offer to write articles like this but less technical for magazines ("on Page 10 learn how easy it is for hackers to steal your facebook account and how you can protect yourself").
There are a multitude of VPN services in the market already. The generally accepted "best practice" for those with VPN service is to use it everywhere (not just on the road). When you're paying monthly, most people feel incentivized to use the service as much as possible.
I've set up VyprVPN for a couple of ultra-paranoid friends, and the whole process was very smooth and end-user friendly.
I get what you're saying, but Dropbox is not a back-up service. The distinction is that Dropbox didn't exist before Dropbox. There are unique aspects of Dropbox that were new when Dropbox was introduced.
There is nothing new or unique in what you described, with the exception (maybe) of automatic initiation of VPN services when you're on "public" wifi. I would argue that this is a differentiation of little or no consequence, because there's no reason to not use a VPN all the time.
You basically described every personal VPN provider in the market as a start-up idea.
If you really want to make it safe, I'd suggest using something with virtual networking (e.g. VMware) and configure a small VM to be your gateway. That way you can have a stripped down, firewalled configuration, with nearly no possibility that a local accident or compromise can evade your traffic policies. Otherwise, if your VPN drops, you run the risk that the system might just start sending traffic out over the public Internet (after all, it has to do so to connect to the VPN).
If you're on a Mac, it's nearly plug-and-play — I use a small menubar app called sidestep[1] that automatically tunnels over SSH, but there are also a few (Viscosity comes to mind) that work in a similar fashion with OpenVPN.
There may be similar bits available for Windows, but I haven't looked into it there in some time.
It's easier (and I'm a fan as well), but setting up an OpenVPN server with pre-shared key is very easy too. It's essentially a matter of apt-getting openvpn and writing a three line config file: http://openvpn.net/index.php/open-source/documentation/misce...
One of the advantages of using SSH is that it almost always works, even in environments (think China) that actively block detected VPN connections. SSH running on port 443 looks a lot like HTTPS.
I do not know for VPN, I use ssh. It is very simple and does not require any system administration right. Install a proxy (squid) on your Amazon EC2. Install putty if you are on windows and launch it with port forward using the option -L: putty -L 3128:127.0.0.1:3128 user@host
Add the option --proxy-server=127.0.0.1:3128 on you chrome shortcut and that's it.
And even more critical, it doesn't reroute DNS queries, the default is "don't redirect DNS" in Firefox and the change must be done through about:config there's no dialog.
Bad the default isn't different when using socks :(
If you're using a protocol that sits on TCP and you push it over SSH sitting on TCP then it's going to be TCP-over-TCP. Or in other words, for the vast majority of use cases, no.
I've had success with OpenVPN. It can set up a default route so everything in channeled over the encrypted connection and it uses client certificates, so it should be solid against MITM. I always turn on OpenVPN when I'm not on a trusted network.
Note that if I can spoof an IP address, I can send you bogus DNS replies, and send you to a web server that impersonates Google/Facebook/etc. but does not require HTTPS (unless they use the strict security header). In this case you do not get a warning, just the absence of a tiny green icon.