セルはコントロールセルとリレーセルの2種類があり、前者は受け取ったノードによって処理されるコマンドを伝達し、後者は接続元から宛先へのデータの受け渡しに使われる。リレーセルは、circID の他に、streamID、チェックサム、リレーコマンド等を持つ。リレーセルのヘッダとペイロードの全ては、暗号化されて送信される。
回線の構築

以下は、TorクライアントAlice（発信元）から、オニオンルータBob、Carolまでの回線を構築する際の説明である[9]。

Aliceは、あらかじめ得ているディレクトリリストの中から、無作為的にBobとCarolを選択する（実際は最初のノードは2、3ヶ月同じ）。

Alice→Bob: Alice は create cell（セルに回線構築要求コマンドを乗せたもの）を送信し、回線構築の要求を行う

このとき、Alice は今までに使われていない circID C A B {\displaystyle C_{AB}} を発行する

ペイロードは Bob のオニオンキーで暗号化された、DH ハーフハンドシェイクを含んでいる ( g x {\displaystyle g^{x}} )


Bob→Alice: Bob は created cell（セルに構築完了を通知するためのコマンドを乗せたもの）の中に g y {\displaystyle g^{y}} と共通鍵 K = g x y {\displaystyle K=g^{xy}} のハッシュを積んで送る

AliceとBobは共通鍵 K 1 = g x 1 y 1 {\displaystyle K_{1}=g^{x1y1}} を共有できた

以降、Alice-Bob間の通信はこの共通鍵で暗号化されて行われる

Alice→Bob: Alice は relay extend cell（セルにサーキットを延長する要求を乗せたもの）を送信する

この中に次の OR (Carol) のアドレスが含まれており、Carol のオニオンキーで暗号化された g x 2 {\displaystyle g^{x2}} も含まれる


Bob→Carol: Bob はハーフハンドシェイクを create cell に入れ、Carolに送信する

このとき、Bob は今までに使われていない circID C B C {\displaystyle C_{BC}} を発行する


Carol→Bob: created cell に共通鍵のハッシュを積んで送る

Bob は C A B {\displaystyle C_{AB}} と C B C {\displaystyle C_{BC}} を対応付けている


Bob→Alice: Carol が created cell を返した場合、ペイロードを relay extended cell に入れて Alice に返す

Alice と Carol は共通鍵 K 2 = g x 2 y 2 {\displaystyle K_{2}=g^{x2y2}} を共有できた

以上の手続きは一方向エンティティ認証、すなわち、Alice は Bob を知っているが、Alice は公開鍵を使っていないので、Bob は Alice が誰なのか知らないということを達成している。一方向鍵認証も達成しており、Alice と Bob は鍵について合意しており、Alice は Bob のみがその鍵を知っていることを知っていることを意味している。前方秘匿性とキーの新鮮さの保持にも成功していて、これにより、鍵共有プロトコルでセッションキーを生成した際に、のちに秘密鍵の安全性が破れたとしてもセッションキーの安全性が保たれることが保証される。

Alice-Bob間、Bob-Carol間の共通鍵はそれぞれAliceとBob、BobとCarolしか知らないので、データを盗聴されることなく、中継により匿名性を得ることができる。

セッション鍵交換のためにDiffie-Hellman鍵交換方式が用いられ、通信の暗号化としてはAESが使用される。オニオンサーキット構築を含めたTorノード間の全通信は、外部からの盗聴や改竄を防ぐために、TLSによる通信の上で行われる。
データの送受信

先述の、リレーセルや回線を用いて行われる。以下は、Alice のデータが Bob、Carol を経由して、Dave まで届く様子を説明したものである[9]。

Alice はペイロードやペイロードのダイジェストをリレーセルに入れ、circID 以外の全てを終端ノードから順番に、共通鍵を用いて暗号化して送信する

Bob は1つ復号し、ダイジェストが一致しない場合、Bob は circID を置き換えて、Carol へセルを送信する

Carol も同じように1つ復号し、ダイジェストが一致した場合、かつ relay cell の内容を認識可能なら、Dave へ送信する (送信完了)

Carol に到着したペイロードとそのダイジェストが一致しなかった場合、回線そのものを切断する

逆に Dave が送信し、Alice が受信する場合、各ノードは自分にセルが回ってきたときに、ペイロードを暗号化していく。
ランデブーポイントとOnion Service

.onionで終わるドメインの一覧については「Onionドメインの一覧」をご覧ください。
A Tor non-exit relay with a maximum output of 239.69 kbit/s

Torの特徴として、Tor経由でしかアクセス出来ない秘匿されたOnion Service (旧 Hidden Service (秘匿サービス))が存在する。これにより、サーバのIPアドレスを明かさずに各種 TCP のサービス（Webサーバ、メールサーバ、IRCサーバなど）を運用することが可能である。これは、.onionの識別子を持つ、特殊な疑似アドレスを持たせることにより、特定のIPアドレスと結びつけることなく、Torを実行させているノード同士が接続することができる。一般のWebサイト等にTor経由で接続するのとは異なり、Onion Serviceは深層Webの一角を成すダークネットに含まれ出口ノードは存在しないし、中継ノードが通信の内容を見ることは不可能である。

Alice を接続元、Bob を宛先とすると、このサービスを用いることで、Bob は自身のIPアドレスをさらすことなくサービスを提供でき、アプリケーションもTorの存在を透過的に扱うことができる。

サーバのBobはまず、複数のORを introduction point として指名し、ルックアップサービスへ広告する[10]。このとき、Bobは長期の公開鍵暗号のペアを持っており、これでサービスを証明する。先ほどの広告も、Bobの公開鍵で署名されている。Bobは introduction points までの回線を開き、リクエストを待つように伝える。

AliceはBobのサービスを知ると（ネットや直接Bobに聞いて）、ルックアップサービスから情報を得る。Alice はある OR を rendezvous point (RP) として指名し、回線を構築する。この際、Bob を識別するためにランダムな rendezvous cookie も渡す。

次に、Alice は Bob の introduction points の1つに匿名でストリームを開く。このとき、AliceはBob の公開鍵で暗号化した RP の情報と rendezvous cookie を渡し、DH 鍵共有を始める。introduction point は Bob へそのメッセージを送る。

Bob は了承すると Alice の RP への回線を構築し、rendezvous cookie、DH 鍵共有の返答、セッション鍵のハッシュを送る。Alice のRP は Alice の回線を Bob の回線に接続する。

以上の手続きにおいて、RP は Alice も Bob も知らないし、データの内容も知ることはない。両端は双方のOPになっているので、AliceとBob以外の中継ノードがデータの内容を復号することもできない。

Bobのintroduction pointは複数存在しているので、DoS対策にもなっている。さらに、Alice が introduction point へメッセージを送信するとき、end-to-end の認証トークンも乗せることができる。Onion Serviceの仮想ドメイン、x.y.onion は、xが認証トークン、yがBobの公開鍵のハッシュになっている[11]。
エントリーガード

現在、Torの回線は3つのノードを経由しているが、悪意のある攻撃者が両端のノードをコントロールできた場合、匿名性が破られてしまう[12]。そのため、Torは2、3ヶ月の間最初のノードを使い続けることで、攻撃のコストを上げており、このノードはエントリーガードと呼ばれる[13]。
問題点
DNS漏洩

ほとんどのソフトウェアは、UDPを用いてDNSを参照するため、TCP専用であるTorネットワークを経由せず直接参照してしまい、匿名性が不完全になる可能性がある。

DNS規格自体はUDPとTCPの両方をサポート (.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation.cs-ja1 q,.mw-parser-output .citation.cs-ja2 q{quotes:"「""」""『""』"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free a,.mw-parser-output .citation .cs1-lock-free a{background:url("//upload.wikimedia.org/wikipedia/commons/6/65/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited a,.mw-parser-output .id-lock-registration a,.mw-parser-output .citation .cs1-lock-limited a,.mw-parser-output .citation .cs1-lock-registration a{background:url("//upload.wikimedia.org/wikipedia/commons/d/d6/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription a,.mw-parser-output .citation .cs1-lock-subscription a{background:url("//upload.wikimedia.org/wikipedia/commons/a/aa/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("//upload.wikimedia.org/wikipedia/commons/4/4c/Wikisource-logo.svg")right 0.1em center/12px no-repeat}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:#d33}.mw-parser-output .cs1-visible-error{color:#d33}.mw-parser-output .cs1-maint{display:none;color:#3a3;margin-left:0.3em}.mw-parser-output .cs1-format{font-size:95%}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}RFC 2136) しており、多くのDNSサーバー実装も両対応となっているが、DNSを参照する多くのソフトウェアではUDPを用いるのが一般的であるという事が問題の根底にある。TCPを用いたDNS参照をサポートしているソフトウェアであれば、この問題の影響を受けることはない。

以上のことより、古いバージョンのTorでは、HTTP通信を行う場合に、TCPを用いたDNS参照をサポートしているPrivoxy（localhost、ポート番号8118）をWebブラウザとTorの間に設置し、併用することが推奨されていた。

バージョン0.2.0.1-alpha以降のTorは、DNS参照をTorネットワーク経由で行うDNSリゾルバが搭載された。これを使用するには、ユーザはシステム（localhost）上の任意のDNSリクエストを、指定したポート（TCP:9053）で動作するTorのDNSリゾルバ経由で処理させるよう、リダイレクトする必要がある (iptables 等を用いて)。こうすることでDNS漏洩問題は解決され、SOCKSに非対応のアプリケーションでも安全にTor経由の通信を行うことができるようになるが、少々設定が複雑で、パケットがリークする可能性があるため、安易に使うべきではない[14]。