超详细https握手与数字签名讲解

以前看过不少https相关内容，感受都是有个大概印象。趁着刚阅读《http权威指南》后，发表一下本身的理解。若是我有讲的不对的地方，麻烦你们帮我指点出来，阿里嘎多～

其实我也不知道从哪里开始讲起，咱走一步算一步吧哈哈哈哈哈哈。

总览

大部分困难的编码及解码工做都是在 SSL 库中完成的，因此 Web 客户端和服务器在使用安全 HTTP 时无需过多地修改其协议处理逻辑。在大多数状况下，只须要用 SSL 的输入 / 输出调用取代 TCP 的调用，再增长其余几个调用来配置和管理安全信息就好了。 

对称密钥与非对称密钥

 相比之下，对于对称密钥加密技术，128 位的密钥被认为是很是强大的。实际上， 长密钥对密码安全有着很是重要的影响，美国政府甚至对使用长密钥的加密软件实 施了出口控制，以防止潜在的敌对组织建立出美国国家安全局(National Security Agency，NSA)本身都没法破解的秘密代码。 基本上能够理解为，用128位的密钥黑客基本GG了。

对称密钥加密技术的缺点之一就是发送者和接收者在互相对话以前，必定要有一个共享的保密密钥。每对通讯实体都须要本身的私有密钥。若是有 N 个节点， 每一个节点都要和其余全部 N-1 个节点进行安全对话，总共大概会有 N2 个保密密钥: 这将是一个管理噩梦。非对称加密不只更安全，并且还减小了服务器端的压力，由于它不用再记住它和每一个客户端的秘钥。

RSA 算法就是一个知足了全部这些条件的流行的公开密钥加密系统，它是在 MIT发明的，后来由 RSA 数据安全公司将其商业化。即便有了公共密钥、任意一段明文、用公共密钥对明文编码以后获得的相关密文、RSA 算法自身，甚至 RSA 实现 的源代码，破解代码找到相应的私有密钥的难度仍至关于对一个极大的数进行质因 数分解的困难程度，这种计算被认为是全部计算机科学中最难的问题之一。所以， 若是你发现了一种可以快速地将一个极大的数字分解为质因数的方法，就不只可以 入侵瑞士银行的帐户系统，并且还能够得到图灵奖了。

（还作什么程序员，不如去研究一下RSA穷其一辈子说不定和毕加索同样永垂不朽了）

但公开密钥加密算法的计算可能会很慢。实际上它混合使用了对称和非对称策略。 好比，比较常见的作法是在两节点间经过便捷的公开密钥加密技术创建起安全通讯， 而后再用那条安全的通道产生并发送临时的随机对称密钥，经过更快的对称加密技 术对其他的数据进行加密。-----------没错就是https.

还在混淆数字证书和数字签名吗？

数字证书

数字证书(一般被称做“certs”，有点像 certs 牌薄荷糖)中包含了由某个受信任组织担保的用户或公司的相关信息。 咱们每一个人都有不少形式的身份证实。有些 ID，好比护照和驾照，都足以在不少场合证实某人的身份。例如，你能够用美国的驾照在新年前夜搭乘前往纽约的航班， 在你到那儿以后，接着用它来证实你的年龄，这样你就能和朋友们一块儿喝酒了。

受信程度更高的身份证实，好比护照，是由政府在特殊的纸上签发并盖章的。很难 伪造，所以能够承载较高的信任度。有些公司的徽章和智能卡中包含有电子信息， 以强化使用者的身份证实。有些绝密的政府组织甚至会对你的指纹或视网膜毛细血 管模式进行匹配以便确认你的 ID ! 

数字证书主要内容：

数字证书一般还 包括对象的公开密钥， 以及对象和所用签名算法的描述性信 息。任何人均可以建立一个数字证书，但并非全部人都可以得到受人尊敬的签发 权，从而为证书信息担保，并用其私有密钥签发证书。 

我要强调一点！数字证书一般还包括所用签名算法的描述性信息。

为何我要强调这个玩意儿呢？由于固然这就是在一开始三步握手交换信息时双方验证摘要报文的时候，要用到！！！不少人很懵逼不知道浏览器和服务器怎么验证报文的，由于几乎没有做者详细介绍是如何验证过程的，或许你看了我下面解释的这个过程，甚至本身想实现一把。

报文摘要：用于对发送的报文生成一个很是小的摘要信息。这个摘要信息保证原报文的完整性，即原报文只要有一位被改变，则摘要信息就会不匹配。对报文使用签名函数（SHA-1和MD5，而签名函数来自数字证书！

摘要是“对信息主体的浓缩”。摘要是一种单向函数，主要用于将无限的输入值转 换为有限的浓缩输出值。7常见的摘要函数 MD5，会将任意长度的字节序列转换为 一个 128 位的摘要。有时也将摘要函数称为加密的校验和、单向散列函数或指纹函数。强调单向防止被逆向啊。  这样才能百分百保证信息没有彻底被修改。听不懂？？？不要紧，这才是开胃菜。

数字签名：

数字签名来验证证书的完整性。就是在第二步握手的时候，稍后讲解。

用加密系统对报文进行签名(sign)，以说明是谁编写的报文，同时证实报文未被篡改过。这种技术被称为数字签名(digital signing)，

签名是加了密的校验和：

• 签名能够证实是做者编写了这条报文。只有做者才会有最机密的私有密钥， 所以，只有做者才能计算出这些校验和。校验和就像来自做者的我的“签名”同样。

• 签名能够防止报文被篡改。若是有恶意攻击者在报文传输过程当中对其进行了修改，校验和就再也不匹配了。因为校验和只有做者保密的私有密钥才能产生，因此攻击者没法为篡改了的报文伪造出正确的校验码。

  RSA 加密系统将解码函数 D 做为签名函数使用，是由于 D 已经将私有密钥做为输入使用了。注意， 解码函数只是一个函数，所以，能够将其用于任意的输入。一样，在 RSA 加密系统中，以任意顺序 应用 D 和 E 函数时，二者都会相互抵消。所以 E(D(stuff)) = stuff，就像 D(E(stuff)) = stuff 同样。

• 此时假定私有密钥没有被人偷走。大多数私有密钥都会在一段时间后过时。还有一些“取消列表”记 录了被偷走或入侵的密钥。

HTTPS方案

一般状况下，非安全 HTTP 的 URL 方案前缀为 http，以下所示:

http://www.joes-hardware.com/index.html

在安全 HTTPS 协议中，URL 的方案前缀为 https，以下所示:

https://cajun-shop.securesites.com/Merchant2/merchant.mv?Store_Code=AGCGS

请求一个客户端(好比 Web 浏览器)对某 Web 资源 执行某事务时，它会去检查 URL 的方案。 

• 若是 URL 的方案为 http，客户端就会打开一条到服务器端口 80(默认状况下) 的链接，并向其发送老的 HTTP 命令 

• 若是 URL 的方案为 https，客户端就会打开一条到服务器端口 443(默认状况下) 的链接，而后与服务器“握手”，以二进制格式与服务器交换一些 SSL 安全参数， 附上加密的 HTTP 命令 

如今一般是第三种方案。

SSL握手

在发送已加密的 HTTP 报文以前，客户端和服务器要进行一次 SSL 握手，在这个握手过程当中，它们要完成如下工做: 

• 交换协议版本号;
• 选择一个两端都了解的密码;
• 对两端的身份进行认证;
• 生成临时的会话密钥，以便加密信道。 

咱们来一个http握手与https握手概览。

这是一个概览，有利于下面咱们在具体分析的时候，不知道在哪一个过程的时候，记得来看图对比。让你对https握手更加清晰。

服务器证书

 经过 HTTPS 创建了一个安全 Web 事务以后，现代的浏览器都会自动获取所链接服务器的数字证书。若是服务器没有证书，安全链接就会失败。服务器证书中包含不少字段，其中包括:

• Web 站点的名称和主机名;

• Web 站点的公开密钥;
  • 签名颁发机构的名称;
  • 来自签名颁发机构的签名。

浏览器收到证书时会对签名颁发机构进行检查。若是这个机构是个颇有权威的公共签名机构，浏览器可能已经知道其公开密钥了(浏览器会预先安装不少签名颁发机构的证书)。这样，就能够验证签名了。

放大招：具体握手过程

（SSL的加密过程是RSA与AES混合进行的。简单归纳一下，就是经过RSA加密方式来交换AES加解密的密钥，而后使用AES加密的方式来传输报文。）

第一步：

有客户端发起的第一次握手，这次握手过程的主要目的是从服务端获取数字签名证书，服务端在发送数字签名证书以前要先确认客户端的SSL版本、加密算法等信息。------第一步用到数字证书

客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表以内。若是数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告。

第二步：

完成第一次握手后，接着进行第二次握手。第二次握手是在客户端收到证书后发起的，主要目的是将AES加解密使用的Key （Pre-master secret）发送给服务端。固然这个AES_KEY是使用第一次握手获取的公钥进行加密的。客户端收到这个使用公钥加密后的AES_KEY，使用服务端的私钥进行解密。这样客户端和服务端通过二次握手后都持有了AES加解密的KEY。———第二步进行数字签名验证。

参考下面的图理解啊！！老哥们～（我说的第二步能够当作下图中2和3）

第二步包括数字签名过程，也就是RSA算法验证过程。（这个过程比较艰难，若是一时无法理解，谷歌一下相关知识。或者请留言前提是你已经研究了一小时了仍是只知其一;不知其二）

节点 A 将变长报文提取为定长的摘要 节点（把A当作浏览器也就是客户端）

A 对摘要应用了一个“签名”函数，这个签名函数就是 数字证书里面约好的。这个函数会将用户的私有密钥做为参数。 由于只有用户B（服务器）才知道私有密钥，因此正确的签名函数会说明签名者就是其全部者。 在图中，因为解码函数 D 中 包含了用户（服务器）的私有密钥，因此咱们将其做为签名函数使用（RSA 加密系统将解码函数 D 做为签名函数使用，是由于 D 已经将私有密钥做为输入使用了。注意， 解码函数只是一个函数，所以，能够将其用于任意的输入。一样，在 RSA 加密系统中，以任意顺序 应用 D 和 E 函数时， 二者都会相互抵消。所以 E(D(stuff)) = stuff，就像 D(E(stuff)) = stuff 同样） 注意：这里请用工程思想去理解，也就是私有密钥做为参数这句话，只有服务器才知道私有密钥。

一旦计算出签名，节点 A 就将其附加在报文的末尾，并将报文和签名都发送给B 在接收端，若是节点 B 须要肯定报文确实是节点 A 写的，并且没有被篡改过， 节点 B 就能够对签名进行检查。节点 B 接收经私有密钥扰码的签名，并应用了 使用公开密钥的反函数。若是拆包后的摘要与节点 B 本身的摘要版本不匹配，要 么就是报文在传输过程当中被篡改了，要么就是发送端没有节点 A 的私有密钥（也 就是说它不是节点 A）

用大白话说：这个过程就是验证A就是浏览器,用户就是服务器。而不是中间者（或者黑客）。浏览器知道数字证书上的签名函数，对发送的报文生成一个很是小的摘要信息。那么这个信息就是惟一不可改变的信息。服务器收到后用公开密钥（固然应用了私有密钥 ）获得报文摘要C。而后本身再用一样的签名函数对明文获得报文摘要D。若是C==D，说明验证成功。不然就是有问题的。

当你看到这里说明你已经成功70%了！！！

第三步：

当Client与Server端都持有AES_KEY后，就能够对HTTP报文进行加解密了。这里就再也不是RSA了，而是使用对称加密，就算被第三方劫持，第三方也不知道密码。除非其中一我的把密码告诉第三方。这里使用对称加密也是为了提升HTTPS的性能。由于自己HTTPS所消耗的时间也是不可忽视的。我能够看一下掘金的用例：

经过代理以隧道形式传输安全流量

CONNECT 方法请求隧道网关建立一条到达任意目的服务器和端口的 TCP 链接，并 对客户端和服务器之间的后继数据进行盲转发。 

客户端一般会用 Web 代理服务器表明它们来访问 Web 服务器。比 如，不少公司都会在公司网络和公共因特网的安全边界上放置一个代理。代理是防火墙路由器惟一容许进行 HTTP 流量交换的设备，它可能会进行 病毒检测或其余的内容控制工做。但只要客户端开始用服务器的公开密钥对发往服务器的数据进行加密，代理就再也 不能读取 HTTP 首部了!代理不能读取 HTTP 首部，就没法知道应该将请求转向何 处了。

为了使 HTTPS 与代理配合工做，要进行几处修改以告知代理链接到何处。一种常 用的技术就是 HTTPS SSL 隧道协议。使用 HTTPS 隧道协议，客户端首先要告知代 理，它想要链接的安全主机和端口。这是在开始加密以前，以明文形式告知的，所 以代理能够理解这条信息。

 HTTP 经过新的名为 CONNECT 的扩展方法来发送明文形式的端点信息。CONNECT 方 法会告诉代理，打开一条到所指望主机和端口号的链接。这项工做完成以后，直接 在客户端和服务器之间以隧道形式传输数据。CONNECT 方法就是一条单行的文本命 令，它提供了由冒号分隔的安全原始服务器的主机名和端口号。host:port 后面跟 着一个空格和 HTTP 版本字符串，再后面是 CRLF。接下来是零个或多个 HTTP 请 求首部行，后面跟着一个空行。空行以后，若是创建链接的握手过程成功完成，就能够开始传输 SSL 数据了。

It's over。

是否是特别详细咩～欢迎指出不正之处！