匿名网络通信(洋葱路由&大蒜路由)原理

     1、（1）做网络攻防，都希望能隐藏自己的真实ip地址，让对方无法精准定位找到自己。最常见的方式就是代理，图示如下：   

      

      client原本是直接访问server的，但又不想暴露自己的真实ip，此时可以找个代理服务器转发流量。站在server角度，访问都来自proxy，不是client；站在client角度，所有的信息都来自proxy（目前很多FQ就是这么干的：买个海外的云主机，装个socket代理软件转发国内的流量）；

      这样就能隐藏自己真实的IP了么？ too yong！ 正常情况下，server是有日志的，肯定记录了proxy的ip地址（如果server在国内，运营商也有相应的记录）；同时国内的运营商也有client的访问记录，两边的数据放专业的大数据实时数仓，一条select xxx from xxx as A join select xxx from xxx as B where A.descIP=B.SourceIP，分分钟查出client的真实IP（千万别小看了运营商和JC叔叔的IT设施，他们背后都有非常专业的IT团队支持的！）这种情况下想要通过proxy来隐藏自己真实的IP是不行的！

     （2）既然一个proxy不行，那2个了？ 

        

       在海外（注意：一定要是海外的节点，国内的运营商是拿不到这些节点进出流量数据的）找两个代理服务器，通过上述2层代理的方式访问。

  •       client->proxy1：国内运营商知道client给proxy1发数据了
  •       proxy1->proxy2：由于两个节点都在海外，正常情况下，国内运营商是不知道这层代理关系的
  •       proxy2->server：正常情况下，server有日志记录；如果server在国内，国内的运营商也有记录

       最关键的是proxy1->proxy2了：国内运营商拿不到这两个海外节点的数据，不好追查。 既然两个proxy已经不好追查了，那么继续增加proxy节点到3个了？—— tor就是这么干的！

      （3）tor从1995年问世，至今快30年了，各种资料google一下能查到一大把，我这里简单介绍一下核心的原理，以下是tor官网的截图：Alice要访问Jane，并不是直接连接Jane，而是通过了3个代理！那么问题来了，Alice是怎么找到这些代理的了？ alice和代理、代理之间、代理到Jane之间的通信数据万一被截获了怎么办了？

         

  •      tor开源了，官网的源码下载地址：https://www.torproject.org/zh-CN/download/tor/   （需要FQ）
  •      使用tor浏览器访问网页，除了走正常的http/https协议的流程外，tor还需要先访问目录服务器，从目录服务器拿到中继服务器的地址和公钥（这是tor的致命问题之一：目录服务器的数量有限，一旦屏蔽目录服务器，tor浏览器就用不了了；据说防火墙有专人盯着目录服务器，一旦发现新增立即加入屏蔽的黑名单；后来tor又提供网桥中继，但还是被防火墙盯上了........）  ; src/app/config/ 这里面存放了主备用目录服务器的ip地址、端口和id，格式如下：全部都屏蔽还是很容易的......   

         

  •      再通过中继服务器层层加密并转发流量。为了更好地阐述建立加密通信链路的原理，这里简单介绍一下加解密的种类：

             （1）对称加密：加密密钥和解密密钥是一样的，优点是加解密速度相对非对称加密快一些，但密钥一定要保管好；代表算法是AES；

             （2）非对称加密：加解密密钥不同，分公钥和私钥；公钥加密后只能用私钥解密。同理，私钥加密后只能公钥解密；公钥之间、私钥之间是无法互相解密的；利用这个原理，一般对外公开公钥，自己保留私钥，然后双方互相通信。常用于数字签名，比如https协议的证书验证；代表算法是椭圆曲线（比特币加密用的就是这种）、RSA；

  •      建立通信链路的过程（本质上是拿到中继节点的公钥，用于后续通信时加密数据包）:   
  1. 客户端与目录服务器建立链接，并从目录服务器中选取一个时延最低的服务器作为第一个中继服务器/OR1；
  2. 客户端向OR1发送一个请求建链请求，OR1验证完客户端的合法性后生成一对密钥（公钥pubkey_OR1_Client、私钥prikey_OR1_Client）,然后将公钥pubkey_OR1_Client发回给客户端（至此，客户端成功的建立了其与OR1的通信链路）；
  3. 客户端又从目录服务器中选择一个时延最低的中继服务器OR2，并向OR1发送一个数据包：使用pubkey_OR1_Client加密OR2的地址；
  4. OR1收到数据包后使用prikey_OR1_Client解开数据包，发现是一个让其自身与另外一个服务器OR2建立链接的请求，那么OR1重复步骤2与OR2建立链接，并将OR2返回的OR1与OR2链路的公钥pubkey_OR1_OR2返回给客户端；
  5. 客户端重复步骤3、4，建立OR2与OR3之间的通信链路，并接收到OR2与OR3之间链路的公钥pubkey_OR2_OR3；
  6. 至此，客户端与3个中继服务器之间的链路/circuit已经成功建立，客户端拥有3把公钥：pubkey_Client_OR1、pubkey_OR1_OR2、pubkey_OR2_OR3。
  •      通信链路建立了，接下来该发数据了，数据加密的过程如下：
  1. 客户端将要发送的数据（data）经过3层加密包裹：*第一层：使用pubkey_OR2_OR3加密data：pubkey_OR2_OR3(data)；*第二层：使用pubkey_OR1_OR2加密第一层加密后的数据：pubkey_OR1_OR2(pubkey_OR2_OR3(data))；*第三层：使用pubkey_Client_OR1加密第二层机密后的数据：pubkey_Client_OR1(pubkey_OR1_OR2(pubkey_OR2_OR3(data)))；
  2. OR1收到客户端发来的数据后使用其与Client链路的私钥prikey_Client_OR1解开数据包，发现数据包是发往OR2的，那么OR1就将解开后的数据包发送给OR2；
  3. OR2收到OR1发来的数据包重复OR1的步骤：将接收的数据包解开发往OR3；
  4. OR3收到数据包后，使用prikey_OR2_OR3解开数据包，这个时候的数据包是客户端要发往目的服务器的真实数据包data。此时，OR3就将data路由给目标服务器。
  5. 这就是洋葱名称的来源：数据被公钥层层加密发送。每个中继节点收到数据后都用自己保存的私钥层层解密，直到看到最终的目的数据包；

     2、洋葱效果：

   （1）洋葱连接的日志：先去directory找relay descriptor，再build a circuit！

2/19/21, 06:32:15.640 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/19/21, 06:32:15.640 [NOTICE] Switching to guard context "bridges" (was using "default")
2/19/21, 06:32:15.640 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/19/21, 06:32:15.640 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/19/21, 06:32:15.640 [NOTICE] Opening Socks listener on 127.0.0.1:9150
2/19/21, 06:32:15.640 [NOTICE] Opened Socks listener on 127.0.0.1:9150
2/19/21, 06:32:15.640 [NOTICE] Renaming old configuration file to "D:\Program Files (x86)\Tor Browser\Browser\TorBrowser\Data\Tor\torrc.orig.1"
2/19/21, 06:32:15.453 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
2/19/21, 06:32:15.454 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
2/19/21, 06:32:16.507 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
2/19/21, 06:32:16.901 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay
2/19/21, 06:32:17.270 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a relay done
2/19/21, 06:32:17.270 [NOTICE] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
2/19/21, 06:32:17.639 [NOTICE] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
2/19/21, 06:32:18.700 [NOTICE] Bridge 'bridge' has both an IPv4 and an IPv6 address.  Will prefer using its IPv4 address (212.12.48.75:8443) based on the configured Bridge address.
2/19/21, 06:32:18.700 [NOTICE] new bridge descriptor 'bridge' (fresh): $11A09CD2766DE5D2625408A92781CA5E65ACFC7E~bridge at 212.12.48.75 and [2a00:14b0:4200:3000:75::1]
2/19/21, 06:32:18.100 [NOTICE] Bridge 'hnapel4tor' has both an IPv4 and an IPv6 address.  Will prefer using its IPv4 address (51.75.74.245:8356) based on the configured Bridge address.
2/19/21, 06:32:18.100 [NOTICE] new bridge descriptor 'hnapel4tor' (fresh): $18C27C9850967FD4BF4188963C1AEBEC40807823~hnapel4tor at 51.75.74.245 and [2001:41d0:701:1100::285d]
2/19/21, 06:32:18.406 [NOTICE] Ignoring directory request, since no bridge nodes are available yet.
2/19/21, 06:32:19.406 [NOTICE] Ignoring directory request, since no bridge nodes are available yet.
2/19/21, 06:32:21.407 [NOTICE] Ignoring directory request, since no bridge nodes are available yet.
2/19/21, 06:32:23.850 [NOTICE] new bridge descriptor 'PickANickname' (fresh): $6FBA3EB375D3849B61996B614EE26441D5AC4C1A~PickANickname at 217.102.166.147
2/19/21, 06:32:24.774 [NOTICE] Bootstrapped 30% (loading_status): Loading networkstatus consensus
2/19/21, 06:32:31.783 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
2/19/21, 06:32:32.156 [NOTICE] Bootstrapped 40% (loading_keys): Loading authority key certs
2/19/21, 06:32:32.798 [NOTICE] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
2/19/21, 06:32:32.798 [NOTICE] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
2/19/21, 06:32:32.799 [NOTICE] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6655, and can only build 0% of likely paths. (We have 100% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
2/19/21, 06:32:33.237 [NOTICE] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
2/19/21, 06:32:34.219 [NOTICE] The current consensus contains exit nodes. Tor can build exit and internal paths.
2/19/21, 06:32:36.799 [NOTICE] Bootstrapped 56% (loading_descriptors): Loading relay descriptors
2/19/21, 06:33:59.136 [WARN] Proxy Client: unable to connect to 217.102.166.147:19202 ("general SOCKS server failure")
2/19/21, 06:34:35.779 [NOTICE] Bootstrapped 61% (loading_descriptors): Loading relay descriptors

   （2）本人肉身在国内，用chrome访问ip138查到自己的ip地址；同样用洋葱访问（需要FQ），查到另一个ip地址：135.148.33.80，显示在米国俄亥俄州；

     

    洋葱自己给出的中转链路: 本机通过网桥中转到德国某中继节点，然后再访问ip138，但ip138显示的是美国地址，这是怎么回事了？

   

   访问google，又显示ip在荷兰:

  

   不但支持IPV4的地址代理，还提供IPV6地址的代理：

   

  洋葱还支持使用新的线路：这次中继是通过立陶宛和美国了，不再经过德国！

   

   访问不同站点，自动使用不同的链路：

   

    （3）用process hacker查看，发现tor其实是基于firefox做的，自己增加了tor.exe和obfs4proxy.exe，分别用于和firefox通信、寻找网桥、建立通信链路等，并且都由firefox启动；

      

      同样在netword这里能查到远程端口：

      

      从tor进程的remorte address和remote portal看，刚好是本机的firefox进程和端口，由此可以推断: tor的主要功能之一是把流量转发给firfox，再通过firefox发出去！

      

      接下来在wireshark抓包，看看tor和obfs4proxy这两个进程在这些端口到底对外发了啥数据！

     （4）先用tor随便打开一个网页，比如ip138（这里多说一句：长时间用同一条链路，也容易通过类似超级ping的工具猜出真实的ip地址，所以tor会不定时更换链路），如下：

        

       同时抓包：发现抓到的大都是本机和网桥obfs4之间的通信。从源端口看，对应的进程是obfs4proxy，印证了之前的猜想: 都是obfs4proxy.exe和网桥之间发数据！发送的数据放Data字段，都是加密的！

       

       分析数据包的时候，发现另一个ip地址：212.12.48.75; 这个地址并未在浏览器的tor链路中展示出来，但根据双方互相通信数据包的特征很容易能看出来：212.12.48.75就是osbf！

      

     比较明显的特征如下：

  •     TCP前面3次握手后建立连接
  •     然后发送4个数据包，每个包的格式、长度完全一样

     这也是tor的弱点之一： 浏览器和osbf之间的通信格式是固定的，很容易通过机器学习的模型、甚至是人为预设的规则检测到（江湖传闻防火墙也会根据部分数据包的特征识别这个包是不是FQ的）！

     3、大蒜路由I2P

     tor是匿名通信的鼻祖，但还是有比较明显的缺陷：（1）上面提到的目录服务器。一旦被防火墙ban，tor浏览器分分钟失效   （2）一旦建立通信连接，双方用这条线路互相传数据；使用时间稍微长一点的话，有一定的概率被猜到； 为了解决这些痛点，大蒜路由孕育而生！

     I2P使用 Kad 算法（用过电驴或电骡的网友应该听说过）来获取网络节点的信息，将传输的原始数据拆散为加密数据包通过多条隧道交叉疏散传递，其优势如下：

  •      不需要目录服务器，不用担心被防火墙“卡脖子”
  •      Kad算法拿到的节点信息只是整个 I2P 网络的一小部分
  •      每一台运行 I2P 的主机都可以成为中继，帮别人转发数据（类似于 P2P 下载）。防火墙不太可能会将所有的I2P节点都加入黑名单ban掉！
  •     上传与下载（也就是双方互相通信）的隧道相互独立而且两个方向上的隧道数量都可能>1；如下图所示：比如A到E走蓝色隧道，E到A走红色隧道，并且隧道还有可能不止1条，增加了追踪的难度！

          

 

 

参考：

1、匿名网络概述：https://juejin.cn/post/6844903462224953351#heading-23

2、tor原理详解：https://zhuanlan.zhihu.com/p/32445479

3、详解Tor Bridge及Pluggable Transport（Part 1）：https://www.anquanke.com/post/id/194480

posted @ 2021-02-21 09:36  第七子007  阅读(5491)  评论(0)  编辑  收藏  举报