HTTPS

        HTTPS一般可以理解为加密的HTTP，HTTP是超文本传输协议，是明文传输的，在安全方面有很大的隐患，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等；并且HTTP是基于TCP协议的，在传输数据前至少会经历三次握手才能建立真正的连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。为了增强传输的安全性，需要使用另一种协议：安全套接字层超文本传输协议（HTTPS）。为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

HTTPS和HTTP的区别主要为以下四点：
 一、https协议需要到ca申请证书，一般免费证书很少，需要交费。
 二、http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
 三、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
 四、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

在详细讲解HTTPS是如何进行加密之前，可以先思考以下几个问题，希望在看过文章内容后能够自己解答。

1.为什么要用对称加密+非对称加密？    

2.为什么不能只用非对称加密？

3为什么需要数字证书？

4.为什么需要数字签名？

加密

上文提出了为了解决HTTP是明文传输带来的安全隐患，采用的是加密的方法。而加密主要分为对称加密以及非对称加密。

对称加密

 

对称加密如图可以看出，有一对相同钥匙，我们称之为私钥，在传输过程中我们通过加密上锁的形式，当数据到了接收方，接收方再通过钥匙解锁，两者之间的通信有了加密的效果。但是问题在于，这钥匙双方是如何得到的？当一方确认了使用这个密钥，它是如何通知另一方的呢，如果还是通过明文传输的HTTP协议，还是存在着被拦截密钥泄露的风险，因此，单用对称加密不能达到加密安全传输的效果。

非对称加密

 

非对称加密还是这一张图，不同的是现在这一对钥匙是不同的，分为公钥和私钥。通过公钥加密的数据，只有私钥能够解开。我们可能会有这种思路：服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开公钥加密的数据。（其实仍有漏洞）然而反过来由服务器到浏览器这条路的安全该怎么保障？按照之前的思路可以确定一个非对称加密可以保障一条单项通道的安全，那么使用两个非对称加密能否保证来回通信的安全？的确可以！抛开这里面仍有的漏洞不谈（下文会讲），HTTPS的加密却没使用这种方案，为什么？很重要的原因是非对称加密算法非常耗时，而对称加密快很多。那我们能不能运用非对称加密的特性解决前面提到的对称加密的漏洞？

对称加密 && 非对称加密

网站拥有用于非对称加密的公钥A、私钥A，浏览器向网站请求，服务器把公钥A发给浏览器，浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。服务器接受到后用私钥A解密，取得密钥X，这样双方都拥有密钥X，之后的通信内容可以进行对称加密。

致命关键

上文提到了对称加密和非对称加密配合使用的方法，HTTPS也基本采用了这种方案，但是这里还存在着一个致命的漏洞，在网站服务器发送公钥给你的时候，你怎么知道这个公钥就是网站服务器的？

1. 某网站有用于非对称加密的公钥A、私钥A’。

2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。

3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。

4. 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。

5. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。

6. 服务器拿到后用私钥A’解密得到密钥X。

这样在双方都不会发现异常的情况下，中间人通过一套“狸猫换太子”的操作，掉包了服务器传来的公钥，进而得到了密钥X。根本原因是浏览器无法确认收到的公钥是不是网站自己的，因为公钥本身是明文传输的，难道还得对公钥的传输进行加密？这似乎变成鸡生蛋、蛋生鸡的问题了。因此数字证书也就应运而生了。

数字证书

如何证明一个人的身份？可以看公安机构办法的公民身份证。数字证书也正是互联网上网站的身份证，而颁布数字证书的权威机构也就是常说的CA机构。

网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了。那么身份证可以造假，数字证书可以造假吗？

我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名。

数字签名的制作过程：

1. CA机构拥有非对称加密的私钥和公钥。

2. CA机构对证书明文数据T进行hash。

3. 对hash后的值用私钥加密，得到数字签名S。

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。 那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）

浏览器验证过程：

1. 拿到证书，得到明文T，签名S。

2. 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。

3. 用证书里指明的hash算法对明文T进行hash得到T’。

4. 显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。

中间人有可能篡改该证书吗？

假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

既然不可能篡改，那整个证书被掉包呢？

中间人有可能把证书掉包吗？

假设有另一个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，这确实会导致上文“中间人攻击”那里提到的漏洞？

其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

怎么证明CA机构的公钥是可信的？

你们可能会发现上文中说到CA机构的公钥，我几乎一笔带过，“浏览器保有它的公钥”，这是个什么保有法？怎么证明这个公钥是否可信？

让我们回想一下数字证书到底是干啥的？没错，为了证明某公钥是可信的，即“该公钥是否对应该网站”，那CA机构的公钥是否也可以用数字证书来证明？没错，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中会有CA机构的根证书，这样就可以拿到它对应的可信公钥了。

实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链。也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。

另外，不知你们是否遇到过网站访问不了、提示需安装证书的情况？这里安装的就是根证书。说明浏览器不认给这个网站颁发证书的机构，那么你就得手动下载安装该机构的根证书（风险自己承担XD）。安装后，你就有了它的公钥，就可以用它验证服务器发来的证书是否可信了。

小结：

回到文章最初的几个问题，在此附上我自己的答案，非标准答案，有不足处可指出。

1.为什么要用对称加密+非对称加密？

对称加密可以保护通信内容的安全，但是如何让对方知道密钥是一个问题，如果直接明文传输密钥，很容易有安全问题，因此需要使用非对称加密对一开始密钥的传输进行保护。

2.为什么不能只用非对称加密？

如果只用非对称加密，浏览器向服务器发送请求，服务器把公钥明文发个浏览器，浏览器使用公钥加密内容 ，服务器使用私钥解密，可以保证从浏览器到服务器的安全，但是服务器到浏览器的安全问题还没有解决。可以再使用一个非对称加密来保证服务器到浏览器的安全。最大的问题就是非对称加密非常耗时，相比之下，对称加密快很多。

3为什么需要数字证书？

使用对称加密+非对称加密的方式时，第一次服务器告诉浏览器公钥A时，可能会被中间人拦截，以自己的公钥B替换公钥A并且保存公钥A，浏览器生成对称加密的密钥X，使用公钥B加密后传给服务器，中间人劫持后使用私钥B，获得了密钥X，再用公钥A加密发送给服务器，服务器解密后也获得密钥X。根本的原因时浏览器无法确认收到的公钥是不是网站自己的，因此需要一个权威的机构颁布权威的证明来解决这个问题。这个证明也就是数字证书。

4.为什么需要数字签名？

CA机构拥有对非对称加密的私钥和公钥，首先会对证书明文数据进行hash，对hash后的值用私钥加密，得到的就是数字签名。明文和数字签名共同组成了数字证书。浏览器得到证书后，会获得明文T，签名S，浏览器使用CA机构公钥对S进行解密得到S+，再对其用证书中指名的hash算法对T进行Hash得到T+，次时比较S+和T+,若是两者相等则证书可信，否则证书不可信。由此可知数字签名是起到验证证书是否可信的作用。

参考资料：

彻底搞懂HTTPS的加密原理 - 知乎 彻底搞懂HTTPS的加密原理

HTTP的起源与发展 - 简书 HTTP的起源与发展