> 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, rega

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