39 ms·
The DNS lookup would be of the form "request PTR record for 128.2.1.2" - this would leak a little info from the nearest recursing resolver, but maybe not enough
by sk5t 7y ago
The DNS lookup would be of the form "request PTR record for 128.2.1.2" - this would leak a little info from the nearest recursing resolver, but maybe not enough to be useful to an attacker. I suppose Snitch might conceivably use some other, non-DNS repository like ipinfo.io though.
- m463 7y agoI think I disagree. It would be: - browser looks up 2020-01-31-user-kstrauser.example.com - dns lookup proceeds, returns 128.2.1.2 - browser connects to 128.2.1.2 - little snitch intercepts - little snitch does reverse lookup - dialog box
- beagle3 7y agoI don’t know how little snitch does it, but iirc our old fortinet at the office caches the DNS response for logging, so that no extra reverse dns requests are needed (and if there isn’t a cached one, you have to explicitly ask to look it up when looking at the logs)
- labawi 7y agoFrom a quick look in opensnitch, it should be tracking DNS replies in UDP packets. I don't see it filtering the responses, so spoofing hostnames or even overloading the translation table (memory exhaustion) might be possible, even for network attackers.
- vetinari 7y agoIt is best effort anyway, just informative. If the app resolves two hostnames (e.g. useful-serivce.cloudprovider.com and malware.cloudprovider.com), that are both at the same ip, and then connects to that ip, which of the hostnames it connects to? Without sniffing Host header (for http) or SNI (for TLS pre-ESNI), it is just a guess.