Opened 4 years ago

Last modified 2 years ago

#16845 reopened enhancement

make unverified consensus ISOTime accessible through Tor's ControlPort

Reported by: proper Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-control needs-design maybe-bad-idea
Cc: proper, intrigeri, anonym, whonix-devel@… Actual Points:
Parent ID: Points: medium
Reviewer: Sponsor:

Description

Currently only verified, accepted Tor consensus ISOTime is available.

Quote Tor control protocol:

     "consensus/valid-after"
     "consensus/fresh-until"
     "consensus/valid-until"
      Each of these produces an ISOTime describing part of the lifetime of
      the current (valid, accepted) consensus that Tor has.
      [New in Tor 0.2.6.3-alpha]

Unverified consensus ISOTime is unavailable.

This information is interesting in context for anonymity distributions and secure network time synchronization, usability and whatnot. Used by Tails' tordate or Whonix's anondate.

However, these tools rely on parsing Tor's log, which is fragile.

It would be nice, if something like

  • consensus-unverified/valid-after
  • consensus-unverified/fresh-until,
  • and consensus-unverified/valid-until

where accessible through Tor's ControlPort.

      Each of these produces an ISOTime describing part of the lifetime of
      the unverified (invalid, rejected) consensus that Tor has.
      [New in Tor 0.2.7.x-...]

This feature requests completes the related one make certificate lifetime accessible through Tor's ControlPort (#16822).

Use cases:

  • clock slightly off: verified consensus (already implemented: #10395)
  • clock more off: unverified consensus (this ticket)
  • clock a lot off: certificate lifetime (#16822)

Child Tickets

Change History (7)

comment:1 Changed 4 years ago by intrigeri

Cc: intrigeri anonym added; tails@… removed

Please don't Cc tails@… -- thanks!

comment:2 Changed 4 years ago by teor

Milestone: Tor: 0.2.???
Points: medium

comment:3 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:4 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:5 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:6 Changed 2 years ago by nickm

Keywords: tor-control needs-design maybe-bad-idea added
Resolution: wontfix
Severity: Normal
Status: newclosed

Closing this as "wontfix", since there's no safe way to actually use this information as far as I can tell. Please reopen if there is?

comment:7 Changed 2 years ago by adrelanos

Resolution: wontfix
Status: closedreopened

This time information is supposed to be used for informational purposes and automated time comparison only. Not to set system clock from unverified consensus ISOTime, which would indeed not be secure.

At boot time of Whonix / sdwdate would - if verified consensus ISOTime is not available - fall back to reading unverified consensus ISOTime. Then compare the result with the system clock. Use that guess inside sdwdate log and to inform the user what the issue with the system clock may likely be.

(Usability / wording of that wouldn't be easy, but that's not something Tor needs to worry about.)

Note: See TracTickets for help on using tickets.