91–100 of 112 posts
The only foolproof way to make sure you're not being MITMd is to visually verify that the domain checks out and that you are indeed connected using SSL.
VPN accounts are cheaper than ever before. You can also install one on a cheap DO box.
How was the hacker able to get Facebook credentials? Facebook uses HTTPS and so does Live.com. Even if I'm connected to a malicious router, only me and Facebook know about the data we're sending each other. Am I missing something or should the author of this article provide more evidence on the type of attack?
Earlier quoted context omitted.
Both Private Internet Access[0] and VyprVPN[1] have apps on the Play store, which are completely plug-and-play. [0] https://play.google.com/store/apps/details?id=com.privateint... [1] https://play.google.com/store/apps/details?id=com.goldenfrog...
GoldenFrog has publicly stated that they are very much in favour of logging things.
Earlier quoted context omitted.
GoldenFrog has publicly stated that they are very much in favour of logging things.
Where did you read this? I haven't check in in a while, but I remember doing research to ensure the provider I used wouldn't be logging - and I settled on PIA.
30 day logs.
Here's what I wrote last time this was posted ( https://news.ycombinator.com/item?id=8457167 ), with some edits to respond to other comments made in this thread: An interesting read, but sparse enough on details to be basically useless. Additionally, there's nothing that I can discern to be new here. The following is demonstrated, all of which are known (and in fact obvious) to people with even an elementary understa…
Knowing what other networks are around is another approach. e.g. if I connect to network A, when networks B, K, L, T, U and X are all visible, the next time I connect to A, I can be reasonably certain that A is the same A as before if I see at least xx% of the networks that were visible the first time I connected to A.
why aren't 'know networks' gps-geofenced on smartphones? You have GPS, if your previous 'known network' (say, home) was in location X, it should not automatically connect (or even try to connect) to it at X + 20 miles. This way you should be able to keep your phone from connecting automatically to (or even looking for) a network that shouldn't be there in that location in the first place, and if you always tether to…
Smartphones mostly use wireless networks and cell towers to determine their approximate location, which can be easily spoofed, except for the current active cell (which could be miles away). If devices had to acquire GPS fix every time they reconnected to a network, batteries would drain much faster. And satellite navigation doesn't work properly indoors. Civilian GPS can also be spoofed.
Manufacturers would probably prioritize usability over rectifying such a "problem" which never had bothered anyone before, except maybe if there was PR involved. I think there's still no way to list all configured wireless networks on iOS devices? Fixing this would probably improve privacy more (if people cared) than this randomized MAC feature.
Here's what I wrote last time this was posted ( https://news.ycombinator.com/item?id=8457167 ), with some edits to respond to other comments made in this thread: An interesting read, but sparse enough on details to be basically useless. Additionally, there's nothing that I can discern to be new here. The following is demonstrated, all of which are known (and in fact obvious) to people with even an elementary understa…
Earlier quoted context omitted.
since theres no url associated any trusted ca-signed cert is valid (for example a cert from startssl). if you use self signed that actually protects you since then the client complains. SOME clients pin the certs (thus you cant impersonate the AP even with a trusted CA-signed cert) but its still quite rare.
But in theory the same CA infrastructure as used for the web could be used. The SSID of the network would be interpreted as the "domain". So if I try to connect to SSID example.com securely, I would verify that the AP can identify itself as example.com (based on the CA roots which I trust) - exactly the same way as a web browser would if I tried to connect to https://example.com . Or is this already supported but nob…
1, we would have to set up a global registry for SSIDs, like we have for domain names. (Otherwise, what's to keep someone else from using a colliding or misleading name and getting a certificate for it?) And even then you run into the problem that the CA infrastructure used for the web is pretty terrible.
2, clients would need some kind of policy database to know what kinds of traffic must go over a "secured" AP and what kinds, if any, can go over the local coffeeshop's or convention hotel's wifi.
And all of this to secure just one link of the communication— all the rest remain vulnerable. Really what we want is end-to-end encryption, not link-by-link encryption. If you have #2, for example, you could instead use that policy database to implement mandatory IPsec (or equivalent end-to-end encryption; MinimaLT if you prefer) for all sensitive traffic, and bingo, you're secure against whole classes of attack even when you are using unknown APs.
Earlier quoted context omitted.
If an attacker controls the access point he could do the following: * Redirect all HTTPS traffic to an HTTP spoof site. Many users probably wouldn't notice. * If the attacker has access to a short, 2-3 character domain, they could redirect to a wildcard HTTPS connection like, https://facebook.aa.com/ - again, many users wouldn't notice. They'd see "facebook" and the lock icon and assume they're ok. * In either case t…
Probably don't even need a short domain. Facebook.login.secureauthredirectsystem.moregibberish.com probably would seem sorta legit. After all, Microsoft's auth systems do crazy stuff like that. So does the moronic Verified by Visa system - it's something like "ww2.secpayment.com" and looks totally sketchy but it's legit.