3 ms·

A couple of notes: * This was not a MITM attempt * When traveling laptops, it's more secure to use DNSSEC + Unbound * The author trusts Google with his data,

by atmosx 13y ago

A couple of notes: * This was not a MITM attempt * When traveling laptops, it's more secure to use DNSSEC + Unbound * The author trusts Google with his data, which uses DNSSEC[1], but not DNSSEC because @tptacek said so - fair enough, I trust Dr Bernstein even more than tptacek - but it's a bit contradictory. He should be using OpenDNS which is the only major DNS provider of DNSCurve[2], instead of Google (8.8.8.8 and 8.8.8.4). Also, note, all major DNS providers are collecting data: OpenDNS (also adds a few suspicious redirects when the URL doesn't exist), Google is the leader of world-data mining, etc. The most trustworthy DNS, according to the a research I did some time ago, was/is OpenNIC. At home I run a dnsmasq + unbound (DNSSEC) + OpenNIC DNS's. On my laptop I have a similar configuration which uses by default a local unbound installation when joins every other network except mine. [1] http://googleonlinesecurity.blogspot.cz/2013/03/google-public-dns-now-supports-dnssec.html http://googleonlinesecurity.blogspot.cz/2013/03/google-publi... [2] http://en.wikipedia.org/wiki/DNSCurve#Deployment http://en.wikipedia.org/wiki/DNSCurve#Deployment [3] http://www.opennicproject.org/ http://www.opennicproject.org/

chimeracoder 13y ago
> This was not a MITM attempt I've heard captive portals on here eferred to as MITM attacks, and I think it's an accurate description of what's happening, regardless of the intent of the captor. In this case, they were hijacking DNS requests that were explicitly being made to another provider (first OpenDNS, then Google), and returning their own results instead of OpenDNS's or Google's. From a cryptographic perspective, I certainly would say that it fits the description of an MITM: https://en.wikipedia.org/wiki/Man-in-the-middle_attack https://en.wikipedia.org/wiki/Man-in-the-middle_attack > He should be using OpenDNS which is the only major DNS provider of DNSCurve[2], instead of Google (8.8.8.8 and 8.8.8.4). Actually, I was using OpenDNS initially - I switched to Google because I thought that might be the source of the OpenDNS error I was getting (the very first screenshot - admittedly a bit small to read in the picture). But it doesn't matter which DNS provider you use if they're hijacking traffic on port 53, which is what was happening here. > The author trusts Google with his data, which uses DNSSEC[1], but not DNSSEC because @tptacek said so It's not just "because tptacek says so" - it's because tptacek wrote a detailed critique comparing both services which I found convincing. I updated the post to link to tptackek's post that explains the issue in more detail; that's what I was referring to, but I couldn't find it at first when I wrote the post.
- jrochkind1 13y ago
  If you want to call it an MITM attack, but your browser gives you a cert error, then the most you can say is it's an incompetent, failed MITM attack, right?
- atmosx 13y ago
  IMHO this diversion doesn't classify as an attack. It was not meant to hurt in any way, or at least there's no sign of any harm done in your post. I try to use common sense first, and only afterwards stick to the letter. Not sure exactly that comparing DNSSEC (signatures == trust) and DNSCurve (encryption + signature but only hop_to_hop, not up to root.) makes sense, that's why I said above that unbound + OpenNIC (which I trust and support DNSCrypt). Thanks for taking the time to reply
  - Dylan16807 13y ago
    If the data is changed without the permission of either end party, then it is an attack. There was no 'harm' done to the parties involved, but the 'attack' here is not aimed at the parties, it's aimed at the integrity of the connection. The integrity was completely destroyed, so I think 'attack' is an appropriate term.
eli 13y ago
OpenDNS makes money off those redirects, but you can turn them off if you create an account.
colmmacc 13y ago
There's no reason to think that running your own copy of DNSSEC + Unbound would have helped here. Firstly, Google don't have DNSSEC signed DNS data, which renders the feature moot. But even if google did, DNSSEC would have triggered the same kind of error that TLS did; the knowledge of a false answer. It wouldn't have resulted in a correct answer. DNSCurve is more robust in that respect. It's very hard to tamper with the data stream other than to break it entirely.
- atmosx 13y ago
  Yes but DNSCurve is hop-to-hop and solves a different problem. If you are able to take a over a resolver between the victim and the TLD, you can easily hijack DNSCurve.

by atmosx 13y ago

chimeracoder 13y ago

> This was not a MITM attempt I've heard captive portals on here eferred to as MITM attacks, and I think it's an accurate description of what's happening, regardless of the intent of the captor. In this case, they were hijacking DNS requests that were explicitly being made to another provider (first OpenDNS, then Google), and returning their own results instead of OpenDNS's or Google's. From a cryptographic perspective, I certainly would say that it fits the description of an MITM: https://en.wikipedia.org/wiki/Man-in-the-middle_attack https://en.wikipedia.org/wiki/Man-in-the-middle_attack > He should be using OpenDNS which is the only major DNS provider of DNSCurve[2], instead of Google (8.8.8.8 and 8.8.8.4). Actually, I was using OpenDNS initially - I switched to Google because I thought that might be the source of the OpenDNS error I was getting (the very first screenshot - admittedly a bit small to read in the picture). But it doesn't matter which DNS provider you use if they're hijacking traffic on port 53, which is what was happening here. > The author trusts Google with his data, which uses DNSSEC[1], but not DNSSEC because @tptacek said so It's not just "because tptacek says so" - it's because tptacek wrote a detailed critique comparing both services which I found convincing. I updated the post to link to tptackek's post that explains the issue in more detail; that's what I was referring to, but I couldn't find it at first when I wrote the post.

jrochkind1 13y ago
If you want to call it an MITM attack, but your browser gives you a cert error, then the most you can say is it's an incompetent, failed MITM attack, right?
atmosx 13y ago
IMHO this diversion doesn't classify as an attack. It was not meant to hurt in any way, or at least there's no sign of any harm done in your post. I try to use common sense first, and only afterwards stick to the letter. Not sure exactly that comparing DNSSEC (signatures == trust) and DNSCurve (encryption + signature but only hop_to_hop, not up to root.) makes sense, that's why I said above that unbound + OpenNIC (which I trust and support DNSCrypt). Thanks for taking the time to reply
- Dylan16807 13y ago
  If the data is changed without the permission of either end party, then it is an attack. There was no 'harm' done to the parties involved, but the 'attack' here is not aimed at the parties, it's aimed at the integrity of the connection. The integrity was completely destroyed, so I think 'attack' is an appropriate term.

eli 13y ago

OpenDNS makes money off those redirects, but you can turn them off if you create an account.

colmmacc 13y ago

There's no reason to think that running your own copy of DNSSEC + Unbound would have helped here. Firstly, Google don't have DNSSEC signed DNS data, which renders the feature moot. But even if google did, DNSSEC would have triggered the same kind of error that TLS did; the knowledge of a false answer. It wouldn't have resulted in a correct answer. DNSCurve is more robust in that respect. It's very hard to tamper with the data stream other than to break it entirely.

atmosx 13y ago
Yes but DNSCurve is hop-to-hop and solves a different problem. If you are able to take a over a resolver between the victim and the TLD, you can easily hijack DNSCurve.