Re: [Captive-portals] poor captive port design --- A Deep Dive on the Recent Widespread DNS Hijacking Attacks — Krebs on Security

[Michael Richardson <[e-mail]>]

Michael Richardson quoted:
    > From https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/

    > "The two people who did get popped, both were traveling and were on their
    > iPhones, and they had to traverse through captive portals during the hijack
    > period,” Woodcock said. “They had to switch off our name servers to use the
    > captive portal, and during that time the mail clients on their phones checked
    > for new email. Aside from that, DNSSEC saved us from being really, thoroughly
    > owned.”

Christian Saunders <[e-mail]> wrote:
    > The active element here seems to be the forced use of insecure DNS
    > servers.

I disagree.  It's due to forced use of the captive portal's DNS.
A device will in general have no trust relationship with a captive portal.
It has no reason to trust the captive portal to do DNS correctly
(and no way to get privacy for the requests either).

    > The fact that the insecure DNS configuration was forced in order to navigate
    > a Captive Portal is incidental, though unfortunate.

So to me, all captive portal DNS systems are by definition insecure.
If one needs to do a DNS lookup in order to get traffic and get a
redirection, then the portal is insecure.  And that's why we need an API that
involves more than just capture port-80 and redirect.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [