tor/changes/reject-tap

  o Major bug fixes (circuit building):
    - Tor authorities, relays, and clients only use ntor, except for
      rare cases in the hidden service protocol.
    - Authorities, relays and clients specifically check that each
      descriptor has an ntor key.
    - Clients avoid downloading a descriptor if the relay version is
      too old to support ntor.
    - Client code never chooses nodes without ntor keys: they will not
      be selected during circuit-building, or as guards, or as directory
      mirrors, or as introduction or rendezvous points.
    - Circuit-building code assumes that all hops can use ntor,
      except for rare hidden service protocol cases.
    - Hidden service client to intro point and service to rendezvous point
      connections use the TAP key supplied by the protocol.
      Fixes bug 19163; bugfix on 0.2.4.18-rc.
Authorities reject descriptors without ntor keys Before, they checked for version 0.2.4.18-rc or later, but this would not catch relays without version lines, or buggy or malicious relays missing an ntor key. 2016-07-06 08:50:48 +02:00			`o Major bug fixes (circuit building):`
Client & HS ignore UseNTorHandshake, all non-HS handshakes use ntor Rely on onion_populate_cpath to check that we're only using TAP for the rare hidden service cases. Check and log if handshakes only support TAP when they should support ntor. 2016-07-08 06:46:00 +02:00			`- Tor authorities, relays, and clients only use ntor, except for`
			`rare cases in the hidden service protocol.`
			`- Authorities, relays and clients specifically check that each`
			`descriptor has an ntor key.`
Clients no longer download descriptors for relays without ntor 2016-07-06 09:32:57 +02:00			`- Clients avoid downloading a descriptor if the relay version is`
			`too old to support ntor.`
Client & HS ignore UseNTorHandshake, all non-HS handshakes use ntor Rely on onion_populate_cpath to check that we're only using TAP for the rare hidden service cases. Check and log if handshakes only support TAP when they should support ntor. 2016-07-08 06:46:00 +02:00			`- Client code never chooses nodes without ntor keys: they will not`
			`be selected during circuit-building, or as guards, or as directory`
Clients avoid choosing nodes that can't do ntor If we know a node's version, and it can't do ntor, consider it not running. If we have a node's descriptor, and it doesn't have a valid ntor key, consider it not running. Refactor these checks so they're consistent between authorities and clients. 2016-07-07 04:58:47 +02:00			`mirrors, or as introduction or rendezvous points.`
Client & HS ignore UseNTorHandshake, all non-HS handshakes use ntor Rely on onion_populate_cpath to check that we're only using TAP for the rare hidden service cases. Check and log if handshakes only support TAP when they should support ntor. 2016-07-08 06:46:00 +02:00			`- Circuit-building code assumes that all hops can use ntor,`
			`except for rare hidden service protocol cases.`
			`- Hidden service client to intro point and service to rendezvous point`
			`connections use the TAP key supplied by the protocol.`
Authorities reject descriptors without ntor keys Before, they checked for version 0.2.4.18-rc or later, but this would not catch relays without version lines, or buggy or malicious relays missing an ntor key. 2016-07-06 08:50:48 +02:00			`Fixes bug 19163; bugfix on 0.2.4.18-rc.`