视频教程
视频代码
服务端配置
#安装x-ui
bash <(curl -Ls https://raw.githubusercontent.com/vaxilu/x-ui/master/install.sh)
#生成自签证书
openssl req -new -x509 -nodes -newkey rsa:2048 -keyout /etc/x-ui/ca.key -out /etc/x-ui/ca.crt -subj "/CN=MITM" -days 36500
x-ui模板
{
"log": {
"access": "",
"error": "",
"loglevel": "warning"
},
"inbounds": [
{
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "bulianglin"
},
{
"id": "bulianglin-mitm",
"email": "[email protected]"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "tls",
"tlsSettings": {
"certificates": [
{
"certificateFile": "/etc/x-ui/ca.crt",
"keyFile": "/etc/x-ui/ca.key"
}
]
}
}
}
],
"outbounds": [
{
"protocol": "freedom"
},
{
"tag": "mitm",
"protocol": "freedom",
"streamSettings": {
"security": "tls",
"tlsSettings": {
"alpn": [
"http/1.1"
]
}
}
}
],
"routing": {
"rules": [
{
"user": "[email protected]",
"outboundTag": "mitm",
"type": "field"
}
]
}
}
客户端配置
xray模板
{
"log": {
"access": "",
"error": "",
"loglevel": "warning"
},
"inbounds": [
{
"tag": "socks",
"port": 8888,
"listen": "127.0.0.1",
"protocol": "socks",
"settings": {
"udp": true
},
"sniffing": {
"enabled": true
}
},
{
"tag": "http",
"port": 9999,
"listen": "127.0.0.1",
"protocol": "http",
"sniffing": {
"enabled": true
}
},
{
"listen": "127.0.0.1",
"port": 11111,
"tag": "in-mitm",
"protocol": "dokodemo-door",
"settings": {
"port": 443,
"followRedirect": true
},
"streamSettings": {
"security": "tls",
"tlsSettings": {
"certificates": [
{
"usage": "issue",
"certificateFile": "ca.crt",
"keyFile": "ca.key"
}
],
"alpn": [
"http/1.1"
]
}
}
}
],
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "你的服务器ip",
"port": 443,
"users": [
{
"id": "bulianglin",
"encryption": "none",
"flow": ""
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "tls",
"tlsSettings": {
"allowInsecure": true
}
}
},
{
"tag": "out-mitm",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "你的服务器ip",
"port": 443,
"users": [
{
"id": "bulianglin-mitm",
"encryption": "none",
"flow": ""
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "tls",
"tlsSettings": {
"allowInsecure": true
}
}
},
{
"tag": "direct",
"protocol": "freedom"
},
{
"protocol": "freedom",
"settings": {
"redirect": "127.0.0.1:11111"
},
"tag": "re-entry"
}
],
"routing": {
"domainStrategy": "IPOnDemand",
"domainMatcher": "mph",
"rules": [
{
"type": "field",
"outboundTag": "direct",
"domain": [
"geosite:cn"
]
},
{
"type": "field",
"outboundTag": "direct",
"ip": [
"geoip:private",
"geoip:cn"
]
},
{
"type": "field",
"inboundTag": "in-mitm",
"outboundTag": "out-mitm"
},
{
"type": "field",
"port": "443",
"protocol": "tls",
"outboundTag": "re-entry"
}
]
}
}
视频文稿(忽略)
TLS in TLS也叫TLS over TLS
意思是在TLS隧道里面传输TLS数据
为了不那么拗口以下简称TIT
这是自去年10月份TLS节点遭到大范围封禁后
大家比较关注的防火墙检测手段
底层传输基于TLS的节点都存在TIT的问题
比如trojan vmess+tcp+tls
vless+ws+tls等等
近期Xray作者RPRX发布了一个trojan-killer的PoC
可以准确识别服务器运行的trojan服务
再次将TIT的问题推到了大众面前
本期就来给大家讲讲
为什么会有TIT的问题
防火墙是否能够精准识别
TIT类型的节点还能使用吗
以及目前有哪些方法解决TIT
顺便教大家通过Xray实现MITM解决TIT特征
TIT的问题早在2017年trojan刚出来的时候
就已经讨论过了
只不过当时普遍认为
防火墙没有能力检测TIT
事实也确实如此
trojan vmess+tls这类底层传输基于TLS的节点
在很长一段时间里都是最稳定的搭建方式
直到去年的10月份
在10月2号的时候
我发布了naive节点搭建教程
里面提到了naive能解决TIT的问题
但是之前从未出现大范围封禁TIT节点的情况
所以在视频中我还自信满满的说道
防火墙目前没有能力检测TIT
tls节点还是非常稳定的
结果戏剧性的一幕发生了
在我发布视频后的第二天
也就是10月3号
立刻出现了大范围针对TIT节点的封禁
当然这肯定跟我没关系
只是这个时间点太过于巧合了
之前即使是敏感时期也没有发生过这种情况
从当时的情况来看
主要原因很有可能就是TIT特征
先来了解一下tls节点为什么会有TIT特征
目前我们访问大多数网站
都是使用HTTPS的方式
也就是HTTP+tls
HTTP是明文的
在互联网上传输非常不安全
于是使用TLS对明文的HTTP数据进行加密
关于TLS的详细内容
可以回看我之前的trojan节点搭建教程
以下简单进行说明
假设我们使用百度搜索相关内容
数据会经过tls加密
再发送到百度的服务器
百度会对其进行解密
获取到我们的意图后返回相应的内容
同样也会先进行加密再返回给我们
经过解密后获取到了网页内容
这是正常的HTTPS网站访问流程
再假设我们开启了代理工具
进行谷歌搜索
同样数据会先经过tls加密
但是加密后的数据不会直接发给谷歌服务器
而是先发给电脑里的代理工具
代理工具选中了trojan或者vmess+tls的节点
由于这类节点的底层是通过tls进行传输
所以会再进行一次tls加密
然后将数据发送给了你的节点服务器
节点收到数据后进行解密
获取到了内层的tls加密数据
这一层是谷歌的加密数据
节点无法进行解密
会帮我们转交给谷歌
谷歌收到数据后再进行解密
获取到了用户的搜索内容
然后返回相应的结果
也是先进行TLS加密
再发给你的节点服务器
节点再进行TLS加密
将数据发回给你的代理工具
代理工具进行外层的TLS解密
然后将结果返回给了浏览器
浏览器在对内层的tls进行解密
获取到了最终的谷歌数据
这就是典型的TIT特征
在tls里面传输tls数据
存在多层加密套娃
防火墙要检测的话说简单也简单
多层加密肯定会导致数据体积增大
和正常的HTTPS流量有区别
并且存在时序特征
上面省略了tls的握手协商过程
简单来讲
正常的访问HTTPS网站
会在TLS握手后就直接开始
发送访问网页的加密数据了
但是两层TLS的情况下
会在外层TLS握手建立连接后
内层还会在外层的加密数据中
进行一次TLS握手
然后才是发送访问网页的加密数据
这也是有特征的地方
你要说难的话也很难
毕竟想在如此海量的数据中进行监控
并成功检测出TIT的特征
在我的认知范围内是难以想象的计算量
所以之前才会觉得防火墙没有这个能力
但是前段时间R神发布了检测trojan的PoC
并没有通过非常复杂的分析
只是非常简单的判断一下
握手阶段数据包的大小
就能非常精准的识别出trojan
刷新了我对这个问题的认知
我也使用PoC做了简单的测试
直连的情况下基本不会有误判
通过trojan访问网站大部分都能被识别出来
也测试了vmess或者vless的tcp+tls节点
有小概率被识别
虽然这个PoC是识别TIT
但它主要还是针对trojan协议本身
所以你也可以看到vmess+ws+tls虽然也有TIT的问题
但是在这个PoC中并没有检测出来
那防火墙目前真的会进行TIT检测吗
众所周知 GFW防火墙是黑盒
没有人能完全知道具体的检测机制是什么
在没有足够多的证据之前
我们都只能通过小部分用户的反馈
来猜测可能的情况
从我个人的观察来看
我倾向于存在TIT检测
但是检测的范围应该不大
和你的运营商和地区有关
我之前发布的一个纯小白节点搭建教程
就是用的vmess+ws+tls
存在TIT特征
大部分用户搭建后可以稳定使用
偶尔收到反馈节点无法使用了
由于教程是面向纯小白用户
有时我会协助他们进行排查
一般是端口被封
帮他们更换端口后
一两天内又会被封
于是换个端口搭建可以缓解TIT的vision流控节点
端口被封的情况就再也没有出现过
直到现在那几个节点还存活着
当然这也不能说明一定是TIT的问题
不过概率还是很大的
毕竟二者的主要区别在于有没有TIT特征
但如果有TIT检测
那为什么大部分用户用同样的方式搭建
并没有出现被封禁的情况
这个问题的话没法回答
我也只能猜测可能是检测的范围不大
前面也说了
防火墙是黑盒状态
没有人能知道具体的封禁机制
能检测和有没有检测是两码事
裸SS协议防火墙已经能够通过
无规则字节流的特征精准识别了
大部分用户搭建这种节点基本上是秒封
但有些地区他就是没问题
你说气不气
甚至我用过某个住宅IP商家的socks5代理
并没有魔改 而是标准的socks协议
居然可以用来直接翻墙
在高强度的使用下
我想让他被封都做不到
这种情况已经在我的认知范围外了
所以还是那句话 没有最好的协议
只有适合自己的才是最好的
trojan还能不能用
只有你自己试过才知道
如果你直接搭建一个SS节点就能用
不会被封
那恭喜你 你是幸运的
但大部分地区的用户基本上都是秒封
需要加上TLS来缓解
针对套了TLS之后还是存在被封的用户
你可能就需要搭建能够解决TIT特征的节点了
但是解决了TIT是不是就万事大吉了呢
并不是 除了协议本身
你在哪个地区
用哪个运营商 哪个商家的VPS
以及什么代理工具 什么分流配置
甚至通过国内信道传输节点链接
这些都可能是导致被封禁的因素
所以没法展开聊 点到为止
目前解决TIT特征的协议
主要有之前讲过的naive
和之前没有讲过的vision流控
他们主要是对内层的tls握手
进行字节填充来缓解TIT特征
但这期我们不讲这两个协议
主要来讲讲如何通过Xray实现MITM解决TIT的特征
在搭建之前我们先来了解一下MITM
为什么可以解决TIT的问题
MITM全称man in the middle
意为中间人
我在之前的奈飞截止cookie那一节中已经讲过了MITM
不过那期并不是为了解决TIT特征
而且那一期是在节点服务器上进行MITM
也无法解决TIT特征
再来回顾一下TIT的定义
在TLS里面传输TLS数据
为什么TLS里面会传输TLS数据
因为大多数情况下
里面传输的都是HTTP+tls的数据
也就是访问HTTPS网站
如果我们访问的网站使用的是HTTP
也就是我们TLS节点里面传输的是HTTP
也就没有TIT的特征了
但是现在大部分网站都是HTTPS
所以MITM要做的就是把网站本身的TLS剥离
只留下HTTP
这种方式解决TIT特征
要比naive和vision的字节填充更彻底
毕竟填充是模仿
MITM是剥离后再重新封装成tls
所以也能解决内层tls的时序特征
因为已经没有内层了
从时序特征来看
就是在访问一个正常的https网站
关于MITM早在5年前
就已经有大佬使用v2ray实现了
只不过当时并不是为了解决TIT特征
纯粹就是为了展示v2ray能做到而整的花活
既然v2ray早就能做到了
又能这么完美的解决TIT特征
那为什么这么久了还没有普及
因为这种方式存在巨大的安全隐患
以代理访问谷歌为例
首先浏览器使用HTTPS访问谷歌
数据先发给本地的代理工具Xray
Xray收到数据后进行MITM
将自己伪装成谷歌
浏览器会和Xray建立TLS连接
并将加密后的HTTPS数据发给Xray
xray收到HTTPS数据后进行解密
还原成了HTTP的明文数据
然后通过trojan或者其他TLS类型的节点
对数据进行TLS加密
很显然这个数据包没有TIT的特征
因为内层传输的是HTTP流量
并不是HTTPS流量
所以这就是一条正常的访问网站请求
数据来到节点服务器
节点服务器对数据进行解密
获取到了用户的明文HTTP数据
然后将这个数据通过TLS加密
再发送给谷歌服务器
谷歌再对其进行解密
数据返回也是按照这样的方式
这里我们简化了期间的握手过程
大家只需要知道数据的加解密流程即可
这里主要存在的问题是
节点服务器可以看到明文的谷歌请求
这是非常不安全的
即使是自建的节点
你也无法保证VPS的绝对安全
访问网银之类的高风险网站
极有可能导致隐私数据泄露
不建议新手尝试搭建
它的意义更多的是在于给大家提供一种判断
防火墙是否存在TIT检测的方法
如果选择继续搭建
你需要明确可能对你带来的安全风险
为了简单一点
服务端我们使用XUI面板
使用这条指令安装XUI
进入面板设置的Xray设置
将我给大家提供的配置模板替换掉原来的内容
模板内容我会放在视频下方的描述栏
本期的MITM是为了解决TIT的问题
所以模板里的节点是vless+tcp+tls
实际上你可以使用任何Xray支持的协议进行MITM
比如ss vmess trojan等等
关于配置文件就不浪费时间给大家解释了
相信愿意搭建的你也不是新手
配合刚才讲的MITM原理应该能看明白
如果你对tls不太熟悉
证书部分可能不太理解
建议回看我的trojan节点搭建教程
点击保存配置
再点击重启面板
由于使用的是vless+tls的节点
所以需要给节点配置证书
如果你有域名的话
可以使用acme找正规的CA机构申请
我这里简单演示就使用之前证书了
使用这条指令在指定目录下生成证书
进入证书目录
这对公私钥是节点的公私钥
由于是自签的ca
也可以用来做MITM的公私钥
如果你的节点用的是正规CA机构颁发的证书
你也需要用这条指令生成一对公私钥给MITM使用
将其下载下来
代理工具我使用v2rayN进行演示
你可以通过直接调用Xray内核的方式使用
这是客户端要用到的Xray配置文件
入站分别为socks的8888端口和HTTP的9999端口
先将其保存为配置文件
找到Xray内核所在的位置
我用的是v2rayN6.0以下的版本
Xray内核和程序在同一目录下
将证书文件和私钥复制到这里
然后在v2rayN中添加自定义配置服务器
随便给个别名
将我们刚才创建的配置文件导入进来
内核选择Xray
点击确定
选中刚才创建的节点
在浏览器中设置代理
可以用配置文件中socks的8888
或者HTTP的9999
尝试访问谷歌
可以看到弹出了不安全的警告信息
这是MITM的正常表现
因为我们现在用的是自己签的ca
证书由于我们还没有信任Xray的根证书颁发机构
所以弹出来警告
尝试访问YouTube
也是同样的警告
接下来需要信任我们的CA证书
双击打开
点击安装证书 存储位置按需选择
我选择当前用户
将证书导入到受信任的根证书颁发机构
导入成功后重启浏览器
此时再来访问谷歌就可以正常访问了
并且消除了TIT的特征
可以看到谷歌的证书是由Xray的自签CA颁发的
我给大家的配置分流规则是
国内网站不走代理
所以百度并没有进行MITM
证书还是正常的证书
只是我们走代理的网站会进行MITM
这就是MITM节点的搭建过程
还是很简单的
如果你不想使用了
强烈建议把刚才导入的CA证书移除受信任
在开始菜单中搜索cer
由于刚才我们是将证书导入到当前用户
所以选择管理用户证书
如果你导入的是本地计算机
就选择下面的管理计算机证书
在受信任的根证书颁发机构里面
找到刚才导入的MITM证书
将其删除即可
删除之后
再重新使用MITM节点访问谷歌
又会弹出安全警告了
这就是MITM节点的搭建方法
我个人是不建议平时用这种方式进行科学上网的
因为你无法保证你的VPS绝对安全
当然具体还是得看你自己
毕竟每个人对安全都有自己不同的标准