Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 974
    • Issues 974
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 26
    • Merge requests 26
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #15548
Closed
Open
Issue created Apr 20, 2018 by goupille@goupille2 of 2 checklist items completed2/2 checklist items

Tails can't connect to obfs4 bridges with a hardware clock East from UTC

Upstream issue: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4/-/issues/32439

Originally created by @goupille on #15548 (Redmine)

Several users reported having issues with obfs4 since a few weeks. I tried with the following bridges


obfs4 76.74.178.195:9443 406A8B5869B72221036291407EC3688C69995F80 cert=FY2R16JOoE2VNCU2gVLWBj6Gg+YBP7mTLU5zl12Fz9iC5TQG6SqE71CFhD3zIuJcEFrcMQ iat-mode=0
obfs4 91.89.79.175:43099 681DD069768F8DF5C94284FFE8CEA600C6EAFB86 cert=Dux9bBro6xfxb7rUr8wdp0TephA7wMV0MjPMAcNqkU/r1Q+56EpHypOFZHRZFDukZNCHYg iat-mode=0
obfs4 34.203.58.40:9443 A3C8B95009DB61BE34B2628C9B9B4E66FCA32FA3 cert=etaJXxltJNQxJlKxVgGXWakop242cHNtzxG/GKroXYPTlzvmsYh818WrcIJ5cZ4DbZREJA iat-mode=0

and ended up with Tor launcher stuck on “Loading Network Consensus” for at least 15 minutes. I saw this behaviour two times on three trials.

I attached a whisperback report and the content of /var/log/tor/log, they are showing a weird jump back in the time :

Apr 20 14:17:56.000 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for connect response' state. Sending it anyway. package_partial=1, buflen=214
Apr 20 14:17:56.000 [info] handle_control_authenticate(): Authenticated control connection (23)
Apr 20 11:30:00.000 [notice] Interrupt: exiting cleanly.
Apr 20 11:30:00.000 [info] or_state_save(): Saved state to "/var/lib/tor/state"

Design

We designed an UI for manual time sync when people choose to hide Tor:

If we can't determine whether we have IP connectivity to the bridge, we might have to add captive portal configuration to the dance and I should go back to the drawing board.

Follow-up tasks

  • check if the MR closes #11589 (closed); if it does, remove the fragile tag in tor_bridges.feature
  • check if the MR closes #5394 (closed) as well: !542 (merged) does

Attachments

  • bug report - obfs4
  • journal.txt
  • torlog.txt

Related issues

  • Related to #15743 (closed)
  • Related to #16972 (closed)
  • Related to #15599 (closed)
  • Related to #17525 (closed)
  • Has duplicate #9268 (closed)
  • Blocked by #15168 (closed)
  • Blocked by #5774
Edited Aug 16, 2021 by intrigeri
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking