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

W.C.A. Wijngaards wouter at nlnetlabs.nl
Fri Jan 27 10:16:24 UTC 2012

Hash: SHA1

Hi Paul,

On 01/26/2012 11:37 PM, Paul Wouters wrote:
> 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.

Yes that would be a user-friendly way to detect that the hotspot is
'open to the internet'.  And if that fails, it is some for a warning
dialog and hotspot_mode.  Until it succeeds, which can have
exponential backoff.

There is then a new requirement for a user-override to insecure mode.
 Sometimes people simply need that, to access a local printer, and
things like that, really a site-configuration issue.  Something also
to store in networkmanager profiles.

Also there is a privacy problem with this page.  What does the probe
send in its http headers to this site (unique numbers?)?  This site
gets to track you because you send it traffic whenever you connect to
the internet?

The site itself could get very high traffic loads, because everyone
downloads the page whenever they switch their wifi.

Due to privacy and traffic load, I did not consider that we could run
such a page ourselves, but then fedoraproject may have a CDN fronting it.

Best regards,
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dnssec-trigger mailing list