漫谈威胁建模下的安全通信

前言

这次文章的主要内容是一次内部技术分享的内容，主要是关于安全通信的威胁建模，设计方案以及算法，其中涉及https。

通信的安全威胁与诉求

在讲解安全通信的方案之前，我们必须要知道通信有哪些安全威胁以及诉求，这样我们才能“对症下药”。根据微软提出的STRIDE威胁模型作为依据：

• Spoofing（伪装）
• Tampering（篡改）
• Repudiation（抵赖）
• Information Disclosure（信息泄露）
• Denial of Service（拒绝服务）
• Elevation of Privilege（提升权限）

STRIDE威胁模型几乎可以涵盖目前绝大部分安全问题，并且有着详细的流程和方法。每一个维度都对应的一个安全属性，也就是相应的安全诉求。

将威胁模型对应到安全数据通信上，前四个对我们来说更有意义，总结一下，安全通信的诉求包括：

1. 完整性：通信的内容信息必须要完整，不可被篡改掉或者存在数据丢失；
2. 机密性：通信的内容必须要得到有效的隐藏和保护，避免被泄漏到第三方；
3. 认证性：包括实体认证和消息认证，其中实体认证是指通信的发送方和接收方是可信的未被假冒的，而消息认证是指消息是由认证过的实体用户发出的，不是被仿冒者发出的；
4. 不可抵赖性：通信的数据携带有实体特质、不可被模仿复制的信息，确保通信数据是可确认的实体发出的。

接下来我们会根据对应的安全诉求来设计安全通信方案。

加密算法

在讲安全通信的方案之前，我们首先说一下通信加密算法，之后我们会使用这些算法来实现上面的安全诉求。

加密算法大体上可以分为三类：对称加密，非对称加密以及信息摘要。

对称加密

对称加密双方的通信密钥是统一的，特点是加解密效率高，而安全性就稍微弱一些。常见的算法例如AES，DES

非对称加密

特点是它拥有两个密钥，任意一个密钥都可以对信息进行加密处理，但是解密就需要用到另外一个密钥才能解析出正确的明文，安全性较高，但是效率低一些。常见的算法例如RSA，DSA。

信息摘要

特点是唯一性，不可逆，常见的算法例如MD5，SHA1。

HTTPS安全通信设计方案

下面咱们根据上述的安全诉求来拆解 HTTPS协议，在描述的过程中，大家肯定会有熟悉的感觉，既是拆解也是我们的设计。

完整性

完整性是靠信息摘要来保证的，将算出的摘要附到明文后，万一明文被修改，只要使用同样的算法得出明文摘要和原始摘要进行对比，不一样就证明被修改了。

但是在上图中，大家会发现，在生成摘要后，我们还会对摘要进行加密生成消息认证码。这是为什么呢？

备注：“通信消息+信息摘要+对称加密=数据验证码”的做法，就是通信中常见的MAC（Message Authorization Code，消息认证码）的实现。

大家可以想一下，如果我将明文修改，然后我又根据修改后的明文生成摘要，将原来的摘要替换掉，这样是不是依然无法发现明文已经被修改了，所以就有了之后的加密步骤。完整性也是需要机密性来保证的，相辅相成。

机密性

机密性在于通信的数据是否被加密，一般频繁的数据加解密，我们采用的是对称加密算法，对于服务器的消耗是很低的，这里的对称密钥我们称之为会话密钥(Session Key)。为什么称作会话密钥? 是因为每次建立通信连接都是随机生成一个对称密钥。会话通信既然是对称加密，那它的安全性是主要在于两点：

1. 使用的对称加密算法是否安全，会不会被破解
2. 对称密钥的交换过程是否安全，会不会被窃取

至于第一点，我们不会考虑这件事，这是密码学家的工作。对称密钥交换的安全是通信的关键，密钥在传输的过程中被窃取，那可真的是裸奔了。我们采用的是公私钥交换体系，下图是SSL/TLS协议握手建立连接的交换密钥简化过程。

在上图的第四步，通过随机数x,y,z生成了会话密钥，但是我们发现在前两步，x和y在传输过程中都是暴露的，因此会话密钥的安全性在于第三步的z的交换。

B使用了非对称加密算法，生成了一对公私钥，公钥交给了A，自己持有私钥。在密钥交换的过程中，A生成随机数z，通过B的公钥进行加密，B接收到数据，使用私钥进行解密得到z，从而保证了z的安全性，最终保证了会话密钥的安全性，防止在通信过程中被窃取。

一句话：通过非对称加密保证了对称加密的安全。

不可抵赖性

在经过完整性和机密性的加持后，通信数据是否就真的安全了？还是有风险。在机密性讲解过程中，我们知道会话密钥是通过公私钥的方式进行交换的，其中A用到了B的公钥，漏洞就在这：A获取B公钥的过程是安全的吗？这存在被劫持的可能性(例如DNS劫持)，A获取到公钥不一定是B的，A可能会被伪造的B所欺骗。下图是利用这个漏洞进行的中间人攻击图：

通过劫持的方式，我们将随机数z在中途获取了，之后的加密通信基本上就是裸奔了，数据可以随便改。这就是http容易被DNS劫持的原因，那https是如何解决这个问题的呢？

这个问题的本质是A无法验证消息的来源是B，这就涉及不可抵赖性了。不可抵赖性的一般做法是使用数字签名，保证A获取的是B公钥，需要对B的公钥进行数字签名。

数字签名

下面描绘一下使用数字签名的场景，主角是A与B：

B手头有点紧，急需用钱，然后发邮件给A，邮件内容为：B借A 100万，银行卡号为xxxxxxx，这个时候A如果把钱打给B就会有以下风险：

• 邮件是可以伪造的，可能是诈骗团伙的发给A的
• 假如邮件确实是B发的，但是事后不承认，A也没有证据证明是B发。

如何解决A的困惑呢？在上述场景中，邮件就是我们所说的消息。在讲解机密性的时候，我们知道公钥是公开的，而私钥则是独有，隐蔽的，因此私钥是可以代表持有者的身份。

那么如果B把邮件的内容使用B的私钥进行加密，然后将加密后的密文即数字签名，附在邮件后面发给A，A这个时候只需要拿B的公钥解密数字签名，并和邮件原文进行比对，就可以确定是不是B发的了，这是非对称加密的特性，B私钥加密的，只有B的公钥才能解密，这就可以解决抵赖的问题了，哈哈哈。

看似完美。。。

在上述的解决方案中，有个巨大的漏洞：数字签名和公钥在传输中都是暴露的，不可信的，B的身份需要A拿B的公钥对数字签名进行解密来证明，那反问一下，A拿到的确定是B的公钥吗？假如B的公钥被篡改为C的，那么数字签名是不是有可能被篡改为由C的私钥进行加密的？

一身冷汗！！！ 陷入了死循环，我们自以为解决了消息内容的抵赖问题，却没解决公钥的抵赖问题，从而导致消息内容的抵赖问题也无法解决，尴尬尴尬！！！

其实如果公钥的传输是可信的，那么数字签名还是可以解决抵赖问题的。想了一个好办法：

A 与B直接见面，互相把公钥交换一下，就可以。

开了个玩笑，两个人可以面对面，确实安全，但是很多人呢？不同的设备呢？面对面的成本实在太高了。

认证性

数字签名中遇到的尴尬，咱们对应到上面中间人攻击的那张图，出现劫持的问题原因是A无法验证B公钥的来源，假如是使用数字签名的话，那么B需要用自己的私钥对自己公钥进行签名，然后将签名附到公钥后面一起发给A。类似下图所示：

大家想一下是不是没什么用，由于公私钥可以互相加解密，中间人完全可以同时替换公钥和数字签名完成伪装。咱们可以思考一下，问题的症结在哪？数字签名用来识别消息篡改，伪装以及防止抵赖，但是我们又必须从没有被伪装的发送者得到没有被篡改的公钥才行，所以解决这个问题，就一句话：

在公钥传输不可信的情况下，数字签名这种证明身份的事情，不能让消息的双方来做。

举个现实中的例子，比如我们的公民身份证，身份证的签发是由公安机关来做的，给我们分配唯一标识身份证号，同时在数据库中存储与之对应的照片信息，这就是我们每个人的”数字签名“。如果身份证的签发由我们个人来做，那想伪造成谁都可以，同样 数字签名，我们需要找一个可信的第三方来做，这就涉及了认证性。

CA证书

认证性和不可抵赖性，他们相互依存，都处在HTTPS协议中的同一组件：CA证书。

备注：CA (数字证书认证机构)：负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

是不是感觉有点抽象？简单解释就是CA给B颁发了身份证，A拿着B的身份证去CA机构比对身份证合法性，从而确定B的身份。至于如何保证身份证的真实性，我们下面会讲。

首先看一下CA签发的证书长什么模样，其实就是一个文件。还是以B为例，下图是CA机构给B颁发的证书。

证书主要包括5个部分：

1. 签发者信息CA
2. 使用者信息B
3. B的密钥信息
4. B的公钥
5. 数字签名

其中数字签名是由CA机构的私钥对证书上的信息(包括公钥)进行加密生成的。首先说一下，证书是如何解决上述问题的，以数字签名那一节中的场景为例：

1.B手头有点紧，急需用钱，首先通过邮件将自己在CA机构申请的证书发给A。 2.A收到邮件后，看到证书签发者的信息是CA，于是拿着证书找CA机构，CA机构用自己的公钥对数字签名进行解密，并比对使用者信息，密钥信息等内容。如果一致，说明这是给B签发的证书，公钥是B的。 3.接着B写邮件，邮件内容为：B借A100万，银行卡号为xxxxxxx，B把邮件的内容使用B的私钥进行加密，然后将加密后的密文即数字签名，附在邮件后面发给A， 4.A这个时候只需要拿B的公钥解密数字签名，并和邮件原文进行比对，就可以确定是不是B发的了

在上述场景中，基本上把证书的作用说明白了，当然https的实现方式会复杂一些，不过本质是一样的。我们看到通过证书的方式，B的公钥是没办法被中间人替换的，除非CA机构的私钥泄露。。。。。。

证书签发与证书链

证书签发

如果我们有一个网站需要使用https,则需要申请证书，以B为例，申请证书需要两步：

1.生成请求信息

2.生成签名合成证书

通过以上的过程就生成了一个合法的证书，但是真实的情况下，CA不可能随便给每个用户签名的，因为CA的私钥是非常机密，随便签发增加泄露的可能性。既然自己干不了，那就找 “代理商”，进行分级签发证书。

证书链

CA为了减轻自己的工作同时也是保护私钥的机密，打算招两级代理 A与B（也可以多招几级），A是一级代理，B是二级代理。这个时候C需要生成合法的证书，直接找B即可，每一级的签发流程如下：

反向校验

在上图中，C找到B生成了证书，之前我们知道要验证证书中公钥的合法性，需要去找证书的签发者进行解密校验，同样道理，证书链也是这个流程，只不过是找了多级，C找B，B找A，A找CA。

大家有没有发现最后一级，CA怎么还有证书？谁给他签名呀？

自签名

为了打通整个证书链，CA自身需要有证书，也就是自签名，很好理解，CA必须要信任自己，自签名的证书被称为根证书。

证书链位置

SSL/TLS协议

证书链的存在就是为了解决图5中B的公钥传输可信问题，B其实就是我们的网站（服务端），A是使用的浏览器（客户端）。证书链的位置如图所示：

可能这样看的有点抽象，访问一下知乎，点击地址栏上的锁，会出现证书：

点击证书就可以查看，这就是从知乎网站服务器返回的证书链。

如果你使用wireshark抓包的话，会更加生动地看到传输的证书链：

客户端本地

浏览器内置了一些可信的根证书和中间证书(大代理)：

当浏览器获得服务器返回的证书链，需要对证书链进行一级一级地校验，如果校验的证书链的最后一级属于浏览器的可信证书，则建立连接，正常通信，否则会被浏览器标识为不安全，甚至断开通信。

潜在的风险

虽然通过上面的方式，整个方案已经非常完美了，但是依然存在风险，不是方案不安全，而是人不安全。问题就出现在证书链上：

1. 证书链中CA机构的保密性最高，但是他的代理不一定了，只要黑客渗透到他的代理商里，窃取私钥进行签发证书，就可以骗过证书链的检测。（已经发生过）
2. 供应链攻击：比如浏览器被黑客内置了一些自签名的根证书，用户下载恶意的浏览器，通信都是不安全的。其实我们对浏览器或者app进行抓包，也是用了这种方法。

最后

推荐一个自己写的一个抓包工具，代码简短明了，方便大家看到证书的伪造和签名流程。

https://github.com/qiyeboy/BaseProxy

推荐两本同事大佬的书，很厉害：

参考文献

https://www.secrss.com/articles/3298

https://blog.51cto.com/11883699/216003