mirror of
https://github.com/torproject/torspec.git
synced 2024-12-14 05:58:33 +00:00
a3fd193023
The clear standard is trailing "." after each numeric section. This fixes the small handful of outliers. This makes it easy to convert these headers to common markup formats, for example: http://hyperpolyglot.org/lightweight-markup
178 lines
6.9 KiB
Plaintext
178 lines
6.9 KiB
Plaintext
|
|
Glossary
|
|
|
|
The Tor Project
|
|
|
|
This document aims to specify terms, notations, and phrases related
|
|
to Tor, as used in the Tor specification documents and other documentation.
|
|
|
|
This glossary is not a design document; it is only a reference.
|
|
|
|
This glossary is a work-in-progress; double-check its definitions before
|
|
citing them authoritatively. ;)
|
|
|
|
0. Preliminaries
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
|
|
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
|
|
"OPTIONAL" in this document are to be interpreted as described in
|
|
RFC 2119.
|
|
|
|
1.0. Commonly used Tor configuration terms
|
|
|
|
ORPort - Onion Router Port
|
|
DirPort - Directory Port
|
|
|
|
2.0. Tor network components
|
|
|
|
2.1. Relays, aka OR (onion router)
|
|
|
|
[Style guide: prefer the term "Relay"]
|
|
|
|
2.1.1. Specific roles
|
|
|
|
Exit relay: The final hop in an exit circuit before traffic leaves
|
|
the Tor network to connect to external servers.
|
|
|
|
Non-exit relay: Relays that send and receive traffic only to
|
|
other Tor relays and Tor clients.
|
|
|
|
Entry relay: The first hop in a Tor circuit. Can be either a guard
|
|
relay or a bridge, depending on the client's configuration.
|
|
|
|
Guard relay: A relay that a client uses as its entry for a longer
|
|
period of time. Guard relays are rotated more slowly to prevent
|
|
attacks that can come from being exposed to too many guards.
|
|
|
|
Bridge: A relay intentionally not listed in the public Tor
|
|
consensus, with the purpose of circumventing entities (such as
|
|
governments or ISPs) seeking to block clients from using Tor.
|
|
Currently, bridges are used only as entry relays.
|
|
|
|
Directory cache: A relay that downloads cached directory information
|
|
from the directory authorities and serves it to clients on demand.
|
|
Any relay will act as a directory cache, if its bandwidth is high enough.
|
|
|
|
Rendezvous point: A relay connecting a client to a hidden service.
|
|
Each party builds a three-hop circuit, meeting at the
|
|
rendezvous point.
|
|
|
|
2.2. Client, aka OP (onion proxy)
|
|
|
|
[Style: the "OP" and "onion proxy" terms are deprecated.]
|
|
|
|
2.3. Authorities:
|
|
|
|
Directory Authority: Nine total in the Tor network, operated by
|
|
trusted individuals. Directory authorities define and serve the
|
|
consensus document, defining the "state of the network." This document
|
|
contains a "router status" section for every relay currently
|
|
in the network. Directory authorities also serve router descriptors,
|
|
extra info documents, microdescriptors, and the microdescriptor consensus.
|
|
|
|
Bridge Authority: One total. Similar in responsibility to directory
|
|
authorities, but for bridges.
|
|
|
|
Fallback directory mirror: One of a list of directory caches distributed
|
|
with the Tor software. (When a client first connects to the network, and
|
|
has no directory information, it asks a fallback directory. From then on,
|
|
the client can ask any directory cache that's listed in the directory
|
|
information it has.)
|
|
|
|
2.4. Hidden Service:
|
|
|
|
A hidden service is a server that will only accept incoming
|
|
connections via the hidden service protocol. Connection
|
|
initiators will not be able to learn the IP address of the hidden
|
|
service, allowing the hidden service to receive incoming connections,
|
|
serve content, etc, while preserving its location anonymity.
|
|
|
|
2.5. Circuit:
|
|
|
|
An established path through the network, where cryptographic keys
|
|
are negotiated using the ntor protocol or TAP (Tor Authentication
|
|
Protocol (deprecated)) with each hop. Circuits can differ in length
|
|
depending on their purpose. See also Leaky Pipe Topology.
|
|
|
|
Origin Circuit -
|
|
|
|
Exit Circuit: A circuit which connects clients to destinations
|
|
outside the Tor network. For example, if a client wanted to visit
|
|
duckduckgo.com, this connection would require an exit circuit.
|
|
|
|
Internal Circuit: A circuit whose traffic never leaves the Tor
|
|
network. For example, a client could connect to a hidden service via
|
|
an internal circuit.
|
|
|
|
2.6. Edge connection:
|
|
|
|
2.7. Consensus: The state of the Tor network, published every hour,
|
|
decided by a vote from the network's directory authorities. Clients
|
|
fetch the consensus from directory authorities, fallback
|
|
directories, or directory caches.
|
|
|
|
2.8. Descriptor: Each descriptor represents information about one
|
|
relay in the Tor network. The descriptor includes the relay's IP
|
|
address, public keys, and other data. Relays send
|
|
descriptors to directory authorities, who vote and publish a
|
|
summary of them in the network consensus.
|
|
|
|
3.0. Tor network protocols
|
|
|
|
3.1. Link handshake
|
|
|
|
The link handshake establishes the TLS connection over which two
|
|
Tor participants will send Tor cells. This handshake also
|
|
authenticates the participants to each other, possibly using Tor
|
|
cells.
|
|
|
|
3.2. Circuit handshake
|
|
|
|
Circuit handshakes establish the hop-by-hop onion encryption
|
|
that clients use to tunnel their application traffic. The
|
|
client does a pairwise key establishment handshake with each
|
|
individual relay in the circuit. For every hop except the
|
|
first, these handshakes tunnel through existing hops in the
|
|
circuit. Each cell type in this protocol also has a newer
|
|
version (with a "2" suffix), e.g., CREATE2.
|
|
|
|
CREATE cell: First part of a handshake, sent by the initiator.
|
|
|
|
CREATED cell: Second part of a handshake, sent by the responder.
|
|
|
|
EXTEND cell: (also known as a RELAY_EXTEND cell) First part of a
|
|
handshake, tunneled through an existing circuit. The last relay
|
|
in the circuit so far will decrypt this cell and send the
|
|
payload in a CREATED cell to the chosen next hop relay.
|
|
|
|
EXTENDED cell: (also known as a RELAY_EXTENDED cell) Second part
|
|
of a handshake, tunneled through an existing circuit. The last
|
|
relay in the circuit so far receives the CREATED cell from the
|
|
new last hop relay and encrypts the payload in an EXTENDED cell
|
|
to tunnel back to the client.
|
|
|
|
Onion skin: A CREATE/CREATE2 or EXTEND/EXTEND2 payload that
|
|
contains the first part of the TAP or ntor key establishment
|
|
handshake.
|
|
|
|
3.3. Hidden Service Protocol
|
|
|
|
3.4. Directory Protocol
|
|
|
|
|
|
4.0. General network definitions
|
|
|
|
Leaky Pipe Topology: The ability for the origin of a circuit to address
|
|
relay cells to be addressed to any hop in the path of a circuit. In Tor,
|
|
the destination hop is determined by using the 'recognized' field of relay
|
|
cells.
|
|
|
|
Stream: A single application-level connection or request, multiplexed over
|
|
a Tor circuit. A 'Stream' can currently carry the contents of a TCP
|
|
connection, a DNS request, or a Tor directory request.
|
|
|
|
Channel: A pairwise connection between two Tor relays, or between a
|
|
client and a relay. Circuits are multiplexed over Channels. All
|
|
channels are currently implemented as TLS connections.
|
|
|