有无数从事HTTPS转发的工具，此处不讨论为什么要用socat干这事，只说想用socat干这事时，咋整。不考虑客户端验证服务端证书有效性的问题，那属于旁枝末节。
cd ~/src/socat/server
生成私钥
openssl genrsa -out server.key 4096
生成10年有效期自签名证书
openssl req -new -key server.key -x509 -days 3653 -out server.crt
由于并不关心证书有效性，一路回车即可，最多在提示”Common Name”时输入个像那
么回事的名字，其他字段完全无所谓。
生成pem文件
cat server.key server.crt > server.pem
至此有三个文件
server.key
server.crt
server.pem
若对这些东西门儿清，都留着无妨。但就本文而言，只需留server.pem。假设socat侦听8443/TCP，收到HTTPS请求后转发至www.target.com:443/TCP。用如下命令进行HTTPS转发:
socat -v ssl-l:8443,reuseaddr,fork,cert=server.pem,verify=0 ssl:www.target.com:443,verify=0
socat -v -r /tmp/request.bin -R /tmp/response.bin ssl-l:8443,reuseaddr,fork,cert=server.pem,verify=0 ssl:www.target.com:443,verify=0
-v会在stdout显示Request、Response明文，-r、-R分别转储Request、Response原始数据。
假设客户端原来访问
https://www.target.com/<something>
现在设法让客户端访问
https://<socat>:8443/<something>
注意，不是给客户端设代理，是URL中变换目标IP、PORT。不同的客户端，达此目的的方案不同，有些客户端极难达此目的，则不适用于本技术方案。接下来socat即可看到HTTPS请求、响应明文，若有细究二进制数据的需求，则查看两个.bin文件。
有些客户端无法不验证服务端证书有效性，但可以导入server.crt，最终也适用本技术方案，但本文不讨论这些情形。
假设Response头有
Content-Encoding: gzip
Content-Length: 64
此时数据区是gzip压缩过的二进制数据，”socat -v”显示不可打印字符时无意义，只能从response.bin中析取数据。首先从.bin获取最后64字节，这是Content-Length告诉我们的。xxd本身不支持负偏移，但结合stat可以方便达成目的。
$ xxd -s $[$(stat -c %s response.bin)-64] -g 1 response.bin
(略)
获得数据区hexdump后，可用CyberChef完成解码，Recipe这样写:
From Hexdump
Gunzip
将数据区hexdump贴进去即可得到解码后的明文。
https://github.com/gchq/CyberChef
Recipe是串行工作的，比如「URL Decode+From Base64+RC4」，然后输入POST数据区的内容，假设第一次解码得到BAS64，那后面自动BASE64解码，再自动RC4解密；缺省一次性串行执行结束，可根据out判断Recipe中的算法顺序是否正确。可随时调整串行顺序，临时禁用某一级算法，单步执行，对某一级设断点，停下时显示该级的in。
这是个好东西，还没用上的速体验之。
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。