博客家

使用SSL感到安全吗?再想想。

jbaruch

通过jbaruch

10分钟阅读

最近，我们听到了很多关于我们对公共二进制存储库的信任的讨论。例如，由Sonatype维护的一个流行的遗留存储库Maven Central，最近被一次成功的MITM攻击所破坏．作为回应,Sonatype设置了https访问中心(取消了为使用SSL向Apache基金会捐款10美元的要求)。这对世界上数百万的maven安装没有影响，它们将继续通过http访问maven Central，除非手动重新配置，但有趣的问题是-这就够了吗?

虽然SSL在保证下载文件的完整性方面很重要，但它并没有说明存储库本身中文件的完整性。Maven Central和其他遗留存储库建议您盲目信任的存储库本身中唯一的(!)验证机制是随文件上传的签名文件集。有趣的是，现代存储库，如RubyGems.org，npm-registry而且Bintray不要强迫你在文件上签字。让我们试着理解为什么。

这是tl,博士如果你需要的话。

SSL访问是否足以让我们感到安全?

要回答这个问题，让我们考虑Maven Central。这是一个使用SSL并使用PGP签名“保护”文件的存储库。理论上，这些签名文件强烈地标识了签名者(假设jar文件和签名都是通过SSL提供的)。但事实真的如此吗?

让我们看看它是如何工作的:

  • 作者使用了gpg工具生成用于识别的对。
  • 然后，作者将公钥上传到可信密钥服务器(其中之一)麻省理工学院，SKS OpenPGP公钥服务器或PGP全球目录）.
  • 任何想要下载包并验证其完整性的人都可以对其中一个服务器运行签名检查，并获得作者的唯一且已验证的身份。

是这样吗?

让我们运行几个实验，看看“安全的”Maven Central是如何安全地维护的。

以下是Sonatype最新的一款罐子:nexus-core-2.8.1-01．

下载下来看看签名写了什么，在导入签名者的公钥之后：

> gpg nexus -核心2.8.1发布- 01. jar.ascgpg:使用DSA密钥ID 8DD1BDFD在中央夏令时05/27/14 18:00:54进行签名gpg:来自“Sonatype, Inc. (Sonatype释放密钥)”的良好签名gpg:警告:此密钥未使用可信签名进行认证!gpg:没有迹象表明签名属于所有者。主密钥指纹:2BCB DD0F 23EA 1CAF CC11 D486 0374 CF2E 8DD1 BDFD

哇!发生了什么事? !"没有迹象表明签名是主人的"

等一下。这是否意味着任何人都可以生成一个对Sonatype, Inc. " (Sonatype发布密钥) "假装是Sonatype发布团队?

这里有一张惊人的照片:

heinrichh@uni-duesseldorf.de
点击查看

Hiene编写代码

根据“可信”密钥服务器，所有这些签名都属于德国诗人海因里希·海涅．我得说这不太可能因为他已经去世很久了1．

让我们再运行几个测试(想想，也许只有Sonatype不能生成“真正可信”的签名):

这是一个签名Eclipse构件：

> gpg aether-1.0.0.v20140518-source-release.zip.ascgpg:使用DSA密钥ID A7FF4A41进行的中央夏令时05/18/14 12:54:52签名gpg:来自“Benjamin Bentmann (CODE SIGNING KEY) ”的良好签名gpg:警告:此密钥未使用可信签名进行认证!gpg:没有迹象表明签名属于所有者。主键指纹:BA92 6F64 CA64 7B6D 853A 3867 2E20 10F8 A7FF 4A41

一样了!

这是Oracle的OpenJDK工具：

> gpg jmh-core-0.9.5.jar.ascgpg:签名made 07/24/14 13:53:36 Central Daylight Time使用RSA密钥ID 060CF9FAgpg:来自“Evgeny Mandrikov (CODE SIGNING KEY) ”的良好签名gpg:警告:此密钥未使用可信签名进行认证!gpg:没有迹象表明签名属于所有者。主键指纹:A413 F67D 71BE EC23 ADD0 CE0A CB43 338E 060C F9FA

谁是叶夫根尼·曼德里科夫?甲骨文员工?不．他为什么用gmail?我想想，也许Sonatype在给他进入Maven中心的权限时对他进行了预先验证?他和甲骨文公司建立了关系吗?什么都没有，一个问题都没有。“我和Oracle没有任何关系，但仍然想发布OpenJDK工件!“好的，去吧。”您能信任他为您提供真实的OpenJDK工件吗?不确定2．

你懂的。你不能相信那些自己生成的密钥对。可信密钥服务器自己也承认这一点!这里引用一段PGP全局目录密钥验证策略：

…总有一个风险，即PGP全球目录中的验证密钥实际上并不属于看起来拥有它的人。虽然目录中的验证机制适用于许多目的，但您应该努力使用其他机制…

这正是现代存储库所喜欢的Bintray而且GitHub做的。但我们很快就会讲到。

但是WoT呢?

”啊，有人会说，那是因为你根本不知道PGP签名是如何工作的!你需要建立一个信任网络有了签名者，瞧，信息消失了!”

虽然在技术上是正确的，但这在我们的环境中没有什么意义。

WoT对pgp签名的原始用法进行了验证——对你直接或间接认识的人的内容进行验证。例如，它用于签署电子邮件。你可能会收到来自第一圈、第二圈或第三圈的人的邮件，但几乎不会收到完全陌生的人的邮件。对于来自Internet存储库的包，这个概念完全被打破了。开发人员亲自知道包的创建者的可能性接近于零，即使是间接地了解到一两个级别。同样适用于包的创建者。作为作者，您不知道谁将使用您的包。你只能希望他们是一群你不认识的陌生人: - d。

我很好奇。告诉我如何在不使用MITM的情况下恶意上传一个伪造的神器到Maven中心!

乏味，但直截了当:

  1. 编造一个假身份(用一个假的，但有用的电子邮件地址)。
  2. 为它生成一个对偶。
  3. 上传到公钥服务器(这是需要你的电子邮件的地方)。
  4. 遵循该指南．最棘手的部分是编造一个关于您的工件的故事，通过Sonatype JIRA在oss.sonatype.org上设置您的帐户。嗯，要有创造力!
  5. 在几个小时(或几天)内，您的工件将被送到Maven中心。如果你发明的描述看起来足够真实，就不会有人问问题。在上传和发布文件过程中的某个地方，Sonatype将检查您为工件签名的签名是否与您用于oss.sonatype.org帐户的电子邮件相匹配。当然，它们是匹配的。
  6. 到Mazal Tov !你们的假藏物现在在Maven中心。从那里，它们将安全(!)通过SSL由Maven下载到您的受害计算机。

容易吗?其实不是。看来MITM的攻击更简单。但这就是向Maven中心添加一个罐子所需要的。
可行的吗?绝对的。

但是Bintray有什么不同呢?

我们意识到，在现代社会，身份盗窃是最常见的犯罪之一，你不能盲目相信一个网络身份。因此，像许多其他服务一样，我们建议您根据社区给予作者的互联网身份的信用来评估任何特定内容(在我们的例子中是一个罐子)的可信程度。

我的意思是:

假设您想下载Groovy。在这儿。让我们看看如何在Groovy二进制文件中建立信任:

那么，你能相信他吗?可能。他是Groovy组织的管理员，因此他的声誉保证了该组织及其中的文件是真实的。你可以出发了。或不呢?

这取决于你!我们给你信息。你决定是否相信它。

但是Maven只是出去带东西!

打造一个安全的你必须使用内部二进制存储库管理器:

  1. 安装它。
  2. 配置一个“脏的”和一个“干净的”存储库。
    1. 脏存储库应该能够代理工件的远程源，使您能够很好地了解工件生产者的身份(而不仅仅是一堆带有自生成签名的文件)。
      考虑代理Bintray的文件JCenter而不是Maven中心。JCenter是Maven Central的超集，因此查找包不是问题。
    2. 干净存储库是没有Internet访问的本地存储库。
  3. 配置您的构建工具(Maven?)，以便能够针对它们中的任何一个进行构建。
  4. 使用“沙盒”(例如虚拟机)对脏库运行“脏”构建。它的缓存将填充构建所需的所有工件。
  5. 检查那些工件的发布者的身份(记住选择一个二进制存储库生成用于每个构建的依赖项列表)与你所拥有的关于他们的信息(如你所知，最好不只是自我签名)。
  6. 将您信任的工件提升到干净的存储库(请记住选择二进制存储库删除处理存储这为您提供了自由和即时的“移动”操作)。
  7. 现在您可以在干净的存储库上安全地构建了!

以下是摘要(又名tl;dr):

  1. SSL是一种重要的方法，用于验证您信任的文件是否安全地从服务器传输到您的计算机。
  2. 不要让SSL给您一种信任文件的起源或作者的错误感觉。
  3. 不要盲目相信自己签发的签名。用户可以为任何身份生成签名，为任何文件签名，并将其上传到Maven Central。
  4. 选择一个支持并鼓励网络身份验证的平台。查阅作者并自行决定。
  5. 使用二进制存储库管理器来发现和控制所需的工件(并明智地选择它)。

了解更多JFrog和Sonatype比较起来怎么样．

1一个gpg工具与PGP签名一起工作是在杜塞尔多夫海因里希海涅大学．为了纪念已故诗人海因里希·海涅(Heinrich Heine)，该工具中的所有默认值都初始化为海因里希·海涅(Heinrich Heine)，并期望人们将它们替换为自己的详细信息。显然，这并没有起作用。人们只是在设置中输入-输入-输入，为可怜的德国人生成数十个密钥对，这说明了“真实的”、自我生成的密钥对是荒谬的。
谢谢你，海因里希!

2事实上，你可以。Oracle不分发OpenJDK的二进制文件，Evgeny是自愿的，并被OpenJDK提交者授权为他们做这件事。
但你能在不熟悉叶夫根尼的情况下知道吗!不，你不能。

受欢迎的标签

试试JFrog平台

在云端或自托管

开始试验

或预约演示