Bug #17525

obfs4 documentation does not mention the need for a hardware clock set to UTC

Added by intrigeri 2020-03-15 10:23:56 . Updated 2020-03-27 09:46:10 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Tor configuration
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
End-user documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

It feels a bit weird that to learn about one of the most common issue with bridges, a user has to figure out that it’s documented on “known issues” but not on the page about bridges.
I’m wondering if https://tails.boum.org/doc/first_steps/startup_options/bridge_mode/ should link to https://tails.boum.org/support/known_issues/#utc.


Files


Subtasks


Related issues

Related to Tails - Bug #15548: Tails can't establish a connection with obfs4 bridges and a hardware clock too far away from UTC Confirmed 2018-05-09
Related to Tails - Feature #15599: Improve known issues about clock going backwards Resolved 2018-05-09

History

#1 Updated by intrigeri 2020-03-15 10:24:14

  • related to Bug #15548: Tails can't establish a connection with obfs4 bridges and a hardware clock too far away from UTC added

#2 Updated by intrigeri 2020-03-15 10:24:21

  • related to Feature #15599: Improve known issues about clock going backwards added

#3 Updated by sajolida 2020-03-24 21:19:14

Indeed, we should mention this issue on
/doc/first_steps/startup_options/bridge_mode/.

Still, let’s be clear that the current known issue is crap, so the extra work of making it more visible as is will probably be helpful to very few people and might even be dangerous:

  • We don’t tell how far is too far East from UTC.

Someone on Tor#32439 reports that UTC+3 is already problematic.
Do we have a way of knowing how far East is too far?

  • I bet that Tor Launcher can get stuck on “Loading Network Consensus”
    for other different reasons: at least bad or slow network, maybe
    censorship (I’m guessing).
  • The workaround that we are pointing to currently is to hack the
    Windows registry. Something that very few people will know how to do and
    that might vary depending on the version of Windows. I’m afraid that people
    could break their Windows if they applied a wrong variant or didn’t
    apply it correctly. We could still keep it as an alternative for power users
    but only if we had something better.

We could:

1. Only explicit the problem but not mention the registry hack anymore. Maybe it’s better than nothing. Something along the lines of what we already have:

If you are East from UTC, connecting to Tor using `obfs4` bridges might be impossible and Tor Launcher might get stuck on Loading Network Consensus.

2. Instruct people to try setting their Windows on UTC from the UI. I tested this on Windows 10. The result is less convenient than hacking the registry but it’s way easier to perform and potentially less dangerous. People could test whether this solve their problem. If it does, they could either do the change when needed or configure another display clock for their local time. As you can see, not a really great solution either.

Below are some screenshots of this process.

Honestly, the situation of Tails with bridges has been very bad since pretty much forever because we lack development resources. I’m not sure that investing several hours of Technical Writing into this would make a significant difference so I’m tempted to go for 1 and forget about it.

intrigeri + cbrownstein: What do you think?

#4 Updated by intrigeri 2020-03-27 09:46:10

Hi,

> * We don’t tell how far is too far East from UTC.
>
> Someone on Tor#32439 reports that UTC+3 is already problematic.
> Do we have a way of knowing how far East is too far?

My understanding is that anything strictly more East than UTC+1 is enough to break obfs4.

I agree that the registry hack is too hard/dangerous for many people.
I think option 2 has too far-reaching problematic UX consequences that IMO it’s not worth the tech writing effort.

> Honestly, the situation of Tails with bridges has been very bad since pretty much forever because we lack development resources. I’m not sure that investing several hours of Technical Writing into this would make a significant difference so I’m tempted to go for 1 and forget about it.

Realizing that it’s where we are at hurts a bit, but I have to agree with you here.

In passing, taking a step back:

  • I don’t know if the ongoing work on Meek support will solve this. If Meek is not affected by this problem like obfs4 is, then supporting Meek would make this obfs4 problem less important for users in places where Tor is blocked, such as potentially Riou.
  • If Meek does not solve the problem, then I think we’re back to what I wrote on Bug #15168: “So the only way we can improve things in this situation is via Feature #5774 (more specifically, the part of the plan where we ”[let] the user set the correct time and choose their preferred timezone" whenever Tor fails to bootstrap" “and/or via the ”Integration with the new Greeter" part of that plan. Both refer to https://tails.boum.org/blueprint/robust_time_syncing/."
    Note that on https://tails.boum.org/blueprint/network_connection/, we’ve postponed this to “Potential extra iterations”.