1. HTTPS基本概念

HTTPS：HTTPS也是一个应用层协议，它在HTTP协议的基础上引入了一个加密层——SSL协议，区别就在于HTTP协议是基于明文传输的（不安全），使用HTTPS加密就能在一定程度上防止数据在传输过程中被他人篡改
“运营商劫持”：这可以说是臭名昭著的案例，比如说之前下载天天动听，如果未被运营商劫持，那么正常弹出的就是天天动听的下载链接，但是一旦被运营商劫持，那么很可能弹出的就是例如QQ浏览器的下载链接，由于我们通过网络传输的各种数据包都要经过运营商的设备（路由器、交换机等）那么运营商就很容易将其中的内容进行篡改，其交互过程可以简化如下图所示：

那么运营商为啥要将"天天动听"的下载链接替换为"QQ浏览器"呢？很明显，这背后一定存在着某种商业交易！不仅仅运营商可以劫持，一些黑客也有可能使用类似的手段进行劫持来获取用户的隐私信息，总之在互联网上使用 明文传输 是比较危险的操作！HTTPS就是在HTTP协议的基础上引入了加密手段，进一步保障信息安全

2. 加密是什么

加密是保障数据安全的有效措施！这里需要强调尽管数据被黑客拿到了，黑客也解析不了/无法篡改，只要能做到这点，那么我们就可以说数据是安全的了；另一方面，在理论上加密的数据也有可能被解密成功，但是如果破解加密数据的成本远远高于数据本身的价值，那么我们也可以说这就是安全的！

2.1 密码学部分重要概念

明文：需要传输的真实数据
密文：针对明文加密之后的结果（往往是不直观、不易理解的）
加密：明文=》密文的过程就称之为加密
解密：密文=》明文的过程就称之为解密
在加密和解密过程中，往往需要借助一个或者多个中间数据进行辅助，这样的数据就称之为 “密钥”
对称加密：加密和解密的过程中使用的是同一个"密钥"
非对称加密：加密和解密的过程中使用的是不同的"密钥"，此时这两个密钥是成对出现的，比如k1、k2，使用k1进行加密，此时就是使用k2进行解密；使用k2进行加密，此时就是使用k1进行解密，这两个密钥，被公开出去的就是 “公钥” ，自己持有的就是 “私钥” ，且如果只知道一个密钥，是无法知道另一个的存在的，这一系列特性背后都是"密码学"涉及的数学原理，在此不展开讨论！

3. HTTPS工作过程

既然要保证数据安全，那么就需要进行"加密"，网络传输的过程中就不再直接传输明文信息，而是加密后的"密文"，加密的方式与算法有很多，但是整体可以分为两大类：对称加密 和 非对称加密

3.1 引入对称加密

我们之前提到过对称加密关键在于加密与解密的过程使用的是 同一个密钥 ，具有以下两个特点：

1. 客户端和服务器无论谁生成密钥都需要告知对方（网络传输）
2. 不同的客户端使用的应该是不同的密钥，如果所有的客户端使用的都是同一个密钥，那么这个密钥形同虚设

这就是问题的关键！比如说不同的客户端随机生成各自的对称加密密钥，都需要进行网络传输告诉服务器密钥值，因此这个过程中 黑客有可能拿到密钥的值 这样一来所有加密解密都是浮云！

此时黑客设备如果知道了密钥是"888888"，那么后续加密传输的数据黑客也是可以解密出来的！如果对这个密钥继续使用"对称加密"算法加密呢？此时又继续需要传输密钥key2，那么在这个过程中黑客还是有可能拿到key2的值，因此单纯使用对称加密无法实现数据安全传输！

3.2 引入非对称加密

引入非对称加密的目的就在于 给对称密钥加密 ，如何来理解这个问题呢？由于服务器持有的称为私钥，公钥就可以暴露出去，因此客户端拿到公钥后就可以对 对称密钥 进行加密再传输给服务器，此时注意黑客是可以获取到公钥的，但是黑客这样就无法对加密后的对称密钥进行解密了，因为解密需要私钥，而私钥是服务器具备的，服务器使用私钥解密获得对称密钥的值，后续数据传输都基于这个对称密钥进行加密就实现了数据的安全传输，上述涉及的概念较多，我们还是使用图的方式来呈现其中的过程：

其中的关键就在于虽然非对称加密的公钥是可以暴露给所有人的，但是客户端使用公钥对 对称秘钥key 进行加密，此时黑客想要解密，必须知道 私钥 ，不巧的是私钥只有服务器端持有，因此这样就保证了客户端和服务器都知晓了对称秘钥key的值但是黑客不知道！

这里还有一个小问题，为什么不直接使用非对称秘钥对数据进行加密传输呢？因为非对称加密算法的解密成本比较大，非常耗费CPU硬件资源，因此无法支持大规模数据的加密传输，但是如果仅仅是加密解密对称秘钥的开销还是可控的！

3.3 中间人攻击漏洞

但是上述过程还存在着一个严重的"安全漏洞"，业界称之为"中间人攻击"，其关键在于服务器可以构造出一对私钥和公钥，但是黑客也可以构造出自己的公钥和私钥！如此一来黑客就可以冒充服务器，其过程可以描述如下图所示：

其中黑客既假扮了服务器欺骗客户端，又假扮了客户端欺骗服务器：

1. 假扮服务器：生成一对非对称密钥pub2以及pri2，当服务器返回公钥pub1时，欺骗客户端返回自己的公钥pub2，此时后续客户端使用pub2将对称密钥进行加密，黑客可以使用私钥pri2解密对称密钥
2. 假扮客户端：客户端实际上使用的是黑客提供的公钥pub2将对称加密密钥进行加密，如果直接将该加密结果返回给服务器，服务器使用自己的私钥pri1就会解密失败！因此黑客还会使用pub2对加密秘钥重新加密以此欺骗服务器

那么应该如何解决上述的 中间人攻击 呢？最关键的一点就在于客户端有能力知道返回的公钥究竟是服务器的还是经过黑客伪造的，这就要借助HTTPS证书了

3.4 HTTPS证书

这就要求服务器提供一个HTTPS证书，这个证书是一个结构化的数据，包含了一系列的信息，例如服务器的域名、证书有效期、第三方公证机构信息，这个证书是需要服务器的搭建者从第三方公证机构中申请的！那么问题来了，这个证书显然也是会经过黑客之手的，那么黑客是否有可能修改其中的内容呢？？? 答案是不行的，因为客户端会先对证书进行验证：
证书验证过程：
一个证书可以看做具有以下内容：

1. 服务器域名
2. 证书有效时间
3. 第三方公证机构信息
4. 服务器公钥
5. 证书签名

其中最重要的就是这个"证书签名"字段了，此处的"证书签名"本质上是一个加密的校验和（把证书中其他字段内容通过某种一系列算法生成校验和），然后使用公证机构的私钥进行加密
客户端拿到这个证书之后，主要做两件事：

• 使用相同的校验和生成算法对其他字段内容进行计算，生成校验和1
• 使用系统内置的第三方公证机构的公钥对证书签名进行解密，得到解密后的校验和2

此时只需要比对校验和1和校验和2是否一致就可以判断黑客是否篡改了其中的部分内容！

比如说：

1. 黑客尝试修改服务器公钥，不修改证书签名，此时客户端生成的校验和1就与解密之后的校验和2不一致
2. 黑客尝试修改服务器公钥，并且修改证书签名，此时黑客不知道公证机构的私钥，因此无法重新加密，那黑客拿自己的私钥进行加密呢？客户端使用公证机构的公钥就会解密失败！
3. 黑客使用自己申请的证书替换呢？那么客户端检查服务器域名的时候就会发现猫腻！

此时，就基本上将黑客窃取并修改的可能扼杀在摇篮里了！HTTPS的工作流程大致如上所示