有没有不利用证书也能安全通信的方案

[benjiam]

证书虽好，关键是证书预制问题，第二点根节点的私钥其实是不安全的，zf一句话就拿到了。所以其实不安全。有无安全的通信机制，可以防止中间人。

[hjc4869]

楼主只要不用CNNIC，“zf一句话就拿到了”这个应该不成立吧。。

[Septembers]

参考Telegram

[yangff]

人肉交换密钥

[realpg]

个人搞浅层暗网多年的黑技术经验告诉你

首先，你不要做大做出名被人工盯上，被人工盯上啥也不好用
然后，如果你没有被人工盯上的话，那些高级加密都不需要。你在代码端把内容base64了，在前端用js解密出来，中间这个传输对于识别引擎来说就是乱码，他们监控不到你的网页内容
因为base64应用太普遍，如果担心ZF的扫描器能识别base64字符串的特征码，二次处理一下base64的字符串，比如用ascii漂移一下，这啥也自动化识别不出来你是啥……

[publicID001]

密码学的一条很重要的原则就是不要自己造轮子，所以说如果不是密码学专家就还是老老实实用 HTTPS 比较好

[cnbeining]

自签呗。

[lijianying10]

RSA+HMAC
HMAC不说了
RSA各种语言都有实现，包括js，网上找就能找得到

通讯登陆过程中互相交换PublicKey,客户端临时生成服务器端周期更新。即可。
之前我写过文档记录这个。https://github.com/lijianying10/FixLinux/blob/master/prob/PHP-RSA%E5%8A%A0%E5%AF%86%E8%B7%A8%E5%9F%9F%E9%80%9A%E8%AE%AF%E5%AE%9E%E6%88%98.md
可以参考一下。

关于造轮子：
都是现成的看看代码复制粘贴的事。

最后希望能帮到楼主。

[DreaMQ]

Shadowsocks 这种 pre-shared key 在密码足够复杂且保密的情况下应该够了吧

[incompatible]

@lijianying10 互相交换公钥的过程如何防止中间人攻击？

[realpg]

比如这个分享一些不和谐内容的内部站，我就是用一个网上的仿V2EX的很小的小BBS程序改的
传输层检测到的内容就是这样的：



因为用了jquery2，不支持IE，用IE看到的就是原始的，js解码未执行
实际上浏览器端如果用chrome就会跑起来算法把加密内容还原了

[kslr]

@realpg 不错的想法

[realpg]

@kslr

这只是最入门的黑科技了……

不过我仔细看了一下不符合楼主主题的 跑题了 楼主是要反中间人反劫持的
我这只是单纯的防止通用旁路分析……

[benjiam]

恩 对安全理解不深，但是对称非 对称加密 https 这种还是都懂


我希望解决的是 在互联网的2点 在没有初始信息交流的前提下， 进行安全的通信。

证书体系 可以解决这个问题，但是还有很多实际的问题， 主root 私钥不安全，被吊销证书查验及时 等客观的问题。


直接使用rsa des 这样的方法，绕不过中间人，这也是为什么会有证书体系，


直接密钥交换机制 不能攻克中间人，否则就完美了。

[cdy]

试一下斯诺登的方法：

https://www.eff.org/deeplinks/2014/10/7-privacy-tools-essential-making-citizenfour

[lianyue]

base64 早能识别了 不行你们自己试试

[publicID001]

@realpg base64 压根不是加密。。连密钥都没有的玩意儿

[publicID001]

@lijianying10 不正确的使用密码学原语会让你的加密系统非常容易受到旁路攻击（以及其他攻击），这是个很有难度的活，没有金刚钻还是别拦瓷器活比较好

一个栗子：
http://m.phys.org/news/2013-12-trio-rsa-encryption-keys-noise.html

[Slienc7]

我也是醉了，自簽證書解決一切問題，内置客戶端中

[lilydjwg]

要可否认性（plausible deniability）就用 bitmessage，不需要就用 OTR、Tox、PGP 加密邮件之类的。都是不依赖于可信第三方的。当然，密钥怎么交换自己看着办！

[lilydjwg]

@incompatible Linux 内核开发者交换密钥的方法是在线下见面交换 :-)

[DreaMQ]

或者让两台设备物理接触，通过蓝牙、NFC、有线（最安全）等线下方法交换非对称密钥

[lilydjwg]

@xgowex 如果证书比较多的话，还是自建一个 CA 吧。

[kn007]

@realpg 有意思

[benjiam]

原意就是 正在开发一个类im 系统， 里面的2者需要通信，我希望2 2 之间通信是安全的。方法1 就是 root
为每个用户颁发个人私钥 签名， 问题是如果root 的私钥泄漏 就会被攻破， 这也是现有的sa 体系的问题。 因为我希望这个系统运行以后，所有人的通信是安全的，无论是否root被攻破，这个系统只是提供一个定位的功能，2者之间的通信将会是安全的。

[Quaintjade]

目前一切加密方式都逃不过预先共享这一环节。
无论是pptp,ss的密码、l2tp的psk、证书体系的根证书、anyconnect和ikev2的自签CA证书，本质都是预先分享的信息。
这是加密的根本，被拿到了就玩完。无非好的加密算法能确保即便该关键信息被拿到，以前的传输的资料仍无法解开（我觉得这个挺神奇）。

[benjiam]

@Quaintjade 有能保证该信息过期无法解开的算法吗？

[msg7086]

@publicID001
base64不是加密并不代表base64没有加密。
下结论前先了解一下并不是什么坏事。

[RqPS6rhmP3Nyn3Tm]

正解，自建CA自用是够了。
其实我感觉 GnuPG 也挺好用的，前提是得先从其他（可靠的）方式获取到公钥。

[msg7086]

@realpg
@publicID001
我以前敏感内容过墙，是用的gz压缩+base64，然后客户端拆开base64后再要做一次解压缩才能用。
框架静态，内容全程走ajax然后js处理。

[msg7086]

@BXIA 自建CA主要是没有信任链，伪造自建CA别人无法分辨。
现在最理想的做法算是DNSSEC+DANE，然而还没普及。指望一下将来的5-10年发展好了。

[realpg]

@msg7086
二次压缩必要性不大
我算是比较熟悉这种旁路分析器的的实现
能实现这么高效率的，一般是用专门芯片做字符流匹配，match黑名单的特定流，只能对通用算法进行匹配，base64后随便再做一点小小手脚就无解了，二次gz开销太大。你看我截的图，其实大多数并不是纯种base64，不信你取个片段解一下试试。

[RqPS6rhmP3Nyn3Tm]

@msg7086 不如用 GPG 咯，信任链倒是可以做出来，就是可控性可能低了点。小项目的话挺好用的我感觉……大项目可能不适合？

[em70]

key=MD5(随机串+密匙+时间戳)

把随机串,时间戳,key发给对方.对方用这几个数据同样做md5计算,如果结果一致则可信任.

这种方法只要保证密匙安全就比较安全.关键是计算简单,性能优异.

[Quaintjade]

@benjiam
无法解开以前的信息的加密算法，我也只是听说，没研究过。

担心共享根的安全性的话，可以参考GPG，每个人创建自己的公钥密钥对，公钥传播出去，别人用公钥加密，自己用私钥解密。
问题在于去中心化的网络如何可靠地把每个人的公钥传播开，这个就得参考tor及ed2k了。我的想法是，依赖已知安全节点以及少数服从多数。不过要小心入侵者伪装成多数，另外网络规模小时可能很慢。

自造车轮终究是个危险的举动，上面只是原始的思路，离实现差了十万八千里。

[Quaintjade]

@Quaintjade 说错，不是ed2k，是kad

[laotaitai]

@realpg 哈哈, 兄弟, 点个赞! 我tmd就是这么想的, 也这么干的, 双层base64, 然后再reverse.

[realpg]

@laotaitai 其实这个还有个更高级的玩法，做更内部的用处使用
就是在客户端并不解码成原始的。
把解码算法封装到一个crx里面去
有指定chrome扩展的电脑就能正常看，没有的就不行……

[Smartype]

@benjiam 密钥交换算法是可以保证不受mitm的影响的

[Smartype]

你看看Diffie-Hellman算法，也就是在还没有发明rsa的时候是怎么交换一个shared secret(aes key/iv)的

[noli]

@benjiam 私钥分发会泄密？容易，只分发服务器的公钥，客户端自己生成私钥。初次与服务器通信的时候，就用服务器的公钥来验证服务器的身份，然后向服务器注册自己的公钥。
反正你的 IM 分发的过程本身就是一次极好的自动分发公钥的过程。

[benjiam]

@Smartype diffe hellman 不能对抗mim


@noli root 失效就全网崩溃

[Smartype]

@benjiam 为什么不能对抗mitm？能通过监听知道双方协调出来的内容么？

[Smartype]

@benjiam 查了一下，可以替换双方的协商内容。你说得没错。

[chenshaoju]

关键词：挑战应答认证

https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication

假设某用户的密码是 abcdefg ，客户端先生成一个随机数，比如 123456 ，并发送给服务器。

中间人拦截到了，没关系，服务器也收到了这个随机数，随后，服务器也生成一个随机数，比如 654321 ，然后也发送给客户端。同样，中间人也拦截到了，一样没关系。

客户端，服务器和中间人都知道客户端的随机数是 123456 ，服务器的随机数是 654321 。

现在，客户端使用 md5("123456abcdefg654321") 进行散列，得出一个MD5：500908fd00948ac2cc7b096315d41ff7，并直接将MD5发送给服务器。

同样，中间人也拦截到了，但是中间人并不知道这个MD5是什么，无法解密。

服务器收到后，从数据库读取用户的密码，用收到的随机数同样进行一次相同的散列过程，进行比较。

结果一致，OK，认证通过。

[noli]

@benjiam 证书更换协议。

[LazyZhu]

@BXIA https://github.com/stealth/opmsg
PFS = Perfect Forward Secrecy

[7654]

你需要“黑话”

[laotaitai]

@realpg 这个限制太高了, 一般用户装不来扩展. 虽然我网站粘度很高, 也不敢冒险去试这个.

[laotaitai]

@realpg 不过, 想法真不错! 适合粘度更高, 用户又不傻逼的网站.

[windyboy]

证书是最简单有效的手段

[9hills]

自签名证书的私钥zf一句话拿到，那你换任何一种加密zf都能一句话拿到。

[kaneg]

@chenshaoju 可是一般来说数据库中的密码都不会以明文保存，服务端如何以同样的方式做散列？

[chenshaoju]

@kaneg 太简单了，假设明文密码以md5形式存储，那么就再md5一下，比如：
md5("1234560cc175b9c0f1b6a831c399e269772661654321")

[benjiam]

@9hills no ， 如果2个节点交互是自己协商密码，任何一方就无法获取了。
@chenshaoju 关于中间人 你还没搞清楚

[9hills]

@benjiam 协商也需要身份验证，身份验证必然某一方要存身份信息，要存身份信息zf一句话拿到，照样中间人

[9hills]

@benjiam 总之一句话，你用任何方法，都不可能获得比证书更加强壮的安全性。

如果你最终找到了，不如share上来。

[benjiam]

@9hills 目前是没有，找到了得个图灵奖是没问题的。可以改变所有网银的认证机制。

[9hills]

@benjiam 其实你仔细想想，在你假设『zf一句话』即通信的某一方被第三方控制的情况下

所有加密方法从逻辑上就都不安全。。。而去尝试寻找一个逻辑上并不存在的解。。就没必要了

[yajiedesign]

如果根CA或者证书路径上的证书不可信.那么据我所知,要完全避免中间人攻击,安全可靠的只有量子密钥分发.其他办法也许看上去可行.但免不了有你我想不到的漏洞.

[noli]

@benjiam 在没有证书的前提下，是没有办法实现两个节点交互协商密码的。其他的全部是空想。

[chenshaoju]

@benjiam 那你说说吧，这种挑战认证，中间人能得到什么信息。最多只能得到两个随机数，以及混合了密码的散列值。

[yajiedesign]

@noli 量子密钥分发可以....虽然离进入千家万户还很远,但毕竟不是空想了.

[yajiedesign]

@chenshaoju 挑战认证没什么问题.然而只能认证,不能用来协商密钥啊...

[xierch]

如果你有一个安全的信道，可以用它再确认一遍对方的证书。比如两个人面对面确认。
（Telegram 就是这样，它会根据 public key 生成一个图案，可以让用户肉眼辨认

那个「事后得到 private key 但无法破解之前截获的流量」的技术，叫 PFS，Perfect Forward Secrecy

[Gandum]

等到量子加密实际应用的时候，也许能够解决楼主的问题。通过量子加密发送密钥，然后根据量子纠缠判断这个密钥是否被监听，如果没有，则使用此密钥，否则就弃用当前密钥，并生成新密钥重新发送，直到发送成功为止。
但是这也只是也许，因为如果在不安全的信道中，你每一次发送都会被监控的话，那么密钥就永远发送不成功，量子加密也解决不了这个问题

[yajiedesign]

我之前表述有些不准确,应该说在面对高度掌握信道的攻击者时,量子密钥分发,有机会解决"中间人攻击"的问题.而不是已经解决了.现在已经有协议宣称可以抵御"中间人攻击",然而毕竟没有实战检验.

[chenshaoju]

@yajiedesign 怎么不能，直接用用用户的密码（或者散列后的密码），加上时间戳（年月日时分），再散列一下，等等作为信息作为密钥进行加密。

[benjiam]

@9hills root证书被攻破，但是通信双方是安全的，通信网络被攻破，但是不代表就能破解通信。

[wy315700]

任何加密都有一个预置的信任关系为前提，证书恰恰是这种实体

[datocp]

证书解密是有时效性的，花了大量cpu时间去解密一个一分钟前过时的信息。

一个常用软件对用户证书认证过程。至少在这个软件下面访问页面100%绿色状态。
With certificate authentication, when the connection source computer attempts to connect to the Virtual Hub it presents a user name together with an X.509 electronic certificate. The SoftEther VPN Server checks whether is correct and the connection source computer is only allowed to connect if it passes.
The connection source computer must possess certificate data and a private key (RSA private key) that corresponds to the public key in the certificate to present. Certificate data is sent from the connection source computer to the VPN Server by private key data is not transmitted. Next the VPN Server sends random number data (called challenge values) to the client. When the client receives the data, it signs it by the private key it possesses and returns the data. VPN Server verifies the signature data sent by the client using the public key in the electronic certificate initially received and makes sure that the client computer has the certificate and corresponding private key (if it can't be confirmed, user authentication fails on the spot). It subsequently checks if the certificate subsequently presented by the client matches the attributed defined for each user as user authentication data. You can select either individual certificate authentication or signed certificate authentication as the test method at this time.

[benjiam]

如同在非对称加密出现以前，我们认为这是不可能的一样。不过没用良好的数学基础，基本也就是痴人说梦了。

[wy315700]

@chenshaoju
这个认证弱了点，要求密码是明文存储的
PPTP就是基本上这个协议

[wy315700]

@chenshaoju
和公钥系统结合起来会比较好，
服务器保存用户公钥，客户端拥有私钥

服务器发送挑战值到客户端，客户端使用私钥加上时间戳签名以后，发送给服务器端，

[breeswish]

客户端与客户端之间建立点对点加密，使用 root CA（其实只要可以公钥私钥就行）确认加密请求可靠性，这样：
1, root CA 被破解了不会影响已经建立起来的点对点加密
2, 仅破解单个客户端不会影响其他客户端之间的通信

[jiongxiaobu]

密码学原理欢迎你

[breeswish]

3, 在 root CA 被破解前客户端与客户端建立的点对点加密不会被 MITM 攻击

[breeswish]

@realpg 这个有人做了： http://priv.ly

[breeswish]

其实吧，这些非对称加密啊什么的..面对国家机器可能都是没什么用的，鬼知道灯塔国在加密算法里藏了多少后门呢..

体系中只要有一个后门，那整个体系就是不安全的，更何况灯塔国还到处都安插过后门——从最底层算法的依赖（如随机数），到算法相关（如曲线参数），到具体实现（如 OpenSSL 函数），可是都被藏过后门的…还有更多没有爆料出来的：我相信只要被 NSA 盯上了你的加密数据一定可以被解密 =。=

[vibbow]

@lianyue base64 两遍就无法识别了，我试过...

[kaneg]

@chenshaoju 一般来说明文密码都要加盐后再做某种散列后存储，总不能让客户端知道盐是什么吧

[comicfans44]

这更多的是个社会问题而不是技术问题，假如他们想知道，那探讨技术问题是没有意义的，直接约谈你就可以了，还是一句话。

但假如你还没那么惹眼，那么自定义的协议就好了，他们懒得（也不可能）去针对每一种自定义的协议。

[realpg]

@laotaitai

用这种技术的要么是涉及敏感(色情/政治)，要么是论坛。基本不靠吸引大众。那种搭个论坛拼命去拉流量，吸引人注册，拼命SEO的要么是管理欲变态(中国这种人特别多)，要么是想套现撸钱。

大众的东西基本我都不碰，有太多成型的网站、论坛没意思。我做的站东西基本上很多程度都有禁止将本站告诉给大众，禁止在外网发表链接到本站的链接，基本靠其他渠道获取，比如线下交流，比如真朋友关系介绍。你能知道有我的站存在，那你就达到门槛了，对于这种情况，我设置多复杂的限制（甚至有些里面会流传一些比较机密信息的我都强制给客户发ssl客户端证书）他们都可以理所当然的视为正常的一部分，别说个简单的扩展了。

早年其实很多人觉得禁止IE6不可实现，其实一点也不难。我早期也做过一些比较大众的网站，我就写明白了禁止IE6(后来chrome流传广泛+chrome壳浏览器多了以后直接IE核心给个不正常乱码，然后提示禁止IE)都不会流失用户，特别小白的用户也会去度娘知道问，为啥我访问XXX是错乱的，然后就会有人替我回答你去下载个firefox 后面附网址 访问就好了…… 前提是，你的站真有内容，别管大众小众，你的站真能吸引他们去看，去访问，去讨论，那就不怕。

而我自己做的非大众东西，从chrome版本号发展到20那一天就开始屏蔽IE访问了，后来，jquery2不支持IE旧版本我太高兴了，可以让IE这种逗比都不正常，都不用再去做额外分析限制了，反正jquery2跑不起来网站肯定不正常。

而且我的小圈子论坛，很多都是无管理的，靠大家VOTE实现管理的功能，狗操的管这个叫人民民主专政……反正因为有简单的防止旁路收集敏感词，哪怕有轮子在里面传教、贩卖军火都不怕，很快就会被人民民主专政掉，在专政掉之前，也不会被一些特定的监管采集到对网站造成关站等恶劣影响。

[chenshaoju]

@kaneg 加盐意义不是很大，现在的泄漏其实绝大多数都包含了盐。如果觉得MD5太容易破解，换一个呗，那么多散列算法。
SHA1()
SHA256()
SHA512()
MD5(SHA1()+SHA256())
……
@wy315700 没错，这就类似于PPTP。但是预共享密钥本身也需要通过不安全的方式传递，所以考虑０信任的方法，挑战认证安全系数仍然相当高。

[wy315700]

@chenshaoju
其实都一样，这里面的预共享秘钥其实就起到了证书的作用，只不过加密比较弱

[laotaitai]

@realpg 看样子你网站真的很牛逼! 估计市面上都不超过3个像你这样的网站. 我简单看了下你个人信息, 咱俩有点类似, 至少我也是FreeLancer, 也是不用第三方程序的站长. 握爪!

[realpg]

@laotaitai

2013年以前我还有做一些大众的东西，后来都放弃了或者转给他人维护了。

现在我自己做的东西都是给小众爱好者圈子的，我自己就是最重度的用户，大多数没有竞争对手，或者有竞争对手的情况下我还做这个是从用户体验出发他们的东西太难用了，我作为用户都受不了的时候我才自己做。而且我的用户有大半至少是跟我在某些方面能达到一个level的能混到一起去的，一些技术上的限制，教教就会了，都不缺学习能力。


其实我做网站，最大的原因就是我的服务器、带宽都不要钱，除了自己写代码外没有成本，没有挣钱压力，做的东西质量就好。我给很多公字头单位朋友做义务技术支持，往他们那里丢个三五十台服务器用个百八十兆带宽都不是事儿。

[laotaitai]

@realpg 看样子是火车或者飞机类型的网站咯.

[caoyue]

你从开始都不能保证客户端连接的服务器不是中间人，所以在此之后的一切机制都无效了吧
所以还是必须有证书，或者类似于证书的东西通过可信渠道交换才行

[invite]

@realpg 求分享服务器资源。

[Smartype]

@chenshaoju 这里的关键是密码如何可靠设置。这又是鸡和蛋的问题了。

[benjiam]

我认为这里有一个前提，客户端是可以有一张预设证书的，但是这张证书可能会丢失私钥。

目前的安全体系都无法安全的交换秘药，所以得靠证书认证，并保证，证书私钥不丢。

[realpg]

@laotaitai
不是 这两个也很大众……
还有更小众的……

[fishioon]

@chenshaoju 还有一个问题，客户端如何识别服务器？中间人模拟成服务器和你通信，你如何识别？

[chenshaoju]

@fishioon 不需要识别，假服务器只能拿到一个散列值，不具备有效性。如同刚才的中间人一样。你拿着这个散列，也做不了任何事情，你没有办法知道这个散列值后对应的密码是什么。

@Smartype 是的，无论无何都得有一个方式来设置密码。。。所以，在一个小群体范围内，比如，企业内部，这种认证方式足以。

[fishioon]

@chenshaoju 假如你要逛淘宝，中间人劫持了并冒充淘宝服务器，然后你连接到了中间人这边，然后你输入了账号密码，然后钱就木有了

[chenshaoju]

@fishioon 你最好仔细想想挑战认证的协商过程。你认为服务器和中间人会产生相同的随机数？

[fishioon]

@chenshaoju 就问认证通过了然后呢？你和服务端后续的通信内容需要加密吧，同时客户端与服务端需要对传输的内容解密吧！还有我冒充服务端与你通信，我直接告诉你认证通过啦，然后你就和我通信了？然后就传输了？你这个都防不了钓鱼

[chenshaoju]

@fishioon 可以啊，通信也是密文啊，你无法解密啊。看６７楼。

[fishioon]

@chenshaoju 明白了，你这种就相当于最开始就已经协商好了密钥（密码作为密钥），这样基本没啥意义了，整个安全系统最困难的就是如何协商并交换密钥

[noli]

http://www.zhihu.com/question/22432753