Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
B
blueprints
  • Project overview
    • Project overview
    • Details
    • Activity
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
Collapse sidebar
  • tails
  • blueprints
  • Wiki
  • detect_captive_portals

Last edited by intrigeri Jan 12, 2021
Page history

detect_captive_portals

tails#5785

  • Open questions
  • Tools
    • Using WWW::Mechanize::Shell
    • Existing hotspot connection applications
    • Captive portal detection
  • Beta testers

For users that haven't read the documentation about the unsafe browser and/or just don't understand when it's necessary, it would be good if Tails does a reasonable job to try to detect whether a captive portal seems to be in place and notify the user if so. The approaches could range from simplistic to more sophisticated:

  • If wait_for_tor_consensus() fails during time syncing. Note that this would happen if Tails is booted on a LAN without Internet connection.
  • Use ooni-probe?
  • Other approaches.

The method used likely has to be active, but it should preferably hook into some common, innocent looking network connection in order to avoid fingerprinting.

Open questions

  • Is it OK to be more fingerprintable by checking (without Tor) whether a captive portal is sitting in the way?

  • Related question: how much is Tails fingerprintable as Tails by a network attacker (ISP), as opposed to being fingerprintable as "someone using Tor Browser"?

  • How shall we integrate the captive portal browser on the desktop in case we need to get back to it (to log in again, to log out)?

    • Lunar's proposal: as a detached windows
    • other possibility: invisible browser by default, can be displayed again somehow

Tools

Using WWW::Mechanize::Shell

For each kind of hotspot:

  • list of possible ESSID
  • optional: allocated IP address classes
  • optional: network test script?
  • optional: SSL certificate fingerprint?
  • a WWW::Mechanize::Shell script

Main script in in /etc/NetworkManager/dispatcher.d.

Test current connection against known hotspots.

When connected to a known hotspot, starts WWW::Mechanize::Shell script. Values are entered through a callback than will uses Gtk2::Notify and some custom widgets. Known login/passwords should be put in gnome-keyring with a browser like completion system (enter first letters, pick login, password is prefilled). Maybe we could use the same login/password database as Epiphany.

For hotspots that requires a periodic refresh, we can run another WWW::Mechanize::Shell script in a loop. NetworkManager is meanwhile monitored through DBUS to kill the loop if connection is lost. If loop fails try once more through default script before displaying a notification.

Existing hotspot connection applications

Looks like there is at least two Python apps doing this already:

  • autowifi
  • autologin-applet

Captive portal detection

hellais and friends are working on ooni-probe which may be interesting, depending on how stealthy the probe is.

  • RFC 7710, aka. Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
  • Subgraph OS's defector
  • Elementary OS' Captive Portal Assistant
  • https://help.gnome.org/misc/release-notes/3.14/
  • https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection
  • https://android.stackexchange.com/questions/82977/cyanogenmod-and-privacy
  • http://blog.superuser.com/2011/05/16/windows-7-network-awareness/
  • https://msdn.microsoft.com/en-us/library/windows/hardware/dn408681.aspx

Beta testers

  • San Bergmans info@sbprojects.com: FON network, KPN hotspots in the Netherlands
Clone repository
  • Home
  • Monthly reports
  • Sandbox