Leo
Profile
GitHub
Welcome to my new blog!

V**节点相关原理

申明

本文内容来源于网络分享，对于一些原理进行简单分析，主要是整体流程的宏观解释

背景

利用开源工具搭建V**节点

  • 独享带宽提升上网体验
  • 提升安全性
  • 了解相关网络知识

技术栈

  • vmess（协议）
  • ws（载体）
  • tls（安全）
  • web（伪装）

网络通信原理

输入url 具体发生了什么事情？

dns

dns检索总体过程

alt text

网络传输每层分别做的事

alt text

发送请求

通过dns服务器拿到域名对应的ip地址 重复上图步骤 拿到对应服务端内容

vmess协议

alt text

客户端

alt text

  1. 协议格式 [加密方式｜密钥｜...其他][内容]
  • 使用密钥和加密算法对内容进行加密
  1. 使用用户id对 报头进行加密
  • 加密方式固定，与服务器进行协商后得出
  1. 在头部加入 md5(系统时间戳 +-random(30s) + 用户id)
  2. 在头部加上服务器ip地址
  • 当前数据包内通： ip | 13hgegar | [加密方式｜密钥｜...其他]|[内容]
  1. 发送
  • 经过防火墙（理论上只能识别到服务器的ip）

alt text

服务器

alt text

  1. 去除ip地址
  2. 生成 [-120s,...,当前服务器时间，...+120s] + 用户id数组
  • 对数据每条进行md5
  • 对比，找到相同的md5
  • 去掉hash头
  1. 用协商的加密方式解密剩余头
  2. 用解密出来的加密方式和密钥对内容进行解密
  3. 得到数据，转发到目标服务器

注：上面过程也说明了为什么服务端和客户端系统时间不能相差90s

额外id

防止random(30s)因为数据量大而重复导致hash相同，被探测出特征

如何精准探测

  1. 多条内容hash一致特征
  2. 重放攻击
  • 中间人，修改hash后的头部内容，探测服务器异常行为

解决方式 - AEAD加密

额外id设置为0，自动开启

Authenticated Encryption with Associated Data (AEAD) 是一种同时具备保密性，完整性和可认证性的加密形式。 AEAD 产生的原因很简单，单纯的对称加密算法，其解密步骤是无法确认密钥是否正确的。也就是说，加密后的数据可以用任何密钥执行解密运算，得到一组疑似原始数据，而不知道密钥是否是正确的，也不知道解密出来的原始数据是否正确。 因此，需要在单纯的加密算法之上，加上一层验证手段，来确认解密步骤是否正确。

tls加密

增加安全性，同时也能将流量伪装成https

http

在了解https之前，我们先了解一些http存在的问题： 明文传输，中间人容易篡改

tls

非对称加密

公钥加密 只有 私钥解密

颁发过程

alt text

https 访问过程

粗略版连接过程

  1. 客户端发起连接
  2. 服务端同意连接，发送证书
  3. 客户端验证证书
  • 颁发给
  • 颁发机构 （根据电脑内受信任颁发机构进行验证）
  • 有效期
  1. 使用证书公钥进协商 [会话密钥]
  2. 通信

具体协商过程

SSL/TLS 协议建立的详细流程:

  1. ClientHello 首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。 在这一步，客户端主要向服务器发送以下信息:
  • 客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。
  • 客户端生产的随机数( Client Random )，后面用于生产「会话秘钥」。
  • 客户端支持的密码套件列表，如 RSA 加密算法。
  1. SeverHello 服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello 。服务器回应的内容有如下内容:
  • 确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。
  • 服务器生产的随机数( Server Random )，后面用于生产「会话秘钥」。
  • 确认的密码套件列表，如 RSA 加密算法。
  • 服务器的数字证书。
  1. 客户端回应 客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。 如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息:
  • 一个随机数( pre-master key )。该随机数会被服务器公钥加密。
  • 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
  • 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个 摘要，用来供服务端校验。

上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

  1. 服务器的最后回应 服务器收到客户端的第三个随机数( pre-master key )之后，通过协商的加密算法，计算出本次通信的「会话秘 钥」。然后，向客户端发生最后的信息:
  • 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
  • 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个 摘要，用来供客户端校验。

至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

vmess加入tls后整体变化

alt text

  • vmess加密方式可以废弃
  • 传输安全增加tls

当前包构成

alt text

使用ws承载流量

不同的承载协议不同的特性，总体都是基于Tcp和Udp

alt text

原因：包裹ws协议方便后续nginx伪装做解析

伪装

将Vmess的ws协议伪装成web协议

这边我们采用nginx反向代理，除了特定代理地址外，其它地址都是直接转发到伪装网站

这种方式隐蔽性强，除非访问到特定url否则整个url看起来跟一般web服务器一样 alt text

完整数据包

alt text

  • 服务端接受
    • nginx解密tls（nginx可以处理ws协议）
    • vmess客户端执行上面类似的解密步骤