Tails

#1 Updated by intrigeri 2018-09-05 11:30:42

• blocks Feature #15334: Core work 2018Q3: Foundations Team added

#2 Updated by intrigeri 2018-09-06 13:31:56

• Assignee changed from intrigeri to segfault

Do you want this one?

#3 Updated by segfault 2018-09-26 22:39:38

• Assignee changed from segfault to intrigeri
• QA Check set to Info Needed

I don’t like the idea of just dropping it. If we don’t set a user agent in curl in htpdate anymore, the user agent will be curl/$CURL_VERSION. This will allow the servers in the HTP pools to deduce that the request comes from curl on Debian Stable (because probably not many other systems use the same curl version as Debian Stable). And because probably not many other systems based on Debian Stable other than Tails will call these exact URLs via curl, the servers can be pretty certain that the request comes from Tails. To me this seems like something we should try to avoid.

Couldn’t we just use the user string that Tor Browser in Tails (and, IIUC, all other 64-bit Linux systems) uses?

#4 Updated by intrigeri 2018-10-03 14:13:33

• related to Bug #16024: Maybe fix getTorBrowserUserAgent added

#5 Updated by intrigeri 2018-10-04 20:48:52

• Assignee changed from intrigeri to segfault

Hi!

> I don’t like the idea of just dropping it. If we don’t set a user agent in curl in htpdate anymore, the user agent will be curl/$CURL_VERSION. This will allow the servers in the HTP pools to deduce that the request comes from curl on Debian Stable (because probably not many other systems use the same curl version as Debian Stable). And because probably not many other systems based on Debian Stable other than Tails will call these exact URLs via curl, the servers can be pretty certain that the request comes from Tails. To me this seems like something we should try to avoid.

Spoofing the HTTP user agent is only relevant for very weak (and mostly passive) adversaries e.g. those who will merely look at web server access logs. If we don’t spoof this info, then these access logs will essentially tell that a Tails system started around time T and was using exit note X. I can live with that. Note that the mere fact we’re not fetching the resources associated with the page we’re fetching can be sufficient to show we’re not a real web browser. Add that we’re connecting via Tor and I think the same analysis as what you did holds: it’s easy to tell that the request comes from Tails.

We should also consider an active attacker who controls one of the servers htpdate queries and is ready to set up an active attack against Tails users (thanks to our htpdate multi-pool design, AFAICT the best they can do is DoS, but whatever). Against such attackers, spoofing the HTTP user agent is not very useful as there are plenty of other ways to fingerprint a HTTP client.

We’ve discussed before using something slightly less obvious than plain curl (e.g. wget + options to retrieve depended-upon resources) but IIRC the conclusion was that it would impact the UX badly and the security benefits were highly disputable.

> Couldn’t we just use the user string that Tor Browser in Tails (and, IIUC, all other 64-bit Linux systems) uses?

We can and I’m fine with it if someone wants to do the work, which includes adding a step to contribute/release_process/tor-browser to update this value.
If you want to take it, feel free to go ahead (and reject Bug #16024). Otherwise reassign to me and I’ll get rid of getTorBrowserUserAgent as proposed earlier.
Your call! :)

#6 Updated by intrigeri 2018-10-08 13:58:15

• blocks Feature #15506: Core work 2018Q4: Foundations Team added

#7 Updated by intrigeri 2018-10-08 13:58:19

• blocked by deleted (Feature #15334: Core work 2018Q3: Foundations Team)

#8 Updated by segfault 2018-10-16 08:30:00

• Assignee changed from segfault to intrigeri

intrigeri wrote:
> > I don’t like the idea of just dropping it. If we don’t set a user agent in curl in htpdate anymore, the user agent will be curl/$CURL_VERSION. This will allow the servers in the HTP pools to deduce that the request comes from curl on Debian Stable (because probably not many other systems use the same curl version as Debian Stable). And because probably not many other systems based on Debian Stable other than Tails will call these exact URLs via curl, the servers can be pretty certain that the request comes from Tails. To me this seems like something we should try to avoid.
>
> Spoofing the HTTP user agent is only relevant for very weak (and mostly passive) adversaries e.g. those who will merely look at web server access logs. If we don’t spoof this info, then these access logs will essentially tell that a Tails system started around time T and was using exit note X. I can live with that. Note that the mere fact we’re not fetching the resources associated with the page we’re fetching can be sufficient to show we’re not a real web browser.

That is true, and I hadn’t realized this before (but I also didn’t work on the time syncing before).

> Add that we’re connecting via Tor and I think the same analysis as what you did holds: it’s easy to tell that the request comes from Tails.

I agree that this already allows the servers to identify requests that were sent from Tails, but only in hindsight. They will only know whether a request was sent from Tails after they replied to it, including the date and links to the resources that won’t be fetched. So at least the fact that the resources aren’t fetched does not allow the servers to reply with a manipulated HTTP date to Tails users only. If we changed the user agent, it would be trivial to specifically target Tails users.

> > Couldn’t we just use the user string that Tor Browser in Tails (and, IIUC, all other 64-bit Linux systems) uses?
>
> We can and I’m fine with it if someone wants to do the work, which includes adding a step to contribute/release_process/tor-browser to update this value.
> If you want to take it, feel free to go ahead (and reject Bug #16024).

I want to do that. As anonym already found out on Bug #16024, it’s not easy to extract the user agent currently used by Tor Browser. So I think the easiest way is to start Tor Browser and see what user agent it is actually sending in requests, like so:

1. Start Tor Browser
2. Open the Network tab in the Developer Tools (Ctrl+Shift+E)
3. Load a website (e.g. tails.boum.org)
4. Select one of the GET requests in the Developer Tools
5. Scroll down to “User-Agent” in the “Request headers” section

But I’m not sure where to include that in the release process in order minimize the overhead. I read contribute/release_process/tor-browser and it currently doesn’t include actually starting Tor Browser. Is there any other step in the release process where Tor Browser is already started, so that we can include this step without too much overhead?

#9 Updated by segfault 2018-10-16 08:58:02

• related to deleted (Bug #16024: Maybe fix getTorBrowserUserAgent)

#10 Updated by segfault 2018-10-16 08:58:06

• blocks Bug #16024: Maybe fix getTorBrowserUserAgent added

#11 Updated by intrigeri 2018-10-16 09:14:23

• Assignee changed from intrigeri to segfault
• QA Check changed from Info Needed to Dev Needed

> I agree that this already allows the servers to identify requests that were sent from Tails, but only in hindsight. They will only know whether a request was sent from Tails after they replied to it, including the date and links to the resources that won’t be fetched.

FTR I think this would be correct if we fetched the entire page. The fact we fetch the HTTP header only (--head) + we connect using Tor is probably sufficient to single out Tails’ htpdate usage and serve a “customized” Date header, even with a relatively cheap investment (and with a bigger investment, as said before, it’s easy to fingerprint HTTP clients so the User-Agent does not matter much).

> I want to do that.

Great! Even if there are other ways to single out Tails users, why not raise the bar a little bit :)

> As anonym already found out on Bug #16024, it’s not easy to extract the user agent currently used by Tor Browser. So I think the easiest way is to start Tor Browser and see what user agent it is actually sending in requests, like so: […]

Yes.

> But I’m not sure where to include that in the release process in order minimize the overhead. I read contribute/release_process/tor-browser and it currently doesn’t include actually starting Tor Browser. Is there any other step in the release process where Tor Browser is already started, so that we can include this step without too much overhead?

I believe there is no such step since we don’t update the uBlock filter lists anymore. But anyway, when one is upgrading Tor Browser, just like any proposed code change, one is expected to do at least a little bit of manual testing, so you can take for granted that they’ll start the new Tor Browser :)

#13 Updated by segfault 2018-10-16 13:17:01

• QA Check changed from Dev Needed to Ready for QA
• Feature Branch set to bugfix/15912-htpdate-user-agent

I added a section in contribute/release_process/tor-browser.mdwn that is ready for review. I also hard coded the current User Agent directly in the config file used by htpdate and removed the two scripts that we used to create this config file. I’m currently building an ISO to test this.

#14 Updated by segfault 2018-10-16 13:17:35

• Assignee changed from segfault to intrigeri

The release process doc part is RfQA

#15 Updated by segfault 2018-10-16 13:54:41

• Status changed from Confirmed to In Progress

Applied in changeset commit:7f43fe409562c8e6eb47530fa8c990564c701dae.

#16 Updated by intrigeri 2018-10-16 15:37:25

• % Done changed from 0 to 50

Pushed a few improvements to the branch, let’s see what Jenkins thinks.

#17 Updated by intrigeri 2018-10-17 07:43:26

• Assignee changed from intrigeri to segfault
• % Done changed from 50 to 80

Passes the (non-fragile) test suite on Jenkins. Please review my additional commits and if happy, merge into stable and then merge stable into devel.

#18 Updated by segfault 2018-10-17 11:25:43

• Status changed from In Progress to Resolved
• Assignee deleted (segfault)
• % Done changed from 80 to 100
• QA Check deleted (Ready for QA)

intrigeri wrote:
> Passes the (non-fragile) test suite on Jenkins. Please review my additional commits and if happy, merge into stable and then merge stable into devel.

Done, thanks for the improvements

#19 Updated by intrigeri 2018-10-17 11:36:28

• Status changed from Resolved to Fix committed
• QA Check set to Pass

> Done,

FYI:

• Next time, please add Fix-committed: <del><a class='issue tracker-1 status-3 priority-4 priority-default closed child' href='/code/issues/15912' title='Deal with getTorBrowserUserAgent not being reliable anymore'>Bug #15912</a></del> to the merge commit message: currently our Git/Redmine integration is half broken (there’s lots of delay until Redmine picks up the changes) but it will be fixed soon via Bug #14587.
• The status should be “Fix committed” because we’ve not released this fix yet.

https://tails.boum.org/contribute/merge_policy/review/ has useful doc about this and other info about what’s expected when reviewing and merging.

> thanks for the improvements

:)

#20 Updated by segfault 2018-10-22 11:56:31

• Status changed from Fix committed to In Progress

Applied in changeset commit:acaad55e767796f4ceba49faab0cf10597dee1fb.

#21 Updated by intrigeri 2018-10-24 16:57:31

• Status changed from In Progress to Resolved