非对称加密与证书(上篇)
本文来自网易云社区。
SSL/TLS是一个密码学协议,它的目标并不仅仅是网页内容的加密传输。SSL/TLS的主要目标有四个:加密安全、互操作性、可扩展性和效率。对于安全性的保障,它还会从多个方面进行,包括机密性,真实性以及完整性。机密性是指,传输的内容不被除通信的双方外的第三方获取;真实性是指,通信的对端正是期待的对端,而不是其它第三方冒充的;完整性则是指,传输的数据是完整的,数据没有被篡改或丢失。为了平衡多种需求,SSL/TLS被设计为一个安全框架,其中可以应用多种不同的安全方案,每种方案都由多个复杂的密码学过程组成。不同的安全方案,在安全性和效率之间有着不同的取舍,并由不同的密码学过程组成。
在密码学上,非对称加密具有更高的安全性,同时计算复杂度更高,性能更差;而对称加密,则效率比较高,计算复杂度较低,但如果在通信过程中明文传输密钥,或将密钥以hard code的形式写在代码里,则安全隐患比较大。
从密码学过程的特性出发,整体来看,SSL/TLS连接是在会话协商阶段,通过 非对称加密 算法,如RSA、ECDHE等,完成身份验证,及后续用到的对称加密密钥的交换;在整个数据传输阶段,通过对称加密算法,如AES、3DES等,对传输的数据进行加密;通过数据散列算法,如SHA1、SHA256等,计算数据的散列值并随应用数据一起发送,以保证数据的完整性。
本文主要描述非对称加密的基本思想,及TLS的证书身份认证。
非对称加密
非对称加密 (asymmetric encryption) 又称为公钥加密 (public key cryptography),是使用两个密钥,而不像对称加密那样使用一个密钥的加密方法;其中一个密钥是私密的,另一个是公开的。顾名思义,一个密钥用于非公开的私人的,另一个密钥将会被所有人共享。
非对称加密的两个密钥之间存在一些特殊的数学关系,使得密钥具备一些有用的特性。如果利用某人的公钥加密数据,那么只有他们对应的私钥能够解密。从另一方面讲,如果某人用私钥加密数据,任何人都可以利用对应的公钥解开消息。 后面这种操作不提供机密性,但可以用作数字签名。
非对称加密保护数据安全
盗用阮一峰老师的几幅图来说明,通过非对称加密保护数据安全的过程。
-
鲍勃有两把钥匙,一把是公钥,另一把是私钥。
-
鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。
-
苏珊要给鲍勃写一封不希望别人看到的保密的信。她写完后用鲍勃的公钥加密,就可以达到保密的效果。
-
鲍勃收到信后,用私钥解密,就可以看到信件内容。
对于非对称加密,只要私钥不泄露,传输的数据就是安全的。即使数据被别人获取,也无法解密。
非对称加密的这些特性直击对称加密中只用一个密钥,而该密钥不方便传输、保存的痛点。它大大方便了大规模团体的安全通信,方便了安全通信在互联网中的应用。
非对称加密生成数字签名
数据的加密安全只是数据安全的一个方面,数据的真实性同样非常重要。经常可以看到这样的案例,骗子在同学参加四、六级考试的时候,给同学的家长打电话或发短信,声称自己是学校的辅导员,并表示同学病重急需用钱,要求家长汇钱,同学家长汇钱给骗子而遭受巨大损失的情况。这就是数据/信息真实性没有得到足够验证而产生的问题。
再比如,一个仿冒的taobao网站,域名与真实的网站非常相似。我们一不小心输错了域名,或域名被劫持而访问了这个仿冒的网站,然后像平常在taobao购物一样,选择宝贝,并付款,但最后却怎么也收不到货物。
现实世界中,常常会请消息的发送者在消息后面签上自己的名字,或者印章来证明消息的真实可靠性,如信件中的签名,合同中的印章等等。类似地,在虚拟的网络世界中,也会通过数字签名来确认数据的真实可靠性。数字签名依赖的主要算法也是非对称加密,生成数字签名主要是使用私钥加密 数据的散列摘要 来签名。
通过几幅图来说明这个过程。
-
鲍勃给苏珊回信,决定采用"数字签名"来证明自己的身份,表示自己对信件的内容负责。他写完后先用散列函数,生成信件的摘要(digest)。
-
然后,鲍勃使用自己的私钥,对这个摘要加密,生成"数字签名"(signature)。
-
鲍勃将这个签名,附在信件下面,一起发给苏珊。
-
苏珊收到信后,取下数字签名,用鲍勃的公钥解密,得到信件的摘要。
-
苏珊再对信件本身应用散列函数,将得到的结果,与上一步得到的摘要进行对比。如果两者一致,则证明这封信确实是鲍勃发出的,信件完整且未被篡改过。
如果鲍勃向苏珊借了钱,并用上面这样的过程写信给苏珊确认自己收到了钱,那么鲍勃就再也不能抵赖了——信件的末尾可是清清楚楚地签着鲍勃的大名呢。
如果我们的网络世界能像上图的过程那样,每个人都可以方便地获得可靠的公钥,那就太美好了。互联网上的网站成千上万,每个人都走到自己要访问的网站站长的办公室把网站的公钥拷走,或者网站站长挨个走到自己的目标用户家门口,把自己网站的公钥交给用户,那可就太麻烦,代价太大了。
公钥通常都是通过网络传输的。不怀好意的人,会试图干扰这个传输过程,将自己伪造的公钥发送给用户,进而破坏后续整个数据传输的安全性。如果用户拿到的是伪造的公钥,那签名也就形同虚设。
如道格想欺骗苏珊,他在鲍勃将公钥交给苏珊时拦住鲍勃,表示要替鲍勃转交。正好鲍勃有老板交待的其它重要事情要完成,于是就把自己的公钥交给道格请他帮忙转交。但道格把鲍勃的公钥丢进垃圾桶,而把自己的公钥交给了苏珊。此时,苏珊实际拥有的是道格的公钥,但还以为这是鲍勃的。因此,道格就可以冒充鲍勃,用自己的私钥做成"数字签名",写信给苏珊,让苏珊用假的鲍勃公钥进行解密。
证书
证书正是为了解决公钥的信任问题而引入。证书体系通过引入可信的第三机构,称为 证书签发机构(certificate authority,简称CA),为公钥做认证,来确保公钥的真实可靠。证书是经过了 CA 私钥签名的 证书持有者的公钥、身份信息及其它相关信息 的文件,用户通过 CA 的公钥解密获取证书中包含的 证书持有者 的公钥。只要 CA 的私钥保持机密,通过证书验证 证书持有者 的身份,及获取公钥的过程就可靠。
证书的工作过程
互联网PKI证书体系的结构如下图:
证书订阅人 ,也就是需要提供安全服务的人,向 证书中心 (CA) 的代理—— 登记机构 提交自己的公钥来申请证书。 登记机构 对 证书订阅人 的身份进行核实,然后向 证书中心 (CA) 提交 证书订阅人 的公钥及身份信息。 证书中心 (CA) 用自己的私钥,对 证书订阅人 的公钥、身份信息和其它一些相关信息进行加密,生成 "数字证书"(Digital Certificate) ,并发送给 登记机构。 登记机构 将证书发送给 证书订阅人 。 证书订阅人 将证书部署在Web服务器上。 信赖方,即安全服务的用户,维护 CA 根证书库,并在与Web服务器通信时,从服务器获得证书。 信赖方 用CA根证书验证接收到的证书的有效性,进而验证服务器的真实性。
同样通过几幅图来说明这个过程。
-
鲍勃去找证书签发机构,为公钥做认证。证书中心用自己的私钥,对鲍勃的公钥、身份信息和一些其它相关信息一起加密,生成"数字证书"(Digital Certificate)。
-
鲍勃拿到数字证书以后,就可以放心,以后再也没人能冒充自己了。再需要发送自己的公钥给朋友们时,只要把自己事先拿到的 数字证书 发送给朋友就可以了。需要写信给苏珊时,照常附上自己的数字签名即可。
-
苏珊收到信后,用CA的公钥解开数字证书,就可以拿到鲍勃真实的公钥,然后就能证明"数字签名"是否真的是鲍勃签的。
证书里有什么
PKI证书是 抽象语法表示一 (Abstract syntax notation one, ASN.1) 表示, 基本编码规则 (base encoding rules, BER) 的一个子集 唯一编码规则 (distinguished encoding rules, DER) 编码的二进制文件。我们通常看到的证书则是DER使用Base64编码后的ASCII编码格式,即 PEM (Privacy-enhanced mail) 这种更容易发送、复制和粘贴的编码格式的纯文本文件。
证书里到底都有些什么呢?这里我们通过一个实际的证书来看一下。我们可以通过openssl
解码数字证书,获得证书的可读形式:
$ openssl x509 -in chained.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 03:5c:25:82:1d:c2:b2:2f:6f:73:39:48:9c:68:07:1b:48:2d Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3 Validity Not Before: Oct 25 01:12:00 2016 GMT Not After : Jan 23 01:12:00 2017 GMT Subject: CN=www.wolfcstech.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit)
Modulus: 00:c3:92:70:78:ff:00:0a:22:c7:14:0b:3d:b3:26: 34:cb:37:63:26:1d:d6:42:7b:5c:ab:51:cc:f7:12: 57:26:b1:d1:4f:5f:a7:02:5b:3c:f3:e6:e1:ec:7c: 66:61:ba:d8:5e:d6:61:60:48:d6:d3:4c:23:9a:50: 75:4b:2d:1b:89:7d:7b:55:2f:12:63:b4:ac:c7:b5: d1:44:95:ed:a2:f4:9d:ee:77:3c:2b:06:48:d9:18: 21:d1:ee:cf:5c:26:ad:c2:11:28:9c:27:65:11:94: c4:1d:0f:5e:4c:4f:00:71:cf:5d:1f:40:4b:9a:5e: 3b:b0:42:45:c5:68:01:62:29:c2:92:b5:ad:8d:13: 11:db:7e:02:65:14:6a:5d:4b:66:16:08:d4:ab:90: dc:06:28:27:cd:84:c0:b7:30:22:ff:54:71:c2:3b: 8d:7d:8b:52:c3:a8:f1:ee:63:42:2a:dd:4d:a7:70: 66:c5:c3:54:d5:8e:a1:e2:02:d0:8b:2f:f6:44:1d: f5:f2:85:fd:49:c7:e0:d7:d0:ae:21:b7:25:ae:7c: 15:dc:56:51:45:f1:e7:19:d6:1c:95:2c:65:f7:34: 2c:67:1c:93:00:81:a7:e2:23:da:1a:3c:d1:9f:84: 5e:01:3f:71:e7:9c:cd:e0:4f:fc:db:a6:2f:33:3a: 3d:ce:6d:52:72:47:0b:08:9c:04:1f:4a:cd:cd:71: db:c2:3f:0d:9c:b4:24:ca:25:06:49:2b:40:a7:96: b6:60:b7:8d:c7:b0:b4:84:96:06:63:3b:d9:0c:25: 8d:af:ad:90:ce:b8:d5:c6:e6:28:28:bd:4b:72:92: 28:1a:0a:b7:15:3c:28:26:15:ab:fc:88:22:74:50: 77:cc:3d:a3:c8:be:83:14:3d:ca:0e:79:aa:71:66: 56:b8:6f:fe:2a:2d:36:ff:0c:af:b9:61:5c:5b:5f: a4:cc:0a:5b:13:31:c9:16:3f:51:9c:19:56:dd:06: 1d:c9:6f:f6:17:61:61:7b:4c:cb:aa:b9:92:52:25: 9b:8f:02:2d:51:39:5f:f0:89:e2:e8:25:6f:04:2a: d3:6f:a3:3e:a7:44:a8:a1:db:01:55:ad:1d:3f:72: 3a:9a:b7:0f:35:a3:de:d2:93:d7:7c:d6:12:66:b2: f9:da:c4:e3:e6:52:6f:55:07:5c:a2:57:0d:7a:ca: 20:5a:59:1b:78:ba:cf:e2:1d:b3:33:0a:53:2e:26: 9f:39:2f:ec:48:8b:9f:a0:b9:e8:e6:61:9b:89:34: 59:02:07:bb:b4:c4:8d:1d:24:72:ea:1e:7c:5f:a9: a3:96:15:e9:4d:7e:4c:94:eb:cb:af:d2:70:83:78: be:36:eb
Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: B8:27:0E:D4:47:BB:27:66:51:3B:E7:F9:8B:9C:48:2E:3D:FD:C8:97 X509v3 Authority Key Identifier: keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1 Authority Information Access: OCSP - URI:http://ocsp.int-x3.letsencrypt.org/ CA Issuers - URI:http://cert.int-x3.letsencrypt.org/ X509v3 Subject Alternative Name: DNS:wolfcstech.cn, DNS:wolfcstech.com, DNS:www.wolfcstech.cn, DNS:www.wolfcstech.com X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 Policy: 1.3.6.1.4.1.44947.1.1.1 CPS: http://cps.letsencrypt.org User Notice: Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/
Signature Algorithm: sha256WithRSAEncryption 46:a1:fb:1c:fe:6e:ef:af:fc:84:e3:7e:20:1d:c8:0c:0b:e4: d2:4b:9e:f6:bc:e5:31:59:08:bb:7e:0d:74:3f:e6:de:39:58: e2:f4:fa:bf:5c:26:86:96:19:8f:00:13:17:2b:4f:95:c4:bd: 02:ad:cd:a6:e5:80:21:f5:ee:e6:4d:01:86:07:82:37:5e:39: c9:55:40:ed:08:2e:8d:94:b8:86:2f:15:76:10:bd:97:46:06: b3:34:80:12:f4:dc:2a:2a:63:80:36:fe:ef:e1:9e:b6:dc:22: 51:c7:54:46:1a:b2:c5:e8:62:98:90:46:ea:92:8c:fd:d4:dd: 00:4f:fb:1e:25:24:93:c1:74:15:07:6f:67:d3:be:5b:47:7e: 18:56:02:01:55:09:fc:bf:7f:ff:27:fc:db:d8:53:55:02:43: 2e:a0:23:28:01:4d:4d:f9:bc:02:bc:fe:50:c2:67:d7:d4:48: 23:c2:0b:25:d4:65:e1:8f:3c:75:12:b6:87:b1:17:86:c8:1a: 26:72:0e:ba:07:92:c4:87:3e:e1:fc:e3:58:ef:a2:23:43:09: 85:c4:82:00:04:07:49:06:10:bc:fd:20:67:0f:63:f8:ff:bf: 7f:6f:da:72:77:51:1d:50:34:07:63:e8:68:e3:ef:70:5f:71: b4:11:9e:27
可以看到主要包含证书格式的版本号;证书的唯一的序列号;签名算法;颁发者的信息;证书的有效期;证书的使用者的信息、身份信息,在这里主要是几个域名;证书使用者的公钥等等。
Let's Encrypt证书申请
我们通过一个 Let's Encrypt 证书申请过程对证书做更多了解。 Let's Encrypt 是一个免费、自动化、开放的证书签发机构,目前它已得到了Mozilla,Chrome等的支持,发展十分迅猛。
证书申请
Let’s Encrypt 使用ACME协议验证申请人对域名的控制并签发证书。要获取Let’s Encrypt 证书,需使用ACME客户端进行。Let’s Encrypt 官方推荐 使用Certbot这个功能强大,灵活方便的工具,不过也可以使用其它的ACME客户端。
这里我们通过Certbot申请Let’s Encrypt证书。
Certbot安装
对于在Ubuntu 14.04平台上部署nginx提供Web服务的情况,应该使用 certbot-auto 来安装:
$ wget https://dl.eff.org/certbot-auto
$ chmod a+x certbot-auto
certbot-auto 接收与 certbot 完全相同的标记;不带参数执行这个命令时,会自动安装依赖的所有东西,并更新工具本身。执行如下命令:
$ ./certbot-auto
相关阅读:非对称加密与证书(下篇)
网易云SSL证书服务提供云上证书一站式生命周期管理,与全球顶级的数字证书授权机构(CA,Certificate Authority)和代理商合作,为你的网站与移动应用实现 HTTPS 加密部署。
网易云新用户大礼包:https://www.163yun.com/gift
本文来自网易实践者社区,经作者韩鹏飞授权发布。