
Want to use my wifi? (2013) - duramato
https://thejh.net/written-stuff/want-to-use-my-wifi?
======
barbegal
>Probably the easiest, yet most powerful one is to only use the browser in
incognito mode while surfing on insecure networks. This way, no information
(like passwords or cookies) can leak out and no evil cache entries can sneak
in.

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.

~~~
bonyt
Here is an interesting dilemma: should HSTS persist in incognito mode?

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...](https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-
dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/)

~~~
varenc
This is possible! HSTS does apply to incognito to my knowledge

Here’s a project that uses this fact to look up browser history:
[https://github.com/diracdeltas/sniffly](https://github.com/diracdeltas/sniffly)

~~~
crunchatized
At least it only works on chromium-based browsers. Firefox fixed the
supercookie problem when opening up a private browsing session back in Firefox
34.0.5 after it was discovered.

Which then makes the HSTS preload list and HTTPS Everywhere extension all the
more valuable to defend against active attacks.

------
dspillett
My solution has always been to use a VPN, not just on an untrusted network but
on _any_ wireless network (for any comms using an insecure protocol any
wireless network, even one run by yourself to the highest standards, _is_ an
untrusted network anyway). When WEP was broken it didn't affect me because the
WLAN was just a transport and my traffic was protected by the VPN. When WPA
was broken it didn't affect me because the WLAN was just a transport and my
traffic was protected by the VPN.

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.

~~~
IgorPartola
There are two places where I found this approach problematic because I want to
VPN to my home LAN.

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.

~~~
dspillett
I'm lucky enough to reliably see 76 down 17 up, the best you can get for a
residential location in the UK generally unless FTTP is available to you,
which is more than sufficient for most of what I do (mail and other mainly-
text-with-some-images comms, HN, StackExchange, shopping, SSH & remote desktop
or equivalent for various admin). On shared wireless or 3G/4G getting 17+ as a
sustained rate is pretty rare in my experience anyway. And I've got a couple
of static IPv4s play with, and a /48 IPv6 should I ever get around to using
that properly, which I can do pretty much anything I like with and the ISP
doesn't shape traffic beyond basic QoS measures either. It isn't a cheap
connection, but nice...

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.

------
GranPC
Mirror:
[https://web.archive.org/web/20180104070103/https://thejh.net...](https://web.archive.org/web/20180104070103/https://thejh.net/written-
stuff/want-to-use-my-wifi)

~~~
superdaniel
Thanks

------
ce4
FYI, this piece is from Jann Horn - known for the recent intel cpu bug
disclosure at Google project zero.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=6766106](https://news.ycombinator.com/item?id=6766106)

------
craftyguy
So using HTTPS seems to mitigate everything in this article?

~~~
bonyt
Well, sslstrip still likely works on websites that don’t use HSTS, or that
you’re visiting for the first time. I suppose the HTTPS Everywhere plugin
might mitigate this.

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.

[https://moxie.org/software/sslstrip/](https://moxie.org/software/sslstrip/)

~~~
geofft
If I'm using a wifi network I don't really trust (coffeeshops, airports,
etc.), I'll turn on HTTPS Everywhere and further enable "Block all unencrypted
requests," effectively giving me "HTTP Nowhere."

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.

~~~
delish
Can I ask why you don't [seem to] use a VPN?

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.

~~~
geofft
I haven't evaluated VPN providers enough to decide if there's one I trust. An
evil VPN (or an insecure one taken over by evil people) is in an extremely
easy position to MITM my HTTP traffic: it's technically easier than MITMing
wifi traffic, and they also know my identity (either because I paid with a
real-world identity, or they have logs of where I'm connecting from and what
I'm connecting to).

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.)

~~~
js2
Use Algo on a droplet.

~~~
shujito
how secure is it?

------
dannyw
An even easier way is to subscribe to a reputable VPN. There are often various
sales where you can pick up annual packages at steep discounts. Having a VPN
is also useful for troubleshooting network connectivity, and bypassing
content-based throttling.

I like Private Internet Access.

~~~
js2
Run Algo on a droplet.

[https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-
th...](https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-that-works/)

~~~
thinkloop
Any reason to use droplet in particular over other vms?

~~~
paulgerhardt
The price is competitive but I've found another important factor when VPN
shopping for VMS's is if that data center tends to be abused by scraping
projects.

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.

------
IncRnd
> _Probably the easiest, yet most powerful one is to only use the browser in
> incognito mode while surfing on insecure networks. This way, no information
> (like passwords or cookies) can leak out and no evil cache entries can sneak
> in._

This isn't true, as incognito can leak cookies. The proper mitigation is for
site and app designers to use cert pinning.

------
bclemens
All of this and more has been explored with BEEF. An easy way to demonstrate
these sorts of attacks is with BEEF + MITMF.

[http://beefproject.com/](http://beefproject.com/)

[https://github.com/byt3bl33d3r/MITMf](https://github.com/byt3bl33d3r/MITMf)

------
leni536
I believe that it's that site's responsibility to set the cookie's secure
attribute. Otherwise I'm surprised nobody mentioned disabling 3rd party
cookies as a mitigation on the client side. Using a VPN provider, a VPS or
even your self-hosted VPN in your home (your home ISP) is just choosing who
you trust.

------
Bromskloss
Aren't all these problems that exist for all unauthenticated traffic, wifi or
not?

------
drdrey
What about browsing over tor?

~~~
Viper007Bond
tor isn't a VPN service, it's an anonymizer. The end node could still sniff
your traffic presumably.

~~~
icebraining
_The end node could still sniff your traffic presumably._

The same is true on a VPN. Tor is no different, except it adds extra layers
for anonymization.

~~~
ce4
It's been shown more than once that this does happen frequently.

[https://motherboard.vice.com/en_us/article/mgbdwv/badonion-h...](https://motherboard.vice.com/en_us/article/mgbdwv/badonion-
honeypot-malicious-tor-exit-nodes)

[https://www.wired.com/2007/11/swedish-
researc/](https://www.wired.com/2007/11/swedish-researc/)

~~~
icebraining
Yes - my point is that the VPN is itself an exit node too.

------
chakalakasp
How I Learned to Stop Worrying and Love the VPN

