比如浏览器的 seesion_id,如果对方得到了 session_id 理论上是有了免登陆的能力,还比如 app 中授权用的 token,如果被拿到就也就不用通过授权验证。 有什么好的方式解决这个问题呢? https 是一个,除了这个方式呢?
1
honeycomb 2018-07-12 19:06:07 +08:00 via Android
那个好办法就是上 TLS ( HTTPS ),或者外部套一个成本更高的套子(虚拟专用网之类的),其它 HTTP 协议范畴内的方法可以作辅助。
在 HTTP 之内再实现一个 TLS 肯定不太像是好主意 |
3
f2f2f 2018-07-12 20:17:20 +08:00
如果能实现的话 https 存在的意义又是什么
|
4
Servo 2018-07-12 20:18:09 +08:00
shttp
|
5
Oceanhime 2018-07-12 20:34:48 +08:00
按照 LZ 举的例子, 实际上可以通过服务端验证更多信息 /算法的方式解决, 比如说可以在这些 session 值中添加更多验证(比如 IP)。
回到主题, HTTPS 一定是最简单且最靠谱的方法, 如 @honeycomb 所说, 如果在 HTTP 内实现一套 TLS 不光费脑子, 性能方面的开销我相信不会比上 HTTPS 要少。当然, 如果真想实现肯定有其他五花八门的方法。比如说加公私钥什么的。 (半吊子写程序的, 回答肯定非常不专业, 见谅) |
6
isCyan 2018-07-12 20:34:58 +08:00 via Android
|
7
panpanpan 2018-07-12 20:41:55 +08:00 via iPhone
Session 绑定 ip 不过太容易误伤了
|
8
listnodeptr 2018-07-12 20:47:20 +08:00
HTTPS 是唯一正解,还有一堆简单、迅速、优雅的错误解法,比如只有登陆时 HTTPS 交换密钥,之后每个 HTTP 请求都在加了抗 CSRF 的时间 token 前提下(不然可重放)再用密钥签名请求,你觉得这样实现一套简单么
|
9
qinxi 2018-07-12 20:49:33 +08:00 3
等你做到了,
那么恭喜你, 你重新发明了 https |
10
shiny 2018-07-12 20:54:28 +08:00
h2 了解下
|
11
xiangyuecn 2018-07-12 20:56:56 +08:00
上了 https 也不敢说信息不被监听窃取
|
12
dawniii 2018-07-12 20:58:31 +08:00
@xiangyuecn 是指不校验证书的情况吗?不校验证书为什么用 tls 呢。。。
|
13
janssenkm 2018-07-12 21:23:58 +08:00 via Android
唯一正解:HTTPS
|
14
xiangyuecn 2018-07-12 21:27:07 +08:00
@dawniii 你说的我不懂啊,也许数据在发送之前、到达服务器之前可能就被窃取了。就算校验证书也会存在问题:
1、客户端存在被信任的恶意根证书 2、客户端直接接受伪造的证书(中间人)不给任何提示(程序员实偷懒,现代码简单,校验证书实现代码就一句 return true 呵呵)。除非果程序断拒绝错误证书,否则给用户提示选择的话,点接受(忽略)错误证书也是会有的( doge https 并不能直接解决常见的 xss、csrf: A、前后端各种漏洞 B、服务器被黑 C、客户端数据泄露(恶意访问敏感数据,包括不限于病毒木马、流氓浏览器、插件、代理、用户人为因素) |
15
Oceanhime 2018-07-12 21:36:21 +08:00
@xiangyuecn 2 这可能太极端了, 除非客户端用的是自己写的浏览器, 否则主流浏览器不可能出现 return true 或者程序员偷懒不验证的问题。LZ 说的是 [ HTTP 通信 ] , XSS 之类的好像不属于这个范围了。
|
16
dawniii 2018-07-12 21:38:13 +08:00
@xiangyuecn 您前面说的客户端被种恶意根证书,黑客有这个权限的话,在客户端那边黑客该有的不该有的权限基本也都有了。。。
后面说的 xss 和 csrf 本来就不是 tls 负责的,这算是业务上面的漏洞。tls 只是保证数据在传输过程中的安全,应该是满足 up 的需求。 |
17
bumz 2018-07-12 21:40:03 +08:00
https + HPKP
|
18
des 2018-07-12 21:43:59 +08:00 via Android
|
19
xiangyuecn 2018-07-12 21:53:28 +08:00
|
20
xiangyuecn 2018-07-12 21:54:26 +08:00
@des 精辟
|
21
usedname 2018-07-12 22:20:25 +08:00 via iPhone
这种帖子也要来水?先自己多看看书多想想再来问吧。
|
22
zj299792458 2018-07-12 22:24:30 +08:00 via iPhone
对称加密呗,key 用时间戳加其他固定的玩意儿,保证每次加密后的 session id 不一样。
|
23
honeycomb 2018-07-12 22:41:39 +08:00 via Android
@cc959798 其它方法肯定比 HTTPS 的代价高(除非你这边有与之匹配的特殊情况,比如网银的 HTTPS 里再套一层加密)
|
24
liuminghao233 2018-07-12 22:59:32 +08:00 via iPhone
自己写客户端
自己写加密 使用 rsa+aes 用 http 传密文 恭喜你发明了 https |
25
WuwuGin 2018-07-12 23:03:34 +08:00 via Android
关于会话安全,php 官方有自己的基础建议,虽然你不一定用 php,但是道理是通的。详情: http://php.net/manual/zh/features.session.security.management.php
|
26
Raymon111111 2018-07-12 23:05:41 +08:00
https
|
27
caola 2018-07-12 23:07:56 +08:00
@cc959798 还在怀疑 https 的效率?你看看现在还有多少网站是 http 的?
再过一两年浏览器都默认走 https 了,如果想访问 http 的地址,还得自己手动在域名前输入协议的部分。 |
28
tiaod 2018-07-13 00:28:25 +08:00 via Android
@caola 然而大部分支持 https 的网站都设置了 http 跳转 https,于是又给你跳回去了
|
29
caola 2018-07-13 01:20:19 +08:00
|
30
ca1123 2018-07-13 02:06:52 +08:00
https 和可信 CA。但是可信 CA 本身就是个笑话。你到底相信 CA 什么,在 NSA 或者土鳖面前的节操么? NSA 会往算法里埋雷,土鳖根本就会要求在他那儿保存私钥。
|
31
caola 2018-07-13 02:40:00 +08:00
@ca1123 可信的 CA,至少比完全不加密的 http 强的不止是一点点,
关于 NSA 的算法,已经有代替者 25519,在 tls1.3 和 quic 下默认就是它,未来将会取代 NIST 系列的算法 |
33
defel 2018-07-13 03:16:35 +08:00 via iPhone
http 通知对方拿硬盘来拷贝😏
|
34
IvanLi127 2018-07-13 03:18:19 +08:00 via Android
自己搭网络
|
36
msg7086 2018-07-13 04:15:59 +08:00 1
@ca1123 这种没有意义的问题问出来有什么意义。
你自己发明出来的算法还能问你怎么知道那不是你第二人格想要偷取你第一人格的数据。 连可信的公共领域算法和可信的机构都不相信了,那世界上还有什么可以相信的。 25519 本来就是人们发现 NSA 插手以后,在野外随便找可靠曲线的时候找到的一个已经发布了 8 年而且根本没什么人关注的曲线。如果 25519 里面有 NSA 插手,就两种可能,NSA 能预知未来,知道 8 年后人们发现他们的后门然后转用 25519,所以坐时光机回去联系作者加入后门。或者作者能预知未来,知道将来国家制定的标准会被 NSA 加入后门,所以把 8 年以后的后门放进他自己的曲线里。 你觉得哪种可能性大点。 人与人之间没有信任还活什么。你出去吃个饭相信老板不会毒死你吗。 |
37
zjyl1994 2018-07-13 07:29:39 +08:00 via Android
HTTPS 即可,不要重新发明轮子
|
38
beginor 2018-07-13 07:47:44 +08:00 via Android
酸酸乳做代理,负责客户端与服务端的通讯
|
39
scmod 2018-07-13 08:31:06 +08:00
@msg7086 233~
但是 sessionid 别人一般拿不到啊...登录后重新发个 sessionid 防下被坑,好像一般不会有什么问题的样子 |
40
youxiachai 2018-07-13 10:44:50 +08:00
lz 要准备重新发明 https 了...
|
41
bannychen 2018-07-13 10:58:09 +08:00
安全还是应该掌握在自己手里,否则都是扯淡
|
42
caola 2018-07-13 12:19:53 +08:00
@ca1123 处处怀疑,你就什么别用了,
但我可以告诉你 25519 是完全开放的,一切加密过程是完全看得清清楚楚,明明白白。不像 NIST 系列的加密,总有那么关键的一部分不被理解,或者是看不明白的地方。 再有一点就是 25519 是目前效率最快的椭圆加密算法,目前还没有之一 |
43
finian 2018-07-13 13:47:47 +08:00
1. 别试图重新发明一遍 HTTPS ;
2. 你的问题无解,请放弃治疗。数据一旦分发到客户端,就一定会被窃取,仅仅是时间和成本问题。 性价比比较高的做法: 如果是浏览器,用 HTTPS。如果是 App,HTTPS + SSL Pinning。然而也只能增加破解的成本而已。 |
44
3dwelcome 2018-07-13 13:58:02 +08:00
虽然 TLS 是行业标准,但 https 也没想的中那么好,第一服务器的性能,第二是本地化安全。
1. 性能的话,http 能同时抗 10000 个同步,那么 https 只能抗几百个同步连接,因为握手的时候,特别消耗 cpu,这点没办法绕过去的。大家之所以感觉 https 不慢,是 chrome 善于复用连接,跳过了重新握手这步。但不管如何,握手慢是物理限制,没办法避免的。 2. 本地化浏览器安全策略,目前大家手机 android 里,一般用的都是 webview,简单封装一下单页面 app,是主流趋势。有个叫 chrome 远程调试手机 webview 的东东,可以直接对手机的页面做拦截调试,和 http 还是 https 无关,js 本身就没那么的安全。所以就算用了 https,多加几层保险措施,也还是能提升安全系数的。 |
45
hxndg 2018-07-13 14:08:22 +08:00
|
46
3dwelcome 2018-07-13 14:23:36 +08:00
@hxndg 上 https 后,只有几百个同步连接不是我说的,是腾讯大公司专门做 https 优化人员说的。你百度搜一下"https 性能优化",第一篇就是,原文是"事实上大部分机器一秒钟只能处理三四百次 RSA",我并没有加油添醋,自己的实际压测,也是这个数量级。
而不用 https,只用 http,随随便便上万个同步连接,服务器没有压力。我希望你也能测试一下自己的机器,RSA2048 握手耗时多少毫秒,看一下结果,就知道所言非虚。 |
47
hxndg 2018-07-13 15:06:31 +08:00
|
48
fancyhan 2018-07-13 15:09:47 +08:00
https over http
|
50
hxndg 2018-07-13 15:20:28 +08:00
@3dwelcome
我对于你说的偷换概念没有任何兴趣,单台设备处理负载均衡 https 握手并发连接,后端通信是明文的 http,懂了么?你让 CPU 去做软解密本身就是极蠢的行为,硬解密交给卡做,ok? 还有就是没事干不要扯 RSA 秘钥交换了,你可能不清楚目前 RSA 密钥交换方式是不推荐的,TLS1.3 当中更是废除了 RSA 密钥交换, |