mirror of
https://github.com/torproject/torspec.git
synced 2024-11-23 09:49:45 +00:00
199 lines
7.5 KiB
Plaintext
199 lines
7.5 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. ;)
|
|
|
|
Table of Contents
|
|
|
|
0. Preliminaries
|
|
1.0. Commonly used Tor configuration terms
|
|
2.0. Tor network components
|
|
2.1. Relays, aka OR (onion router)
|
|
2.1.1. Specific roles
|
|
2.2. Client, aka OP (onion proxy)
|
|
2.3. Authorities
|
|
2.4. Hidden Service
|
|
2.5. Circuit
|
|
2.6. Edge connection
|
|
2.7. Consensus
|
|
2.8. Descriptor
|
|
3.0. Tor network protocols
|
|
3.1. Link handshake
|
|
3.2. Circuit handshake
|
|
3.3. Hidden Service Protocol
|
|
3.4. Directory Protocol
|
|
4.0. General network definitions
|
|
|
|
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.
|
|
|