Here in Australia, they were attempting to force us to provide Government Photo ID on Airbnb several years ago, we stopped using them instead.
There's a Know Your Customer (KYC) legislation that keeps being interpreted by numpties as requiring that they store these documents, rather than identify the user, create an account and dispose of the documents, which is making these companies rich hunting ground for infiltration by groups wanting to monetize personal data and provide identity theft services.
If you use HTTPS, the attacker can still see what websites you connect to, they just can't see what you are sending or receiving. So basically they can steal your browsing history, which defeats the purpose of a commercial VPN for many users.
This is blatantly false. They can see IP addresses and ports of you connect to from IP packets, and hostnames from TLS negotiation phase (and DNS requests if you don’t use custom DNS settings). HTTP data is fully encrypted when using HTTPS.
If exposing hostnames and IP addresses is dangerous, chances are that establishing a VPN connection is as dangerous.
If exposing hostnames and IP addresses is dangerous
It's not necessarily dangerous, but it's a major privacy issue. Hiding your browsing history from other people (except for the VPN provider) is one of the main reasons why people get a commercial VPN in the first place. And this vulnerability mainly concerns those users.
It says right in there that they can't see what you are sending or receiving, but seeing the SNI provides content on what you're doing. Not seeing where it's false at all.
Using that SNI header profile though if one was inclined and the site doesn't enforce HSTS it would be simple enough to proxy traffic through their gateway, or to creating a phishing duplication of the site with a DNS redirect.
Yes, sorry, but I can't take something seriously if every paragraph begins and ends with an emoji. I know it's dismissive, but all my Facebook lunatic conspiracy theory alarm bells are blaring.
Paying a tutor or a class might be a good accelerant since you could ask fundamental questions in your native language. Once you have the grammar scaffolding, you could then use flashcards to start building vocab or looking for natives to share conversations with. Note also: immersion rarely works without some foundations to build on (unless the language in question is basically the same as your native language like Dutch is to English). The TL;DR is apps are more entertainment then education.
Overall a solid writeup, but this part could use some clarification. Assuming the VPN client doesn't leak DNS this is only a concern after exploitation by DHCP option.
Another thing that might be noted, since this is a DHCP based issue the window for compromise is largely going to be at the time of connection unless the server has a particularly short lease time. If there are multiple DHCP servers on the same network answering requests it's bound to raise some alarms if someone is watching the network so it makes 3rd person exploitation a very noisy method since you would have a race for who offered the lease first.
Edit: Really this attack isn't just a problem for VPNs but could apply to any network connectivity. A rouge DHCP sever can cause all sorts of havoc. There used to be an single button APK called 'firesheep' that would do similar to this by presenting itself as the gateway, although that wouldn't have allowed for the specific split routing config option push.
I added clarification that the HTTPS part is assuming that the attacker has already performed the DHCP attack. Thanks for the note!
The DHCP race is one part I didn't go into detail about since I'm not very familiar with the details, but what you wrote makes sense. One potential danger is a hacker at a coffee shop, where the shop owner is unlikely to be monitoring the network, and there are going to be many new connections coming in all the time. It's still an unlikely scenario, but it also isn't a particularly difficult attack.
Discover/offer/request/acknowledge since it didn't make a pretty picture for me.
Basically it's just a case of who answers first. A DHCP discover is a broadcast message since the client doesn't know where or even if there is a server on the net. Whoever gets back to the client first with an offer though will end up with the request/ack following up and get to provide whatever options they push along with the offer.
I've been using network namespaces in Linux where each one also use a different user; this way you can have multiple profiles of apps separated not only by permissions but also by the VPN connection that is the only route out
So you can have a connection that will supply your favorite iso sharer, a VPN connection to work, all unaware of each ot
I still haven't figured how to make GUI media applications work on them though
Sure, someone helped me setting up a script to share the wl socket between namespaces so I can run GUI programs in isolated namespaces, and if you look at this post you can check the namespaced-openvpn; also check vole's answer if you want to run GUI programs
Great write-up, I've been looking for something like this. I've heard of vopono and eznetns before but not namespaced-openvpn, and this is the first post I've seen where somebody details how they use a tool like this, so thanks! I'll have to try setting it up some time.
You mean, with things similar to TG channels? Will try. Still answering specific messages with referencing them, referencing specific posts in channels and so on don't seem to be in XMPP functionality yet.
OpSec fail, never ever use any personal info when you are dealing with something you don't want to be indentified for, it include obviously recovery emails, usernames and passwords.
If you want anonymity and the advantages of a VPS VPN at the same time you should look for a provider which accept crypto payments, and optionally setup tor, i2p and freenet nodes to obfuscate your traffic.
That way you will be helping the community and at the same time securing yourself.
I wonder if their recent blog post promoting conspiracy theorists and right-wing people turned away more people from telegram than they expected and now they feel the need to spread FUD against their competitors.
1488 and other Nazi numbers are, eh, just normal jokes in Russia.
But in general yes, I think this is on purpose. Probably want some people think Telegram is kinda counterculture and more secure. It's not secure at all, of course.
You know what, in my head I think I want a whole new messenger.
There's an indexer that acts as a phone book, but at the same time, people can bypass that by directly adding contacts.
All chat history and groups are peer 2 peer and are stored like torrents with the extended backup being self-hostable.
Recent chat history (up to 30 days) can be stored on the indexer, though they're encrypted and so the server is blind to what's in them. They should explicitly be opt-in.
Whenever a user adds a new client (device), all conversations recipients should have to approve in order for them to see the chat history.
It should also have all the bells and whistles, like emoji, stickers, groups, channels, etc.
I have been thinking of something like this too, the thing in common between us is that neither of us has the competency, the time and the persistence to make this happen.
Sometimes putting the ideas we have out there makes a difference. While we lack the competency, perhaps someone that sees this will and it will inspire them to bring something to life.
Whenever a user adds a new client (device), all conversations recipients should have to approve in order for them to see the chat history.
Why though? In case of a public chat or a chat with at least few dozens of users it'll already be excessive if it could work at all.
All chat history and groups are peer 2 peer
Like really P2P or E2E? Because I know at least one chat app that is serverless but doesn't involve E2E apparently - tox. E2E is an overkill for big group chats because it means you have to re-encrypt every message for every new user for them to see it. Else if you rely on just a fixed shared key it's not E2E anymore (which will make some people sad and hate your app).
For public chats, you wouldn't need to approve, only for private chat groups.
I get that but it kind of defeats the purpose. If your group is so small that it's worth it for every member to approve new ones then it probably doesn't produce enough content for each new member to care about.
Privacy
Hot
This magazine is not receiving updates (last activity 52 day(s) ago).