-
EE_KEY_TOO_SMALL
Windows 11 + Python 3.10, ssl 加载了 1024-bit 的 证书和私钥。然后遇到了错误 EE_KEY_TOO_SMALL 。 尝试手动修改并加载 openssl.cnf ，无效。 由于是临时服务，只对内，所以简单粗暴 Python 3.10 的 OpenSSL 版本
-
Windows 使用 mitmproxy 劫持 TLS 连接
本来是一个直连 127.0.0.1:xxx 的连接，发现服务器可以手动指定端口，就xxx + 1 手动起服务器连接，不改端口的方案先不管，只做技术验证。 环境：Windows 11 + mitmproxy 9.0.1 原有软件的连接，使用 openssl s_client -connect 127.0.0.1:xxx 看到是 TLS 1.2，经过某些手段提取了私钥，配合证书，如果还能还原协议就可以自建server或者篡改请求了。 私钥的环节其他另文。 假设已经拿到了 PEM 格式的私钥，加上 openssl s_client 看到的证书 PEM，在验证之后，可以编辑一个满足 mitmproxy 要求的证书文件。格式说明在 https://docs.mitmproxy.org/stable/concepts-certificates/，结构如下 这个场景下只是针对明确目标的 MITM 攻击，所以选用 mitmproxy 的反向代理模式 “reverse”，文档在 https://docs.mitmproxy.org/stable/concepts-modes/。 基本结构是 假设xxx = 12300，则对应的命令是 由于上游证书是自签的，经验证服务端也没有要求客户端使用证书，所以需要使用 -k 关闭证书校验 。 然后，还需要让下游客户端继续维持上游的证书，防止内部有额外的校验，引入之前的证书文件假设为 mitm.pem 则完整命令为 脚本看文档 https://docs.mitmproxy.org/
-
Protected: NanoPi R6s Ubuntu Build Kernel Module Error
There is no excerpt because this is a protected post.
-
Protected: 某家App签名算法还原过程
There is no excerpt because this is a protected post.
-
apc.use_request_time
发现 Ubuntu 下的 PHP 里的 apcu 的 cache 始终不过期，结果查了半天，cli 模式下， apc.use_request_time 是被开启的状态。
-
WordPress Extra Authentication
Nginx snippets adding extra basic auth to wordpress. Create Password File Add User
-
Protected: i百联 加密分析
There is no excerpt because this is a protected post.
-
iOS HTTPS 抓包工具
介绍一些用过的好用的 iOS 下 HTTPS 的抓包工具。 这些工具的实现原理都是使用 Network Extension 实现VPN，设置路由规则到 VPN 的设备里，再进行流量筛选，例如筛 TCP Port 443 的，转发到内部实现的一个代理服务上，通过中间人攻击的方式，实现 HTTPS 的协议解密甚至劫持。 这些工具的操作步骤大都如下： 安装 App。 安装并信任证书。最近的 iOS 安装自定义 CA 证书，会需要用户自己到设置里安装描述文件，再去关于本机的证书信任设置里手动启用 CA 证书。 创建 VPN。App 里有明确的引导，将用户跳转到 VPN 添加页面。但是这里的VPN 在 App 卸载的时候不会自动删除。 配置规则或者默认全部TCP 443 启用并解析 这里有个风险，如果使用者不能确认 App 安装的证书完全是本机现生成的私钥及证书且都没有上传到服务器上，那请在使用完相关App 后，至少是取消掉对该 CA 的信任。 以下对比仅限于被对比的对象，优点和缺点不是绝对的。 1. Stream，一款免费的 iOS 程序，看简介应该是中国开发者开发的，可以在 IAP 里赞助开发者。 优点：免费，功能直观，而且还算比较完整，可以构造请求。 缺点：用户引导做得不够好，如果不懂原理，可能配置不成功。 2. Charles…
-
MITM 与 HTTPS 流量劫持
VPS 硬盘挂之前，blog 里留了一篇文章，如何使用 redsocks + linux policy based routing 实现对手机 HTTPS 流量的劫持。具体方案懒得再写了。简单描述一下原理，后边的文章会需要引用。 上图是引用自 Wikipedia 的中间人攻击的页面。 最古老的年代，通信缺少加密，所以中间传信的人可能能看到并篡改内容。后来，从算法保密，到算法公开密钥保密，再到后来 PKI 的出现，逐渐实现了相对安全的加密通信。 但是，从开发、调试和安全研究的角度看，在拿不到 SSL/TLS 通信密钥的情况下，中间人攻击是协议调试的一个重要手段。（当然，如果能拿到 SSL/TLS 通信密钥，例如可以修改 SSL/TLS 握手的库，记录下来，就可以直接 tcpdump/wireshark 抓包，再用 wireshark 填入密钥就可以解密了。） 加密通讯的中间人攻击，第一个典型场景的必要手段是让客户端信任中间人的证书，常见的手段： 例如客户端不校验证书（签发者，时间，Common Name等）， 或者当客户端使用系统的方法和系统的 CA 库去校验的时候，安装自签的 CA 证书再用这个 CA 去签发被劫持的证书， 甚至 Patch 的方式替换原有程序里写死的证书或证书策略（例如 Android）。 第二个典型的必要手段是劫持流量，或者信道。常见的做法： 如果被劫持的目标对象使用系统的代理，或者有代理设置的选项，修改这个选项。 如果该目标不使用代理，但是系统平台有方法劫持，例如 proxifier（一个值得买的 win/mac 代理工具），使用 proxifier 可以按通讯地址端口或者进程名称将应用的流量。 如果是不认代理设置的运行在封闭系统（iOS / Android）下的程序，就可以考虑网络设备上 NAT…