全球主机交流论坛

标题: 史上最最最安全的个人自用留学方案，没有之一，先抛个砖 [打印本页]

作者: Tankie 时间: 2022-11-12 15:39
标题: 史上最最最安全的个人自用留学方案，没有之一，先抛个砖
概述：之前一直以为Trojan是完美的解决方案了，直到最近针对TLS的清网行动。之前没事在想TLS怎么才能更安全，还发过一个SB贴子，见：https://lilynana.eu.org/thread-1083134-1-1.html。

但后来，我想通了，我的想法并不SB，只是中间要加一层中间人劫持。

原理：
1，浏览器--------（完成TLS握手，解密http发给本地客户端）------本地客户端
2，本地客户端---------（完成服务器上正规网站tls握手，将解密的浏览器http数据发给服务器端）-----------服务器端
3，服务器端---------（服务器端用浏览器的http请求信息加上本地自已的tls握手获得数据）--------------目标网站
4，数据从服务器端一路回传。

其中经历了三次TLS握手，但在外面监控流量的来看，就完全是正常的一次https访问。除非大局域网不让用外面https,否则理论上不可能封。

实现起来，对于神通广大的MJJ应该不难。因为涉及到根证书的东东，理论上只能小部分群体自用。

我自己尝试着实现了下，用的mitmproxy + flask + requests，因为我只懂一点python皮毛，所以只能在一堆报错的情况下，勉强用用。期待大佬完善一下。

试了下测速，因为在尝试可行性，只试了下get，所以测速，只能成功运行单向。

如图的中间人截持百度：

最后，看有没有大佬完善下脚本。

作者: Akewa 时间: 2022-11-12 15:42
楼下大神马上出现。

作者: HOH 时间: 2022-11-12 15:43
根本就不是那一回事瞎折腾

作者: Tankie 时间: 2022-11-12 15:45

HOH 发表于 2022-11-12 15:43
根本就不是那一回事瞎折腾

这个只是https流量的双重TLS问题，其它的自然转发就好。

有什么问题吗，大佬？

作者: 炒土豆丝 时间: 2022-11-12 15:46

端口怎么选，五位数和443都会阵亡。

作者: 奧巴马 时间: 2022-11-12 16:04

炒土豆丝发表于 2022-11-12 15:46
端口怎么选，五位数和443都会阵亡。

那我六位数端口,无敌了吧.

作者: 主菜单 时间: 2022-11-12 16:05
不是sing-box的很像

作者: adminisd 时间: 2022-11-12 16:24
根证书没必要，有根证书只是不报HTTPS不安全而已，v2ray忽略tls验证就行

作者: waini1110 时间: 2022-11-12 16:25
提示: 作者被禁止或删除内容自动屏蔽

作者: Erik 时间: 2022-11-12 16:25
先留帖

在慢慢看看

作者: 闲月疏云 时间: 2022-11-12 16:28
本帖最后由闲月疏云于 2022-11-12 16:30 编辑

那你还不如直接让浏览器直接通过ws发送你要传输的数据，也没有指纹问题，一个效果，还只要2次TLS握手，搞一下padding也难检测TLS in TLS的特征

作者: Meocat 时间: 2022-11-12 16:30
中间人劫持的方案是对的，只不过比较麻烦，没办法推广到机场

这样你访问网页的时候显示的应该都是你本地自签的证书，即使有一天真被中间人劫持了也看不出来

作者: pjk 时间: 2022-11-12 16:32
提示: 作者被禁止或删除内容自动屏蔽

作者: Tankie 时间: 2022-11-12 16:34

Meocat 发表于 2022-11-12 16:30
中间人劫持的方案是对的，只不过比较麻烦，没办法推广到机场

这样你访问网页的时候显示的应该都是你本地自 ...

所以，我说自用啊，只会小部分人，小范围用啊。

另个，你自己加的根证书理论只有你知道，即使有被人劫持风险，第一步要别人知道你加的根证书啊，然后才能劫持。

对于个人来说，这个风险太低了吧。

作者: SK_ 时间: 2022-11-12 16:41
我听说实际情况是因为两次tls握手特征造成的。tls in tls就会产生6次握手，而且特征明显，可以精确匹配。

作者: Tankie 时间: 2022-11-12 16:44

SK_ 发表于 2022-11-12 16:41
我听说实际情况是因为两次tls握手特征造成的。tls in tls就会产生6次握手，而且特征明显，可以精确匹配。 ...

这个方案就是避免这个情况

完全正规合法的TLS握手，不含丝毫伪造，100% 保真

作者: 1121744186 时间: 2022-11-12 16:45
用不着那么麻烦， tls + 大流量 + AI 上网习惯一下就实锤了，再给你弄个用户画像 "上网代理惯犯" 重点给你添加点判断权重

作者: 昔洛z 时间: 2022-11-12 19:17
学习一下呢

作者: yem 时间: 2022-11-12 19:29
反正我现在都拉cf 随便你们怎么封

作者: Senly 时间: 2022-11-12 19:33
确实如推荐所说，也许真的有用户画像，我和我弟都是联通的宽带，在一个村，一样的鸡，一样的配置，他用得少，从来不阻断，一个ip没死过。我用的多，阻断严重的时候几分钟无限循环，ip偶尔会挂。

作者: hitachi 时间: 2022-11-12 20:27
本帖最后由 hitachi 于 2022-11-12 12:33 编辑

MITM 确实能解决 TLS over TLS 的问题，但却引入了额外的问题。
相对于 e2e，这种方案没法确认对端证书，还记得 GoAgent 的教训么；使用前须导入证书，略繁琐，且移动端适配不够；对卡巴斯基、Surge 这种需要 MITM 机制才能正常工作的软件来说，兼容性也是个问题。
综上，这种方案只适合个人小规模自用。
BTW，这个方案很早就有人提出了（2016-2017），彼时也是为了解决内层包裹的 TLS 问题。

作者: baby不卑鄙 时间: 2022-11-12 20:30
trojan封了两次443

作者: Yzindex 时间: 2022-11-12 20:31

hitachi 发表于 2022-11-12 20:27
MITM 确实能解决 TLS over TLS 的问题，但却引入了额外的问题。
相对于 e2e，这种方案没法确认对端证书；使 ...

还有人记得GoAgent这玩意？
记得彼时连谷歌Play都用不了。

对技术这块不是很懂……
我现在电脑常用PHP代理。
应该就类似楼主说的这种技术。

作者: hitachi 时间: 2022-11-12 20:43
本帖最后由 hitachi 于 2022-11-12 12:45 编辑

以及，TLS 从来都不是最完美的解决方案，只能说是一种别无选择的方案。
TLS 设计之初就不是为了对抗审查。TLS 建立会话需要交换大量信息，而信息交换得越多，特征越明显。
所有代理全都套层 TLS 更是加剧了同质化。

理想的解决方案应该是，每个人都自定义一套自己的协议，避免同质化。
成千上万种千奇百怪的协议，我看你怎么封。

作者: idc专业户 时间: 2022-11-12 21:04
呃，我都是3389直接来的，不玩这些虚的，

作者: Tankie 时间: 2022-11-12 21:40

hitachi 发表于 2022-11-12 20:27
MITM 确实能解决 TLS over TLS 的问题，但却引入了额外的问题。
相对于 e2e，这种方案没法确认对端证书，还 ...

真大佬。

安卓端其实同样可以信任证书。

局域网或自身开个共享代理就OK了。

确实只能个人规模用，感觉在未来的环境下，准备一下还是极好的。

作者: sah 时间: 2022-11-12 21:47
RDP是不是就不用这么折腾了，还是说只要外网流量大就容易触发强

作者: terrytw 时间: 2022-11-12 21:50
你都不知道人家封锁的时候靠的是什么原理

作者: miss8 时间: 2022-11-12 23:02
技术大佬啊，膜拜一下。

作者: tkn 时间: 2022-11-13 00:49
骚操作，好炫酷。墙：什么？流量大，封了。

作者: wxhscc 时间: 2022-11-13 01:13

tkn 发表于 2022-11-13 00:49
骚操作，好炫酷。墙：什么？流量大，封了。

你能不能严谨一点，技术讨论！！！大半夜的给我整笑了

作者: 萌十七 时间: 2022-11-13 01:17

1121744186 发表于 2022-11-12 16:45
用不着那么麻烦， tls + 大流量 + AI 上网习惯一下就实锤了，再给你弄个用户画像 "上网代理惯犯" 重点 ...

ai上网习惯来讲解一下
根据出境流量大小来判断？判断什么？
我有点不理解

欢迎光临全球主机交流论坛 (https://lilynana.eu.org/)