Want to use my wifi? (2013)(thejh.net)
thejh.net
Want to use my wifi? (2013)
https://thejh.net/written-stuff/want-to-use-my-wifi?
66 comments
I go a little further in the same direction: I treat even my wired home network as an untrusted network transport. My home server exposes exactly the same things to the LAN that it does to the public Internet (indeed as far as I'm concerned the LAN just is part of the public Internet - with IPv6 my home server even has the same address from either). My only open ports are secure protocols like SSH or HTTPS or PostgreSQL-with-SSL.
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.
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.
I'm with you on the majority of your comment, but I'd contend that VPNs are definitely accessible for your average person, assuming they're are actually aware of them and how they help. Sure you don't get the same guarantee regarding logs etc. if you use a commercial option instead of rolling your own, but that's a different threat to the one described in the article.
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.
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.
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.
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.
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.
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.
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/
https://github.com/byt3bl33d3r/MITMf
http://beefproject.com/
https://github.com/byt3bl33d3r/MITMf
[deleted]
Aren't all these problems that exist for all unauthenticated traffic, wifi or not?
Discussed at the time: https://news.ycombinator.com/item?id=6766106
So using HTTPS seems to mitigate everything in this article?
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/
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/
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.
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.
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.
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.
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.)
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.)
> I suppose the thing I should actually do is route over an SSH SOCKS tunnel to some server I control, which would work fine.
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.
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.
Keep in mind your browser isn't the only app you're running that makes network connections, and it's not even the only app that makes network connections that runs network-supplied javascript. I wonder how much research has been done into Electron apps like Slack and Whatsapp from a javascript exploit point of view?
I don't run the Electron apps because I just don't trust them - I already have a perfectly good and secure thing for running JS, it's my browser. :-) I agree that they're a huge attack surface.
The only other things that should be making connections are OS update checks, which should be secure already, and an SSH or mosh client.
The only other things that should be making connections are OS update checks, which should be secure already, and an SSH or mosh client.
[deleted]
No. That is only the case when the certificate is pinned, which is the proper mitigation in this case. VPNs do not have stellar records regarding security.
> VPNs do not have stellar records regarding security.
I rely on them. Can you elaborate?
I rely on them. Can you elaborate?
Sure. You can take a look here to see some common issues with VPNs. https://www.theregister.co.uk/2016/02/26/ssl_vpns_survey/
>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.
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.
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...
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...
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
Here’s a project that uses this fact to look up browser history: https://github.com/diracdeltas/sniffly
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.
Which then makes the HSTS preload list and HTTPS Everywhere extension all the more valuable to defend against active attacks.
Unless the website makes use of HSTS preload
Yeah the only true part there was 'no evil cache entries.' Chrome's incognito mode even explicitly warns that it does not defend against your ISP/employer/school (aka any man-in-the-middle). All incognito does is keep any data from the session from being saved to disk.
What about browsing over tor?
tor isn't a VPN service, it's an anonymizer. The end node could still sniff your traffic presumably.
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.
The same is true on a VPN. Tor is no different, except it adds extra layers for anonymization.
It's been shown more than once that this does happen frequently.
https://motherboard.vice.com/en_us/article/mgbdwv/badonion-h...
https://www.wired.com/2007/11/swedish-researc/
https://motherboard.vice.com/en_us/article/mgbdwv/badonion-h...
https://www.wired.com/2007/11/swedish-researc/
Yes - my point is that the VPN is itself an exit node too.
you trust the VPN... TOR exit nodes should be considered adversaries trying to spy on you. They probably are :)
Ah, "trust the VPN". Sounds naive :) at least the Tor exit node can't directly match my traffic with my payment information.
Yeah but that would protect you from the insecure wifi attacker, no?
No, it wouldn't. You still need to protect that you are connecting to the wifi access point and not a spoofed one, due to arp or DNS poisoning.
Why? Protocols like Tor and HTTPS include authentication layers just to make sure your connection is secured even over an insecure channel.
Great question. I used the word "to" when it is more correct to use "thru" the AP.
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.
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.
Right, but Tor itself includes their own implementation of "cert pinning", so you are protected from an insecure Wifi network by using it (of course, you are then at the mercy of the exit node, but that's another matter).
Agreed, if the pinning extends from the client to outside the 'cafe' then that traffic is protected against modification from within the cafe.
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?
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?
I mean Tor itself. It uses TLS to connect securely to the nodes.
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 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 worst the attacker could do is prevent you from accessing the Tor network, but that can be mitigated by using Bridges.
How I Learned to Stop Worrying and Love the VPN
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.
I like Private Internet Access.
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-th...
Any reason to use droplet in particular over other vms?
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.
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.
Not particularly. Droplets are $5/mo and very easy to set up.
Doesn't seem like this would be as anonymous as something like PIA....assuming you can trust pia.
Still thanks for the idea, going to look into it more.
Still thanks for the idea, going to look into it more.
From Algo's readme: Does not claim to provide anonymity or censorship avoidance.
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.
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.
One will make different VPN/proxy choices depending on one's priorities and threat models — here, for example, the tension between anonymity, which is most likely to lead you to choose a commercial VPN with a large number of users at each endpoint, and privacy, which is most likely to lead you to choose a private VPN solution where you have full control over the endpont's settings, logging, etc. These aren't the only factors, and neither option perfectly solves either, but carefully thinking through what you actually expect a VPN to be protecting you from is important.
I love it when developers write web copy
> 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!
> 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!
how secure is it?
How would you know if it’s reputable? Better to run your own on a VPS (or even better a dedicated box at home).
I have strong confidence in my home ISP -- they have a track record of standing up for their customers, they are vocal about human rights to privacy and they generally are not easy to compel. So, naturally, I run a VPN server on my gateway machine.
But just looking at the market out there, I feel incredibly fortunate that I can choose such a good ISP. They are very rare.
But just looking at the market out there, I feel incredibly fortunate that I can choose such a good ISP. They are very rare.
'I like Private Internet Access'
Ironically, 50% of the time, I get access denied on Hacker News whenever I am on PIA (london)
Ironically, 50% of the time, I get access denied on Hacker News whenever I am on PIA (london)
The "MiniHack" iOS app totally fails for me on PIA. I can usually access the site from my desktop just fine though.
I’ve been getting a blank page, on mobile only, when on PIA in the last week or two (also about 50% of the time).
> 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.
This isn't true, as incognito can leak cookies. The proper mitigation is for site and app designers to use cert pinning.
FYI, this piece is from Jann Horn - known for the recent intel cpu bug disclosure at Google project zero.
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.
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.