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

@hst001 这个可以有。直接告诉使用者一个 key ，让使用者使用前手输。

@Hardrain 看清楼主的假设好吗? 只考虑监听, 不考虑篡改内容.

基于这个假设的条件下, 服务器先下发 RSA 公钥, JS 生成一个用于加密的 KEY,
然后对要进行提交的数据使用生成的 KEY 加密,
使用 RSA 算法对 KEY 进行加密, 将 RSA 的结果和要传递的数据的加密结果一起传给服务器,服务器自己解 RSA 之后,用 KEY 解加密数据, 即可.

端到端加密

@xqin 我并不认为我没有看清楚楼主的假设

中间人攻击并不<b>仅仅</b>用于篡改传输内容
你要是用匿名(不签名)的 DH/ECDH 抑或是为签名过的 RSA 公钥进行密钥交换，窃听者完全有可能用中间人攻击的手段获取加密通讯的内容.

gpg 签名且加密，不走 http ，直接走 smtp ＋ tls 互传，即 gpg 加密和签名后的消息报文。

公私钥安全传递，自己派人用加密 U 盘人肉信使传递吧。（重要的外交文件，依然人肉信使传递)

想想当前航空用的空地文本通讯，还是用加密的电报传输呢。

@Hardrain 允许 窃听到内容呀, 但只要能保证不被解密得到原文就可以了.

先搞清楚什么样的中间人，如果客户端拥有者同时想扮演中间人，他有很多方法截获通信内容；

如果只是防止真正的第三人， https+浏览器+HPKP 、 HSTS ，或 https+客户端+built-in certificate pinning 就可以。

如果还不放心，直接双向证书认证的 ipsec 够了吧。

@xqin 我不明白你说的"内容"是指的密文还是明文

我表达的意思是『窃听者可以用中间人攻击的手段获取明文 明文 明文』
明文都叫窃听者获取了还叫"防止监听"吗？

@Hardrain 我上面说的传输的内容用算法进行加密, 你完全忽略了?

大概三年前我做过一个简单的实验。大致的介绍在这里： https://ifconfiger.com/page/cryptography-on-application-layer 。现在回过头来看，感觉实现的方法还是有点不太成熟的。

简单的流程大概是这样的：
1.服务器和用户共享一对相同的密码。
2. 用户在浏览器输入密码后，浏览器的 JavaScript 对密码进行 hash 获得对称密钥。
3. JavaScript 用对称密钥对 http 请求的数据进行加密，将加密的数据使用 base64 编码发送至服务器。
4. 服务器解密请求，生成响应的消息体，使用密钥加密消息体并传回客户端。

以上流程我能想到的一些缺点：
1. 一个是不能保证数据的完整性==》密钥生成的方式容易收到重放攻击。
2. 再一个是使用了 ECB 模式加密数据==>这个倒是可以使用类似的 DH 算法协商一个 IV 。
3. 前向安全性貌似不能保证。

@Hardrain 还是用代码来说话吧.
演示地址: https://xqin.net/http/
源代码: https://github.com/xqin/http_encrypt_demo

查看演示的时候, 可以打开控制台, 看 Network 中的请求及响应,
请以窃听者的身份, 根据请求和响应的内容, 得到服务器返回的原始数据.
> PS: 客户端收到的原始数据会在页面中输出, 以便你检测你自己还原出来的和服务器返回的是一样的.
>> 再再 PS: 如果觉得演示是放在 HTTPS 的站点上有问题的话, 可以自己 clone 一下源码,然后在你本地部署一份,
>>> 然后用 Fiddler 做为 HTTP 代理(窃听者), 根本 Fiddler 里捕获到的数据, 还原输出服务器返回的原始数据.

我倒是好奇坚持不让用 https 的原因

@jybox

能篡改的话，想要监听也是轻而易举的把？

TLS 之所以安全是因为通讯双方的身份都是得到过认证的。服务器向客户端发出一把锁，客户端用自己本地的 CA 记录验证服务器发来的锁是否合法，然后将数据用锁锁好发送给服务器。

如果没有服务器和客户端验证的过程，数据加密就跟没有一样。

就楼主需求来说，如果 Web 应用上不了 TLS ，就不要考虑加任何“加密通讯”手段了。因为都是徒劳的，只是给自己的安慰剂而已。别人真想监听，它可以注入一个 JavaScript 绑定所有 Input 的 onChange 事件发出来，这样你拦都拦不住。

@xqin
https://www.zhihu.com/question/45069626
https://program-think.blogspot.com/2016/09/https-ssl-tls-3.html

学习一个
你这个实现无论如何也要进行密钥协商吧？似乎没有使用 DH/ECDH
服务器---RSA 公钥--->客户端
那么有上一行这个过程吧？

如果中间人有能力篡改连接内容，改了你公钥不就做成了中间人攻击？
SSL 中你把 CSR 交给 CA 不就是给公钥签名让中间人改不了，如果改了客户端会发现吗？
照你的神逻辑 自签名证书也有足够的安全性 OpenSSL 随便就能生成一个谁还花钱找 CA 买证书去？

此外，你所说"传输的内容用算法进行加密",如果你用了非对称加密那不用保证『客户端获取的是服务器的公钥而不是中间人的公钥』？
此外此外，我不明白你一直说的原始数据是指什么？我可以理解为密文吗？

@Hardrain 看清楼主要讨论的内容好吗?

都说了 只考虑防窃听到原始数据(未加密前的内容, 上面的例子中服务器返回的 Hello Client 的那段), 不考虑篡改.

楼主在上面 强调了好几次, 只考虑防窃听不考虑篡改, 可还有一堆上人, 在往 篡改数据上面扯.

@Hardrain #39 其实 PGP 的信任体系是基于指纹的，密钥服务器不可信，正确的做法是通过传统方式（电话等）核对指纹

@xqin 我没有说『篡改具体通信内容』
而是强调攻击者『通过篡改 [公钥] 』来 [获取] 通信内容

你听得懂话？

@BXIA 查证了一下 这点上的确我错了 可能是习惯了 Ubuntu 的 ppa 源添加后要导入 GPG 公钥

但是 GPG 的安全性也基于『有条件以确保公钥不被篡改』 这个理解应该没有错误吧

@Hardrain 篡改公钥 不是篡改吗? 麻烦你去前面看清楼主的要求好吗?