这是一个创建于 3399 天前的主题，其中的信息可能已经有所发展或是发生改变。
证书虽好，关键是证书预制问题，第二点根节点的私钥其实是不安全的，zf一句话就拿到了。所以其实不安全。有无安全的通信机制，可以防止中间人。
 |
1
hjc4869 2015-08-02 09:03:56 +08:00  1
楼主只要不用CNNIC，“zf一句话就拿到了”这个应该不成立吧。。
|
 |
2
Septembers 2015-08-02 09:08:13 +08:00 via Android 1
参考Telegram
|
 |
3
yangff 2015-08-02 09:23:43 +08:00 via Android 1
人肉交换密钥
|
 |
4
realpg 2015-08-02 09:23:48 +08:00 2
个人搞浅层暗网多年的黑技术经验告诉你
首先，你不要做大做出名被人工盯上，被人工盯上啥也不好用 然后，如果你没有被人工盯上的话，那些高级加密都不需要。你在代码端把内容base64了，在前端用js解密出来，中间这个传输对于识别引擎来说就是乱码，他们监控不到你的网页内容 因为base64应用太普遍，如果担心ZF的扫描器能识别base64字符串的特征码，二次处理一下base64的字符串，比如用ascii漂移一下，这啥也自动化识别不出来你是啥…… |
 |
5
publicID001 2015-08-02 09:24:10 +08:00 via Android 1
密码学的一条很重要的原则就是不要自己造轮子，所以说如果不是密码学专家就还是老老实实用 HTTPS 比较好
|
 |
6
cnbeining 2015-08-02 09:31:24 +08:00 1
自签呗。
|
 |
7
lijianying10 2015-08-02 09:35:03 +08:00 1
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 可以参考一下。 关于造轮子： 都是现成的看看代码复制粘贴的事。 最后希望能帮到楼主。 |
 |
8
DreaMQ 2015-08-02 09:36:25 +08:00 via iPhone 1
Shadowsocks 这种 pre-shared key 在密码足够复杂且保密的情况下应该够了吧
|
 |
9
incompatible 2015-08-02 09:39:30 +08:00 via iPhone 1
@lijianying10 互相交换公钥的过程如何防止中间人攻击？
|
|
10
realpg 2015-08-02 09:40:46 +08:00 6
比如这个分享一些不和谐内容的内部站，我就是用一个网上的仿V2EX的很小的小BBS程序改的
传输层检测到的内容就是这样的：  因为用了jquery2，不支持IE，用IE看到的就是原始的，js解码未执行 实际上浏览器端如果用chrome就会跑起来算法把加密内容还原了 |
|
12
realpg 2015-08-02 11:17:52 +08:00 1
|
 |
13
benjiam OP 1
恩 对安全理解不深，但是对称非 对称加密 https 这种还是都懂
我希望解决的是 在互联网的2点 在没有初始信息交流的前提下， 进行安全的通信。 证书体系 可以解决这个问题，但是还有很多实际的问题， 主root 私钥不安全，被吊销证书查验及时 等客观的问题。 直接使用rsa des 这样的方法，绕不过中间人，这也是为什么会有证书体系， 直接密钥交换机制 不能攻克中间人，否则就完美了。 |
 |
14
cdy 2015-08-02 12:15:51 +08:00 1
|
 |
15
lianyue 2015-08-02 12:24:25 +08:00 1
base64 早能识别了 不行你们自己试试
|
|
16
publicID001 2015-08-02 12:25:48 +08:00 via Android 1
@realpg base64 压根不是加密。。连密钥都没有的玩意儿
|
|
17
publicID001 2015-08-02 12:28:48 +08:00 via Android 2
@lijianying10 不正确的使用密码学原语会让你的加密系统非常容易受到旁路攻击（以及其他攻击），这是个很有难度的活，没有金刚钻还是别拦瓷器活比较好
一个栗子： http://m.phys.org/news/2013-12-trio-rsa-encryption-keys-noise.html |
 |
18
Slienc7 2015-08-02 12:37:10 +08:00 1
我也是醉了，自簽證書解決一切問題，内置客戶端中
|
 |
19
lilydjwg 2015-08-02 12:42:58 +08:00
要可否认性（plausible deniability）就用 bitmessage，不需要就用 OTR、Tox、PGP 加密邮件之类的。都是不依赖于可信第三方的。当然，密钥怎么交换自己看着办！
|
|
20
lilydjwg 2015-08-02 12:44:16 +08:00 1
@incompatible Linux 内核开发者交换密钥的方法是在线下见面交换 :-)
|
|
21
DreaMQ 2015-08-02 12:50:10 +08:00 via iPhone 1
或者让两台设备物理接触，通过蓝牙、NFC、有线（最安全）等线下方法交换非对称密钥
|
|
24
benjiam OP 1
原意就是 正在开发一个类im 系统， 里面的2者需要通信，我希望2 2 之间通信是安全的。方法1 就是 root
为每个用户颁发个人私钥 签名， 问题是如果root 的私钥泄漏 就会被攻破， 这也是现有的sa 体系的问题。 因为我希望这个系统运行以后，所有人的通信是安全的，无论是否root被攻破，这个系统只是提供一个定位的功能，2者之间的通信将会是安全的。 |
 |
25
Quaintjade 2015-08-02 13:44:20 +08:00 via Android 1
目前一切加密方式都逃不过预先共享这一环节。
无论是pptp,ss的密码、l2tp的psk、证书体系的根证书、anyconnect和ikev2的自签CA证书，本质都是预先分享的信息。 这是加密的根本，被拿到了就玩完。无非好的加密算法能确保即便该关键信息被拿到，以前的传输的资料仍无法解开（我觉得这个挺神奇）。 |
|
26
benjiam OP 1
@Quaintjade 有能保证该信息过期无法解开的算法吗？
|
 |
27
msg7086 2015-08-02 13:48:38 +08:00 1
|
 |
28
RqPS6rhmP3Nyn3Tm 2015-08-02 13:48:46 +08:00 via iPad 1
正解，自建CA自用是够了。
其实我感觉 GnuPG 也挺好用的，前提是得先从其他（可靠的）方式获取到公钥。 |
|
29
msg7086 2015-08-02 13:50:51 +08:00 1
|
|
30
msg7086 2015-08-02 13:52:42 +08:00 1
@BXIA 自建CA主要是没有信任链，伪造自建CA别人无法分辨。
现在最理想的做法算是DNSSEC+DANE，然而还没普及。指望一下将来的5-10年发展好了。 |
|
31
realpg 2015-08-02 14:01:24 +08:00
@msg7086
二次压缩必要性不大 我算是比较熟悉这种旁路分析器的的实现 能实现这么高效率的，一般是用专门芯片做字符流匹配，match黑名单的特定流，只能对通用算法进行匹配，base64后随便再做一点小小手脚就无解了，二次gz开销太大。你看我截的图，其实大多数并不是纯种base64，不信你取个片段解一下试试。 |
|
32
RqPS6rhmP3Nyn3Tm 2015-08-02 14:02:50 +08:00 via iPad
@msg7086 不如用 GPG 咯，信任链倒是可以做出来，就是可控性可能低了点。小项目的话挺好用的我感觉……大项目可能不适合？
|
 |
33
em70 2015-08-02 14:06:06 +08:00
key=MD5(随机串+密匙+时间戳)
把随机串,时间戳,key发给对方.对方用这几个数据同样做md5计算,如果结果一致则可信任. 这种方法只要保证密匙安全就比较安全.关键是计算简单,性能优异. |
|
34
Quaintjade 2015-08-02 14:27:15 +08:00 via Android
@benjiam
无法解开以前的信息的加密算法，我也只是听说，没研究过。 担心共享根的安全性的话，可以参考GPG，每个人创建自己的公钥密钥对，公钥传播出去，别人用公钥加密，自己用私钥解密。 问题在于去中心化的网络如何可靠地把每个人的公钥传播开，这个就得参考tor及ed2k了。我的想法是，依赖已知安全节点以及少数服从多数。不过要小心入侵者伪装成多数，另外网络规模小时可能很慢。 自造车轮终究是个危险的举动，上面只是原始的思路，离实现差了十万八千里。 |
|
35
Quaintjade 2015-08-02 14:33:45 +08:00 via Android
@Quaintjade 说错，不是ed2k，是kad
|
 |
36
laotaitai 2015-08-02 14:34:50 +08:00
@realpg 哈哈, 兄弟, 点个赞! 我tmd就是这么想的, 也这么干的, 双层base64, 然后再reverse.
|
|
37
realpg 2015-08-02 15:36:09 +08:00
|
 |
39
Smartype 2015-08-02 16:12:16 +08:00 via iPhone
你看看Diffie-Hellman算法，也就是在还没有发明rsa的时候是怎么交换一个shared secret(aes key/iv)的
|
 |
40
noli 2015-08-02 16:16:20 +08:00
@benjiam 私钥分发会泄密？容易，只分发服务器的公钥，客户端自己生成私钥。初次与服务器通信的时候，就用服务器的公钥来验证服务器的身份，然后向服务器注册自己的公钥。
反正你的 IM 分发的过程本身就是一次极好的自动分发公钥的过程。 |
 |
44
chenshaoju 2015-08-02 18:52:14 +08:00
关键词：挑战应答认证
https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication 假设某用户的密码是 abcdefg ，客户端先生成一个随机数，比如 123456 ，并发送给服务器。 中间人拦截到了，没关系，服务器也收到了这个随机数，随后，服务器也生成一个随机数，比如 654321 ，然后也发送给客户端。同样，中间人也拦截到了，一样没关系。 客户端，服务器和中间人都知道客户端的随机数是 123456 ，服务器的随机数是 654321 。 现在，客户端使用 md5("123456abcdefg654321") 进行散列，得出一个MD5：500908fd00948ac2cc7b096315d41ff7，并直接将MD5发送给服务器。 同样，中间人也拦截到了，但是中间人并不知道这个MD5是什么，无法解密。 服务器收到后，从数据库读取用户的密码，用收到的随机数同样进行一次相同的散列过程，进行比较。 结果一致，OK，认证通过。 |
 |
46
LazyZhu 2015-08-02 19:34:13 +08:00
|
 |
47
7654 2015-08-02 19:42:22 +08:00
你需要“黑话”
|
 |
50
windyboy 2015-08-02 20:05:13 +08:00
证书是最简单有效的手段
|
 |
51
9hills 2015-08-02 21:29:06 +08:00 via iPad
自签名证书的私钥zf一句话拿到，那你换任何一种加密zf都能一句话拿到。
|
 |
52
kaneg 2015-08-02 21:47:45 +08:00 via iPhone
@chenshaoju 可是一般来说数据库中的密码都不会以明文保存，服务端如何以同样的方式做散列？
|
|
53
chenshaoju 2015-08-02 22:10:50 +08:00
@kaneg 太简单了，假设明文密码以md5形式存储，那么就再md5一下，比如：
md5("1234560cc175b9c0f1b6a831c399e269772661654321") |
|
54
benjiam OP |
|
58
9hills 2015-08-02 22:22:15 +08:00
|
 |
59
yajiedesign 2015-08-02 22:29:06 +08:00
如果根CA或者证书路径上的证书不可信.那么据我所知,要完全避免中间人攻击,安全可靠的只有量子密钥分发.其他办法也许看上去可行.但免不了有你我想不到的漏洞.
|
|
61
chenshaoju 2015-08-02 22:39:37 +08:00
@benjiam 那你说说吧，这种挑战认证，中间人能得到什么信息。最多只能得到两个随机数，以及混合了密码的散列值。
|
|
62
yajiedesign 2015-08-02 22:40:39 +08:00
@noli 量子密钥分发可以....虽然离进入千家万户还很远,但毕竟不是空想了.
|
|
63
yajiedesign 2015-08-02 22:43:07 +08:00
@chenshaoju 挑战认证没什么问题.然而只能认证,不能用来协商密钥啊...
|
 |
64
xierch 2015-08-02 22:49:31 +08:00
如果你有一个安全的信道，可以用它再确认一遍对方的证书。比如两个人面对面确认。
（Telegram 就是这样，它会根据 public key 生成一个图案，可以让用户肉眼辨认 那个「事后得到 private key 但无法破解之前截获的流量」的技术，叫 PFS，Perfect Forward Secrecy |
 |
65
Gandum 2015-08-02 23:18:21 +08:00 via iPhone
等到量子加密实际应用的时候，也许能够解决楼主的问题。通过量子加密发送密钥，然后根据量子纠缠判断这个密钥是否被监听，如果没有，则使用此密钥，否则就弃用当前密钥，并生成新密钥重新发送，直到发送成功为止。
但是这也只是也许，因为如果在不安全的信道中，你每一次发送都会被监控的话，那么密钥就永远发送不成功，量子加密也解决不了这个问题 |
|
66
yajiedesign 2015-08-02 23:29:21 +08:00
我之前表述有些不准确,应该说在面对高度掌握信道的攻击者时,量子密钥分发,有机会解决"中间人攻击"的问题.而不是已经解决了.现在已经有协议宣称可以抵御"中间人攻击",然而毕竟没有实战检验.
|
|
67
chenshaoju 2015-08-02 23:39:49 +08:00
@yajiedesign 怎么不能，直接用用用户的密码（或者散列后的密码），加上时间戳（年月日时分），再散列一下，等等作为信息作为密钥进行加密。
|
 |
69
wy315700 2015-08-02 23:49:39 +08:00
任何加密都有一个预置的信任关系为前提，证书恰恰是这种实体
|
 |
70
datocp 2015-08-03 00:04:05 +08:00 via Android
证书解密是有时效性的，花了大量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. |
|
71
benjiam OP 如同在非对称加密出现以前，我们认为这是不可能的一样。不过没用良好的数学基础，基本也就是痴人说梦了。
|
|
72
wy315700 2015-08-03 00:07:56 +08:00
|
|
73
wy315700 2015-08-03 00:10:47 +08:00
|
 |
74
breeswish 2015-08-03 00:21:32 +08:00
客户端与客户端之间建立点对点加密，使用 root CA（其实只要可以公钥私钥就行）确认加密请求可靠性，这样：
1, root CA 被破解了不会影响已经建立起来的点对点加密 2, 仅破解单个客户端不会影响其他客户端之间的通信 |
 |
75
jiongxiaobu 2015-08-03 00:22:39 +08:00 via Android
密码学原理欢迎你
|
|
76
breeswish 2015-08-03 00:22:43 +08:00
3, 在 root CA 被破解前客户端与客户端建立的点对点加密不会被 MITM 攻击
|
|
77
breeswish 2015-08-03 00:26:46 +08:00
@realpg 这个有人做了： http://priv.ly
|
|
78
breeswish 2015-08-03 00:33:29 +08:00
其实吧，这些非对称加密啊什么的..面对国家机器可能都是没什么用的，鬼知道灯塔国在加密算法里藏了多少后门呢..
体系中只要有一个后门，那整个体系就是不安全的，更何况灯塔国还到处都安插过后门——从最底层算法的依赖（如随机数），到算法相关（如曲线参数），到具体实现（如 OpenSSL 函数），可是都被藏过后门的…还有更多没有爆料出来的：我相信只要被 NSA 盯上了你的加密数据一定可以被解密 =。= |
|
80
kaneg 2015-08-03 08:34:56 +08:00 via iPhone
@chenshaoju 一般来说明文密码都要加盐后再做某种散列后存储，总不能让客户端知道盐是什么吧
|
 |
81
comicfans44 2015-08-03 08:35:45 +08:00
这更多的是个社会问题而不是技术问题，假如他们想知道，那探讨技术问题是没有意义的，直接约谈你就可以了，还是一句话。
但假如你还没那么惹眼，那么自定义的协议就好了，他们懒得（也不可能）去针对每一种自定义的协议。 |
|
82
realpg 2015-08-03 09:54:49 +08:00
@laotaitai
用这种技术的要么是涉及敏感(色情/政治)，要么是论坛。基本不靠吸引大众。那种搭个论坛拼命去拉流量，吸引人注册，拼命SEO的要么是管理欲变态(中国这种人特别多)，要么是想套现撸钱。 大众的东西基本我都不碰，有太多成型的网站、论坛没意思。我做的站东西基本上很多程度都有禁止将本站告诉给大众，禁止在外网发表链接到本站的链接，基本靠其他渠道获取，比如线下交流，比如真朋友关系介绍。你能知道有我的站存在，那你就达到门槛了，对于这种情况，我设置多复杂的限制（甚至有些里面会流传一些比较机密信息的我都强制给客户发ssl客户端证书）他们都可以理所当然的视为正常的一部分，别说个简单的扩展了。 早年其实很多人觉得禁止IE6不可实现，其实一点也不难。我早期也做过一些比较大众的网站，我就写明白了禁止IE6(后来chrome流传广泛+chrome壳浏览器多了以后直接IE核心给个不正常乱码，然后提示禁止IE)都不会流失用户，特别小白的用户也会去度娘知道问，为啥我访问XXX是错乱的，然后就会有人替我回答你去下载个firefox 后面附网址 访问就好了…… 前提是，你的站真有内容，别管大众小众，你的站真能吸引他们去看，去访问，去讨论，那就不怕。 而我自己做的非大众东西，从chrome版本号发展到20那一天就开始屏蔽IE访问了，后来，jquery2不支持IE旧版本我太高兴了，可以让IE这种逗比都不正常，都不用再去做额外分析限制了，反正jquery2跑不起来网站肯定不正常。 而且我的小圈子论坛，很多都是无管理的，靠大家VOTE实现管理的功能，狗操的管这个叫人民民主专政……反正因为有简单的防止旁路收集敏感词，哪怕有轮子在里面传教、贩卖军火都不怕，很快就会被人民民主专政掉，在专政掉之前，也不会被一些特定的监管采集到对网站造成关站等恶劣影响。 |
|
83
chenshaoju 2015-08-03 09:55:43 +08:00
|
|
84
wy315700 2015-08-03 10:27:00 +08:00 via Android
@chenshaoju
其实都一样，这里面的预共享秘钥其实就起到了证书的作用，只不过加密比较弱 |
|
85
laotaitai 2015-08-03 10:51:26 +08:00
@realpg 看样子你网站真的很牛逼! 估计市面上都不超过3个像你这样的网站. 我简单看了下你个人信息, 咱俩有点类似, 至少我也是FreeLancer, 也是不用第三方程序的站长. 握爪!
|
|
86
realpg 2015-08-03 11:16:07 +08:00
@laotaitai
2013年以前我还有做一些大众的东西，后来都放弃了或者转给他人维护了。 现在我自己做的东西都是给小众爱好者圈子的，我自己就是最重度的用户，大多数没有竞争对手，或者有竞争对手的情况下我还做这个是从用户体验出发他们的东西太难用了，我作为用户都受不了的时候我才自己做。而且我的用户有大半至少是跟我在某些方面能达到一个level的能混到一起去的，一些技术上的限制，教教就会了，都不缺学习能力。 其实我做网站，最大的原因就是我的服务器、带宽都不要钱，除了自己写代码外没有成本，没有挣钱压力，做的东西质量就好。我给很多公字头单位朋友做义务技术支持，往他们那里丢个三五十台服务器用个百八十兆带宽都不是事儿。 |
 |
88
caoyue 2015-08-03 12:26:27 +08:00
你从开始都不能保证客户端连接的服务器不是中间人，所以在此之后的一切机制都无效了吧
所以还是必须有证书，或者类似于证书的东西通过可信渠道交换才行 |
|
90
Smartype 2015-08-03 14:21:18 +08:00 via iPhone
@chenshaoju 这里的关键是密码如何可靠设置。这又是鸡和蛋的问题了。
|
|
91
benjiam OP 我认为这里有一个前提，客户端是可以有一张预设证书的，但是这张证书可能会丢失私钥。
目前的安全体系都无法安全的交换秘药，所以得靠证书认证，并保证，证书私钥不丢。 |
 |
93
fishioon 2015-08-03 17:02:20 +08:00
@chenshaoju 还有一个问题，客户端如何识别服务器？中间人模拟成服务器和你通信，你如何识别？
|
|
94
chenshaoju 2015-08-03 17:43:14 +08:00
|
|
95
fishioon 2015-08-04 13:30:08 +08:00
@chenshaoju 假如你要逛淘宝，中间人劫持了并冒充淘宝服务器，然后你连接到了中间人这边，然后你输入了账号密码，然后钱就木有了
|
|
96
chenshaoju 2015-08-04 13:36:09 +08:00
@fishioon 你最好仔细想想挑战认证的协商过程。你认为服务器和中间人会产生相同的随机数？
|
|
97
fishioon 2015-08-04 13:51:55 +08:00
@chenshaoju 就问认证通过了然后呢？你和服务端后续的通信内容需要加密吧，同时客户端与服务端需要对传输的内容解密吧！还有我冒充服务端与你通信，我直接告诉你认证通过啦，然后你就和我通信了？然后就传输了？你这个都防不了钓鱼
|
|
98
chenshaoju 2015-08-04 14:01:13 +08:00
@fishioon 可以啊，通信也是密文啊，你无法解密啊。看６７楼。
|
|
99
fishioon 2015-08-04 14:10:59 +08:00
@chenshaoju 明白了，你这种就相当于最开始就已经协商好了密钥（密码作为密钥），这样基本没啥意义了，整个安全系统最困难的就是如何协商并交换密钥
|
|
100
noli 2015-08-07 20:35:01 +08:00
|
Select Language