[Dnssec-trigger] bugzilla can be used to file dnssec-trigger bug reports via the web browser

Paul Wouters paul at nohats.ca
Thu Jan 26 22:37:55 UTC 2012

On Thu, 26 Jan 2012, W.C.A. Wijngaards wrote:

> There are two insecure modes right now:
> hotspot mode: use chose hotspot mode to sign in. stay insecure until
> reprobe menu item.
> insecure dialog: probe failed, insecure dialog shown to user (disconnect
> or insecure?).  Silent reprobes with timeouts in the background (with no
> popups, but if secure, takes it).

Ahh, I did not realise the difference.

> Yes, if the insecure-ness was because of a failed probe, then an
> exponential backoff timer is implemented today.
> If insecure-ness is because user chose hotspot-mode we keep that mode
> until the user clicks to exit it.  Because, as Stephane found out, some
> hotspots can have DNSSEC (via some workaround), but then you cannot
> actually sign-on anymore (that uses the insecure local cache).
> This user hotspot and reprobe menu item thing works with you tech-guys,
> but it is difficult.  I would like something easier, but I do not know
> how to help the user here.  To dnssec-trigger everything may seem to be
> fine (dnssec with some workaround, yay), but then the web browser cannot
> connect anywhere and cannot sign-in either ...

> Somehow know that 'hotspot signon' mode is necessary, and sign-in
> completion can trigger a reprobe somehow...

You should detect hotspot mode not based on DNS but based on web
traffic. This is how apple (and I assume android) does it. For
example, check http://nohats.ca/hotspot/

That should always return a page just containing "OK". If it returns
ANYthing else, a redirect, a 404, or different html, you're on a
hotspot. I am going to add such a super static page to the fedoraproject
infrastructure that we will be able to test with that is more highly
available then my single server instance, but it can be used for
testing code.


More information about the dnssec-trigger mailing list