https的加密解密过程
前置知识
SSL是90年代Netscape弄出来的一套东西，为的是解决HTTP协议明文传输数据的问题。后来SSL慢慢成了事实上的标准，于是IETF就把SSL标准化了，名字叫做TLS，TLS 1.0其实就是SSL 3.1。所以SSL和TLS经常被放在一起写成SSL/TLS，因为这两个名词在现在其实就是同一个东西。HTTPS是使用TLS的HTTP协议。
证书以及信任链
我们知道，HTTPS的网站都有一个自己的证书，用于表明自己的身份。证书本质上是为了让公钥能可信的传输。公钥是放在证书里面的，如果证书可信，那么公钥就也是可信的。那为什么一个公钥是可信的呢？这就要说到信任链和CA。CA指的是Certificate Authority，CA都是权威机构，他们的证书叫做根证书，这些根证书被操作系统信任，根证书信任的证书也是可信的。因此权威机构颁发的证书都能被操作系统信任，这就组成了信任链。
这里以RSA密钥交换算法为例为例，CloudFlare提供Keyless服务，把网站放到它们的CDN上，不用提供自己的私钥，也能使用SSL加密链接。
https加密解密过程：
-
客户端发起https请求到服务端（服务器端要一套数字证书，可以自己制作，也可以向组织申请），向服务器端索要公钥。
发送的信息一般带上：
-
客户端生成的一个随机值
-
支持的SSL/TSL协议的版本号
-
所支持的加密算法
-
Session ID（用于恢复会话）
-
-
服务端接收到客户端的请求后回应客户端以及公钥（也就是证书）传给客户端。如果带有Session ID，直接恢复对话。
没有Session ID一般会返回这些信息给客户端：
-
选择SSL/TLS协议的版本号
-
选择加密方式
-
一个服务器随机生成的数
-
服务器的证书
-
-
客户端收到服务端发来的公钥后会解析证书，首先是由TLS层来验证服务端证书是否有效，比如说颁发机构、有效时间、证书中的域名与当前会话域名是否匹配等。
如果发现异常，就会弹出一个警告框，提示证书有问题。
验证完证书的有效性后，客户端向服务端发送的信息包括有一下内容：
-
证书校验没有问题的话，生成一个premaster secret（另一个随机值），然后用服务端发过来的证书对该随机值进行加密。
-
客户端把加密的随机值传回给服务器，加密约定改变，通知服务器，其目的是让服务端得到这个随机值，以后客户端与服务端之间的通信就用协商好的加密方法和密钥进行加密。
-
客户端握手结束通知。这个报文也是验证消息，是前面发送的所有内容的哈希值，用来供服务器校验。
-
-
服务器用私钥解密后，得到了客户端传过来的随机值（私钥），然后对该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，除非知道私钥，否则无法获得内容，因而客户端和服务端都知道这个公钥，只要加密算法够彪悍，私钥够复杂，数据就越安全。
这是握手过程的最后一步，服务器会把以下信息发送给客户端：
-
加密约定改变通知，通知客户端，以后的通信都适用协商好的加密方法和密钥进行加密
-
服务器握手结束通知，该报文也作为校验消息，供客户端验证
-
-
服务端利用这个私钥加密数据并发送数据给客户端，加密的数据可以被还原
-
客户端接收到这份数据后，利用私钥解密这段数据，于是获取了加密的内容。即时第三方在数据传输的中途获取了这份数据，没有私钥也束手无策
SSL/TLS层是位于应用层和传输层之间，应用层的数据不再直接传递给传输层，而是传递给SSL/TLS层，对传过来的数据进行加密，并增加相应的头信息。
整个对话过程中（握手阶段和其后的对话），服务器的公钥和私钥只需要用到一次。这就是CloudFlare能够提供Keyless服务的根本原因。
某些客户（比如银行）想要使用外部CDN，加快自家网站的访问速度，但是出于安全考虑，不能把私钥交给CDN服务商。这时，完全可以把私钥留在自家服务器，只用来解密对话密钥，其他步骤都让CDN服务商去完成。
加解密相关知识
对称加密
对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中，加密密钥和解密密钥是相同的，所以也称这种加密算法为秘密密钥算法或单密钥算法。
常见的对称加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA
非对称加密
与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（public key）和 私有密钥（private key）；并且加密密钥和解密密钥是成对出现的。非对称加密算法在加密和解密过程使用了不同的密钥，非对称加密也称为公钥加密，在密钥对中，其中一个密钥是对外公开的，所有人都可以获取到，称为公钥，其中一个密钥是不公开的称为私钥。
主要算法：RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法）
使用最广泛的是RSA算法，Elgamal是另一种常用的非对称加密算法。
RSA性能是非常低的，原因在于寻找大素数、大数计算、数据分割需要耗费很多的CPU周期，所以一般的HTTPS连接只在第一次握手时使用非对称加密，通过握手交换对称加密密钥，在之后的通信走对称加密。
总结：
服务端用RSA生成公钥和私钥，把公钥放在证书里发送给客户端，私钥自己保存
客户端接收到公钥后，首先向一个权威的服务器检查证书的合法性，如果证书合法，客户端产生一段随机数，这个随机数就作为通信的密钥，我们称之为对称密钥，用公钥加密这段随机数，然后发送到服务器
服务器用密钥解密获取对称密钥，然后，双方就已对称密钥进行加密解密通信了
传输服务器的证书（公钥）时，被别人窃取走了怎么办？
当然服务器没有这么笨，传给客户端的证书是被加密了的，而且是由第三方权威机构CA的私钥加密证书，第三方权威机构CA的公钥维护于(存在于)每个浏览器(无论是中间的黑客、真正的请求者，还有服务器)中。这些有CA机构颁发的证书，都是有CA机构加密了的，客户端或者中间商收到这份CA颁发的证书，都可以解密出服务器的公钥。
那么，最开始https请求到服务器给的证书（CA机构颁发的）过程中，证书到达客户端的路上被黑客拦截了，中间的 "笨笨的黑客" 向CA申请了一套自己的证书，把自家的证书发回给那个客户端，然后通过自己申请的那一套证书的私钥解密出客户端发出的信息，通过拦截下来的服务器端的公钥解密服务端返回给客户端的信息，在中间的位置窃取信息。当然这种事情不会发生，权威的CA机构颁发的证书是有数字签名的，任何组织申请的证书都有对应的证书编码，证书是颁发给谁的，使用者是谁，这些申请者的详细信息都是被记录在案，客户端接收到这份证书后会计算出证书数字签名，证书的使用者对不上也是没有用的。
这样，通过权威的CA机构和证书的数字签名，客户端和服务器端之间建立起的对话秘钥就不会被别人窃取走，即时中间的第三者拿到了服务器的公钥也没有办法解密用服务器公钥加密的内容。
