这是一个创建于 1165 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天整理 HTTPS 相关内容，想到之前没有 HTTPS 时我的安全通信方式，感觉除了 server 、client 麻烦一点外还挺好用的
server 端生成一对非对称加密密钥对，pk 公开；再生成一个对称加密的密钥保存中 server 端不公开 client 端第一次请求 server 时用 pk 加密，里面存储一个 client 端生成的对称加密密钥及算法参数，server 端接到请求之后把 client 发来的密钥信息存储在 token 中(token 也可以带一些其他的信息)用 server 端独有的对称加密密钥进行加密发给 client 。client 每次请求都带着 token，可以用它生成的密钥进行加密，server 可以从 token 中拿到解密的密钥，当然了，也可以把 client 的密钥放在 session 或 redis 中。
我感觉这样挺安全的，你们觉得呢？
第 1 条附言 · 2021-10-09 21:16:17 +08:00
结帖了，结贴了
感谢各位老哥热心回复，果然 V2EX 人才还是多啊，苦思冥想半个月的方案感觉已经无懈可击了，结果不到半小时就把我问的答不上话，向各位学习
感谢各位老哥热心回复，果然 V2EX 人才还是多啊，苦思冥想半个月的方案感觉已经无懈可击了，结果不到半小时就把我问的答不上话，向各位学习
 |
1
PureWhiteWu 2021-10-09 20:14:29 +08:00
不知道该从何开始评价……
pk 公开是如何公开？ client 首次请求时返回 pk ？ |
 |
2
copymaster OP @PureWhiteWu pk 不是很重要，请求获取和放在 js 中都是可以的，我之前是写的 Android 就直接写死了
|
 |
3
lcdtyph 2021-10-09 20:17:47 +08:00 via iPhone
怎么防中间人？怎么保证前向安全？
|
 |
4
Tianao 2021-10-09 20:21:53 +08:00
如何实现认证——客户端如何获取 /验证服务端的公钥？
|
 |
5
ooxxcc 2021-10-09 20:22:55 +08:00 via iPad  16
重新发明简化版劣化版 TLS
|
 |
6
mxT52CRuqR6o5 2021-10-09 20:23:15 +08:00 via Android
没有 CA 防不了中间人
|
 |
7
lostpg 2021-10-09 20:24:00 +08:00
你能够保证 client 拿到的 server 的公钥是正确不被篡改的，就可以省去 HTTPS 握手的证书验证步骤，关于这点你要如何保证呢；
至于对称加密的密钥的处理部份，恕我没有读懂楼主的表述； |
 |
8
deplivesb 2021-10-09 20:29:33 +08:00 5
这是民科进入了信息安全领域了？
|
|
9
copymaster OP Fuck，结帖！！！
|
|
10
lostpg 2021-10-09 20:55:56 +08:00
|
|
11
copymaster OP @lostpg 嘿嘿嘿，没有 https 的无奈之举
|
 |
12
neteroster 2021-10-09 21:24:23 +08:00 via Android 5
「当我在 70 年代初上大学时，我设计了一个我认为是绝妙的加密方案。一个简单的伪随机数流被添加到明文流中以创建密文。这似乎会阻碍对密文的任何频率分析，...，我对自己的成就感到非常自鸣得意。
多年后，我在几本介绍性的密码学文本和教程论文中发现了同样的方案。多好。其他密码学家也想到了同样的方案。不幸的是，该方案是作为一项关于如何使用基本密码分析技术轻松破解它的简单家庭作业而提出的。我的绝妙计划到此为止。 从这次令人羞愧的经历中，我了解到在设计加密算法时很容易陷入错误的安全感。大多数人都没有意识到设计一种能够承受足智多谋的对手长期而坚决的攻击的加密算法是多么困难。」 PGP 创始人的一段话（机翻），楼上上那个链接里面也有。 |
|
13
copymaster OP @neteroster 感同身受
|
 |
14
zscself 2021-10-09 22:40:06 +08:00
《关于我重新发明 TLS 的那些事》
|
|
15
PureWhiteWu 2021-10-09 23:14:13 +08:00
密码学第一课——不要自行发明算法。
|
 |
16
hlwjia 2021-10-09 23:28:52 +08:00
互联网发展那么多年了，你准备半个月就攻破吗？
|
 |
17
wdlth 2021-10-10 00:07:43 +08:00
你这个还不如用密钥交换……
|
 |
18
walpurgis 2021-10-10 00:25:43 +08:00
这个也是月经贴了，要是天天刷 v2 就根本不会产生去发明新的加密通讯协议的想法。
换个角度想，HTTPS 可靠的原因是它有 CA，解决了信任从无到有的问题，而根证书一般是系统内置，来源链路都不一定是网络，使得中间人难度大大提高。单一链路基本无法防御中间人，由此可推导出没 CA 机制的加密协议安全性其实都不能跟 HTTPS 相提并论的 |
 |
19
yangyaofei 2021-10-10 01:08:44 +08:00 1
其实不丢人, 你只是想一想,我都实现了,而且上生产环境了呢.
但是唯一不一样的是, 我没发 key,发 token(私下可信任通道), 然后 token 自签名用来验证 client 的权限, 并利用 token 内的信息加密传输数据和做自签名验证用的 token. 有时候,就是非要 http 环境,还要验证 client 和加密,就是很没办法. |
 |
20
msg7086 2021-10-10 01:51:37 +08:00
有想法挺好的，这帖子发出来你才会知道还有哪些知识是自己不了解的，然后去读懂学会他们，就能扩充你的知识面。
|
 |
21
cnnblike 2021-10-10 07:00:16 +08:00 via Android
ca 意义挺大的，如果是安卓别人也可以重打包的
|
 |
22
0o0o0o0 2021-10-10 07:27:39 +08:00
安卓有签名，可以通过系统级的 ca 防止包被篡改，所以 ca 在哪都很重要
|
 |
23
hcocoa 2021-10-10 11:51:38 +08:00 2
想起来我本科毕业设计的时候，其中一个部分是我“独立设计”自认为炫酷吊炸天的防重放机制。
结果答辩的时候： 老师：这不就是一个挑战应答吗？ 我：……（等了 10 秒钟），是的，这就是一个挑战应答…… |
 |
24
stevenhawking 2021-10-10 20:38:52 +08:00
你放 JS，怎么保证 JS 不被劫持?
|
 |
25
eason1874 2021-10-10 21:10:35 +08:00
楼主这个方法在 APP 是可行的，其实就是在应用层实现 TLS 简化版。在网页不可行，网页不像 APP 可以提前内置证书，用户访问时才下发证书，所以得有 CA 去验证证书的真实性。
不过 HTTPS 的意义不仅是防监听，还有防劫持，防缓存 |
 |
26
leiakun 2021-10-12 03:39:57 +08:00 via iPhone
可以看看 quic 或者 http/3，还有 ECH 。可能会解答你的问题。
|
|
27
copymaster OP @leiakun 感谢，前两天看 https 的时候了解了一下 ECH 算法，感觉挺厉害的
|
Select Language