Thinking about this a bit more, it seems to me that the advice that
should be followed in the case of a captive portal is this:
- You must make it possible to resolve any names required to register
using DNSSEC, whether you support DNSSEC or not.
- You should support DNSSEC
- You must make it possible to do all appropriate validation for any SSL
certs that are required to validate the connection to the portal.
- You must use SSL for the portal, and you must use validate-able certs.
My concern is that while this is really good advice, there's no real
incentive in place to get the captive portal vendors to implement this
nor to get the captive portal providers to require it or set it up
correctly. There is some small cost to supporting broken portals, but
by and large laying this cost off on the end user works.
Similarly, as you say, the host software provider has no incentive to
require this functionality: for the most part, it simply makes life
difficult for the end user. At present, Google is actually pretty good
about this; the result is that it's hard to use Google devices on
networks with broken captive portals, which are of course endemic.
Google seems not to have paid a price for this thus far, but I don't see
other vendors doing what Google is doing.