GoLang：你真的了解 HTTPS 吗？

智库百科对数字证书的解释是：

抓重点：数字证书用于主体身份验证。

首先，数字证书=主体信息+数字签名。

Windows 下，我们可以在 Chrome 浏览器上点击地址栏的“锁”标记后会出现下拉框，接着点击“证书”即可看到通过 HTTPS 访问该服务器时的数字证书。具体操作如下：

证书“常规”页面，是关于该证书的一个笼统介绍，包括签发该证书的 CA 机构、该证书绑定的域名(颁发给)、证书有效期。

证书“详细信息”页面，以键值对形式展示了这张证书的完整内容。(后文将详细介绍证书内容)

证书的“证书路径”，以层级结构展示了从该证书绑定的域名一直到根证书的路径，这就是证书链。(后文会展开介绍证书链)

看完了 Chrome 浏览器上的证书，在让我们通过 Wireshark 抓包来来看看数字证书：

对比 Chrome 上看到的数字证书和 Wireshark 抓包得到的数字证书，可以看到两者呈现的证书内容是一致的。总结来看，一张完整的数字证书包括：

主体的必要信息：版本(version)、序列号(serialNumber)、签名算法(signatureAlgorithm)、颁发者(issuer)、有效期(validity)、使用者(subject)、公钥信息(subjectPublicKeyInfo)

主体的扩展信息(extension)：如密钥标识符、证书策略等

数字签名(signature)，也称指纹

抽象为下图：

2.  为什么是数字证书呢?

HTTPS 已经对通信数据进行了加密，为什么还要验证身份?说好的“人与人之间最基本的信任呢?”

这还不是因为各路黑客、骇客们总是在制造各种攻击吗?(捂脸)其中一个大名鼎鼎的中间人攻击(Man-In-The-Middle Attack，MITM 攻击)，简单的讲，“中间人”在客户端和服务端都不知情的情况下，夹在双方之间窃听甚至篡改通信信息，过程见下图(图引自《HTTPS 中间人攻击实践(原理·实践)》)：

在 HTTPS 的握手阶段，一端向对端发送请求，对端返回自己的公钥;而一端未验证对方的身份和公钥，直接协商密钥。“中间人”看到了这个漏洞，夹在中间截获了对端的公钥，替换成了自己的公钥。正是这步“拿错了公钥”或者说“信错了对端”，使得 HTTPS 为加密(密钥协商的非对称加密和通信数据的对称加密)所做的努力全部泡汤。

可见，在 HTTPS 中，“确保对端身份正确”即“确保拿到的公钥正确”，而在网络通信中所谓的“身份”，一般指的是通信一端的域名、IP 地址甚至是Mac 地址。所以，数字证书同时包含了通信一端的身份信息和公钥信息。

但是数字证书会在网络中传输(由被要求验证身份的一端通过网络传给另一端)，这就意味着证书也可能会被窃取篡改。这个时候权威的 CA 机构就出马了，他想了个办法：加了一个“防伪标识”— 数字签名。具体做法如下：

signature = RSA(PriKey_CA, Hash(message)) 

这里啰嗦几句：数字签名生成过程是首先对原文作哈希，把一段不定长的文本映射成固定长度的字符空间，接着再用 CA 机构的私钥对这段定长字符做加密。大大提高了整体的运算效率。

3. 证书是怎么工作的?

要了解证书是怎么做“身份验证”，即“防冒充”，得从 2 个角度来说明：

申请证书，即需要被验证身份的一端，需要申请一份能够验证自己身份的证书

验证证书，即需要验证对方身份的一端，拿到证书后验证对端的身份

请注意，这里有一个前提：这张证书必须是由权威 CA 机构颁发的，且尚在有效期内;或者是一张信任的私人证书。

(1) 申请证书

CA 机构和证书的分类本文不讨论，这里我们讨论正规权威 CA 机构签发的证书，至于是 DV、OV 还是 EV，只是安全强度问题，工作原理是一样的。

总结申请证书的过程：用户向 CA 机构提交自己的信息(如域名)和公钥(用户自己生成的非对称加密公钥，用于 TLS 握手阶段和另一端协商密钥用)，CA 机构生成数字证书，如下图：

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!