除了 https，有什么防止网络监听的成熟方案

[nilai]

最近写了个小项目， 要求不用 https （丫的，就是这么奇葩）， 要求保证通信的安全， 防窃听

浏览器 ----> 服务端 （这个倒好做， RSA 浏览器公钥加密, 服务端私钥解密。中间人没有私钥，就算窃听到数据也解密不出来）。


服务端 ------> 浏览器 （目前仅应付一下 就是 服务端发送数据时 AES 加密， 浏览器 AES 解密， 这样明显的缺点就是中间人分析一下网页，就知道 AES 的 KEY,然后就能解密出对应的数据了，因为不管怎么着， 数据都得在浏览器正常展示出来）

后来觉得 DH 算法应该可以， 但是实现过程略显麻烦，对 web 类的纯 HTTP 应用不是很适合，


说了这么多， 求指教。

[jybox]

@BXIA 发了假证书就已经是篡改行为了呀，楼主说不考虑篡改只考虑窃听

[snnn]

看来你还不知道啥是消息完整性

[liyvhg]

私有协议，全程 websocket

[hjc4869]

客户端可以，浏览器不行。

[RqPS6rhmP3Nyn3Tm]

@jybox 我理解的篡改内容是篡改传输的内容，而非握手阶段的信报。如果是这样的话，确实算是篡改了。
不过 aes 那段，真的没啥想说的……

[maplerecall]

简单的说，如果是纯浏览器环境就放弃吧

[mengzhuo]

没有
不要自欺欺人

[hst001]

简单从信息加密的角度想一下，其实从服务器发给浏览器，无论何种方法，客户端都有有一个解密的 key ，所以问题在于怎么安全的把解密的 key 交到客户端的手里，我的想法是。。。。。当！当！当！亲自上门交到客户手里！不要喷我

[wwqgtxx]

@rogerchen payload 就算用 rsa 加密其实也不需要 e7 那么夸张，我用过纯 python 实现的 rsa 加密，在 500k/s 下也就用了 10%的 cpu(cpython3.5+i7 4790)

[momomirage]

线下交换公钥, 线上 PGP

[jsq2627]

讲道理的话，就算 https ，没有进 preload list 也谈不上多安全。

就楼主的需求，简单的对称加密，密钥明文下发都没啥大问题。不定期换换密钥和稍微更新一下加密方式就好。
如果楼主遇到的是强大的对抗力量（比如国家机器）的话，在现在的环境下基本是无解的。

[zjcqoo]

------- 楼歪了，我来说个方案 ------

HTTP 下防劫持比较靠谱的方案 —— 给入口页面使用前端缓存，比如 html5 appcache 、 max-age 等等，资源使用加密传输。

这样做的好处是，把风险缩小到首次访问。之后就算遇到不安全的网络，打开的也是缓存里的页面，不会被中间人篡改程序和界面。

这种方案叫做 TOFU （ Trust on First Use ，信任首次使用）。

[KKKKKK]

pjax+aes 加密

[majinjing3]

直接用带 tls 的 tcp 就好了，和 http 没有啥必然关系的，

[loading]

vpn 拨上，链路不就加密了？

[whimsySun]

没有

[xqin]

其实楼主的问题, 要解决很简单嘛, 约定一个算法.
比如 QQTEA https://github.com/xqin/qqtea

浏览器随机生成加密 KEY, 然后用 RSA 加密, 发给服务器,
服务器 用同样的算法 (PHP 版的 QQTEA https://github.com/xqin/qqtea.php), 使用相同的 KEY 来进行加密,
加密后的内容返回给浏览器, 这样 key 在传输的过程中是加密的, 且 服务器回来内容的时候只有加密后的内容.
这个 key 只有 浏览器和服务器 俩人知道.

所以就达到了保密的目的.

[NUT]

把序列化的后的数据（比如 protocol ）的二进制数据，加自己的头，做下偏移。或者伪装成 zip 的文件等等。 说白了就是他自己拿到包也用不了。

[bdbai]

@majinjing3 读题 纯 web

[Hardrain]

个人认为无法做到
因为在没有预先建立信任体系的前提下无法对抗中间人攻击

预先建立的信任体系 是指:
对于 SSL/TLS 则是 PKI(公钥基础设施)
对于 GPG 则是通信双方都信任的、能与通信双方建立可靠连接的 Key Server

如果你有极可靠的方法(如嵌入软件中或"面对面交换")来完成 SSL/TLS 中密钥交换机制所完成的 那另当别论