HTTPS协议了解

一 https介绍        

        先前我们看到http协议的整个报文都是明文的，只要被截取就都能看得懂，所以说http完全没有安全可言，必须要加密。所以就有了HTTPS，和http一样都是应用层协议。已经到HTTPS了，我想我们应该要对应用层协议有个概念了。先前说https就是http协议的加密版。

这个图很方便我们理解HTTPS和HTTP的区别。

        那https如何加密的呢，其实也很简单，我们之前是把数据序列化转为字符串传递，这是个明文传递，现在我们要写个加密函数，加密完再发送。所以https的重点在于如何加密的。

可是如何保证用户用https访问，服务端也用https协议来解释。用端口号来区分不同协议的服务端进程。我在http中曾解释过成熟的应用层协议是和服务端端口号一一绑定的。

二 加密解密过程

        明文通过密钥加密转为密文，密文通过密钥解密转为明文，例如7就是密钥，10异或7就变成其它的数据了。

为什么要解密，因为我们曾经加过密。为什么要加密，不加密你的数据就是明文传递的啦，那不就泄露了吗。在以前我们下载一个软件，其实就是往服务端发起请求，然后服务端给你响应，这个时候就有很多中间人，例如运营商，它可以轻易截取你的请求，并修改，你说你要下载一个qq，运营商修改你的请求，给你加了很多其它的软件。

        为什么运营商和黑客这些中间人能拿到我们的数据，我的手机明明在我手上。不如先想想为什么我们欠费了不能给其他人打电话，却可以打电话给运营商，就是因为我们发消息是先给运营商，由运营商去发送，如果发现你欠费就不让你发送了。那黑客如何拿到我们的数据呢，用免费wife来钓鱼，我们链接了别人的wife，数据就要先发给别人，由别人的手机去发送，这个时候黑客就可以获取用户数据。

如果现在加密了，这些中间人例如黑客就没那么容易篡改我们的请求了。

三 常见加密方式

        1 对称加密

只有一个密钥，这个密钥既可以加密也可以用来解密。

        2 非对称加密

        之前对称加密锁就是钥匙，钥匙就是锁，现在是非对称加密就有两个密钥，一个密钥用来加密，另一个就可以用来解密，也就是说锁和钥匙的角色可以互换，神奇吧。这两个密钥可以一个设为公开，一个设为私有，不能都为私有或者公开(全网公开，随便你获取)，

当我们将加密密钥公开时，此时解密密钥就必须为私密的；一般传输重要文件防止泄露就可以用公开密钥加密，私有密钥解密。

当我们将解密密钥公开时，加密密钥就要设为私密的。这不是谁都可以看文件了吗，是滴，我们不在乎是否泄露，而是在乎这个文件是不是由某人发的，当我们能用这个公开的解密密钥成功解密时，就说明这个文件确实是某人发的，因为加密密钥是私密的。

       3 数据摘要和数据指纹

        数据摘要又称数据指纹，是可以标定一份数据的唯一性的，使用如下。对原始文本使用hash算法，将其转为特定长度的字符串序列，比较两个文本是否相等可以比较字符串，而不用比较大文本，可以判断数据是否被篡改，因为一旦篡改原始文本，此时hash算法算出来结果就大不相同了。

        4 数据摘要应用1

        我们每次输入密码，为啥软件会告诉我们密码正确或者错误，它是怎么知道的，难道直接保存了我们的密码，我们输入一次作对比吗，如果软件公司内部出了叛徒，那我们的密码不就被泄露了吗，所以软件公司为了以免泄露，就都保存摘要，而不是保存密码。

        5 数据摘要应用2

        我们往百度网盘传数据时，有时候百度会提供一个秒传功能，这是什么意思呢? 因为我们传入的数据可能别人传过了，如何保证别人上传的和我要上传的一样，就是用数据摘要作对比，百度网盘会提供秒传来把别人传的文件和你的用户空间相连接，这样对用户来说上传速度变快，百度网盘也不用保存重复资源了。

注意:数字签名是数据摘要被加密后的称呼。

四 https的加密方案

 1 只使用对称加密

        客户端和服务端拿到同一个对称密钥，传输数据时就用这个密钥加密，对方再解密，黑客截取数据也没事，因为不知道密钥。

        可是服务端会有很多个客户端，难道都要给一个对称密钥，而且要保证对称密钥的唯一性，不然谁和黑客拿到一个那不就倒霉了(黑客可以大范围尝试，看看可以解密哪个客户端的信息)，那管理成本会很高。

       既然服务端不想苦哈哈地管理那么多密钥，你可能会说，我服务器每次通信生成一个传过去呗，这样就很难会和别人在同一时候拿到同一个密钥，服务端只要管理当前生成的密钥就好了，还不用担心和黑客的密钥一样了，那传密钥的时候被黑客获取了怎么办。

        那我内置到我的客户端软件呗，你内置那服务端不就又要管理很多密钥，而且黑客下载软件不也能拿到一个密钥吗，万一有些用户的密钥和黑客的一样，那不是倒霉了。所以要解决两个问题，密钥唯一性管理的问题，客户端服务端保持密钥一致的问题。
 

2 只使用非对称加密

        服务器要给客户端响应，先生成一对密钥，此时解密密钥是私密的，设加密密钥为公开的，这样每次通信才生成，服务端管理密钥的数量就减少了，因为我们每个人使用一个软件的时间段是不一样的。在通信时把公开密钥发送过去，然后客户端通信就用公钥加密给服务端发数据，黑客没有解密密钥，拿到数据也没用，此时就保证了客户端到服务端的数据安全，可是有个问题是服务端给客户端发数据，如何保证信息安全，此时服务端难道用私密密钥加密，然后客户端用公开的密钥解密，那不是谁都能看到消息了，我们知道对称密钥一个用于加密，另一个就可以解密。所以新方案如下。

3 双方使用非对称加密

        服务端和客户端都生成密钥，服务端拿着公钥S和S'，客户端拿着公钥C和私钥C'，服务端客户端交换公钥，之后客户端给服务端发消息，就用S加密，服务端S'解密，安全性保证了，服务端给客户端发消息，就用S加密，然后客户端用S'解密，也保证了安全性。

缺陷

        加密速度比较慢，因为加密解密的运算一般是大数乘法，而对称加密解密则是位运算，而且也有安全问题，好，你们交换公钥后就没问题了，那我交换前做手脚呢，我让你客户端服务端拿到的都是黑客的密钥，你用黑客的密钥加密，那黑客不是照样能拿到你们发的数据吗。

4 非对称+对称加密

        我们先解决效率的问题，服务端生成非对称密钥，然后将公钥发送给客户端，客户端本地生成的对称密钥用服务端的公钥加密，然后发给服务端，只有服务端能拿到客户端的对称密钥，之后就用对称密钥加密解密来通信，这样效率就变高了。

        也有安全问题，上述方案2,3,4,都有一样的安全问题，就是把交换的公开密钥给替换了。

        上面方案情况都能被攻击，核心原因就是客户端无法验证公钥的合法性。当然客户端和服务端也无法判断这个数据和发出前是否被篡改，用数据摘要也没办法，黑客可以直接不用你的报文，有数据摘要有什么用。

5 安全问题解决

        解决公钥的合法性，服务端要先生成公钥私钥对，然后申请证书前推送公钥给CA机构，我们一般用公钥加密，私钥解密，CA机构给服务端发一个证书，服务端通信时把证书发给客户端，然后此时客户端生成对称密钥，用证书上的公钥加密发给服务端，之后就用对称密钥通信。每次通信前服务端就发这个证书，客户端知道证书上的公钥一定是合法的，就用这个加密了，这个证书不会被截取和替换吗。放心，我们接下来就看看证书的构成就知道了。

        证书由两部分构成，一个是明文信息，还有个数字签名，数字签名就是数据摘要加密后形成的。CA机构生成一个非对称密钥对，用私钥加密数据摘要，由于CA机构是官方标准机构，所以公钥就内置在客户端服务端程序中了。接下来分明文信息和数字签名来讨论证书安全性。

        明文信息如果被黑客截取并修改，此时客户端用公钥解密数字签名，也对明文信息做数据摘要，两个摘要一对比就知道是否有人修改过明文信息。

        那数字签名被修改了呢?好，黑客可以解密，但是用什么密钥加密呢，加密密钥可只有CA机构才有，中间人如果用自己的密钥加密，客户端用标准的公钥一解密，发现解不了，就知道被证书被替换了。

这样就不用担心中间人制作假的证书了，那如果中间人申请一个真的证书去替换服务端发的证书呢，因为浏览器要对比证书的服务端域名是不是自己要访问的，一看不是，就会报错说网站证书有问题了。

        最后一个问题，为什么我们要有数据摘要，而不是直接对明文做加密呢? 1 这个安全方案适用于大多数场景，有时候报文可能很长，加密解密对比时间很长，不如用摘要做对比，所以说这套方案安全性和效率都很不错。