阅读： 9

有无数从事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）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。