问一个 git gpg 公钥 分发的问题,再问一 ssh 私钥保存的问题

2016-04-20 10:10:05 +08:00
 sunjourney

问题一: SF 毕竟冷清,提了好几个问题无人解答,愿意在 SF 上解答的移步 git-scm 上提供的 gpg 公钥分发方式似乎不可以防止内容伪造吧?

重复下问题,使用 git-scm 上 https:/git-scm.com/book/zh/v2/分布式-Git-维护项目#为发布打标签 设计的公钥分发方式,遇到伪造者用他的私钥加密,用 tag annotate 发布假公钥,再伪造内容,根本无解啊?

你说用指纹?指纹发布在 site 上吗,那我何不在 site 上直接写公钥?

问题二: ssh 的私钥明文存储在 ~/.ssh/ 下,要 private key 的 passphrase 又有何用?

2266 次点击
所在节点    问与答
11 条回复
BOYPT
2016-04-20 10:13:44 +08:00
1 没看懂
2 加密了的 key 不是明文。
AstroProfundis
2016-04-20 10:21:32 +08:00
1. 实现你说的那种情况,前提是网页或其他某个地方公布的公钥、和签名提交用的公钥,都被攻击者替换成自己的,概率比单点爆破低很多;当然不能说不存在

2. passphrase 是在有人拿到了你的私钥文件的情况下提供的最后一层遮羞布
sunjourney
2016-04-20 10:25:47 +08:00
@BOYPT 第二个问题取消,我弄错了, private key 是加密的,我之前以为是未加密的,第一个问题是 git-scm 提供的一个分发设计,原理是把 pubkey 放到一个有 annotate 的 git tag 下,传到 remote 上, 使用者只要 git show 一下这个 tag 的 annotate ,就知道 gpg pubkey 了,实现分发
AstroProfundis
2016-04-20 10:25:59 +08:00
@AstroProfundis 又看了一遍,我也不确定我是不是看懂了你第一个问题... “只能靠发布公钥指纹在站点上可以防止这点” 网站也可以被黑啊,按这种极端推论的话...

另外,理论上只要公钥发布出来的第一时间是发布者本人的那一个,然后别人存下了这个公钥,后面发现签名的公钥变成了另一个而发布者本人没有公布过“以上一个公钥签名的表示更换为下一个公钥的申明”,就可以认为有问题了

至于怎么保证第一个公钥确实是发布者本人持有, WoT 就是专门解决这个问题的
sunjourney
2016-04-20 10:33:04 +08:00
@AstroProfundis 你的意思是:使用者要保证安全,还是要在 site 上看公钥,再看 tag 里的公钥,两个一致的情况下还是伪造的可能性只有 site 被 hack , git 被恶意提交了,发生这样事情的概率要很低?

可如果 签名没有被 fake ,发布者在 site 上伪造 pubkey 的意义一点都没有。 git-scm 上的问题在于,公钥和内容都用 git pull 下来,没有分开。
shiji
2016-04-20 10:44:39 +08:00
1. 这个跟 git 没关系,是 GPG 的事,你可以看这个:
http://security.stackexchange.com/questions/62791/pgp-gpg-verifying-authenticity
更多可以参看这里: https://www.gnupg.org/gph/en/manual.html#AEN385
即便是一般的安全证书,在没有预置 CA 的情况下,并且在和对方没有见过面(交换公钥)的情况下,你永远都不能得知和你通信的那个人究竟是不是真的。 gpg 靠的也是信任网。

2. 那个密码能加密你的私钥,这样即使你这个文件被坏人通过各种手段偷走了(按理来说不应该被轻易偷走,这密码是最后一道防线了),你也能有三五天的时间更换密钥对。(比如用于登录 ssh 的 authorized keys , git 的公钥等等) 前提是你的密码够复杂。
有的时候,比如在 osx ,系统在 keychain 里面帮你记住这个私钥密码,所以会造成这个密码没用的错觉。
sunjourney
2016-04-20 10:50:50 +08:00
@shiji @AstroProfundis 我提出的问题是 git-scm 设计的分发方式没有解决公钥分发方式,过度设计,还是得依靠 CA 、网站等。伪造者如果只能伪造内容,或是 hack 网站,只能实现其一,内容都是安全的。但 hacker 在 hack 到了你的机器,提交了假的内容并用他的的 gpg 签名,同时用 git-scm 的方式发布他的公钥,其它人 pull 下来的就是伪造的了。

1 ,如果网站有公钥且网站没有被 hack ,其它人可以比对破之,但既然要比对,那我为何不就信任网站的公钥呢?见 2 。
2 ,在 1 的前提下,网站既然可以发布公钥,使用者就没必要用 git-scm 的方法获取公钥了,因为网站公钥必然是有效的(网站与机器分离,网站就算被 hack ,假公钥也不能通过验证),只看网站即可。

第二问题是我搞错了,已明白理解,感谢!
AstroProfundis
2016-04-20 10:59:59 +08:00
@sunjourney 论 GPG 公钥签名的重要性

如果我攻破某个仓库,在里面放了我伪造的公钥,但我却没办法伪造发布者真正公钥上的各种交叉签名
可以粗暴(并且不严谨)地解释为:没有和他人交叉签名的 GPG 公钥,其可信度和自签名的 SSL 证书一样,随缘
sunjourney
2016-04-20 11:24:09 +08:00
@AstroProfundis pro git 提供这样自验证的方案,一点也不 pro 。
sunjourney
2016-04-20 11:40:14 +08:00
@AstroProfundis 嗯,觉得是个烂设计,已经在 pro git 的 repo 上发 issue 去 讨论了,看看有没有什么玄机是我没看出来的。 pro git 这么不 pro ,有点怀疑自己也怀疑作者了
AstroProfundis
2016-04-20 11:49:29 +08:00
@sunjourney 要我说的话,这个只是解决公钥分发方便的问题,安全性校验是交给 PGP/GPG 本身了,于是真正管用的唯一手段是保证自己的公钥在 WoT 网络中并有足够的交叉签名以显得可靠(伪造难度较高,但通过一些社工手段显然还是可以伪造)

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/272452

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX