HTTP 通信中有什么方式防止重要信息被监听窃取

[cc959798]

比如浏览器的 seesion_id，如果对方得到了 session_id 理论上是有了免登陆的能力，还比如 app 中授权用的 token，如果被拿到就也就不用通过授权验证。 有什么好的方式解决这个问题呢？ https 是一个，除了这个方式呢？

[honeycomb]

那个好办法就是上 TLS （ HTTPS ），或者外部套一个成本更高的套子（虚拟专用网之类的），其它 HTTP 协议范畴内的方法可以作辅助。

在 HTTP 之内再实现一个 TLS 肯定不太像是好主意

[cc959798]

@honeycomb 那终极解决方案是 https 了吗？全程 https 会不会影响效率？

[f2f2f]

如果能实现的话 https 存在的意义又是什么

[Servo]

shttp

[Oceanhime]

按照 LZ 举的例子, 实际上可以通过服务端验证更多信息 /算法的方式解决, 比如说可以在这些 session 值中添加更多验证(比如 IP)。
回到主题, HTTPS 一定是最简单且最靠谱的方法, 如 @honeycomb 所说, 如果在 HTTP 内实现一套 TLS 不光费脑子, 性能方面的开销我相信不会比上 HTTPS 要少。当然, 如果真想实现肯定有其他五花八门的方法。比如说加公私钥什么的。
(半吊子写程序的, 回答肯定非常不专业, 见谅)

[isCyan]

@cc959798 https://istlsfastyet.com

[panpanpan]

Session 绑定 ip 不过太容易误伤了

[listnodeptr]

HTTPS 是唯一正解，还有一堆简单、迅速、优雅的错误解法，比如只有登陆时 HTTPS 交换密钥，之后每个 HTTP 请求都在加了抗 CSRF 的时间 token 前提下（不然可重放）再用密钥签名请求，你觉得这样实现一套简单么

[qinxi]

等你做到了,
那么恭喜你,
你重新发明了 https

[shiny]

h2 了解下

[xiangyuecn]

上了 https 也不敢说信息不被监听窃取

[dawniii]

@xiangyuecn 是指不校验证书的情况吗？不校验证书为什么用 tls 呢。。。

[janssenkm]

唯一正解：HTTPS

[xiangyuecn]

@dawniii 你说的我不懂啊，也许数据在发送之前、到达服务器之前可能就被窃取了。就算校验证书也会存在问题：
1、客户端存在被信任的恶意根证书
2、客户端直接接受伪造的证书（中间人）不给任何提示（程序员实偷懒，现代码简单，校验证书实现代码就一句 return true 呵呵）。除非果程序断拒绝错误证书，否则给用户提示选择的话，点接受（忽略）错误证书也是会有的（ doge

https 并不能直接解决常见的 xss、csrf：
A、前后端各种漏洞
B、服务器被黑
C、客户端数据泄露（恶意访问敏感数据，包括不限于病毒木马、流氓浏览器、插件、代理、用户人为因素）

[Oceanhime]

@xiangyuecn 2 这可能太极端了, 除非客户端用的是自己写的浏览器, 否则主流浏览器不可能出现 return true 或者程序员偷懒不验证的问题。LZ 说的是 [ HTTP 通信 ] , XSS 之类的好像不属于这个范围了。

[dawniii]

@xiangyuecn 您前面说的客户端被种恶意根证书，黑客有这个权限的话，在客户端那边黑客该有的不该有的权限基本也都有了。。。

后面说的 xss 和 csrf 本来就不是 tls 负责的，这算是业务上面的漏洞。tls 只是保证数据在传输过程中的安全，应该是满足 up 的需求。

[bumz]

https + HPKP

[des]

@xiangyuecn
第一恶意根证书，就好比你家进了小偷(小偷在你家装了摄像头)，你没办法避免的，你说是浏览器环境。

第二，根本没有一劳永逸的安全解决方案

[xiangyuecn]

@Oceanhime 没写过浏览器（关键是不会写，哈哈），app 套一个 webview 还是会的，不光是 Android，ios 估计也有这种问题。


@dawniii 单纯的数据传输我能想到的也就是证书的问题了，不极端点目测大部分情况下其实算是安全的。其实我想的通信过程不仅仅是数据传输，这之前还要有规范的数据格式，之前的之前还要有数据的生成，之后的数据接收解码，数据的使用。哈哈，写的啰嗦了，不管是哪个地方有问题，都会导致整个系统有问题，问题出的多的往往是开头和结尾处

[xiangyuecn]

@des 精辟

[usedname]

这种帖子也要来水？先自己多看看书多想想再来问吧。

[zj299792458]

对称加密呗，key 用时间戳加其他固定的玩意儿，保证每次加密后的 session id 不一样。

[honeycomb]

@cc959798 其它方法肯定比 HTTPS 的代价高（除非你这边有与之匹配的特殊情况，比如网银的 HTTPS 里再套一层加密）

[liuminghao233]

自己写客户端
自己写加密
使用 rsa+aes

用 http 传密文







恭喜你发明了 https

[WuwuGin]

关于会话安全，php 官方有自己的基础建议，虽然你不一定用 php，但是道理是通的。详情： http://php.net/manual/zh/features.session.security.management.php

[Raymon111111]

https

[caola]

@cc959798 还在怀疑 https 的效率？你看看现在还有多少网站是 http 的？
再过一两年浏览器都默认走 https 了，如果想访问 http 的地址，还得自己手动在域名前输入协议的部分。

[tiaod]

@caola 然而大部分支持 https 的网站都设置了 http 跳转 https，于是又给你跳回去了

[caola]

@tiaod hsts preload 了解一下，或者使用你的浏览器访问一下 cao.la ，在现在的浏览器正常的情况，你永远无法回到 http，包括子域名

[ca1123]

https 和可信 CA。但是可信 CA 本身就是个笑话。你到底相信 CA 什么，在 NSA 或者土鳖面前的节操么？ NSA 会往算法里埋雷，土鳖根本就会要求在他那儿保存私钥。

[caola]

@ca1123 可信的 CA，至少比完全不加密的 http 强的不止是一点点，
关于 NSA 的算法，已经有代替者 25519，在 tls1.3 和 quic 下默认就是它，未来将会取代 NIST 系列的算法

[TheKiller]

@bumz HPKP 已经被抛弃了 不再建议使用
chrom 67 也将完全移除支持

[defel]

http 通知对方拿硬盘来拷贝😏

[IvanLi127]

自己搭网络

[ca1123]

@caola 你怎么知道新的没有雷？

[msg7086]

@ca1123 这种没有意义的问题问出来有什么意义。
你自己发明出来的算法还能问你怎么知道那不是你第二人格想要偷取你第一人格的数据。
连可信的公共领域算法和可信的机构都不相信了，那世界上还有什么可以相信的。
25519 本来就是人们发现 NSA 插手以后，在野外随便找可靠曲线的时候找到的一个已经发布了 8 年而且根本没什么人关注的曲线。如果 25519 里面有 NSA 插手，就两种可能，NSA 能预知未来，知道 8 年后人们发现他们的后门然后转用 25519，所以坐时光机回去联系作者加入后门。或者作者能预知未来，知道将来国家制定的标准会被 NSA 加入后门，所以把 8 年以后的后门放进他自己的曲线里。

你觉得哪种可能性大点。

人与人之间没有信任还活什么。你出去吃个饭相信老板不会毒死你吗。

[zjyl1994]

HTTPS 即可，不要重新发明轮子

[beginor]

酸酸乳做代理，负责客户端与服务端的通讯

[scmod]

@msg7086 233~
但是 sessionid 别人一般拿不到啊...登录后重新发个 sessionid 防下被坑,好像一般不会有什么问题的样子

[youxiachai]

lz 要准备重新发明 https 了...

[bannychen]

安全还是应该掌握在自己手里，否则都是扯淡

[caola]

@ca1123 处处怀疑，你就什么别用了，

但我可以告诉你 25519 是完全开放的，一切加密过程是完全看得清清楚楚，明明白白。不像 NIST 系列的加密，总有那么关键的一部分不被理解，或者是看不明白的地方。

再有一点就是 25519 是目前效率最快的椭圆加密算法，目前还没有之一

[finian]

1. 别试图重新发明一遍 HTTPS ；
2. 你的问题无解，请放弃治疗。数据一旦分发到客户端，就一定会被窃取，仅仅是时间和成本问题。

性价比比较高的做法：
如果是浏览器，用 HTTPS。如果是 App，HTTPS + SSL Pinning。然而也只能增加破解的成本而已。

[3dwelcome]

虽然 TLS 是行业标准，但 https 也没想的中那么好，第一服务器的性能，第二是本地化安全。

1. 性能的话，http 能同时抗 10000 个同步，那么 https 只能抗几百个同步连接，因为握手的时候，特别消耗 cpu，这点没办法绕过去的。大家之所以感觉 https 不慢，是 chrome 善于复用连接，跳过了重新握手这步。但不管如何，握手慢是物理限制，没办法避免的。

2. 本地化浏览器安全策略，目前大家手机 android 里，一般用的都是 webview，简单封装一下单页面 app，是主流趋势。有个叫 chrome 远程调试手机 webview 的东东，可以直接对手机的页面做拦截调试，和 http 还是 https 无关，js 本身就没那么的安全。所以就算用了 https，多加几层保险措施，也还是能提升安全系数的。

[hxndg]

@3dwelcome
https 只有握手的时候慢是因为握手的时候使用的是非对称，但是这个 https 同时抗几个同步连接没关系。
关于重新握手你这列说的很不清楚。


@caola 有一点你说错了,tls1.3 没有要求必须 25519,只是说是实现者应当实现


@ca1123 啥都不信，你以为是无根之水？


@shiny 你需要加深对于 h2 的理解，h2 本质上包着 https

[3dwelcome]

@hxndg 上 https 后，只有几百个同步连接不是我说的，是腾讯大公司专门做 https 优化人员说的。你百度搜一下"https 性能优化"，第一篇就是，原文是"事实上大部分机器一秒钟只能处理三四百次 RSA"，我并没有加油添醋，自己的实际压测，也是这个数量级。

而不用 https，只用 http，随随便便上万个同步连接，服务器没有压力。我希望你也能测试一下自己的机器，RSA2048 握手耗时多少毫秒，看一下结果，就知道所言非虚。

[hxndg]

@3dwelcome
我说的很清楚了，https 同时能保持多少个连接并没有限制，你说的东西是握手。
我司做负载均衡，https 能开到 1m，你是说我们在做梦么？

[fancyhan]

https over http

[3dwelcome]

@hxndg 偷换概念是你厉害，把单机负载和多机负载均衡混一起比数量级。

[hxndg]

@3dwelcome
我对于你说的偷换概念没有任何兴趣，单台设备处理负载均衡 https 握手并发连接，后端通信是明文的 http，懂了么？你让 CPU 去做软解密本身就是极蠢的行为，硬解密交给卡做，ok?

还有就是没事干不要扯 RSA 秘钥交换了，你可能不清楚目前 RSA 密钥交换方式是不推荐的，TLS1.3 当中更是废除了 RSA 密钥交换，

[3dwelcome]

@hxndg 你们完全是 gateway 套了一层？有点创意，我还以为都是软件硬算 RSA2048，因为现在 let's encrypt 的最小长度就是 2048，软解 cpu 压力还是比较大，如果能用硬件卡那就很 NB 了。

至于 TLS1.3，感觉普及率好低，而且协议要废弃 RSA 网站签名证书，强上 ECC 证书，还是有点难度。现在双证书的网站也不是那么常见。

[hxndg]

@3dwelcome
TLS1.3 　 draft-28 版本，年内估计正式公布，今年硬件商必然支持。