Https

https协议与http协议有着相当大的联系。说明白点，https实则就是以安全为目标的http通道。就是http的安全版。本文重点讲的是http与https之间的区别，就是那层加密。

1 https简介

https（Hypertext transfer protocol over secure socket layer),是以安全为标准的http通道。在http下加入了ssl层。https协议需要到ca申请证书，一般免费的证书很少，是需要缴费的。http是超文本传输协议，信息是明文传输的，而https则是具有安全性的ssl加密传输协议。并且http和https采用的是完全不同的连接方式，并且两者的端口号也是不一样的，一个默认是80， 另外一个默认是443.https是由http + ssl 构建的加密传输，身份认证的网络协议，要比http协议安全的多。
上面提到了http和https采用的是不同的连接方式这句话。对于http而言，实则就是很典型的TCP连接方式来与服务端建立连接，著名的三次握手和四次分手。但是对于https来说，由于多了一些关于身份认证方面的细节，是与http的连接方式有区别的。下图展示了https建立连接的过程。其中里面涉及了认证，对称性加密，非对称性加密，密钥，公钥，私钥等概念。不过此时只需要知道建立连接会有这么多步骤即可。剩下的文章后面会讲解。

2 https协议的主要作用

1 建立一个信息安全的通道，来保证数据传输的安全。
2 确认网站的真实性。（有CA认证）
那么接下来我们探讨为了实现这两个作用，https究竟做了什么。先给张https的图片：

3 如何来建立一个信息安全的通道？

3.1 数据加密

提到信息安全，首推的就是加密。假设客户端用http协议给服务端发了一个很重要的信息。但是我们都知道http
传输数据是明文传输的，倘若此时有一个黑客从中间截获了信息，那么信息便会一览无余。显然这种情况是十分不安全的。于是我们想到了，在信息发送的时候，如果我们对这段信息进行加密不就得了。这样的话，即使黑客从中间截取了信息，那是被加密完的一堆看不懂的字符，不解密的话基本没有啥意义。那么此时我们就得考虑加密要采用哪种加密呢？通常的加密种类有两种比较常用，一种是对称式加密，另一种是非对称式加密。（不了解加密的请转站加密简介 进行简单的了解）

对称式加密：客户端和服务端具有相同的密钥，客户端用密钥加密，服务端用密钥解密。加密解密的速度相对于非对称加密是比较快的，但是缺点是一旦被别人知道这个密钥了，截取信息之后根据密钥解密分分秒的事情。所以密钥不能被盗不能被盗不能被盗！！

非对称式加密：直白来讲就是加密的密钥和解密的密钥不相同。 通过一种算法生成公钥和私钥这两种密钥。。其中明文会根据公钥进行加密，只有刚生成的那个私钥才能解密。也可以用私钥进行加密，只能用公钥才能解密。公钥可以是大家都知道的，但是我们即使知道公钥也难以从公钥反推出相应的私钥是多少，因为公钥反推出来的解往往有无穷个。鬼才晓得到底是哪一个！公钥和私钥的生成是根据一种数学原理计算出来的，我们在这里不做考究了。 那么根据公钥和私钥这种使用的联系，我们可以想象一种场景，服务端生成了一对公钥和私钥，然后把公钥传给客户端（此时无需担心传输过程中公钥是否泄漏，因为即使第三人知道了也反推不出来私钥是什么）。等客户端发送数据的时候，拿这条公钥来对数据进行加密。然后传给服务端。服务端再拿出本地持有的私钥进行解密。是不是perfect？？这样的加密和解密，完全避免了对称加密的那种害怕密钥被盗的缺点。因为公钥全世界知道都没事儿，，重点是私钥，生成私钥的那一端压根就不发出去私钥，，怎么在传输中间盗取？？所以这种加密方式相对于对称性加密来说实则是更加安全的。 但是鱼与熊掌不可兼得，非对称加密得到了安全却失去了速度。他的加密过程往往会耗时较长。至于为啥，请看稍后补充.

那么我们该考虑了，客户端给服务端发消息，该采取哪种加密方式呢？已知对称加密 加解密速度快， 但是怕密钥被别人知道。 非对称加密不用担心密钥被盗取，但是其速度比较缓慢。 首先我们不确定要传输的信息量到底是多大，万一特别大吧，如果采用非对称加密的话，速度估计会不理想。用对称加密吧，还担心钥匙搞丢了。
https的加密实则采用了对称式加密和非对称式加密相结合的方式来确保速度和安全性的平衡。 它采用了对称性加密来加密具体的信息，但是对称加密的密钥必须客户端和服务端都得知道吧。那么客户端生成密钥的时候，会把这个密钥，用公钥加上一层非对称加密，然后再将这个经过加密的密钥传给服务端，服务端获取后，用私钥解密，就可以得到原来的对称加密的密钥了。 在密钥数据的传输中，即使被第三方知道了这个加密串，他也因为得不到私钥无法进行解密。
那么这样的话，逻辑上讲，我们要做什么呢？（事实上https 的对称性加密采用的是 AES-256， 非对称加密采用的是RSA算法。）
1 服务端用RSA生成公钥和私钥， 并且把公钥给客户端。
2 客户端得到了公钥， 然后用AES产生一个对称性加密的 密钥，以后称之为AES密钥，用于给传递的数据进行对称性加密。
3 客户端将AES密钥，用公钥进行加密，并传递给服务端。（确保密钥传输过程中的安全性）
4 服务端得到了进行非对称加密之后的AES密钥，用自己持有的私钥进行解密。 得到原始的AES密钥。
5 这样等以后真正的传数据的时候，客户端只需要用AES密钥进行加密，传至服务端，服务端用AES密钥进行解密。

3.2 站点认证

那么这样就完了吗？其实这样只是保证了数据在传输过程中是否安全。但是遇到了以下场景，照样歇菜。
假设，在客户端第一次发的时候，服务端会返回一把公钥，但是如果中间环节被黑客截住了，并且伪装成服务端，生成了自己的一把公钥私钥，把公钥回给了客户端，，等客户端以后发请求的时候，实则是采用了恶意黑客给的公钥加密 发给了黑客， 然后黑客进行解密之后，得到了信息， 再把这波信息用真正的服务端的公钥进行加密，再发给真正的服务端。。一来一往的，成功的欺骗了真正的客户端和服务端。就这样信息神不知鬼不觉的被盗取了。所以只是在信息上做加密是不够的。我们要避免中间环节被他们截取，这点也是挺重要的。

于是乎https，除了做了加密之外，还做了一种认证机制。也就是他的第二个作用–确认网站的真实性。（CA认证）。
https引进了一个非常权威的第三方，一个专门用来认证网站合法性的组织，叫做CA（Certificate Authority)。各个网站服务商可以向CA申请证书，使得客户端和服务端在建立安全链接的时候带上CA签名。而CA的安全性是由操作系统或者浏览器来认证的！

你的 Windows、Mac、Linux、Chrome、Safari 等会在安装的时候带上一个他们认为安全的 CA 证书列表，只有和你建立安全连接的网站带有这些CA的签名，操作系统和浏览器才会认为这个链接是安全的，否则就有可能遭到中间人攻击。

一旦某个 CA 颁发的证书被用于的非法途径，那么这个 CA 之前颁发过的所有证书都将被视为不安全的，这让所有 CA 在颁发证书时都十分小心，所以 CA 证书在通常情况下是值得信任的。
谈到这个我们需要大致看一下，CA证书里面大约是什么内容：
颁发者
使用者
版本
签名算法
签名哈希算法
使用者
公钥
指纹
指纹算法等等。。。
其中有一个很重要的点，就是CA证书里面是包含公钥的。
那么CA证书具体要在哪个环节出现呢？根据CA证书用于解决站点真实性的这一作用来看。显然，在没有证书的情况下，我们要先找CA认证中心认证一下自己，这样以后才能正常进行客户端服务端交互传递数据并且搞加密这之类的事情。
所以在服务端会提早向CA这个机构来申请一下自己的证书：
首先证书申请者生成相应的公钥和私钥，把公钥，和自己其他的相关证书信息发送给CA中心–>证书中心进行审核，并对审核通过的证书申请信息，以及公钥做签名（签名这个概念之后讲）。–> 证书中心将处理过的证书返还给证书申请者。

3.3 签名的概念简介

上面的描述中又出现了一个新的概念，叫签名。这个根本目的就是防止数据遭到篡改。那么他是如何实现的呢？它主要用到了非对称加密的特点，以及一种数字摘要算法。
对于非对称加密而言，我们已经知道，
1公钥大家都可以知道，私钥从始至终只有一方知道并且不可泄漏。
2 知道公钥的情况下，很难反推出私钥是什么。 但是公钥进行加密，只有私钥可以解密。 私钥进行加密的情况下，只有公钥可以解密。
那么是如何利用这些特点来实现签名呢？
假设B是公钥私钥生成方， 公钥公布出来， 而私钥只有B持有。然后B给A发送一段数据，并且不希望传输途中遭到篡改。那么B会这样做：
首先B给A的数据可能会非常大，如果对这段数据进行全加密的话，会耗费更多的时间，全加密的话是不太好的。但是B不希望传输途中这段数据被篡改，那么它一般不会对原数据做加密，反而是对原数据做一段摘要算法，生成一个固定位数的摘要，然后用自己的私钥对这个摘要进行非对称加密。 等A收到数据的时候，会用公钥对这段摘要进行解密， 得出摘要，，然后把接收到的数据进行同样的摘要算法，看看生成的摘要是否与刚刚解密的那个摘要进行对比。如果一模一样，代表数据没有遭到篡改。如果不一样则表示数据遭到篡改了。
到了这里，你似乎并没有瞧出特别之处。以及为什么要生成摘要，还要对摘要进行私钥加密。那么请想象一个场景， B 对数据做完这些操作之后，要发送给A，但是中间恰好被一个坏人F截住了。 它想改其中一个很重要的数据项。于是就改了。改完后转发给了A， 那么A收到信息后首先要把数据用摘要算法计算一下呀，于是就把这个经过F偷偷修改的数据进行摘要计算，然后用公钥解密原先包里的摘要部分，对比一下看看是不是一样。 很显然，这次计算出来的结果，新摘要和原先的老摘要必然不一样的！因为新摘要是经过F篡改后的内容计算得出的。怎么会和老的一样呢！这样就可以瞧出来数据是否遭到篡改了。
但是如果你深入想的话，你可能会想到F怎么那么傻，只改了数据里面的数据项，为什么不顺便对截获包里面的摘要做手脚呢？只要把摘要也改成自己修改之后生成的摘要不就得了？这样不就能坑住A了么？？好我们假设F真的这么做哈，它截住B发来的数据时留了个心眼，改了数据里面的重要项目，然后生成了一个新的摘要，，但是他知道A得到数据后首先要对摘要部分进行公钥解密的，于是乎，他必须得对新的摘要进行加密，但是加密用的密钥呢？老摘要是B用自己的私钥进行加密的呀。 F现在无论如何也不知道B的私钥呀。。并且公钥只能解真正的私钥的密。。。无论怎么糊弄，这个摘要到了A那里，光是解密环节就已经被pass了！！根本行不通！！这就是B要对摘要进行私钥加密的原因！！！

4 Https 客户端与服务端的连接过程

参考文章： 网络安全–一图看懂https建立过程

好吧，对于理解的部分大概讲完了，那么下面我们看一下具体的https方面，客户端与服务端连接的整体过程吧。相信看过上文之后，会很容易的理解相关的过程。
如图展示了Https与服务端连接的整体过程：
图一：

前提条件，获得CA认证

在一个站点没有被认证的情况下，首先要到CA认证中心这个很可靠的认证机构去认证一下自己：
1 服务端会生成自己的公钥和私钥并且把公钥连带自己的信息等内容发送给CA机构，私钥自己收藏保存
2 认证机构根据发送过来的内容，进行审核，通过之后，对证书进行签名，发送给服务端。
3 操作系统，或者浏览器中，都会内置这些已经通过审核的证书。每个证书中都含有相应站点的公钥。

客户端与服务端的连接（TCP部分）

前面的准备工作成了之后，接下来就是最初的发起请求。我们知道https实则是建立在http的基础上来进行的，而http的连接过程实则是tcp协议的连接过程。所以https最初的连接，实则和http是一样的。先建立三次握手！三次握手请参考：http

客户端与服务端的连接（SSL/TLS层部分）

SSL又称为安全套接字层。它在整个协议栈的位置是这样的：

其中TLS是SSL的升级版。这里主要探讨的是SSL层。这一层是https比http更加安全的关键因素。其实它做的事情在前文中是讲过的。
下图为SSL层包含的部分，了解一下即可

上面这张图不是重点。重点是下图，前面已经贴过一次：

其中2-5 代表的是SSL层做的事情。
当我们建立了三次握手之后，接下来就要重点搞一些鉴别CA证书合法性， 传输对称加密私钥这些事情了。
1 客户端发送Client Hello包（对应图中2）
随机数
里面有1970年1月1日到现在的秒数，后面还有一个客户端发来的随机数Client.random

Session ID
如果客户端与服务器费尽周折建立了一个HTTPS链接，刚建完就断了，也太可惜，所以用Session ID将其保存，如果下次再来可以直接使用之前的链接进行对话(对称密钥)。

密文族
告诉服务器，自己支持的加密算法种类

Server_name
2 Server Hello（对应图中2）
随机数：对应服务器时间，服务器sever.random
Seesion ID，如果客户端发给服务器的session ID在服务端有缓存，服务端会尝试使用这个session；否则服务器会启用新的并返回给客户端；
服务器挑选一个密文族
3 Certificate（对应图中2）
服务器终于发来我们想要的数字证书，包含了：签发机构、过期时间、主题名称、公共密钥信息、指纹信息等等

4 Server Hello Done（对应图中2）
服务器发送结束

5 客户端验证（对应图中3）
客户端从内置的CA根证书获取C.pub，对服务器发送来的数字证书进行验签，如果一致，说明证书是CA颁发的（前提是C.pub是真实的，确实是CA机构的公钥）。然后看看证书是否过期，域名是否匹配

6 生成对称密钥（对应图中4、5、6）
客户端根据之前的：Client.random + sever.random + pre-master生成对称密钥
经过S.pub加密发送给服务器，之后即可通过对称密钥进行通讯。（就是之前我们熟悉的http）

双方传输数据

经过前两步对称密钥的成功交换，双方就可以根据这个对称密钥进行加解密交互了。至此，https安全性重点讲解完毕。