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

[cc959798]

比如浏览器的 seesion_id，如果对方得到了 session_id 理论上是有了免登陆的能力，还比如 app 中授权用的 token，如果被拿到就也就不用通过授权验证。 有什么好的方式解决这个问题呢？ 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 版本，年内估计正式公布，今年硬件商必然支持。