Skip to content

GitLab

Last edited by sajolida
Page history

network_connection

title: Network connection (configuration and startup)

This is about tails#10491 (closed).

Current issues in Tails

  • A. After Tails Greeter, it might be hard for some people to understand where to click on the GNOME desktop to connect to a Wi-Fi network.

  • B. It's impossible to go from direct Tor connection to bridge mode in case you realize once in the session that you actually need bridges to connect.

  • C. It's hard to know whether you need to log in through a captive portal. (tails#5785)

  • D. There's no way of triggering Tor to reconnect after logging in through a captive portal, except by closing the Unsafe Browser (which is not obvious).

  • E. Once cannot set up bridges if they need the Unsafe Browser (to log into a captive portal or to get bridges), if they close the Unsafe Browser (that restarts Tor which breaks Tor Launcher). Too bad, for non-bridge use cases one has to close the Unsafe Browser to make Tor connect. (tails#11535 (closed))

  • F. It can be scary for people who cannot afford connecting without obfuscated PTs (to hide they're using Tor) to postpone this choice after the session is started.

  • G. Bridges, firewall and proxy have to be configured again each time. (tails#5461)

  • H. It's not clear how one is supposed to get bridges if they need some.

  • I. One can't get bridges automatically if one needs some to connect. (tails#15331)

  • J. There is no visual feedback on whether the connection to Tor is making progress.

  • K. If MAC spoofing fails but I decide that it's OK not to spoof MAC in my situation, then I have to reboot Tails all the way.

  • L. The Unsafe Browser allows to retrieve the public IP address by a compromised amnesia user with no user interaction. (tails#15635)

  • M. No audio in Unsafe Browser breaks accessible CAPTCHAs. (tails#16795)

  • N. People use the Unsafe Browser to browse the Internet.

  • O. A persistent network connection is associated to a specific network interface (via its MAC address) so it cannot be reused easily when hoping between computers with the same Tails. (tails#10803)

  • P. People who cannot afford connecting without obfuscated PTs (to hide they're using Tor) have very little margin for error: if they forget to choose the right option in the Greeter, their last chance is to notice their mistake before connecting to a network (which might be automatic).

  • Q. Hard to connect using PTs when the computer's hardware clock is not set to the current, correct UTC time (tails#15548, upstream issue)

    This is one of the top complaints we get from censored users. tor's improvements wrt. accepting a consensus that's a little in the past or in the future should help, but will probably not fix all these problems, that stem from the fact Tails can't easily tell whether the hardware clock is in UTC or local time, combined with the fact Tails can't tell what the local timezone is.

Open questions

  • How is the status/progress displayed to the user (in the app and/or via notifications and/or via a status icon in the top bar)

  • What's left from this configuration process on the desktop after Tor is started?

  • Do we allow changing or visualizing the current settings?

  • In the current mockups, to use a wired DHCP connection or a Wi-Fi network saved in persistence with the default settings (direct Tor, MAC spoofing), one needs to click twice. While in current Tails, it works automatically with no user interaction. Both have pros and cons.

  • Once Tor settings can be persisted, will the new Tor Launcher still be opened automatically on startup (with the persisted settings configured)?

  • Do we handle the use case that a user who persistently stored the setting to connect without a bridge / without obfuscation wants to configure a bridge / obfuscation for a session before any connection is made to Tor (because their situation / threat model has changed and they cannot afford connecting to Tor directly anymore)?

Out of scope

  • Adversary who blocks access to the captive portal they control once they notice you're using Tor: they can as well forbid your MAC address from connecting to their Wi-Fi AP.

  • People who have to disable MAC spoofing all the time as this is pretty uncommon, cf. tails#16385 (closed)#note-5. As long as they can do this manually every time they start Tails (as they do currently), or for each new Wi-Fi network they connect to, that will be good enough. That is, we don't improve UX for this use case, but we don't make it worse either.

  • Problem O: it's fully orthogonal to the other problems and the solutions to it are orthogonal to the solutions envisioned for the other problems.

Iterations

First batch

  1. Enable "bridge mode" by default and remove it from the Welcome Screen — tails#17330 (closed)

    That is, start Tor Launcher on every connection to a network, if we never successfully connected to tor during this session, or if our last attempt to connect to tor during this session failed.

    And then:

    • Don't restart Tor anymore when exiting the Unsafe Browser, otherwise this breaks Tor Launcher.

    • If time allows, we can consider removing the "Tor is ready" notification, now that we have feedback wrt. the status of connecting to Tor (tails#8061).

    • Solves issues: B, J.

    • Improves issues:

      • P: the prompt for bridges will get in your way while connecting to the network, which is better than the current workflow where you have to remember to activate it in Tails Greeter
      • C: you know it's not worth waiting longer
      • D and E: Tor Launcher lets you retrigger tor bootstrap, either manually or after a timeout

    • Bonus points: makes UX closer to the one in regular Tor Browser.

    • Worsens issues: F (temporarily and for 1st time users affected by issue F, until they understand that the new behaviour behaves by default, all of the time, in they way they had to opt-in for previously). → Add a temporary note about the change in Tails Greeter.

    • Cost:

      • Need to deal with tor's sandbox settings (currently we disable it in bridge mode) or accept losing some security here.
      • How to tell Tor Launcher that last settings failed and it needs to prompt for manual config again. Does Tor Launcher load previous settings from torrc / via the control port, or does it store them somewhere itself?
      • Test suite needs quite a bit of updating wrt. waiting for Tor to be ready.
      • Needs new automated tests for the handling of the various failure modes (whether or not we start Tor Launcher again on 2nd and further connections).
      • Doc probably needs updates.

  2. Persistent Tor settings — tails#5461

    • Let's assume here that iteration 1 is done already.
    • Solves issues: G.
    • Improves issues:
      • F (increases user confidence in Tails consistently doing what they need)
      • P (not fully solved as the user still can forget to unlock their persistent volume in the Greeter; we could improve further via tails#15573)
    • Cost:
      • Needs sync'ing relevant torrc settings to a persistent file, and back.
      • Needs Tor Launcher to load these settings but that should be handled by iteration 1 already.
      • Needs new automated test scenarios: persisting settings initially, updating persistent settings (in the live environment and in persistent storage), clearing them up.
      • Doc needs updates.

    Shall they be global or per-network? Per-network is vastly harder to implement and makes UX more complex. Per-network could be useful for:

    • I want to hide I use Tor for this place → solved by iteration 1: as long as Tor Launcher pops up and I get to choose whether I want to diverge from my usual, persistent settings.
    • I need to use a proxy when I'm in this place → solved by iteration 1 (same as above).
    • The ISP in this place blocks Tor and I'd rather not use bridges everywhere else as I don't need them (but it does not hurt much) → solved by iteration 1 (same as above).

    ⇒ No, we won't do per-network persistent Tor settings, but global ones.

    With respect to allowing the user to revisit their choices that were persisted: we'll always persist the last choice. We will not give the user the option of using different settings today without modifying persistent ones.

Potential extra iterations

Not ordered yet.

  • Automatic bridges/PTs retrieval (Moat) — tails#15331

    • Solves issues: H, I
    • Bonus points: UX closer to Tor Browser's
    • Benefit seems marginally higher than persistent Tor settings for our personas.
    • Cost: at first sight, vastly higher than persistent Tor settings
    • Blocked by Meek (to be verified)

    While designing/implementing solutions, keep Snowflake in mind (tails#5494): it might require similar kludges to Moat, so better use kludges that will work for both.

  • Better UX wrt. clock & timezone — tails#5774

    Current design & iterations probably needs an update.

    • Solves issues: Q
    • Benefit: higher than Moat (would be ridiculous to help folks get PTs if they can't connect to tor via these PTs)
    • Cost: to be evaluated in order to prioritize this vs. Moat

  • Include configuration with default bridges/PTs — tails#8825 (closed)

    Why we want to do it: it will make Tails work out-of-the-box for some censored users, while currently they need to find out how to get their own bridges before they can even try using Tails, which is discouraging.

    Why it's not trivial: as long as using custom bridges requires typing them every time they start Tails, users will use the default ones. So in order not to overuse these default bridges/PTs, this feature requires allowing Tails users to configure their own bridges/PTs in a persistent manner; and/or perhaps Moat support too, in order to encourage them even more to use their own bridges/PTs.

    But once we have Moat and/or persistent Tor settings, this should be mostly trivial: removing the code we have that disables the default bridges/PTs condition (and encouraging to get their own bridges and use persistence in this context?).

    • Solves issues: I

  • Support Meek bridges

    Why we want to do it: it will make Tails work in some places that block other kinds of bridges.

    This requires first including configuration with default bridges/PTs and allowing Tails users to configure their own bridges/PTs in a persistent manner. Otherwise, if the only default bridges/PTs available by default are the Meek ones, users will (over)use them even in situations where other kinds of bridges would work just fine for them.

    • Cost: low (remove code we have that disables Meek default bridges)

  • Replace GNOME UI to connect to new networks with our own.

    Is this still useful given previous iterations dismiss the per-network settings approach? Or can we skip the "select a network" step of our mockups and jump to the "Tor configuration mode" once we've connected to a network?

    • Solves issues: A, F (not current mockups but doable)
    • Can probably be solved in other ways.

  • Option "I want to hide the fact that I'm using Tails and use Tor bridges on every network."

    • So we can jump to manual Tor configuration directly.

    • So we can avoid probing captive portals too early.

    • Solves issues: F

  • Display a locked-down browser to log into a captive portal when needed

    See blueprint on captive portal detection.

    And remove the Unsafe Browser.

    • Solves issues: C, D, E, L, N (some of then only if we require the user to tell this system once they have successfully logged in; some of them only if we can keep this window somehow open for captive portals that require a permanent connection to them)
    • Related to:
      • Wayland in Tails 5.0 (Bullseye) (tails#12213)
      • Problem M: audio should work in that locked-down browser

  • Persistent Tor state — tails#5462

    See blueprint on persistent Tor state.

    Related but orthogonal.

Dismissed ideas

  • Tails suggests disabling MAC spoofing if it fails

    • Solves issues: K
    • Note that "People who have to disable MAC spoofing all the time" is out of scope.
    • Cost: same as moving MAC spoofing to per-network (hard to get right)

  • Move "Disable networking" and MAC spoofing from per-session (Greeter) to per-network. Optional, can happen at the end or never, not needed by anything else. Probably the hardest to get right on the implementation side.

    • Solves issues: K
    • Makes harder: P

Process

Related work

At Tor

At Whonix

UX design

Onion menu

Expand the onion menu to provide feedback on the status of the connection to Tor:

onion_menu_-_not_connected

onion_menu_-_connecting

onion_menu_-_without_bridges

onion_menu_-_with_bridges

Pop up the onion menu when the Wi-Fi gets disconnected:

onion_menu_-_disconnected

onion_menu_-_reconnecting

Add a disabled Wi-Fi icon when the Wi-Fi is not connected:

onion_menu_-_no_wi-fi

See (tails#13274).

Tor Connection assistant

The Tor Connection assistant can be opened from:

  • Onion icon → Open Tor Connection Assistant
  • Applications → Tor Connection

applications

Empty template:

tor_connection_-_empty

The following screenshots correspond to the content of the right part of this template.

Without hardware Wi-Fi

tor_connection_-_everything

tor_connection_-_no_wi-fi_hardware

Without connection to a local network

tor_connection_-_everything

tor_connection_-_no_local

Consent question

We ask the user to choose between autoconfig and hiding Tor:

tor_connection_-_everything

tor_connection_-_question

If the user chooses autoconfig, we give them an option to configure bridges anyway:

autoconfig_-_bridges_option

Toggle this help below:

autoconfig_-_bridges_option_help

Autoconfig

If the user chooses autoconfig, we automate as much as we can:

We can display some progress of the connection on each screen:

autoconfig_-_internet_access

Image on the left pane

We change the image on the left pane to avoid confusion with the term "bridges".

autoconfig

Autoconfig with bridge option

autoconfig_-_bridges

Captive portal

autoconfig_-_captive_portal

Connecting to Tor without bridges

autoconfig_-_direct

Connecting to Tor with default bridges

autoconfig_-_default

Connecting to Tor with custom bridges

autoconfig_-_custom

Success

tor_connection_-_success

Reset Tor connection

tor_connection_-_reset

Hide Tor

If the user chooses to hide Tor, we don't automate anything nor use default bridges.

As a consequence, we cannot display the same progress indicator like we do for autoconfig.

Image on the left pane

We change the image on the left pane to avoid confusion with the term "bridges".

hide

Bridges

We always use bridges:

hide_-_bridges

Clicking Cancel goes back to the million dollar question.

Moat

Starting Moat:

moat_-_start

Captcha:

moat_-_captcha

Success:

moat_-_success

Help to saving persistent bridges:

persistent_storage_-_help

Failure:

moat_-_failure

Persistent bridges

Persistent bridges are proposed by default and the label is changed to Use instead of Type in:

hide_-_persistent

Connecting to Tor

hide_-_connecting

Failure

  • Time sync

    If we have IP connectivity to the bridge but cannot connect to Tor, it's probably a time sync issue:

    hide_-_time

  • Captive portal or proxy

    If we don't even have IP connectivity to the bridge, we might be behind a proxy or captive portal.

    hide_-_failure

Persistent Storage

Mention Tor bridges in the first screen of the Persistent Storage settings:

persistent_storage_-_discovery

When creating the Persistent Storage coming from a switch that turns on persistent bridges, for example, display a button to skip configuring all the features of the Persistent Storage:

persistent_storage_-_create

persistent_storage_-_only_save

Network features:

persistent_storage_-_network

Welcome Screen

Offline Mode:

welcome_screen_-_offline_mode

Change management to replace the Network Configuration setting:

welcome_screen_-_change_management

Tor Browser

When Tor is not connected:

tor_browser_-_proxy_error

Alternative UX with or without the Persistent Storage redesign (tails#11529)

hide_-_persistent

  • With the Persistent Storage redesign:

    • The switches that turn on the persistent bridges are always displayed.
    • If there is a Persistent Storage already, the switch turns the feature on and off.
    • If there is no Persistent Storage yet, the switch launches the Persistent Storage creation.

  • Without the Persistent Storage redesign:

    • If there is a Persistent Storage already, the switches are displayed.

    • If there is no Persistent Storage yet, the switches are not displayed. We display a help text below the textarea used to enter brigdes:

      To save your bridges, [create a Persistent Storage](https://tails.boum.org/doc/first_steps/persistence) on your Tails USB stick.

    • We might add or not add a switch to the Persistent Storage settings.

      This would require intrigeri to add Perl backend to reflect the existence of a bridges.conf configuration file instead of a mount point, as of now. We can live without this and only offer switches in the Tor Configuration assistant.