Feature #5461
Persistence preset: Tor configuration
0%
Description
Team: ?
It would be great to be able to have persistent Tor settings, e.g. bridges and anything that can be configured via Tor Launcher.
Comments:
- This makes sense. If a user wants to use only bridges to connect to the Tor network it makes sense to be able to store their bridges as a persistence option. I currently save my bridges in a text file in the persistent storage and manually enter them into Vidalia, and use the "bridge" parameter when tails first starts booting. There seem to be problems with tordate and tor not connecting quickly enough for the tordate script(s) when using bridges.
Subtasks
Related issues
Related to Tails - Feature #5462: Persistence preset: Tor state | Confirmed | 2016-08-26 | |
Related to Tails - Feature #10491: Redesign the network configuration and startup | Confirmed | 2014-06-22 | |
Related to Tails - Feature #14544: Spend software developer time on smallish UX improvements | In Progress | 2018-08-31 | |
Related to Tails - |
In Progress | 2014-11-08 | |
Related to Tails - Feature #15331: Support automatic bridge retrieval in Tor Launcher (Moat) | In Progress | 2017-12-12 | |
Blocks Tails - Feature #8825: Provide default bridges | Confirmed | 2015-01-30 |
History
#1 Updated by intrigeri 2013-10-04 08:14:42
- Category set to Persistence
- Starter set to No
#2 Updated by coolnodje 2014-05-07 02:17:29
Especially in a web censored country where https://bridges.torproject.org/ is blocked, it’s such a hassle to set up a working Tails (you need to already have an uncensored connection, unlikely for a random user) that you really want to have a persistent Tor setup.
#3 Updated by coolnodje 2014-05-07 02:23:44
I’m willing to help to get this working as it’s really the last missing bit to get a usable distrib in my situation.
Where to start? Without any prior knowledge about Tails, from the way it works, I guess the problem is that nothing can be made persistent. If right the question becomes: is there any system that allow for reading external data in place? Could we read a file containing bridges that would be on the USB key, along with the disturb?
If not, then it’d be easy to write the Tor config somewhere on the filesystem, like it’s usually done.
Directions welcome.
#4 Updated by intrigeri 2014-05-07 16:54:21
> I’m willing to help
Great!
> Where to start?
https://tails.boum.org/contribute/how/code/ and
https://tails.boum.org/contribute/design/ :)
> Without any prior knowledge about Tails, from the way it works,
> I guess the problem is that nothing can be made persistent.
This is not correct:
- https://tails.boum.org/contribute/design/persistence/
- https://tails.boum.org/doc/first_steps/persistence/
If someone wants to implement this, I would suggest to start with
a design that stores the list of bridges in a file at the root of the
persistent volume, and uses it to re-configure Tor at login time (see
how the additional software code does something very similar).
Note that the UX needs some care here: if this feature is enabled,
most likely we don’t want to run Tor Launcher.
#5 Updated by BitingBird 2014-06-09 10:50:55
- Subject changed from persistence preset - bridges to Persistence preset - bridges
#6 Updated by intrigeri 2014-07-20 14:51:30
- Subject changed from Persistence preset - bridges to Persistence preset - Tor configuration
- Description updated
#7 Updated by garrettr 2015-02-18 19:49:44
Another use case for Tor configuration persistence would be support for authenticated Tor Hidden Services (ATHS). In order to access an ATHS, you need to add a corresponding “HidServAuth” line to your torrc. It would be nice if we could automatically add such lines to the Tails torrc and reload Tor so it picks them up on boot. I think this could easily be added to the design suggested in #4.
#8 Updated by BitingBird 2015-03-14 13:59:06
- Subject changed from Persistence preset - Tor configuration to Persistence preset: Tor configuration
#9 Updated by intrigeri 2015-03-15 10:32:25
- related to Feature #8825: Provide default bridges added
#10 Updated by anonym 2015-06-03 20:44:54
- related to deleted (
Feature #8825: Provide default bridges)
#11 Updated by anonym 2015-06-03 20:45:06
- blocks Feature #8825: Provide default bridges added
#12 Updated by sajolida 2015-08-14 12:19:34
- Description updated
- Target version set to 2017
#13 Updated by sajolida 2015-11-06 03:51:10
- related to Feature #10491: Redesign the network configuration and startup added
#14 Updated by kurono 2015-12-02 10:25:05
- Assignee set to kurono
#15 Updated by intrigeri 2016-06-10 06:27:32
I’m told that those working on this project will need to have a good look at https://trac.torproject.org/projects/tor/ticket/12600.
#16 Updated by sajolida 2016-06-16 10:11:30
Thanks for the pointer. I subscribed to this ticket and pointed back to our related efforts.
#17 Updated by Dr_Whax 2016-08-20 12:34:19
- Description updated
- Assignee deleted (
kurono) - Priority changed from Normal to Elevated
- Target version deleted (
2017)
#18 Updated by Anonymous 2018-08-19 10:23:49
intrigeri wrote:
> I’m told that those working on this project will need to have a good look at https://trac.torproject.org/projects/tor/ticket/12600.
“These tickets, tagged with 034-removed-*, are no longer in-scope for tor 0.3.4. We can reconsider any of them, if time permits.”
#19 Updated by sajolida 2019-08-07 11:06:08
- related to Feature #14544: Spend software developer time on smallish UX improvements added
#20 Updated by intrigeri 2019-08-08 11:15:06
- related to
Feature #8243: Support meek bridges added
#21 Updated by intrigeri 2019-08-11 17:51:49
- related to Feature #15331: Support automatic bridge retrieval in Tor Launcher (Moat) added