Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #21107

Closed (moved)
Open
Opened Dec 29, 2016 by Roger Dingledine@arma

0.3.0.x dir auths enforcing ED identity keys: intended?

Check out the 'atlassky' relay. n-1 dir auths are voting about it because they find it to be Running. (I think it is Running.)

But moria1 is voting only V2Dir, and no other flags. That seems to come from:

Dec 29 12:21:44.517 [info] channel_tls_process_versions_cell(): Negotiated version 4 with 176.123.26.11:80; Sending cells: CERTS
Dec 29 12:21:44.517 [info] connection_or_client_learned_peer_id(): learned peer id for 0x7f97d5d688f0 (176.123.26.11): 848878591CAF51274E3A9B71933E9599FA39E122, <null>
Dec 29 12:21:44.517 [info] dirserv_orconn_tls_done(): Router at 176.123.26.11:80 with RSA ID 848878591CAF51274E3A9B71933E9599FA39E122 did not present expected Ed25519 ID.
Dec 29 12:21:44.517 [info] channel_tls_process_certs_cell(): Got some good certificates from 176.123.26.11:80: Authenticated it with RSA
Dec 29 12:21:44.517 [info] channel_tls_process_auth_challenge_cell(): Got an AUTH_CHALLENGE cell from 176.123.26.11:80: Sending authentication type 1
Dec 29 12:21:44.517 [info] channel_tls_process_netinfo_cell(): Got good NETINFO cell from 176.123.26.11:80; OR connection is now open, using protocol version 4. Its ID digest is 848878591CAF51274E3A9B71933E9599FA39E122. Our address is apparently 128.31.0.34.

From the new code in dirserv_orconn_tls_done(), I see

    if (! ed_id_rcvd || ! ed25519_pubkey_eq(ed_id_rcvd, expected_id)) {
      log_info(LD_DIRSERV, "Router at %s:%d with RSA ID %s "
               "did not present expected Ed25519 ID.",
               fmt_addr(addr), or_port, hex_str(digest_rcvd, DIGEST_LEN));
      return; /* Don't mark it as reachable. */
    }

So it looks like the dir auths are now enforcing whatever ED key they saw from the relay earlier? Is this change intended at this point? If so, is there anything we need to do to explain to current relays what they need to do or not do?

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: 0.3.0.x-final
Milestone
Tor: 0.3.0.x-final
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#21107