HTTPS on lategege 的技术博客

网络代理与移动安全攻防：从 TUN/iptables 到 Hook/TEE 的工程化全景

Thu, 26 Mar 2026 18:29:00 +0800

这篇是工程向版本：不聊概念套话，直接给分层模型 + 可验证命令。目标是把“流量怎么走”和“结果该不该信”彻底分开。

0) 先说结论（TL;DR）

SOCKS5 是本地入口接口，不是抗审查协议本体。
全局代理不止是改路由，常见是 TUN + 路由 或 Netfilter(iptables/nftables)。
iptables ≠ 路由表：前者改包/拦截，后者选路。
fake-ip 的价值是夺回 DNS 控制权，不是“拿假 IP 去公网通信”。
VPN 只能保证路径经过你，不保证你能看 HTTPS 明文。
Hook 的本质是控制流重定向，不是“改点内存”这么简单。
支付类 App 的核心是服务端裁决 + 硬件密钥边界，不是“客户端看起来对了就放行”。

1) 三个层次别混：入口、调度、封装

入口层：SOCKS5 / HTTP / TUN
调度层：Clash/OpenClash/sing-box（规则、分流、策略）
封装层：SS/SSR/VMess/VLESS/Trojan/TLS

一句话：你看到“本地 7890/1080”通常只是在入口层，不代表后面协议是什么。

2) “全局代理”到底改了什么（带命令）

2.1 SOCKS5/HTTP 手动代理（应用层）

应用主动把流量交给代理，系统路由本身可能不变。

验证：

1
2


# 看本地代理端口是否监听
lsof -nP -iTCP -sTCP:LISTEN | grep -E '1080|7890|7891'

2.2 TUN 模式（路由接管）

典型流程：创建 tun0 → 改路由 → 代理进程读 TUN fd。

验证：

1
2
3
4
5
6
7
8


# 看虚拟网卡
ip a | grep -A2 -E 'tun|utun'

# 看默认路由是否指向 tun
ip route

# macOS
netstat -rn | grep -E 'default|utun'

2.3 iptables 透明代理（内核链路接管）

不要求应用配代理，内核侧重定向/标记。

验证：

1
2
3
4
5
6


# 查看 NAT 表规则
sudo iptables -t nat -S
sudo iptables -t nat -L -n -v

# nft 环境
sudo nft list ruleset

3) 为什么说 iptables 不是路由表

对比：

路由表：决定“从哪张网卡走、下一跳是谁”。
iptables：决定“这个包要不要改、要不要丢、要不要重定向”。

实操对照：

1
2
3
4
5


# 路由决策（看某个目标会走哪）
ip route get 1.1.1.1

# 包计数变化（是否命中某条劫持规则）
sudo iptables -t nat -L -n -v | head -60

4) fake-ip 的关键：把 DNS 控制权拿回来

fake-ip 常见逻辑：

App 询问 example.com
代理返回保留网段假 IP（如 198.18.x.x）
App 连接假 IP
代理查映射表反解域名，再用可信 DNS 做真实解析并转发

排查命令：

1
2
3
4
5
6
7


# 直接查本机解析结果（对比开/关代理前后）
dig example.com

# 抓 DNS 包看请求打向哪里
sudo tcpdump -ni any port 53

# 如用 DoH/DoT，53 端口可能很少，需结合代理日志看

5) HTTPS 可见性边界：路径控制 ≠ 明文可见

典型误区：

“我有 VPN 服务器，流量都过我机子，为什么还是看不到请求正文？”

因为 TLS 端点通常是：App <-> 目标服务。中间节点看到的是密文。

可验证：

1
2


# 抓到的通常是 TLS record，不是 HTTP 明文
sudo tcpdump -ni any host <target_ip> and port 443

如果能看明文，一般说明你在终端侧成功做了 MITM（且 App 信任了你的证书链）。

6) Hook 的工程定义：改“执行路径”

更准确地说：

Hook = 在运行时把“调用 A”改成“先走你的逻辑，再决定是否回到 A”。

常见层级：

Java 层：方法替换/拦截（ART）
Native 层：PLT/GOT / inline hook
网络层函数：SSL_write / send 等

判断口诀：

改变量值，不一定是 hook
改调用去向，才是 hook 的核心

7) 支付/银行类 App 为何“看到了也不一定有用”

真实防线是多层组合：

环境检测：root、调试、注入框架
运行时完整性：关键路径自检、反篡改
密钥边界：Keystore/TEE，密钥不可导出
服务端裁决：签名复核、nonce/timestamp、设备指纹、行为风控

所以：

你可能拿到某段明文
但不代表你能伪造一个服务端接受的完整交易

8) 一套实战排障顺序（建议直接照这个查）

Step A：先确认“流量有没有经过代理”

1
2
3


curl --proxy socks5h://127.0.0.1:1080 https://ifconfig.me
curl https://ifconfig.me
# 两者出口 IP 是否不同

Step B：再确认“DNS 控制权在谁手里”

1
2


dig +short example.com
sudo tcpdump -ni any port 53

Step C：最后确认“你想看的数据在哪层”

抓包层只看到 TLS：正常
需要明文：要么 MITM 成功，要么在应用加密前拦截

9) 最后一句

网络代理解决的是 怎么走。
安全工程决定的是 该不该信。

把这两件事分开，你会少走很多弯路。

https协议为什么安全？

Sat, 04 Nov 2023 17:07:25 +0000

现在网络上使用http的网站越来越少了，这很大部分原因要归功于浏览器的强制要求，浏览器强制用户使用https而非http，人们的安全意识也逐渐增强了。

那么为什么使用https协议是足够安全的呢？

首先协议的本质，至少站在程序员角度去看，就是一段按照协议要求编写的程序，而且必然是供两端或者多端使用的，要不然不可能会被定义为协议，比如TCP协议，IP协议，ICMP协议，ARP协议等网络相关协议，协议所要解决的本质诉求必然是通信。哪怕是电子电路中的协议也一样，CAN,SPI,I2C,UART,USB等都是解决电路之间通信问题，蓝牙、wifi、星闪、nfc协议都是解决无线通信问题，http(https)、ftp、smb、ssh等是为了更方便的解决网络通信问题而生。它们的诞生本质就是为了方便，如果把IP,ARP等协议比作钻木取火，那么http(https)就是打火机。

越原始的协议构造越简单，无论怎么变化，怎么定义，它们都是为了传输数据，既然是传输，就势必会有安全问题，网际传输会经过无数路由和交换机，它们一个个都是快递转运站，谁能保证快递员不拆开包裹来瞧一瞧？http对快递员来说就是一个使用了透明盒子的协议，你里边的数据完全公开，但是用http传输也可以是安全的，那就需要程序员把数据加密后再丢给http协议，对端收到后再解密。那么问题来了，谁能保证密钥安全，加密算法安全，这两个东西泄漏了就和透明没啥两样，特别是CS架构下，客户端若去解密，相当于明文了，代码一览无余。

https就是为了解决上面的问题而生，其本质就是在数据按照http协议加工之后，在http数据传输之前将数据加密，然后发送，对端在接收之后解密，然后按照http协议解包还原。

那么加密后一定安全吗？密钥和算法被攻破怎么办？网景公司软件工程师设计https之初肯定也想到了，它们想着只要密钥不被攻破，那么传输就是安全的，还好数学上有一个叫做非对称加密的东西，即使我算法摆给你看，只要你拿不到我的私钥，我们之间的通信就是安全的。

https最核心的安全实现就是利用了非对称加密，非对称加密的本质是大质数极难分解。由两个因子产生一个公钥和一个私钥，而且他们其中一个加密，另一个可以解密，它们的诞生全都源于这两个因子，你无法从公钥私钥反推两个因子，因为分解难度极高。之所以一个加密，另一个能解密是由于它们具备某些数学特性，可以看做一个黑盒，就是这么神奇地被发现了，没有什么理由，这背后说不定和造物主有关。

我们把公钥加密，私钥解密称之为对数据进行了非对称加密，而用私钥加密，公钥解密称之为签名验证，这是非对称加密的两种应用。

https 有了非对称加密后，数据安全是有保证了，但是还要解决一个传输效率问题，因为非对称加密时间复杂度很高，如果传输数据都要使用非对称加密，那https的延迟高的没法用了，所以https采用的办法是引入对称加密，非对称加密RSA只对对称加密的密钥进行加密，没人能解出对称加密的密钥，那不就是最安全的吗？

https解决了效率问题，又有一个问题产生了，我作为服务器，我假冒一个银行系统，你登录我的网站，你全程都是用我的公钥和我来通信，你输入的密码在最终会被我的私钥进行解密，虽然互联网上别人没法获取，但是我获取到了，我再利用这个密码去真的银行把钱转走，这就是信任危机。客户端怎么来信任你，这就是签名技术，客户端需要信任这个公钥就是来自官方，怎么做呢？找第三方权威机构呗，权威机构使用它们的私钥对官方的公钥进行加密，也就是签名，我们拿权威机构的公钥来验证官方的公钥，也就是解密。解密失败就是该公钥非法，权威机构的公钥怎么信任呢？那只能信任，权威机构的公钥以证书的形式内置在操作系统中，不信任都没办法。实际的公钥是以证书的形式发送的，证书包含了公钥以及官方的域名、主机、签发时间、有效期等信息，也包含了权威机构的签名信息。

https解决了信任问题，又产生新问题了，虽然我不知道你的数据是什么，但是我可以修改，当我中间将密文修改再转发给目标，此时服务端必然解密失败，面对这种捣乱的行为确实无解，但这对攻击者也没啥好处，我们假设攻击者恰巧伪造了一段居然能被解开的数据，但却不是原数据，整个事情就是这么凑巧，那面对这种情况需要引入防篡改机制，哈希就是这个用途，在对数据进行对称加密的同时，原数据会做一次哈希摘要，这个摘要连同密文一并发给对端，对端在解密后，还要对原文做一次哈希摘要来和对端发过来的对比是否原文被篡改过，这在安全层面上又添上了一大保障，哈希算法的本质就是将大区间的数据映射到小范围的数，它不可还原，但不同数据所映射形成的数几乎不可能是同一个，因为https所使用的哈希是带密钥的哈希，每次安全链接的哈希密钥都是协商出来的而且不是同一个，这种概率极低极低。如果奇迹真发生了，不同数据产生了同样的哈希值，并且还是同一次连接，那我们说发生了哈希碰撞，但从https应用的角度讲，没有任何影响。

解决完上述问题后，https诞生了，其流程如下：

1.客户端和服务端建立TLS连接(期间协商了使用的加密算法，还互送了两个随机数给对方) 2.服务器将证书(包含了公钥、签名、有效期、域名、主机等信息)发给了客户端 3.客户端用系统证书来验证该证书的合法性和有效性。 4.客户端生成一个前置加密密钥，使用商定好的RSA算法对该密钥加密，并将该密钥传给服务器。 5.服务器收到后，解密得到前置加密密钥。两端各自使用该密钥配合前面的随机数生成一个实际密钥，该密钥不是一个，而是四个，分别是客户端加密密钥，服务端加密密钥，客户端哈希密钥钥和服务端哈希密钥。因为两端信息对等，所以算出来的都是一致的。 6.客户端使用客户端对称密钥对原文进行加密，同时对原文进行哈希摘要，将密文和哈希摘要发送给服务端。 7.服务端收到后用用客户端对称密钥进行解密，然后对解密后的数据也做一个哈希摘要，进行比对，来验证来源的可靠性。 8.服务端向客户端通信则使用服务端的密钥，方式同客户端加密一致。

上述流程保证了https的安全性，在私钥不泄漏的情况下，即使试出了对称密钥和哈希密钥，你也不可能同时算出客户端的和服务端的，就算都算出来，每一次安全通信，随机数不同，密钥也完全不同，你解出来的信息是过时的，所以https的安全性得到了最大的保障。

群晖gitlab开启https只需三步

Sun, 21 Nov 2021 07:16:39 +0000

前提条件：群晖已经配置了https证书

第一步:

打开群晖控制面板-->synology应用程序门户-->反向代理服务器填入你自己的域名，配置访问端口，一般群晖都是家庭使用，国内宽带封443，所以想外网访问的话443是不能使用的，这里配置成50000端口，具体可按照自身需求决定，路由器做好端口映射就好了，下面启用hsts勾选，启用http/2勾选，目的地协议http,主机名填群晖的局域网ip地址或者127.0.0.1 端口填8000，可根据自身需求变更。

第二步：

进入套件中心将gitlab停用

进入docker容器，找到synology_gitlab右键编辑

检查端口设置，8001这个端口映射为gitlab22端口，这个映射的作用是git克隆使用ssh协议所需要的，同样路由器应该开启端口映射以供外网使用来支持ssh协议克隆

第三步：

进入环境，新增GITLAB_HTTPS 值为true 这个配置改变的是gitlab的克隆地址的协议，和端口设置没有任何关系，也就是说如果没有这个配置，克隆的时候地址还是http，这样克隆地址就无法经过反向代理。

配置gitlab_host，gitlab_port , gitlab_ssh_port 同样这三个值和端口设置没有半毛钱关系，这三个值都是在配置git克隆的地址，gitlab_host应该和反向代理的域名保持一致,gitlab_port应该和反向代理的端口保持一致，gitlab_ssh_port和端口映射中的端口保持一致（以支持ssh协议,如果不需要ssh协议的克隆方式，就无所谓)