BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

如何构建私有公钥基础设施

| 作者 谢丽 关注 8 他的粉丝 发布于 2015年6月30日. 估计阅读时间: 14 分钟 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

相当复杂的现代Web服务大多数都不是由单体应用提供。为了处理复制的操作,应用程序通常被分解成许多服务,分别处理业务逻辑或数据存储的不同部分。这些服务可能部署在不同的机器甚或是不同的数据中心。在CloudFlare,随着服务的增加,应用程序之间安全通信的需求也在增长。他们需要一种简单、可维护的方法来确保CloudFlare内部服务之间的所有通信都始终处于安全保护之下。因此,他们基于已知且可靠的协议构建了一个这样的系统。该系统基于一个“公钥基础设施(public key infrastructure,缩写为PKI)”,使用了内部托管的认证中心(CA)。近日,CloudFlare系统工程师Nick Sullivan介绍了私有PKI构建过程和内部使用方式。

他们的方法是所有的新服务都使用一种同加密协议——传输层安全(TLS)协议——保护服务间通信。这是一种很自然的选择:HTTPS中的“S”就是TLS,它是Web加密的基础。而且,现代Web服务和API均以TLS作为应用层加密事实上的标准。它可以与RESTful服务无缝集成,并获得了Kyoto TycoonPostgreSQL和Go标准库的支持。另外,Nick在先前发表的一篇文章中讨论过,未经身份验证的加密可能遭受中间人攻击。也就是说,加密但不做身份验证无法在传输中保护数据。为了连接安全,每个连接方都必须向另一方提供身份标识。公钥加密技术提供了许多种信任机制,包括PGP的“信任网络(web of trust)”和HTTPS的公钥基础设施模型。由于更易于使用和部署,他们选择了PKI,由它和TLS一起提供可信任的通信。

PKI借助数字证书和公钥加密技术提供可信任的网络身份。通常,证书就是一个包含如下身份信息的文件:

  • 证书所有组织的信息
  • 公钥
  • 证书颁发组织的信息
  • 证书颁发组织授予的权限,如证书有效期、适用的主机名、用途等
  • 使用证书颁发组织私钥创建的数字签名

每个公钥都有一个对应的私钥,后者在证书所有者的管控之下,可以用于对数据进行数字签名,验证器可以使用证书中的公钥对数据进行验证。如果证书本身包含第三方认证中心的数字签名,那么只要验证器信任该第三方,就可以确保证书是合法的。有时候,证书是由中介认证中心签名,而中介认证中心的证书又是由不同的认证中心签名。在这种情况下,证书验证器会沿着这条链一直找到它信任的证书。对于认证中心而言,信任链模型非常有用,它允许我们将根证书的私钥离线存储,只为中介证书签名。中介认证中心的正式存在时间较短, 可以为端点证书签名。

这与Web上HTTPS使用的系统相同。但对于不需要通过浏览器访问的内部服务,就没有必要通过第三方认证中心。也就是说,受信任证书不必由GlobalsignComodoVerisign或其它认证中心颁发,它们可以由你自己的CA颁发。

创建自己的认证中心(CA)

为了创建一个可以轻松获取和操作证书的内部认证中心,他们使用了自己开源的PKI工具箱CFSSL。该工具具有运行一个认证中心所需的全部功能。虽然CFSSL是为运行内部CA而创建,但它足够健壮,可以用于公开的受信任CA。实际上,Let’s Encrypt项目就使用CFSSL作为CA基础设施的一个核心部件。

运行认证中心需要一个CA证书和相应的私钥。后者是极其敏感的数据。任何知道私钥的人都可以充当CA颁发证书。因此,私钥的保护至关重要。CFSSL支持以下三种私钥保护模式:

接下来,我们将沿着Nick的思路看下如何使用纯文本私钥快速配置一个内部CA。

生成CA证书和私钥

创建一个包含如下组织基本信息的文件csr_ca.json

{
  "CN": "My Awesome CA",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
    "names": [
       {
         "C": "US",
         "L": "San Francisco",
         "O": "My Awesome Company",
         "OU": "CA Services",
         "ST": "California"
       }
    ]
}

执行下面的命令:

$ cfssl gencert -initca csr_ca.json | cfssljson -bare ca

该命令会生成运行CA所必需的文件ca-key.pem(私钥)和ca.pem(证书),还会生成ca.csr(证书签名请求),用于交叉签名或重新签名。

配置证书生成策略,并启动CA服务

配置证书生成策略,让CA软件知道颁发什么样的证书。下面是一个简单的示例:

config_ca.json  
{
  "signing": {
    "default": {
      "auth_key": "key1",
      "expiry": "8760h",
      "usages": [
         "signing",
         "key encipherment",
         "server auth"
       ]
     }
  },
  "auth_keys": {
    "key1": {
      "key": <16 byte hex API key here>,
      "type": "standard"
    }
  }
}

该策略指定了证书有效期(1年)、用途(服务器验证等)以及一个随机生成的私有验证密钥。该密钥可以防止未经授权的机构请求证书。

执行下面的命令,启动CA服务:

$ cfssl serve -ca-key ca-key.pem -ca ca.pem -config config_ca.json

证书生成与签名

截止目前,基于CFSSL的CA已经配置完成,不妨假设它运行在服务器“ca1.mysite.com”上。该CA如何颁发证书呢?CFSSL提供了两个命令:gencertsigngencert将自动处理整个证书生成过程。该过程需要两个文件,一个告诉CFSSL本地客户端CA的位置以及如何验证请求,另一个为CSR配置信息,用于填充CSR。下面是为一个为数据库服务db1.mysite.com创建证书的例子:

config_client.json

{
  "signing": {
    "default": {
      "auth_key": "key1",
      "remote": "caserver"
    }
  },
  "auth_keys": {
    "key1": {
    "key": <16 byte hex API key here>,
    "type": "standard"
    }
  },
  "remotes": {
    "caserver": “ca1.mysite.com:8888"
  }
}

csr_client.json

{
  "hosts": [
        "db1.mysite.com"
  ],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "San Francisco",
      "O": “My Awesome Company",
      "OU": “Data Services",
      "ST": "California"
    }
  ]
}

有了这两个文件就可以使用下面的命令为数据库服务器db1.mysite.com创建证书了:

$ cfssl gencert -config config_client.json csr_client.json | cfssljson -bare db

前面已经提到过,该命令会生成三个文件,其中db-key.pemdb.pemdb.csr,其中db.csr可以再次提交给CA,使用sign命令重新签名:

$ cfssl sign -config config_client.json db.csr | cfssljson -bare db-new

该命令会生成新证书db-new.pem。这两个命令使私有PKI搭建变得非常容易和便利。

使用PKI

为应用程序生成证书和密钥有两种方式:集中式和分布式。前者是指预先配置好一台中央服务器,由它创建所有的证书并发送给每台应用程序服务器;后者是指由应用服务器创建自己的私钥,并向验证中心发送证书申请。按照Nick的说法,在第一种方式中,中央服务器管理复杂,而且向应用服务器传输私钥会引入不必要的风险。相比之下,第二种方式可以按需申请证书,非常易于扩展。

确立服务之间的信任关系

浏览器通过检查证书签名以及根据“主题备用名称(Subject Alternative Names,缩写为SAN)”列表检查主机名来验证网站证书。这种显式检查有用,但可能会出现不正常情况。另一种使服务相互信任的方式是基于单服务CA的隐式检查,其思想很简单:每组服务使用不同的CA。比如,由数据库CA颁发所有数据库的证书,由API服务器CA颁发所有API服务器的证书。

当这些服务彼此间使用相互TLS验证进行通信时,将信任关系配置为:

  • API服务器只信任DB CA
  • DB服务器只信任API CA

配置完成后,A类型的服务将只能和B类型的服务通信。下图描述了两个应用程序如何使用相互TLS验证确立相互信任关系:

如上图,API 服务器信任DB CA(红色)。因此,它只接受由DB CA(带红丝带)签名的证书。反之,数据库服务器只接受由API CA(带橙丝带)签名的证书。为了建立一个受信任连接,双方互相发送一个“密钥共享(key share)”,并用它们的私钥签名。密钥共享合并到一起创建一个会话密钥,会话双方用它加密数据。

将PKI用于远程服务

内部PKI非常灵活,可以用于向集成到PKI所在网络的第三方发放证书。例如,CloudFlare有一个名为Railgun的服务,可以用于优化CloudFlare与源服务器的连接。Railgun与CloudFlare之间的通信就是使用CloudFlare认证中心颁发的证书进行加密与身份验证。这可以确保数据传输安全。

小结

实现应用程序层数据安全是确保分布式系统架构安全的重要一步,但只有在有一个强大的PKI时才能实现真正有效的安全防护。


感谢徐川对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群InfoQ好读者)。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT