> 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

> 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.

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

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.

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?

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.

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.

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