Proxy 問題、last forwarder 的表格與封包 padding

3.5.1 Proxy 中間傳遞 key 可能的問題

封包傳遞過程中，last forwarder 是由 proxy 決定的，並且，用來加密原始封 包的 secret key 也是由 last forwarder 一開始產生後，經 proxy 轉送回給 client。因 此 proxy 也是擁有該把 key。而當 client 接下來真正傳送資料時所送出的封包中，

內部用來加密的 keyproxy 皆知道，如此會造成 proxy 可以將這些封包解密來得 知連線目的 server 的真正位址。

因此若是 client 上的使用者若是想避免此情形發生，可以在一開始開啟匿名 連線要求時，向不同群組的 proxy 發出要求，收到要求的 proxy 同樣會在自己的 群組中選定一 last forwarder，被選定的 last forwarder 同樣都擁有一把 secret key，

這把 key 會以 client 的 public key 加密後傳給 client。

-圖3.5.1 client

接著 client 會收到兩個不同群組 proxy 所回應的資訊，包含該 proxy 中所選 定 last forwarder 之一把 forwarding 用的 secret key，另外就是選定的 last forwarder 之 IP 位址。此時 client 可任意選定其中一部 proxy 做為第一個接收封包的目的 地，由該 proxy 所屬的 forwarder 轉送封包後，經 last forwarder(同樣的群組)，再 送給另外一個群組中被選定的 last forwarder，由另外一群組的 last forwarder 送給 真正的目的 server。會採取這種方式，是因為這麼做可以避免加密最內層 IP 封包 的 secret key，若經過的 proxy 也同樣知擁有該把 key，，則 client 所送出的封包，

proxy 皆能解密開來得知真正的目的 server。

-圖3.5.2 透過兩個群組的 forwarder

轉送封包-3.5.2 封包傳送時需建立的表格

由於我們希望能做到 client 的真實身分只有 proxy 能知道，並且 client 欲連 線的目標 server 位址，我們又不希望被 proxy 得知。並且，client 的位址我們也 不希望其他的 forwarders，包含 last forwarder 所知道。而每個 client 所送出的 TCP/UDP 封包中，含有連線所使用的 source port numbre 與 destination port number，因此我們可以藉由透過 source port 與 destination port，配合 proxy 針對 每個要求匿名連線的 client 隨機配給的 session number，建立封包傳送往返時，

查詢出真正目標位址的資訊。

proxyA 首先對於每個屬於自己群組的 forwarder 建立一個表格，當該

forwarder 被選為某次匿名連線的 last forwarder 時，所有的相關資訊，包括 client IP 位址、source port 與 destination port 便紀錄於此，另外 proxy 還會紀錄著 client 一開始要求匿名連線時產生的 session number(也可以視為在這一此的匿名連線 中對此 client 所產生的 ID)。接著當封包移動到 LFB 時，在此也同樣會建立一組 表格，內容紀錄了 session number、source port、destination port、pre-forwarder(即 LFA)， LFB 使用自己的 secret key(此 key 為 proxyA 所不知的)解開可以得到原 始封包，就能知道目的 server IP 位址。

而當 LFB 收到 server 回應的封包後，由 server IP 位址、source port 與 destination port 查出對應的 session number，將 session number 資訊包裝至封包 中，再回傳給 LFA，經 LFA 再回傳給 proxyA。

proxyA 收到由 LFA 所送來的封包之後，藉由該部 last forwarder_ID、source port、destination port 與 session number，查出 client 的 IP 位址，將這些資訊包裝 至封包中，再透過一些 forwarders 轉送給 client。整個查表傳送的流程如

圖 3.5.3

-圖3.5.3

封包往返與查表-3.5.3 封包 padding

封包每經過一個 forwarder 後，會有一大小為 8 bytes 的 forwarding information 被去除，使得封包變小，並且這個封包每經過一部 forwarder 後便會變小 8 bytes，

例如一個大小為 540 bytes 的封包，進入第一個 forwarder 後，出來的封包尺寸便 由原先的 540 bytes 縮小為 532 bytes，再進入第二個 forwarder 後，出來的封包大 小會再變小為 524 bytes，如此容易讓攻擊者有較多的資訊來分析封包行經的路 徑，因此整個封包傳遞過程，除了最後的 LFB to server 以外，其他所有 forwarder 間的封包傳遞，封包大小應保持一致。

例如，當有一筆資料大小為 500 bytes 的訊息要傳遞時，首先，因為 DES 加 密系統是以 8 bytes 為單位，因此 500 mod 8 = 4，8 – 4 = 4，因此需要 padding 4bytes，再加入 8 bytes 的 forwarding information，共為 512bytes，如

圖 3.5.4；

而若是希望封包傳遞過程中再多經過一部 forwarder，則可以再加入一 8 bytes 的 forwarding information，由於每多加一 forwarding information 皆為 8 bytes，因此 不須再做 padding，如

圖 3.5.5。

-圖3.5.4 加密時封包大小需 padding 成 8

的倍數--圖3.5.5 增加多筆 forwarding

當第一部 forwarder 收到如圖 3.5.5 最右邊，大小為 540 bytes 的封包後，先 扣除 20 bytes 的 IP header，解密 IP header 之後的 520 bytes 資料，則可以看到第 一組 forwarder information，由這裡可以知道實際資料大小為 512 bytes，剛好為 520 bytes 扣除 8 bytes 的 forwarder information 的大小，也就是說並沒有做 padding，之後當封包要由 forwarder1 送出給 forwarder2 時，512 bytes 的資料之 後，由於剛剛去除了 8 bytes 的 forwarder information，因此必須再 padding 8 bytes 的大小，最後再加上一 IP header，512 + 8 + 20 = 540 bytes，如

圖 3.5.6 所示，這

-圖3.5.6 每移除一筆 forwarding information 需再

padding-或是動態決定 padding 的大小，使得封包進入 forwarder 與送出時的大小皆不相 同，使封包在進出之間難以辨別相關性，更能提升攻擊者分析封包的難度，如

圖 3.5.7。

-圖3.5.7 動態決定 padding