Monkey With A Shell
Some dingbat that occasionally builds neat stuff without breaking others. The person running this public-but-not-promoted instance because reasons.
- 0 Posts
- 63 Comments
It depends on how many layers of obfuscation you are looking to deal with. There always needs to be some publicly shared token to initiate a connection, even if that’s only the public key of a asymmetric key pair to a 3rd party auth system.
There are ways to do it, but part of the difficulty is there are so many ways to do it that coming to an agreed method is like herding cats.
It’s interesting that this is kicking up some controversy. Personally I’ve held similar thoughts since the time of AOL, that once it leaves your system it’s no longer in your control. You can ask people to delete it, and maybe they did, or maybe they deleted the one copy but not the cache version, or maybe just didn’t and lied about it. I’ve actually accidentally found stuff I thought was long lost when I decided to just mess around with some data recovery tools and pulled a bunch of pictures back from a drive I didn’t remember them ever being on.
One of my kids I saw take a picture of a snapchat with another phone. Asked what they where doing and it was explained that if you do a regular screenshot it notified the other person, so this was how they kept a copy secretly. So with that in mind, you never know who has copies of what that was posted.
This isn’t new, cell tower triangulation is a fact of the network operation and is part of how your signal gets handed off between towers as you travel. Airplane wouldn’t do anything unless it where to actually disable the sim entirely, and functionally even that doesn’t cut it in the USA given that a device without one can still connect to emergency services via any tower in reach.
This is just the carrier giving a customer the data that would already exist, for a price, which I thought T-Mo actually used to give for free…
TOR is just slightly harder to keep up on as far as being listed on the same tables as commercial VPN hosts because it’s so dynamic. Anyone can spin up a node and be a relay or, for the brave/foolish, an exit node in a few minutes.
Privacy largely comes from a plausible deniability in that the person asking for a site could be the originator or they could just be relaying a request for the originator. Freenet, or now called hypha net is similar that way.
My perspective on internet privacy has long been that while I don’t expect to be a ghost, I can make the picture as muddy as I can to make whatever profile they gather be as useless as possible.
From the infosec practitioner perspective the number of bad actors coming from public VPN pops is exceptionally high compared to any other random IP, so they get put on a naughty list. We often cut out entire countries just because they have such a high ratio of bad 2 good traffic, particularly if it’s a country that we have no real expectation of user traffic originating from.
It’s not so much a VPN bad, but just that you’re hanging out with others that act bad. Kind of the Nazi bar thing but for hackers. If you set up a private VPN somehow on a random cloud host you likely wouldn’t see the same issues, how to keep the ownership anonymous though is another problem.
Blocked as in sites reject traffic, or blocked as in can’t connect to the VPN?
The former is on the far end and not uncommon. A lot of sites reject connections from known VPN endpoints because the same tunnels that provide privacy to you also provide privacy to attackers quit often. You just need to decide if the site is important enough to use without a cover.
If it’s the latter, that would be a near end issue and would likely be your ISP or someone nearby that is looking to control your traffic.
There is a convenience vs privacy/security line to things that any given individual needs to decide where that lies for themselves. Plenty of people use Facebook and similar because there are a lot of people using it and there is a low bar to entry. Many of these big tech options will let you authenticate via a single click to share creds from another service, the ‘sign into Reddit with your Google account’ simplicity.
Then there are people like me who self host everything they can. I know exactly where my cloud files are, where my movies are, where my chat messages reside, heck where the Lemmy instance I’m posting this from is, all a few feet away from me. There is a cost to this, not only in actual hardware and electricity but in time and friction in that these systems are not going to have that ease of access that other do.
The bigger challenge is the bleed-over privacy risk. There’s no reasonable way for to ask the rest of the world not to post pictures or similar side channel disclosures. Short of becoming an outright hermit in the woods there’s always going to be some level of privacy leakage, that’s the part harder to manage.
Long ago I used a system called hushmail that promised a lot of the same as proton. Eventually I set up my own but it still has the problem of having to relay outgoing external mail through another box because of all the restrictions on home based dynamic IPs, so it’s largely relegated to system alerts in house rather than general use.
It’s a balancing act to be sure. VPNs stop local ISP inspection in exchange for potential viewing by the VPN host. DNS filters can only filter known threats. Things like P2P private nets can be infiltrated by 3rd parties via the ‘6 degrees of separation’ premise or even tracking pixels.
Making the picture muddy is about the best we can do, but it’s always worth the effort to not be another data point in the profile machine.
WiFi pineapples are fun that way. I’ve taken one out on a drive going to our cabin in scanning mode and picked up 100+ different SSIDs along the way. It can also respond as a wildcard to any request that comes by or just be obnoxious and advertise them all at one.
Never setting an ‘auto connect’ for unsecured WiFi is a must in that case. Secured not so much an issue unless the interceptor has the key for the network at least.
It’s pretty much the same thing that ‘tile’ does, it’s scary that they do this as an opt-out though. Having that as a system level function effectively means they can enable or disable it at will without having to have a separate app.
One more bug to sort out with notifications and I’m full time onto GraphineOS.
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.
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.
Claim: if you use HTTPS you are safe!
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.
Short version of this attack, it involves split routing for the tunnels. A lot of clients will have a default route-all to send traffic through the VPN. There is however a limitation to this because the tunnel itself needs a route from the local nic to connect to the VPN endpoint and establish the tunnel, otherwise you end up with a chicken and egg where you can’t establish the VPN. By taking advantage of the DHCP option to set preferred routes (really anything more specific than 0.0.0.0/0) it can tell the host system to send the specified traffic through the local gateway rather than the tunnel’s virtual adapter.
One relatively simple fix if you happen to have a fancy router/firewall on the edge of the network that handles the VPN would be to use policy based routing rather than relying on the underlying network configuration. Static route tables would be possible too, but in theory that could be overridden by just sending a more specific route again than what was set statically.
A favored test by the AirVPN people. Gives a decent picture of your print. Thing is, they can pick all the scree resolutions and browser types they like, but it only does good with a location
Generally yes, it would matter a lot how it was structured. Today you couldn’t call up AWS and ask for the details on a service owner out of privacy reasons and there are ways to register things by proxy. If they started stripping those kind of protections away though there’s bound to be some pushback.
The problem with that line of thought though, while people generally expect/wish for private communication, few actually care to understand the mechanics of it. Nor should they have to, that’s what security engineers are for, to do all that archaic setup so people can just use it without having to check certificates and protocols and all that stuff.
I’d say that if we could just have a simple to use, no-click pgp style system things would be good and we no longer have to keep nagging people to set things up the ‘right’ way, but so much of the hassle comes in by people using 100 different communication platforms.
Of course though: https://xkcd.com/927/
How much simpler can I make this…
You have a primary ‘master’ server in the pool.
Replica/cache servers periodically ask the master for any updates.
Master gives a new update, which is a sinkhole for a marked malicious domain.
Replica/cache server now resolves malicious domain to the sinkhole address.
This is not a ‘feature’ you have to implement, it’s a basic function of running a redundant DNS system.
This has been a theory for a while, just not sure it was a specifically ruled precedent. The notion being similar to how they can force fingerprinting but not testimony. Access to a physical lock or location you can’t simply say ‘stay out’ but they can’t force you to divulge a password since it’s a thought in your mind.
Also, relying on biometrics is terrible, quick but immutable keys are a big no-no.
There’s two avenues for opening an encrypted file, attacking the password/access method or attacking the encryption itself.
Generally using a basic zip-lock is not going to have a second factor, a rate limiting mechanism, anything really other than the password to stop a random brute force effort if they got a hold of the file for local processing.
Using something with some front end protection like bit warden with 2FA or keepass with the key file option added in makes it more a task of going after the crypto itself which is a much much harder approach.
Roku enabled by chance? I have 2 of them plugged in on my IOT space and have 54K blocks to scribe.logs.roku.com in the past 30 days.
The opener version by necessity makes it apparent that you are running a node, but without some coordinated efforts to ‘surround’ you and be in control of all node points connecting to it nobody can verify what requests originated or ended at your host. It’s a plausible deniability state rather than pure anonymity as far as the neighbors go.
Very simple comparison, shout to everyone in the room you want a file, if they have it they’ll send it, if not they’ll ask their neighbors, but they never tell the neighbors it’s not for them they just ask for the file, this continues on until someone has the file and passes lt back to the one who requested it from them up the chain until the first person gets it. In this way even the second person who was the first peer doesn’t know who originally requested it, just that this person asked them.
Interesting, hadn’t looked recently to see that. Ian Clark, aka Toad, wrote both though and likely just wanted to take advantage of the name recognition from Freenet without all the uproar that happened when they announced the 0.5 to 0.7 rewrite of Freenet. Back then, it was migrating TCP to UDP now it’s moving from Java to Rust. Both though end up being an effective reset of the odd little sub-web we know as Freenet.
I’ve been off and on since the way back times. It seems to be frozen for some while ever since the original dev ‘Toad’ went off to do his own thing a few years back. Conceptually it’s a neat idea but suffers greatly from a ‘slowest link in the chain’ problem when looking to fetch sites since any given node only knows their immediate peer rather than the true source on either end of a request.
The transport between you and the endpoint will see an encrypted tunnel, nothing of what is passed through it. Unless your ISP also happens to control the VPN gateway and where the ISP carrier for the VPN they wouldn’t be able make a correlation.
The VPN provider knows all of the above, so if you’re really concerned with privacy make sure to pay the provider with untraceable means like a cash purchased debit card or crypto and use an email not used anywhere else for authentication.
Right, I just use the term sometimes to say hiding things, even if it’s hidden via encrypting it.
Will have to delve into the papers for simplex later here, but in the end there needs to be some type of known identity to pin a communication to, otherwise you’ve already breached the confidentiality point of the security triad by not authenticating the recipient.