191–200 of 204 posts
Earlier quoted context omitted.
No, modern resolvers like systemd-resolved actually check the dnssec signatures on the client.
Can you link to a distro config that defaults to that?
Earlier quoted context omitted.
It's not necessarily equivalent to a recursive lookup, you can ask a cache for all the answers because you already know the root keys a priori. But yes, it does follow the entire chain of trust, that's the entire point of dnssec : if you don't do that the whole exercise is utterly pointless.
It's explicitly not the point of DNSSEC, which has for most of its entire existence been designed to be run as a server-to-server protocol, with stub resolvers trusting their upstream DNS servers. I agree with you, though. It's utterly pointless.
Earlier quoted context omitted.
I had organized neighbors who broke WPA3 using tools, i disabled downgrade to WPA2 and they still broke it. I had one that setup an evil twin to catch my Linux login They stole the IP of one of boxes so they could get my login, and joined my network to setup the credential stealer. I caught this when my password didn't work at the ssh login. That was an apartment and they knew when I caught them. The problem is not w…
Where the fuck do you live? Both an apartment you lived in and a house you moved to had neighbors who cracked your WPA3 network and compromised your infrastructure? Also: You use EAP TLS on your home network but not SSH keys?
I realize the security relevance of that, but I do not have daily images to restore from if something happens. I got locked of a key only box one time with an error after a reboot, and never want it to happen again. It felt like being robbed.
Earlier quoted context omitted.
It's explicitly not the point of DNSSEC, which has for most of its entire existence been designed to be run as a server-to-server protocol, with stub resolvers trusting their upstream DNS servers. I agree with you, though. It's utterly pointless.
Not true, RFC4035 says all security aware resolvers SHOULD verify the signatures. It's far from pointless when actually implemented. Don't dismiss a whole protocol just because some historical implementations have been half assed.
Earlier quoted context omitted.
Can you link to a distro config that defaults to that?
No, it's experimental. But I run it on all my machines, the only time I've had a problem is when it caught a typo in a DS record.
You can see at this point how hollow "DNSSEC" is as an answer to the problem of this thread.
As far as I can tell, all of these attacks require the attacker to already be associated to a victim's network. Most of these attacks seem similar to ones expected on shared wifi (airports, cafes) that have been known about for a while. The novel attacks seem to exploit weaknesses in particular router implementations that didn't actually segregate traffic between guest and normal networks. I'm curious if I missed som…
I'm a co-author on the paper: I would personally indeed not use the phrase "we can break Wi-Fi encryption", because that might be misinterpreated that we can break any Wi-Fi network. What we can do is that, when an adversary is connected to a co-located open network, or is a malicious insider, they can attack other clients. More technically, that we can bypass client isolation. We encountered one interesting case whe…
- Buy cheap IOT device
- Isolate it on guest network
- IOT device is compromised (or shipped that way)
- IOT device now has clear access to traffic on both your guest and primary networks
Is that accurate?
Earlier quoted context omitted.
You would like the film The Conversation (1974) .
Enemy of the State is a pretty good light weight successor of that movie as well. It's such a fun watch too. (RIP Gene Hackman)
Quote (from movie): "just think, all this technology is already twenty years old..."
Much better than The Conversation, but the links were uncanny (including Hackman's line: "yeah this has been my office where I do things for a long time*" — and it's the same set[up]).
EotS honestly has the best death finale scene I've ever seen (not being hyperbolic, the best). Don't want to spoil it }:D ------>
Earlier quoted context omitted.
No, it's experimental. But I run it on all my machines, the only time I've had a problem is when it caught a typo in a DS record.
Nobody has ever disputed that you could run a fully recursive cache on your workstation, only that any ordinary user ever does. You can see at this point how hollow "DNSSEC" is as an answer to the problem of this thread.
Earlier quoted context omitted.
Nobody has ever disputed that you could run a fully recursive cache on your workstation, only that any ordinary user ever does. You can see at this point how hollow "DNSSEC" is as an answer to the problem of this thread.
It's not a full recursive lookup: you don't understand how DNSSEC works. I'm not replying to you any more.
Earlier quoted context omitted.
Yeah, that commercial-grade hardware didn't actually isolate at the PHY-MAC layer is a bit surprising. How would they have working VLANs at the AP?
Fun story, back in uni, if you would spin up a webserver ($ python -m http.server 8000 for example) one could access it from other campuses. We never tried it across countries, but it might (have) worked