Rick Moen <r...@linuxmafia.com> wrote: >> That latter point means that you go to https://myfavouritewebsite.com >> and no you don't get the portal page - you get a certificate warning. >> Given that most people these days will have https URLs cached in their >> browser, you have to manually and explicitly try and connect to a site >> (doesn't matter what, any random URL will do) over HTTP. > > Counter-tactic: If you're in a place (hotel, motel, conference centre) > where you suspect there might be a captive portal, fire up first an > _alternate_ Web browser (after temporarily disabling one's bespoke > choice of DNS nameserver IP), and try to load something, to see if the > captive portal page shows up. After navigating any captive portal, > switch to your production-use Web browser. > > Equivalently (I think?), use a private-browsing tab for the first page > load.
Indeed, a number of ways around the problem. I usually just open up a new window and navigate to (not literally) http://some_site_I'm_not_going _to_use so I don't poison the system DNS or browser page caches for any site I am planning to use. Doesn't help for all the stuff that automatically tries to connect in the background and starts popping up certificate error messages while you are trying to get the problem fixed. The last thing anyone wants when there's a problem you are working on is more alerts telling you about the problem ! Mind you, not all captive portals work that way. I've seen at least one that gives you genuine DNS results, but intercept the port 80 traffic (and I assume block the rest). A "VPN over DNS" tunnel would probably be a workaround, but I've never been bothered enough by this one to make the effort worthwhile - the only time I recall seeing it was many years ago when I was abroad with work. Simon _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
