Https：认识和扫盲

阅读量：5879 次

发布时间：2019-06-19

本文共 6309 字，大约阅读时间需要 21 分钟。

Https

什么是Https

Http协议经过SSL/TLS加密后传输，成为HTTPS协议。HTTPS其实就是secure http的意思啦，也就是HTTP的安全升级版。稍微了解网络基础的同学都知道，HTTP是应用层协议，位于HTTP协议之下是传输协议TCP。TCP负责传输，HTTP则定义了数据如何进行包装。

为什么要SSL/TLS

- Http的明文传输

Http协议的传输，都是明文传输，这就意味着，介于发送端和接收端之间的任意一个节点，都可以很轻松的获取到通信的报文信息。

- 报文信息完整性的不确定

由于Http协议传输都是明文的，所以如果有需要，可以随时获取到一个用户和服务器交流的所有数据。一些黑客什么的可以获取倒着写报文并且进行篡改，变成一些奇怪的东西。

- http无状态的局限性

http是无状态响应，不保存具体的响应状态，也就是说，通信方身份不验证，可能遇到假的客户端或服务器。例如，服务器不知道客户端，黑客通过发送大量的无意义请求，造成服务器假死拒绝响应，这就是所谓的Dos攻击。又或者是客户端不知道发送的是什么服务器，所以会有大量的钓鱼网站对用户信息进行套取。

如何确保安全？

在说如何保障安全以前，要先解释一些密码学的名词。

对称加密

加密数据用的密钥，跟解密数据用的密钥是一样的。

对称加密的优点在于加密、解密效率通常比较高。缺点在于，数据发送方、数据接收方需要协商、共享同一把密钥，并确保密钥不泄露给其他人。此外，对于多个有数据交换需求的个体，两两之间需要分配并维护一把密钥，这个带来的成本基本是不可接受的。

非对称加密

非对称加密方式能很好地解决对称加密的困难。

非对称加密方式有两把密钥。一把叫做私有密钥（private key），另一把叫做非对称（public key）。私有密钥是一方保管，而非对称则谁都可以获得。这种方式是需要发送密文的一方先获得对方的非对称，使用已知的算法进行加密处理。

对方收到被加密的信息后，再使用自己的私有密钥进行解密。这种加密方式有意思是的加密算法的神奇，经过这个公开的算法加密后的密文，即使知道非对称，也是无法对密文还原的。要想对密文进行解决，必须要有私钥才行。所以非对称加密是非常安全的，即使窃听到密文和非对称，却还是无法进行解密。

公钥、私钥两个有什么联系呢？

简单的说就是，通过公钥加密的数据，只能通过私钥解开。通过私钥加密的数据，只能通过公钥解开。

很多同学都知道用私钥能解开公钥加密的数据，但忽略了一点，私钥加密的数据，同样可以用公钥解密出来。而这点对于理解HTTPS的整套加密、授权体系非常关键。

非对称加密算法用的一般是 RSA 算法（这可能是目前最重要的算法了）。这个算法由3个小伙子在1977年提出，它的主要原理是：将两个大素数相乘很简单，但想要这个乘积进行因式分解极其困难，因此可以将乘积公开作为非对称。不过随着目前的分布式计算和量子计算机的快速发展，说不定在将来也许能破解这个算法了。

非对称加密的例子

小明想要访问一个网站，于是小明向客户端发送请求时，客户端会使用公钥加密小明的请求数据到服务器，服务器通过密钥解开后得到数据，登陆授权程序通过私钥，将账号、密码解密，并验证通过。之后，将小明的个人信息（含隐私），通过私钥加密后，传输回浏览器。浏览器通过公钥解密数据，并展示给小明。

* 步骤一：小明输入账号密码 --> 浏览器用公钥加密 --> 请求发送给XX

* 步骤二： XX用私钥解密，验证通过 --> 获取小明社交数据，用私钥加密 --> 浏览器用公钥解密数据，并展示。

可是这种方式真的安全吗？

带来的问题

- 公钥如何获取

公钥加密的数据只有私钥才能解开，可是公钥如何获取？

数据传输仅单向安全
前面强调了一下，私钥加密的数据公钥同样可以解开，那么说明在服务器加密数据返回给客户端以后，返回的数据公钥可以解开，而公钥是共开的，所以说，这是换了一种方式的裸奔而已。

公钥如何获取

关于这个问题，要引出两个比较关键的概念：证书和CA(证书颁发机构)

证书

证书相当于一个网站的身份证，证书里面包含了很多很多的信息，其中有一项就是该网站的公钥。

所以有了证书以后，我们就可以不用很费劲的去寻找公钥，而是在访问网站的时候，就可以通过网站的响应获取到公钥信息。

CA

CA，即第三方可信证书颁发机构。

非对称加密方式存在一个很大的问题：它无法证明非对称本身是真实的非对称。比如，打算跟银行的服务器建立非对称加密方式的通信时，怎么证明收到的非对称就是该服务器的密钥？毕竟，要调包非对称是极为简单的。这时，数字证书认证机构（CA，Certificated Authority）就出场了。

数字认证机构是第三方的证书颁发机构，很多CA都可以颁发证书，但是只有少数的CA被认为是权威、公正的，这些CA颁发的证书，浏览器才认为是信得过的。比如VeriSign。（CA自己伪造证书的事情也不是没发生过。。。）

证书颁发的细节可以先简单理解为，网站向CA提交了申请，CA审核通过后，将证书颁发给网站，用户访问网站的时候，网站将证书给到用户。

解决数据传输单向安全

如果说，通过私钥加密的数据用公钥同样可以解开，那么我们是不是可以说，在服务器响应数据给用户的时候，回传给用户的数据同样是不安全的？

是的没错就是这样。(滑稽)

HTTPs的这种非对称加密机制，本质上只是换了一种方式在裸奔而已。

而且Https由于是非对称加密，相对于对称加密而言，虽然维护成本较低，但是效率也更低，所以我们为什么还是要用Https？

如果真的是这样的话，拿前面提到的对称加密岂不是可以删掉了？

是的，Https虽然用到了非对称的公开密钥加密，但是同时也结合了其他手段，比如对称加密。

简单的来说，整个简化的加密通信流程就是：

1. 小明访问网站，网站服务器将证书颁发给小明(的浏览器)。

2. 小明的浏览器从证书里得到公钥。

3. 浏览器生成一个session唯一的密钥B，使用公钥A加密，成为新的密文C，发送给服务器。

4. 服务器收到C，使用公钥对应的密钥D解密得到浏览器生成的密钥B。

5. 之后的通信都是用浏览器的密钥B对称加密发送。

如图：

简单理解了这个流程以后，我们就可以来看看更详细的了。

HTTPs握手机制

所谓握手，就是说上面提到的那个流程。在浏览器和服务器进行通信之前，都是有一次获取浏览器自己的密钥的过程。这个使用公钥交换密钥的过程就成为握手机制。

不多说，来看一下握手的过程具体都有什么：

浏览器将自己支持的一套加密算法发送给网站服务器,这个过程被称为Client Hello。

2. 服务器从其中选出一中加密算法和Hash算法，并且将自己的身份信息和公钥等，通过证书返回给客户端。这就是Server Hello，证书的具体内容等下再讲。

3. 浏览器接受到证书并且处理

- 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。

- 如果证书受信任或者用户手动确认接受不受信的证书，浏览器就生成一串随机密码并且对公钥进行加密。

- 使用约定好的Hash算法计算握手消息，并且使用生成的的随机数对消息进行加密。最后将生成的全部信息发回服务器。

4. 服务器接收到浏览器的信息。

- 使用自己的私钥解密取出密码，使用密码解密浏览器发送的握手消息，并且验证Hash是否与浏览器发送回来的一致。

- 使用浏览器给的密码加密一段握手消息发送给浏览器。

5. 浏览器解读并计算Hash，如果和服务端Hash一致，握手结束。之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。

浏览器一般使用的加密算法：

非对称加密算法：RSA，DSA/DSS

对称加密算法：AES，RC4，3DES

HASH算法：MD5，SHA1，SHA256

证书会不会有问题？

有个问题，怎么样确保证书有合法有效的？

证书非法可能有两种情况：

1. 证书是伪造的：压根不是CA颁发的

2. 证书被篡改过：比如将XX网站的公钥给替换了

比如，翻过墙的都知道代理，所以我们真实访问一个网站的情况也很有可能是这样的：

小明 --> 邪恶的代理服务器 --> 登陆授权服务器

小明 <-- 邪恶的代理服务器 <-- 登陆授权服务器

然后，这个世界上的坏人太多了，某一天，代理服务器动了坏心思，或者说被黑客入侵了，把小明的请求拦截了。同事反悔了一个非法的证书：

小明 --> 邪恶的代理服务器 --x--> 登陆授权服务器

小明 <-- 邪恶的代理服务器 <--x-- 登陆授权服务器

tips:代理服务器把篡改的请求发送给服务器，服务器返回的证书也被修改

如果善良的小明相信了这个证书，那他就再次裸奔了。所以，通过什么机制保证证书的防伪的呢？

证书

聊证书以前，再来引出两个名词概念。

数字签名和摘要

“摘要”就是对传输的内容，通过hash算法计算出一段固定长度的串（是不是联想到了文章摘要）。然后，在通过CA的私钥对这段摘要进行加密，加密后得到的结果就是“数字签名”。（这里提到CA的私钥，后面再进行介绍）

明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名

结合上面内容，我们知道，这段数字签名只有CA的公钥才能够解密。

证书格式

好了，我又要开始无耻的复制粘贴大段内容了。

内容非常多，这里我们需要关注的有几个点：

证书包含了颁发证书的机构的名字 -- CA
2. 证书内容本身的数字签名（用CA私钥加密）

3. 证书持有者的公钥

4. 证书签名用到的hash算法

此外，有一点需要补充下，就是：

1. CA本身有自己的证书，江湖人称“根证书”。这个“根证书”是用来证明CA的身份的，本质是一份普通的数字证书。

浏览器通常会内置大多数主流权威CA的根证书。

1\. 证书版本号(Version)版本号指明X.509证书的格式版本，现在的值可以为:    1) 0: v1    2) 1: v2    3) 2: v3也为将来的版本进行了预定义2\. 证书序列号(Serial Number)序列号指定由CA分配给证书的唯一的"数字型标识符"。当证书被取消时，实际上是将此证书的序列号放入由CA签发的CRL中，这也是序列号唯一的原因。3\. 签名算法标识符(Signature Algorithm)签名算法标识用来指定由CA签发证书时所使用的"签名算法"。算法标识符用来指定CA签发证书时所使用的:    1) 公开密钥算法    2) hash算法example: sha256WithRSAEncryption须向国际知名标准组织(如ISO)注册4\. 签发机构名(Issuer)此域用来标识签发证书的CA的X.500 DN(DN-Distinguished Name)名字。包括:    1) 国家(C)    2) 省市(ST)    3) 地区(L)    4) 组织机构(O)    5) 单位部门(OU)    6) 通用名(CN)    7) 邮箱地址5\. 有效期(Validity)指定证书的有效期，包括:    1) 证书开始生效的日期时间    2) 证书失效的日期和时间每次使用证书时，需要检查证书是否在有效期内。6\. 证书用户名(Subject)指定证书持有者的X.500唯一名字。包括:    1) 国家(C)    2) 省市(ST)    3) 地区(L)    4) 组织机构(O)    5) 单位部门(OU)    6) 通用名(CN)    7) 邮箱地址7\. 证书持有者公开密钥信息(Subject Public Key Info)证书持有者公开密钥信息域包含两个重要信息:    1) 证书持有者的公开密钥的值    2) 公开密钥使用的算法标识符。此标识符包含公开密钥算法和hash算法。8\. 扩展项(extension)X.509 V3证书是在v2的基础上一标准形式或普通形式增加了扩展项，以使证书能够附带额外信息。标准扩展是指由X.509 V3版本定义的对V2版本增加的具有广泛应用前景的扩展项，任何人都可以向一些权威机构，如ISO，来注册一些其他扩展，如果这些扩展项应用广泛，也许以后会成为标准扩展项。9\. 签发者唯一标识符(Issuer Unique Identifier)签发者唯一标识符在第2版加入证书定义中。此域用在当同一个X.500名字用于多个认证机构时，用一比特字符串来唯一标识签发者的X.500名字。可选。10\. 证书持有者唯一标识符(Subject Unique Identifier)持有证书者唯一标识符在第2版的标准中加入X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时，用一比特字符串来唯一标识证书持有者的X.500名字。可选。11\. 签名算法(Signature Algorithm)证书签发机构对证书上述内容的签名算法example: sha256WithRSAEncryption12\. 签名值(Issuer's Signature)证书签发机构对证书上述内容的签名值