前段时间在考虑一个优雅的内网穿透方式，最好能利用已有的服务（因为本地已经在运行着太多的服务了）来实现，而且对隧道的安全性也需要一些要求。对于最常见的加密流量来说，采用 TLS 是最为普遍且经过数理验证的方法。

0x00 TLS / SSL 的奥秘

为什么 TLS 加密传输数据就可以确保不会被第三方解密、窃听或修改呢？这要从加密的传输方法开始探究讲起了。最原始的加密方式便是双方共同规定一段字符串来作密码。显然采用固定的一段密码是不行的，比如有一个公共的服务，若希望用户都能访问的同时也采用加密传输让服务商认定的服务范围外用户不可见数据，则需要给每一个提供服务的用户一段密码。在这种情况下，每个人都可以去使用这个密码去伪造服务商提供的服务来攻击其他的用户，此时便引出了 TLS。TLS 的前身是 SSL，在客户端-服务器连接中对服务器进行身份的验证，并提供了对客户端与服务器通信的加密。解决的问题是如何证明用户 Alice 是 Alice，而不是 Bob。

非对称加密

现在采用的一般为非对称加密传输技术。非对称加密(Asymmetric cryptography)需要两个密钥：公钥(Publickey)和私钥(Privatekey)。公钥用于加密，而私钥用于解密。将要传输的消息体 "Hello" 会被公钥加密，生成的加密内容用来传输，且只有相应的私钥才能解密出原本的明文，用于加密的公钥不能用作解密的用途。由于加密与解密需要两个不同的密钥，故称为非对称加密。公钥是可以公开分发到任何地方，每个人都可以轻易的获取到。而私钥是不可以公开的，其必须由拥有者自行秘密保管，不能透过任何途径向任何人提供，包括通信的另一方。

TLS

TLS 证书是一个数据文件，其文件中包含了用于验证的服务器信息、设备信息、公钥及其生效时间段。通常在 TLS 中，服务器有一个 TLS 证书和一个公钥/私钥对，而客户端没有。典型的 TLS 流程如下：

1. 客户端发送请求到服务器
2. 服务器回应请求，并返回其拥有的 TLS 证书
3. 客户端获取到服务器返回的 TLS 证书，验证其有效性
4. 客户端与服务器建立了有效的 TLS 连接，通过 TLS 传输加密的信息

mTLS

mTLS全名是 Mutual TLS，是一种相互验证身份的方法。与普通 TLS 不同的是，mTLS中客户端与服务器都有一个证书，且双方都会使用它们的公钥/私钥进行身份验证。与上述TLS步骤中相比，mTLS会有一些额外的步骤来验证对方

1. 客户端发送请求到服务器
2. 服务器回应请求，并返回其拥有的 TLS 证书
3. 客户端获取到服务器返回的 TLS 证书，验证其有效性
4. 客户端发送自己的 TLS 证书给服务器
5. 服务器收到客户端发送来的 TLS 证书，验证其有效性
6. 服务器接受此客户端的连接
7. 客户端与服务器建立了有效的 TLS 连接，通过 TLS 传输加密的信息
   在 TLS 中，通常使用 CA 颁发的有效证书，其主要负责检查证书所有者是否拥有合法的关联域。而在 mTLS 验证时，是需要自签名证书，授权的客户端与服务器使用的证书必须由此自签名的根证书生成的。

0x01 加密隧道方案

其实生活中便有着双向验证的例子。如在使用 ssh 远程连接服务器时，需要先将公钥上传到 ssh 服务器上。在第一次建立连接时，本地的 ssh 客户端展示服务器的公钥，提示是否信任。在信任后便会将服务器信息与公钥保存到~/.ssh/known_hosts中

如果key发生了变化，再次建立 ssh 连接时客户端会提示公钥不匹配

而 git 一般也是通过 ssh 协议完成的，故其也是一种双向的验证。如在使用 GitHub时，需要建立彼此的信任。GitHub 通过已经上传的公钥来验证，而客户端是通过验证 GitHub 分发在互联网上的公钥

0x02 自签证书

为了实现 mTLS，先进行自签名证书操作。共需要两套证书，一套分配给客户端，另一套给服务器使用。
使用 openssl 生成 CA key 与证书:

[object Object]

这里给证书设置了十年的有效期，避免证书过期后再生成的问题。至此已经有了 CA 的私钥与证书文件，现在已经可以签发给客户端与服务器证书了。
继续生成两套证书:

[object Object]

这样就为客户端与服务器分别生成了证书。需要注意的是，在为服务器生成证书时额外添加了证书对应的域名，这可以在一些验证域名的场景中使用。
此时我们获得了以下文件:

准备工作就已经完成了。接下来开始部署给 nginx 使用

Nginx 作为服务端提供服务端口

启用一个测试用 HTTP 服务

这里以一个简陋的 HTTP 服务作为测试端口是否转发成功：

[object Object]

启用 Nginx 服务

这里推荐使用 Docker 启用便于管理。新建一个文件夹用于存放 nginx 相关文件，并将以下内容保存到文件docker-compose.yml中

[object Object]

而后建立一些文件夹:

[object Object]

把生成的证书放入目录./certs里
修改 Nginx 的配置，将以下内容保存到nginx.conf中:

[object Object]

新建一个 stream 监听，将以下内容保存到./conf/stream.d/myproxy.conf中:

[object Object]

其中

• listen 字段代表服务器监听的端口，即将来客户端请求的接口
• proxy_pass 字段与常规的 http 代理中 proxy_pass 一致，是请求到 listen 监听端口的请求转发的目的。
• ssl_certificate 与 ssl_certificate_key 分别为已经生成的证书私钥与证书位置
• ssl_verify_client 来决定是否启用客户端身份验证
• ssl_client_certificate 来指定 CA 的证书
  由上述各字段内容可知，此配置是 nginx 在本机 8889 端口启用监听，将 8889 端口接受的请求进行客户端身份的验证。若验证通过后将请求转发到本机的 8888 端口，即之前已经启用的 HTTP 服务上。
  此时文件已准备完成，执行命令docker compose up -d即可启用 nginx 服务

客户端 Nginx 服务配置

大部分内容与服务器的配置相同，不同的地方在于目录stream.d下的配置文件
将以下内容保存到./conf/my_proxy_client.conf

[object Object]

需要注意的是，proxy_ssl_name这里要填写在服务器生成证书时指定的域名。

连接验证

在正确的配置了上述的客户端与服务器上的 nginx 服务并启用后，TCP 数据流在公网中由服务器的 8889 端口加密传出，客户端便可以请求本地的 4008 端口来访问到服务器 8888 端口上的服务了。该数据流是高度加密的，常见的用途如本地连接到服务器上的数据库。

看完了？说点什么呢

在使用 Docker 部署 MySQL 8.4.0 时，提示错误Fatal glibc error: CPU does not support x86-64-v2。于 Github 找到相同 issue。

解决方案

使用8.4.0-oraclelinux8替换原有的镜像，即

[object Object]

看完了？说点什么呢

启动台的应用图标顺序总会出现错乱，有时需要自动整理一下。在升级了 macOS 15.2 后，原先使用的

[object Object]

不再生效。参考帖子，使用命令

[object Object]

即可

看完了？说点什么呢

在加入到Apple Pay中的有些银行卡的卡面很精美，想要保存下来大图。在Terminal中运行如下

[object Object]

即可将卡面图保存到桌面cards文件夹中

看完了？说点什么呢

0x00 背景

在使用RDP(Windows Remote Desktop)时，无论是输入IP地址还是域名都会提示无法验证远程计算机的身份，是否仍要连接？

而在macOS设备上，会弹出如下的提示，与Windows的提示大意相同，都是在表明将要连接的计算机所使用的是不被信任的证书。

这个证书是在Windows安装的过程中以计算机名称为域名的证书，不被信任也是合理的。虽然在Windows下点了不再提示后便再也不见，但在macOS客户端上仍会有此提示。故要想完整的解决这个证书问题，只能修改被连接计算机系统中的RDP所使用的SSL证书文件。

在正式进入下列步骤之前，确保已经拥有了域名与相应的证书文件。

0x01 前提准备

若使用的国内云厂商（如阿里云、腾讯云等）提供的证书，可以选择PFX证书下载以作备用。而使用acme.sh 进行申请所得到的证书有your.domain.key和your.domain.crt。需要注意的是，Windows并不能直接使用此类证书，而是采用了PKCS#12标准证书，样式通常为上述所提到的your.domain.pfx。

转换证书可以使用OpenSSL操作。假使已经完成了OpenSSL的安装与证书的申请，便开始进行证书的转换。

[object Object]

执行上述命令后会提示键入私钥密码，记住此密码，稍后添加证书时需要使用。完成后将在当前工作目录下找到需要的your.domain.pfx文件。

0x02 添加证书

将上一步得到的证书上传到Windows计算机中，并双击打开，会弹出证书导入向导。

• 存储位置：本地计算机
• 要导入的文件：直接点击下一步即可
• 私钥保护：此处输入上一步中键入的密码
• 证书存储位置：个人

点击完成后即可导入成功。此时已将上一步中的pfx证书文件导入到Windows中。但只导入证书还不能达到使用此证书作为RDP证书的效果。

使用快捷键Win+R ，输入certlm.msc ，打开本地计算机证书管理器。在个人→证书列中可以发现刚刚导入的证书。右键此证书→所有任务→管理私钥，在打开的对话框中点击添加，输入NETWORK SERVICE 并点击确定。给NETWORK SERVICE以允许读取的权限。

点击确定即可保存权限。

再次双击此证书，点击详细信息，在字段中找到指纹字段项，点击后将对应的值复制作备用。

0x03 配置SSL证书

此时需要将证书指纹配置到注册表中。

假使上述得到的指纹为yourprivatefingerprint 。右键Windows菜单，以管理员身份运行PowerShell，并输入

[object Object]

到此处已经配置完成了Windows RDP的证书。若证书对应的域名已经解析到此Windows计算机上，再次远程桌面时将不再提示证书问题。

看完了？说点什么呢

看完了？说点什么呢

0x00 背景

在两个月前，对网络进行测速时发现不论是有线连接还是无线连接，测速结果总会是在940Mbps徘徊。而众所周知，运营商在进行带宽限速模板的制定时总会给出额外的20%带宽作为冗余。随着WiFi协议的不断增进，现阶段WiFi6 160Mhz 2x2即可有着2400Mbps的速率，跑满这20%冗余带宽绰绰有余，于是有了更换光猫的念头。若想充分利用这部分冗余带宽，不仅需要2.5G及以上的上行光口，也要确保有2.5G的电口保证下行设备的速率。为了节省一个2.5G路由器的成本，最终选购的光猫便是中兴的G7615 V1。

在某二手交易平台购入了一个G7615 v1，并让卖家在发货前提前刷好相应地区相应运营商的固件，同时打开telnet。经过了漫长的等待后，终于是在一周后收到了快递。当天便将原光猫的内容进行抄录备份，如Internet接口的VLAN ID、光猫注册用的LOID、原光猫的序列号与MAC地址、宽带拨号的账号与密码等，随后更换并通过telnet在新光猫的shell中进行配置与注册，最后更换成功，也解锁了940Mbps的速率限制。

随着有了shell的权限，便开始在光猫中翻找一些有趣的内容。此处一大部分的略过，但最后在执行了一句恐怖的mount -o rw,remount auto /命令后，G7615变一蹶不振，无法再次启动。在某论坛查到了相关的内容，了解到只要对根目录进行rw的remount操作后就会无法启动，遂决定拆机从TTL开始救砖。全家扫荡似的也没找到USB-TTL，于是从某电商平台以￥11.8的价格购入了三个CH340G模块，开始G7615的救赎之路。

0x01 救砖前的准备

在救砖前您需要准备的内容是：

• 一款串口监视器软件，如MobaXterm或Lucy
• 一个USB→TTL，如CH340，并确保已安装驱动
• 一位已拆机连接了TTL线正在等待复活的G7615
• G7615的固件

查阅资料后得知，左上角四个触点的含义分别是VCC、TX、RX、GND，TTL用1.8V或3.3V均可，VCC不可以接入，故最终接线为：空、TTL的RX、TTL的TX、TTL的GND。

连接了CH340到电脑后，请确保在设备管理器的端口中可以看到CH340字样

记录COM口的数字，并双击打开，在新的对话框中选择端口设置，设置为如下状态

在接线完成后，打开电脑上的串口监视器软件，Serial Port选择新接入的CH340串口，波特率选择115200，同时启用MobaXterm的TFTP服务，并将需要刷写的固件（kernel.bin、framework.bin）放入到TFTP服务的目录中。在准备完毕后，便可以开始监听串口，并在启动光猫的时候狂敲空格确保进入交互终端中。

在显示了⇒ 字样后，代表已成功中断了正常的引导，进入了UBOOT模式，此时便可以选择刷机。

0x02 开始刷机救砖

通过网线将电脑的网口与光猫的LAN口相连，并在电脑设置为静态IP：192.168.1.100/24，默认网关项留空。

先输入nand bad ，检查是否有坏块。若返回结果为Device 0 bad blocks，便可执行下列操作进行刷机，否则需要先进行坏块清理。

需要执行的代码有：

• 设置本机的IP与光猫的IP

[object Object]

• 下载所需要刷机的固件

[object Object]

• 进行写入操作并重启

[object Object]

不出意外的话，光猫在重启后已经能够成功引导，剩下的只需要进行初始化配置与注册LOID等内容了。

余下的配置部分，可参考网络上大量的配置流程，具体过程则因地区而异，此处不再详细描述。

0x03 补全shell与探索新功能

不难发现，G7615的配置是很有诚意的。处理器为ZX279132，四核A53，频率为1.1G，同时有着512M的内存与256M的闪存，这个配置可以说在硬路由上也颇为高端，仅仅作为拨号上网设备看来有些许的暴殄天物了，故打算在其上补上一个busybox，顺便跑一些有用的插件。

事情太多了，剩下的内容想起来再更，先咕了

看完了？说点什么呢

看完了？说点什么呢