http 加密的正确方法

[senx0000]

如果不上 https 的话，直接生成一对密钥，前端应用预置对应的公钥来加密，后端直接用私钥来解密，这样一来是不是中间人就无法知道请求的具体内容了？
除了性能问题，暂时没想到有啥其他问题，不知道大家有没有建议？
不考虑伪造或者篡改请求的情况，需求只是实现中间人无法得知请求内容。

[t6attack]

在 http 时代，qq 邮箱就是这么干的，密码是 rsa 加密一下传到服务端。
它的公钥我还有记录：
CF87D7B4C864F4842F1D337491A48FFF54B73A17300E8E42FA365420393AC0346AE55D8AFAD975DFA175FAF0106CBA81AF1DDE4ACEC284DAC6ED9A0D8FEB1CC070733C58213EFFED46529C54CEA06D774E3CC7E073346AEBD6C66FC973F299EB74738E400B22B1E7CDC54E71AED059D228DFEB5B29C530FF341502AE56DDCFE9

[zhangxh1023]

客户要的国密应该是要在 https 上再套一层加密吧。
你就用客户端随机生成一个 aes 的密钥，然后加密请求数据，再用 sm2 加密一下密钥传给后端。

[selfAccomplish]

HTTPS 算法使用 RSA2048 位以上。然后前端使用 SM2 算法 公钥加密，后端解密。
性能影响可以忽略吧，除非服务器是小霸王学习机哈哈

[tysb777]

国内有一家厂商做到了服务器上安装 SM2 和 ECC/RSA 两个证书，可以自由切换。在国产浏览器里加载 SM2 ，在其他里加载 ECC/RSA 。

不过 SM2 证书现在价格很高，可以捞点油水。

[ren2881971]

@senx0000 他有国 M 浏览器么 就要上国密 SSL 。

[dzdh]

可以 GM+RSA 一起上

[JohnBull]

在加密算法领域,不是数学家的话就不要搞发明创造.
老老实实上 https 最安全

[brader]

我建议你 https 照常上，这是给你自己的保障，然后说下我的使用国密解决中间人窃取的想法：客户端生成一个临时的密钥，使用 RSA 公钥加密，请求消息使用国密算法和刚才的临时密钥进行加密，请求消息带上密钥一起发送给服务端，服务端接收到的请求，使用 RSA 私钥解密出密钥，使用密钥进行国密解密。

[iOCZ]

https 也能用国密吧

[sxyclint]

直接用国密版本的 HTTPS ，然后会发现有些浏览器不支持，这样就说服他了

[flyqie]

如果是纯 web 项目的话，那这样就有个问题。

你既然是用了公私钥加密，那我可不可以用中间人方案有针对性的来拦截并修改你公私钥加密的代码？

[flyqie]

@flyqie #31

这个问题 tls 是通过在客户端预置可信证书来规避的，很好奇你打算怎么做。

[olaloong]

是可以啊，有不少 toB 厂商的接口请求响应体都是全加密的，SM4 加密 SM2 签名再套个 https 传输
我们 H5 端就是前端 SM4 加密请求到后端的

[ochatokori]

不用 https 的话，那我中间人直接在客户端接收你那个写死的公钥的时候把你公钥给替换了，不还是能随便解密你的密文，你客户端又发现不了公钥是假的（中间人用你原来的公钥和服务器通信，服务器也发现不了客户端在使用假公钥）

[wangritian]

防中间人最关键的一步在于客户端要用 ca 证书验证服务器证书，且不信任系统提供的 ca 证书
加密算法只要不用太落后的就都安全
浏览器环境，就买大机构的证书； app 环境，可以自签名，然后把 ca.crt 丢进客户端自己校验

[mritd]

国米的东西… 糊弄糊弄就行了，毕竟他们又不懂你说是不是？

[wanguorui123]

中间人反向代理你的请求，糊弄一下别人可以

[izzy27]

用自己设计的加密算法是很危险的

[joshu]

你这个方法应该不防重放

[momocraft]

需要国密的客户看得出你用什么加密吗？