服务端生成一对 RSA 的公钥和私钥，在前端第一次请求的时候，将公钥返回给前端。
前端保存这个公钥，每次向服务端发起请求的时候，请求的内容体使用这个公钥加密。
并且前端在发起请求前，也生成一对 RSA 公私钥，请求内容附上公钥，这样服务端返回的内容就可以用这个公钥加密了。（单页面应用，秘钥都是2048位的）
（可能防篡改、防重放还有些问题，但是再加上验证的步骤应该也能实现。）
如此，不使用 https，直接在http的之上做这样一套，这样能实现 https 一样的安全程度吗？
在Internet上凡是没有完整性（Integrity）保护的数据，都是可以删除、篡改、替换的。
其中包括MAC头、IP、TCP、HTTP，由于用HTTP传输RSA公钥没有完整性保护，无法保证不被第三方替换。如果被替换，用没有任何安全性可言。
如果服务器RSA公钥/私钥对的RSA公钥被CA权威签名，成为X.509证书。用HTTP明文携带这个X.509证书，虽然中间人依然可以删除、篡改、替换HTTP内容，但是这个X.509证书是没法篡改的。如果篡改，由于X.509有完整性保护（CA签名），Client会发现并放弃。
可是中间人可以将X.509证书整个删掉，Client永远也发现不了。
受CA签名可以保护X.509证书的启发，如果用服务器RSA私钥对HTTP整体做一个签名（RSA签名），是不是中间人就没有办法删除、篡改、替换HTTP了？
Client收到HTTP报文之后，根据本地信任CA的公钥，验证X.509证书合法（CA签名）。服务器的RSA公钥信任OK，用RSA公钥尝试验证RSA签名，验证成功即意味着HTTP没有被污染，是原始的模样。
然后，Client就用服务器RSA公钥加密HTTP传输给服务器，这个安全性没有大问题，但是有很多小问题：
Operation | Milliseconds/Operation | Megacycles/Operation|
RSA 1024Encryption 0.08 0.14
RSA 1024Decryption 1.46 2.68
-
-
中间人捕获历史packet，可以replay，服务器很难分辨是真实的数据还是被重放的数据。
-
同样的明文，RSA加密会产生相同的密文。这在安全上也是不可接受的。即使同样的明文，使用相同的RSA公钥，也要产生不一样的密文。如果要满足这样的要求，需要对明文添加Nonce或者Padding处理。
另外，如果不用权威CA对服务器RSA公钥签名，还可以预先生成RSA公钥的指纹，带外的方式copy到Client本地。一旦收到RSA公钥，计算RSA公钥指纹 = 本地保存的RSA公钥指纹，那么就信任这个公钥，否则就拒绝这个公钥。
而要解决以上种种的难题与不便，只要使用TLS 1.3加密HTTP（1.1/2.0）即可。如果要使用HTTP3，可以使用基于UDP QUIC，QUIC将TLS 1.3融合进来了。
-
极端情况下，可以实现0-RTT通信（QUIC PSK Resumption）
-
正常情况下，可以实现1-RTT通信（QUIC Full Handshake）
-
极端情况下，可以实现1-RTT通信（TCP PSK Resumption）
-
正常情况下，可以实现2-RTT通信（TCP Full Handshake）
原文始发于微信公众号（车小胖谈网络）：不用 https 自己实现对 http请求的内容的 rsa 加密，这样足够安全吗？
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
https://cn-sec.com/archives/2897147.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论