Want to use my wifi? (2013)
thejh.net
thejh.net
Is only partially true. If you sign in using incognito mode your passwords and cookies will leak. And you have to remember to open the incognito window after connecting to an insecure network and close it before you connect to a secure network because the cache and cookies are maintained until you close the window.
If not, then this becomes bad advice, because all the attacker has to do to disable HTTPS is not redirect http sites to https ones (sslstrip).
If so, then the list of sites for which your browser attempts HTTPS connections without being told to is the list of sites you’ve accessed in the past. This information could become a supercookie allowing sites to identify and track you even in incognito mode.
https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-bro...
Here’s a project that uses this fact to look up browser history: https://github.com/diracdeltas/sniffly
Which then makes the HSTS preload list and HTTPS Everywhere extension all the more valuable to defend against active attacks.
Of course this creates two problems which make it impractical for the man-on-the-street: choosing the solution and host (in my case OpenVPN with end-points running on my home network and a hosted VM as a backup in case that link is down) and keeping yourself (your server, your client, your configuration) up-to-date as new exploits are found. But I'm not a man-on-the-street in this instance so it works for me. There are a number of solutions that claim to provide out-of-the-box methods that the untrained can use without any effort, but there is still the "which service do I trust?" issue to contend with from both security and reliability points of view.
A side problem is client support on devices, particularly mobile phones, though from my selfish PoV that is a lot easier now: OpenVPN seems reliable on my Android devices, Windows Phone is effectively dead, and I never had an iDevice so haven't needed to care. The final problem is a human one: remembering to turn it on if you don't have ti on all the time automatically.
The same works when providing wireless access to or via a network you care about, such as wireless access in an office environment. The access point could be left as open as open can be (though security in depth: there is no harm in turning WPA2 on as an extra layer of protection) but don't let it route anything that doesn't look like your VPN traffic and let the VPN handle security.
If you need to provide wireless access for guests (visiting clients for instance) have a separate WLAN with all the usual protections that doesn't route to your other local network legs at all (without going out and back in via a VPN of course). Beyond that, their security is their problem.
In terms of trust, I'm happy going with bigger names which have more to lose if they turn out to not be doing what they say. Private internet access (no affiliation) for me ticks this box, is a really simple install on my phone + laptop, and has anonymous payment methods as well if that's something that's important to you.
First, client devices with OpenVPN don't support tap only tun. This means that when I'm not home, I can't e.g. my home NAS, etc.
Second, like most Americans, my home internet connection is dog slow. I get 80/5 Mbps. The 80 is tolerable, but the 5 is a drag. Surfing the web when first I have to VPN home...
Bonus problem: even with a business ISP setup, I am still under restriction with what I can do with my own IP address, can't get a static IPv6 allocation, etc.
Another advantage of the VPN endpoint being at home is that location sensitive applications think I'm there. This seems to reduce "are you a human?" checks in some places, and extra "characters 3, 9, and 11 from your password" requests during credit card payments.
One extra disadvantage, that doesn't affect me but would be a concern to someone gaming or taking part in other timing sensitive tasks, is extra latency, but you'll experience that on any VPN.
I've not found lack of tap support an issue, as I've only needed TCP & UDP via IPv4 anyway so normal routing options over tun do the trick. The lack of local broadcast support can break name resolution in some cases but that is nothing I can't fix with a hosts file entry or static hack in the LAN's DNS resolver.
I do use OpenVPN to run a few nonsecure "legacy" nonsecure protocols - the servers for those listen only on the VPN interface which isn't bridged to the physical LAN - but these days I very rarely need it.
Do any browsers try https first yet?
Now that I think of it, I guess many search engines now use HTTPS with HSTS and will send you straight to the https site if it knows of one, so that’s good.
This works for most things - for a few things I'll open an incognito window in Chrome, which simultaneously turns off extensions and doesn't send my original cookies, and I'll be careful about what I do in that window (certainly no logins to sites I care about). This is generally enough for e.g. reading some random news site that doesn't support HTTPS at all.
The reason I ask is, I'm under the impression that a VPN definitively mitigates this kind of attack. I'd have to change my habits if it turns out a VPN is not a one-stop-shop solution for this kind of attack. And, in case convenience matters to you: an enabled-by-default VPN is also less configuration and fewer manual steps than turning on HTTPS everywhere and blocking all unencrypted requests.
For performance reasons I don't want an always-on VPN; I trust my home wifi, my phone's hotspot, etc. at least as much as I trust any VPN I could use, so I wouldn't get any benefit from it.
I suppose the thing I should actually do is route over an SSH SOCKS tunnel to some server I control, which would work fine.
(A thing I have wanted for a while is a configuration that does this for HTTP and lets HTTPS through normally for performance, which now that I think about it, I can probably just write a proxy PAC file to do ... thanks, I'll see if I can improve my setup.)
This is what I do. The only danger with that over a regular VPN is anything not part of your browsers standard stream will not be sent over the proxy. This includes browser plugins as well. Thankfully Flash and Java are generally disabled by default, but it's still worth baring that limitation in mind.
Despite this, SSH SOCKS is still my preferred method as well.
The only other things that should be making connections are OS update checks, which should be secure already, and an SSH or mosh client.
I rely on them. Can you elaborate?
I like Private Internet Access.
https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-th...
Craigslist for instance is very slow when accessing via a VPN on Digital Ocean but quick when accessed via one hosted on Rackspace.
Google Scholar may send you through captcha hell for 10 rounds or so every few minutes if you're hoping on from a fishy ip.
The only time I had trouble with sites protected by Cloudflare was when viewing through Tor or AWS.
Still thanks for the idea, going to look into it more.
Algo’s use case is confidentiality, protecting your last mile connection including public wifi points. It is a solution to the problems given in “Want to use my wifi?”
Anonymity is a much harder problem to solve, and I personally wouldn’t be comfortable with any of the options claiming to offer anonymity, especially a commercial VPN provider.
> Setup is automated. Just answer a few questions, and Algo will build your VPN for you.
There are 5 steps before you get to the "Setup is automated" part! They're easy enough steps for someone with a bit of tech chops behind them and I will go easy on the first two (Set up VPS, download Algo) but come on, that is not automated!
But just looking at the market out there, I feel incredibly fortunate that I can choose such a good ISP. They are very rare.
Ironically, 50% of the time, I get access denied on Hacker News whenever I am on PIA (london)
This isn't true, as incognito can leak cookies. The proper mitigation is for site and app designers to use cert pinning.
You need https for cert pinning, so when I mentioned cert pinning that automatically included https. The reason to pin the certificate is to ensure that the server certificate presented today is the same server certificate that was seen yesterday. Otherwise the server may be spoofed and still pass the certificate checks. This is generally mitigated via certificate pinning. See Twitter's history and implementation of such.
I am not saying to NOT use another layer on top of this, as defense in depth is always important. There are ways to get around VPN use and ways to get around cert pinning, but using both makes the attacker's job far more difficult.
Implementing cert pinning is something that needs to be done by app developers, and what you mention are definitely good first measures one should take to protect their OWN systems in a hostile environment. By themselves, though, they don't completely mitigate all threats in the threat model.
I'm a little suspect that they have their own implementation, which might be incomplete, but it is likely better than no pinning.
By Tor, do you mean the firefox browser fork or Tor itself?
The code includes a list of Directory Servers, along with the fingerprints of their certs[1], so those are pinned. Then the relays are fetched from a Directory Server, along with their own fingerprints. So those connections are also authenticated.
[1] https://oniongit.eu/dgoulet/tor/blob/42cee727fa281fff4e27f98...
The same is true on a VPN. Tor is no different, except it adds extra layers for anonymization.
https://motherboard.vice.com/en_us/article/mgbdwv/badonion-h...