Tag: tls

EE_KEY_TOO_SMALL

Windows 11 + Python 3.10, ssl 加载了 1024-bit 的证书和私钥。然后遇到了错误 EE_KEY_TOO_SMALL 。

> python3.10 proxy.py
Traceback (most recent call last):
  File "\proxy\proxy.py", line 11, in <module>
    server_context.load_cert_chain('../../docs/cert.pem', '../../docs/cert.key')
ssl.SSLError: [SSL: EE_KEY_TOO_SMALL] ee key too small (_ssl.c:3874)

尝试手动修改并加载 openssl.cnf ，无效。

由于是临时服务，只对内，所以简单粗暴

server_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
server_context.set_ciphers('ALL:@SECLEVEL=0')
server_context.load_cert_chain('../../docs/cert.pem', '../../docs/cert.key')

Python 3.10 的 OpenSSL 版本

>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.1.1s  1 Nov 2022'

2023-02-10

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/，结构如下
```
-----BEGIN PRIVATE KEY-----
<private key>
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
<cert>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<intermediary cert (optional)>
-----END CERTIFICATE-----
```
这个场景下只是针对明确目标的 MITM 攻击，所以选用 mitmproxy 的反向代理模式 “reverse”，文档在 https://docs.mitmproxy.org/stable/concepts-modes/。

基本结构是
```
Client ---> [port xxx] mitmproxy(reverse mode) [port xxx+1] ---> [port xxx+1] Server
```
假设xxx = 12300，则对应的命令是
```
mitmproxy --mode reverse:tls://127.0.0.1:12301@12300 
```
由于上游证书是自签的，经验证服务端也没有要求客户端使用证书，所以需要使用 -k 关闭证书校验。

然后，还需要让下游客户端继续维持上游的证书，防止内部有额外的校验，引入之前的证书文件假设为 mitm.pem 则完整命令为
```
mitmproxy --mode reverse:tls://127.0.0.1:12301@12300 -k --certs *=mitm.pem
```
脚本看文档 https://docs.mitmproxy.org/
2023-02-08

Tag: tls

EE_KEY_TOO_SMALL

Windows 使用 mitmproxy 劫持 TLS 连接