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加密解密过程：

1. 客户端发起https请求到服务端（服务器端要一套数字证书，能够本身制做，也能够向组织申请），向服务器端索要公钥。

   发送的信息通常带上：

   • 客户端生成的一个随机值

   • 支持的SSL/TSL协议的版本号

   • 所支持的加密算法

   • Session ID（用于恢复会话）

2. 服务端接收到客户端的请求后回应客户端以及公钥（也就是证书）传给客户端。若是带有Session ID，直接恢复对话。

   没有Session ID通常会返回这些信息给客户端：

   • 选择SSL/TLS协议的版本号

   • 选择加密方式

   • 一个服务器随机生成的数

   • 服务器的证书

3. 客户端收到服务端发来的公钥后会解析证书，首先是由TLS层来验证服务端证书是否有效，好比说颁发机构、有效时间、证书中的域名与当前会话域名是否匹配等。

   若是发现异常，就会弹出一个警告框，提示证书有问题。

   验证完证书的有效性后，客户端向服务端发送的信息包括有一下内容：

   • 证书校验没有问题的话，生成一个premaster secret（另外一个随机值），而后用服务端发过来的证书对该随机值进行加密。

   • 客户端把加密的随机值传回给服务器，加密约定改变，通知服务器，其目的是让服务端获得这个随机值，之后客户端与服务端之间的通讯就用协商好的加密方法和密钥进行加密。

   • 客户端握手结束通知。这个报文也是验证消息，是前面发送的全部内容的哈希值，用来供服务器校验。

4. 服务器用私钥解密后，获得了客户端传过来的随机值（私钥），而后对该值进行对称加密。所谓对称加密就是，将信息和私钥经过某种算法混合在一块儿，除非知道私钥，不然没法得到内容，于是客户端和服务端都知道这个公钥，只要加密算法够彪悍，私钥够复杂，数据就越安全。

   这是握手过程的最后一步，服务器会把如下信息发送给客户端：

   • 加密约定改变通知，通知客户端，之后的通讯都适用协商好的加密方法和密钥进行加密

   • 服务器握手结束通知，该报文也做为校验消息，供客户端验证

5. 服务端利用这个私钥加密数据并发送数据给客户端，加密的数据能够被还原

6. 客户端接收到这份数据后，利用私钥解密这段数据，因而获取了加密的内容。即时第三方在数据传输的中途获取了这份数据，没有私钥也一筹莫展

SSL/TLS层是位于应用层和传输层之间，应用层的数据再也不直接传递给传输层，而是传递给SSL/TLS层，对传过来的数据进行加密，并增长相应的头信息。

整个对话过程当中（握手阶段和其后的对话），服务器的公钥和私钥只须要用到一次。这就是CloudFlare可以提供Keyless服务的根本缘由。

某些客户（好比银行）想要使用外部CDN，加快自家网站的访问速度，可是出于安全考虑，不能把私钥交给CDN服务商。这时，彻底能够把私钥留在自家服务器，只用来解密对话密钥，其余步骤都让CDN服务商去完成。

 

加解密相关知识

对称加密

对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥可以从解密密钥中推算出来，同时解密密钥也能够从加密密钥中推算出来。而在大多数的对称算法中，加密密钥和解密密钥是相同的，因此也称这种加密算法为秘密密钥算法或单密钥算法。

常见的对称加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC四、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机构和证书的数字签名，客户端和服务器端之间创建起的对话秘钥就不会被别人窃取走，即时中间的第三者拿到了服务器的公钥也没有办法解密用服务器公钥加密的内容。