不用 https 自己实现对 http请求的内容的 rsa 加密，这样足够安全吗？

设想的方案如下：

服务端生成一对 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传输给服务器，这个安全性没有大问题，但是有很多小问题：

1.性能问题

RSA非对称加密/解密运算速度慢：

Operation | Milliseconds/Operation | Megacycles/Operation|

RSA 1024Encryption                 0.08    0.14

RSA 1024Decryption                 1.46    2.68

1. 2.Forward Security

服务器RSA私钥泄露，历史加密数据统统可以破解。

1. 3.Replay

中间人捕获历史packet，可以replay，服务器很难分辨是真实的数据还是被重放的数据。

1. 4.Known Clear Text

同样的明文，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 加密，这样足够安全吗？