一种无 HTTPS 的安全通信方式

[copymaster]

今天整理 HTTPS 相关内容，想到之前没有 HTTPS 时我的安全通信方式，感觉除了 server 、client 麻烦一点外还挺好用的

server 端生成一对非对称加密密钥对，pk 公开；再生成一个对称加密的密钥保存中 server 端不公开 client 端第一次请求 server 时用 pk 加密，里面存储一个 client 端生成的对称加密密钥及算法参数，server 端接到请求之后把 client 发来的密钥信息存储在 token 中(token 也可以带一些其他的信息)用 server 端独有的对称加密密钥进行加密发给 client 。client 每次请求都带着 token，可以用它生成的密钥进行加密，server 可以从 token 中拿到解密的密钥，当然了，也可以把 client 的密钥放在 session 或 redis 中。

我感觉这样挺安全的，你们觉得呢？

[PureWhiteWu]

不知道该从何开始评价……
pk 公开是如何公开？ client 首次请求时返回 pk ？

[copymaster]

@PureWhiteWu pk 不是很重要，请求获取和放在 js 中都是可以的，我之前是写的 Android 就直接写死了

[lcdtyph]

怎么防中间人？怎么保证前向安全？

[Tianao]

如何实现认证——客户端如何获取 /验证服务端的公钥？

[ooxxcc]

重新发明简化版劣化版 TLS

[mxT52CRuqR6o5]

没有 CA 防不了中间人

[lostpg]

你能够保证 client 拿到的 server 的公钥是正确不被篡改的，就可以省去 HTTPS 握手的证书验证步骤，关于这点你要如何保证呢；

至于对称加密的密钥的处理部份，恕我没有读懂楼主的表述；

[deplivesb]

这是民科进入了信息安全领域了？

[copymaster]

Fuck，结帖！！！

[lostpg]

https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own

为什么不要自行设计加密方案。

[copymaster]

@lostpg 嘿嘿嘿，没有 https 的无奈之举

[neteroster]

「当我在 70 年代初上大学时，我设计了一个我认为是绝妙的加密方案。一个简单的伪随机数流被添加到明文流中以创建密文。这似乎会阻碍对密文的任何频率分析，...，我对自己的成就感到非常自鸣得意。

多年后，我在几本介绍性的密码学文本和教程论文中发现了同样的方案。多好。其他密码学家也想到了同样的方案。不幸的是，该方案是作为一项关于如何使用基本密码分析技术轻松破解它的简单家庭作业而提出的。我的绝妙计划到此为止。

从这次令人羞愧的经历中，我了解到在设计加密算法时很容易陷入错误的安全感。大多数人都没有意识到设计一种能够承受足智多谋的对手长期而坚决的攻击的加密算法是多么困难。」

PGP 创始人的一段话（机翻），楼上上那个链接里面也有。

[copymaster]

@neteroster 感同身受

[zscself]

《关于我重新发明 TLS 的那些事》

[PureWhiteWu]

密码学第一课——不要自行发明算法。

[hlwjia]

互联网发展那么多年了，你准备半个月就攻破吗？

[wdlth]

你这个还不如用密钥交换……

[walpurgis]

这个也是月经贴了，要是天天刷 v2 就根本不会产生去发明新的加密通讯协议的想法。
换个角度想，HTTPS 可靠的原因是它有 CA，解决了信任从无到有的问题，而根证书一般是系统内置，来源链路都不一定是网络，使得中间人难度大大提高。单一链路基本无法防御中间人，由此可推导出没 CA 机制的加密协议安全性其实都不能跟 HTTPS 相提并论的

[yangyaofei]

其实不丢人, 你只是想一想,我都实现了,而且上生产环境了呢.

但是唯一不一样的是, 我没发 key,发 token(私下可信任通道), 然后 token 自签名用来验证 client 的权限, 并利用 token 内的信息加密传输数据和做自签名验证用的 token.

有时候,就是非要 http 环境,还要验证 client 和加密,就是很没办法.

[msg7086]

有想法挺好的，这帖子发出来你才会知道还有哪些知识是自己不了解的，然后去读懂学会他们，就能扩充你的知识面。