【技术整理】HTTPS安全设计思路

本文是由我在公司的技术分享中抽取部分内容重新书写的文章。公司的技术分享原本讲的是开发人员常用的工具，然后由charles引申出网络安全的思考。
本篇文章以HTTPs的设计理念为主线，讲解网络安全思路，文中会提到一些charles软件相关的知识，特此提前告之，避免各位觉得讲解内容突然提到charles很奇怪。

概述

谈到Https, 我们可以想到的关键词有：对称/非对称加密、p12证书、CA机构等等。
网上有非常多的文章去讲解这些事。我当年每次面试前，都会去记一次，但过了几个月又会忘掉。所以，我换了另一个思路去记忆Https的原理、机制：Http的安全性很低，为什么目前会设计成Https这样的安全思路？如果是我，有没有别的办法去设计安全连接？Https有没有漏洞？

黑客手段

抛去木马这种靠骗术、软件完全获取到所有用户设备信息的手段不谈，黑客对于网络方面的手段可以简单理解为：黑客能做到charles软件提供的各项功能。

Charles基本功能（针对Http）

抓包：看到用户端请求的所有参数，以及服务端返回的所有信息

更改请求数据：将请求中的某些参数更改

Charles对应功能：Rewrite\断点Debug联调

更改结果数据：将服务器返回回来的信息做更改

Charles对应功能：Map Remote\Map Local\Rewrite

黑客如何做到Charles类似的功能（针对Http）

方法1: DNS截持

本来用户请求的域名是www.baidu.com，正确通过DNS解析的IP应该是xxx.xxx.xxx.xxx, 却被劫持到yyy.yyy.yyy.yyy的黑客服务器下，黑客获取到用户的请求信息后，可以随意阅览、修改信息，再转发到正确的IP服务器下；收到服务器的返回结果，可以随意阅览、修改信息后，将修改后的结果发给用户。

方法2:设置免费的WIFI

人们登上了这种黑客设置的WIFI，发送、返回的所有请求、结果，黑客都可以通过自己路由器的权限随意更改。

被黑客攻破的结果

如果你访问网站、使用的APP健全性不够（用的Http协议，关键信息未加密），那么黑客可以了解你访问过哪些网站、看过哪些内容、发过哪些言论、登录的用户名和密码是什么、仿造你的token冒充你去与银行和支付软件进行转账操作（前提是银行的软件、支付软件本身的安全校验功能不高）。

从Http到Https的安全方案

image.png

Http是明文传输的，在黑客已经成功截持了用户客户端浏览器的情况下，我们如何将Http协议增强安全性呢？

方案1: 简单对称加密

image.png

浏览器在与服务器进行沟通时，首先告诉服务端：“我们以后用密钥为A的对称性加密方式进行沟通”，服务端看到消息后，用公钥A加密消息，回复给浏览器。

方案1黑客破解

image.png

浏览器在第一次告诉服务端以后沟通的密钥是A时，中间的黑客已经获取到这条信息。所以，未来浏览器与服务端的加密沟通，黑客都可以破解，任意更改两边发送的消息。

方案2: 可信的第三方介入(CA机构)

浏览器与服务端的通信是不可靠的，因为作为其中一边，你完全无法判断对面的是你真正想交流的对象还是黑客冒充的对象。
那么此时，引入可信的第三方（CA机构）。CA机构使用非对称加密，将加密私钥自己保留，解钥公钥公布出去，供各个浏览器、客户端下载使用。

（提前说明，这仍是个不安全的设计思路）

image.png

设计方案：

1. （这一步就有错误，诸位可以自己想想错在哪里）服务端在上线前，将自己的公司信息、未来供给浏览器的对称加密密钥（图中的密钥B）发给CA，CA将这些信息通过自己的加密私钥加密后，生成证书发给服务端（这个证书我们称为CA证书）。
2. 未来服务端上线后，与浏览器进行通信。将自己的明文公司信息、CA机构名、CA证书发给浏览器。
3. 浏览器使用之前下载保留好的对应的CA解密公钥将CA证书解密，对比解密后的信息是否与服务端给的明文信息相同，如果相同，则认为校验通过。
4. 使用CA证书里服务端提供的对称加密密钥（图中的密钥B）将信息加密与服务端开始通信。

方案2黑客破解

这种方案仍然会有安全性问题。原因见下图后的文案说明：

image.png

原因：CA机构的解密公钥是对所有人公开的，服务端如果直接传的是对称型加密密钥，那么中间的黑客也可以获取服务端对称加密密钥，仍可以在中间冒充双方进行沟通。对称加密的消息对黑客来说相当于明文。

方案3:将服务端封入证书的对称密钥改为非对称加密的加密公钥(也就是HTTPS使用的方案)

image.png

设计方案：

1. （与方案2不同）服务端在上线前，将自己的公司信息、未来供给浏览器的非对称加密的加密公钥（图中的密钥B）发给CA，CA将这些信息通过自己的加密私钥加密后，生成证书发给服务端（这个证书我们称为CA证书）。
2. (与方案2第2步相同)未来服务端上线后，与浏览器进行通信。将自己的明文公司信息、CA机构名、CA证书发给浏览器。
3. (与方案2第3步相同)浏览器使用之前下载保留好的对应的CA解密公钥将CA证书解密，对比解密后的信息是否与服务端给的明文信息相同，如果相同，则认为校验通过。
4. （与方案2不同）使用CA证书里服务端提供的非对称加密的加密公钥（图中的密钥B）将未来沟通使用的 对称加密密钥（图中的密钥C） 加密传给服务端。
5. （新加步骤）未来客户端浏览器与服务端使用对称加密密钥（图中的密钥C）互相沟通。

一个细节注意，第4步，客户端浏览器也可以传给服务端一个自己的非对称加密的加密公钥，解密私钥自己保留。这样，客户端浏览器与服务端的通信可以使用对方提供的加密公钥去加密信息互相沟通。也可以保证消息的安全性。
但HTTPS为什么没有用这种方案呢？
答案是：对称加密的加密、解密时间消耗更小，所以，在确保安全的前提下，要尽量使用对称加密去互相通讯。

方案3黑客尝试破解，显然破解会失败

image.png

1. 黑客可以破解服务端初次传给客户端浏览器的信息（图中XX），获取到服务端的公司信息与非对称加密的加密密钥B
2. 当客户端浏览器收到信息XX，返加信息YY时，黑客无法知道客户端浏览器发了什么内容
3. 黑客唯一能做的，就是完全屏蔽掉浏览器对服务端的通信，自己去和服务端通信。但这样做对于窃取更改数据的目的来说， 是无意义的。黑客相当于自己开了个浏览器上网，无法获取到用户的任何信息。
4. 发生了这种事，对于客户端浏览器来说，就是显示请求异常，无法上网，但保证了自身信息的安全性。

总结

以上概述，希望各位能对“对称/非对称加密、p12证书、CA机构”这些关键词有进一步的理解。
何时使用对称加密？何时使用非对称加密？p12证书是什么？CA证书里面有什么内容？为什么要有CA机构来配合通信？Https真的是100%保证数据安全的吗？
这些问题，都弄清楚怎么回事，我们才会真正懂得HTTPS的意义。

题外话

对于非技术人员，提醒一些安全性方面的小建议：

1. 不要随使用公用的免费wifi，黑客喜欢开这种wifi来截取用户的信息。
2. 尽量不访问浏览器标记为“通信不安全”的网站，这些网站没有使用一个合格的Https CA证书，有被黑客攻破的风险。
3. 使用手机客户端时，如果手机登录了不安全的wifi，那么你自己的信息会不会泄露，全依靠客户端的开发人员是否将客户端设计的安全(是否用https通信、信息是否做了一些加密)。