密码技术（十四）之SSL/TLS

作者: Invincibled | 来源:发表于2019-04-20 18:25 被阅读0次

SSL/TLS

————为了更安全的通信

什么是SSL/TLS

SSL/TLS综合运用了前面提到的对称密码、消息认证码、公钥密码、数字签名、伪随机数生成器等密码技术。严格来说SSL（Secure Socket Layer）与TLS（Transport Layer Security）是不同的，TLS相当于是SSL的后续版本。这里介绍的大多是SSL/TLS两者兼具备的，因此，除具体介绍通信协议外，都统一写作SSL/TLS。

Alice在Bob书店买书

Bob书店是Alice 经常光顾的一家网店，因为在Bob书店她可以搜索到新出版的图书，还可以通过信用卡快速完成支付，购买的书还能快递到家，非常方便。
有一天，Alice读了一本关于网络信息安全的书，书上说“互联网上传输数据都是可以被窃听的”。Alice非常担心，自己在购买新书的时候输入的信用卡号会不会被窃听了呢？
Alice看到Bob书店的网站下面写着一行字：“在以https://开头的网页中输入的信息将通过SSL/TLS发送以确保安全”。
的确，输入信用卡号的网页URL是以https://开头的，而不是一般的http://。此外，在浏览这个网页时，Alice的Web浏览器上还会显示一个小锁头图标，看上去好像挺安全的。
但Alice心想，就算写者通过SSL/TLS发送我也不放心，到底在我的Web浏览器和Bob书店的网站之间都发生了哪些事情呢?

客户端与服务器端

Alice的Web浏览器（客户端）和Bob书店网站（服务器）进行HTTP通信.png

Alice和Bob书店之间的通信，实际上是Alice所使用的Web服务器和Bob书店的Web服务器之间的通信。Web浏览器是Alice的计算机上运行的一个程序，而Web服务器则是在Bob书店的计算机上运行的一个程序，它们都遵循一种HTTP（HyperText Transfer Protocol，超文本传输协议）的协议来进行通信。其中，Web浏览器称为HTTP客户端，Web服务器称为HTTP服务器。
当Alice点击网页上的链接或者输入URL时，Web浏览器就会通过网络向Web服务器发送一个“我要浏览这个网页”的请求。
Web服务器则将请求的网页内容发送给Web浏览器，以便对请求作出响应。服务器和客户端之间所进行的处理就是请求和响应的往复。HTTp可以认为是HTTP客户端与HTTP服务器端之间进行的请求和响应的规范。
Alice向Bob书店发送信用卡号也是使用HTTP来完成的。Alice输入信用卡号之后按下提交按钮，这是客户端就会将信用卡号作为HTTP请求发送给服务器端。服务器则会将“生成订单”的网页作为HTTP响应返回给客户端。
如果直接发送请求的话，信用卡号就可能被窃听。

不使用SSL/TLS发送信用卡号的情形.png

用SSL/TLS承载HTTP

当Web浏览器发送信用卡号时，信用卡号的数据会作为客户端请求发送给服务器。如果通信内容被窃听者Eve窃取，Eve就会得到信用卡号。
于是，我们可以使用SSL或TLS作为对通信进行加密的协议，然后在此基础上承载HTTP。通过将两种协议进行叠加，我们就可以对HTTP的通信协议进行加密，从而防止窃听。通过SSL/TLS进行通信加密时，URL不是http://开头的，而是以https://开头。

用SSL/TLS承载HTTP，对请求和响应进行加密.png

SSL/TLS的工作

大致了解SSL/TLS之后，我们想要实现的是通过本地的Web浏览器访问网络上的Web服务器，并进行安全的通信。就是Alice希望通过Web浏览器向Bob书店发送信用卡号。

Alice的信用卡号和地址在发送到Bob书店的过程中不能被窃听。
Alice的信用卡号和地址在发送给Bob书店的过程中不能被篡改。
确认通信对方的Web服务器是真正的Bob书店。
1，机密性问题，2 完整性问题，3，认证问题。
要确保机密性，可以使用对称密码。由于对称密码的密钥不能被攻击者预测，因此我们使用伪随机数生成器来生成密钥。若要将对称密码的密钥发送给通信对象，可以使用公钥密码或者Diffie-Hellman密码交换。
要识别篡改，对数据进行认证，可以使用消息认证码。消息认证码是使用单向散列函数来实现的。
要对通信对象进行认证，可以使用对公钥加上数字签名所生成的证书。

SSL/TLS也可以保护其他的协议

我们提到用SSL/TLS承载HTTP通信，这是因为HTTP是一种常用的协议，其实SSL/TLS不仅仅可以承载HTTP,还可以承载其他很多协议。例如，发送邮件时所使用的SMTP协议和接收邮件时使用的POP3协议，都可以用SSL/TLS进行承载。这样就可以对收发邮件进行保护。
SSL/TLS承载HTTP、SMTP、POP3的结构如图所示。

用SSL/TLS承载HTTP、SMTP和POP3.png

密码套件

SSL/TLS提供了一种密码通信的框架，这意味着SSL/TLS中使用的对称密码、公钥密码、数字签名、单向散列函数等技术，都是可以像零件一样进行替换的，也就是说，如果发现现在所使用的某个密码技术存在弱点，那么只要将这一部分今天替换就可以了。
尽管如此，也不是说所有的组件都可以自由的选择。由于实际进行对话的客户端和服务器端必须使用相同的密码技术才能进行通信，因此如果选择过于自由，就能以保证整体的兼容性。为此，SSL/TLS就像事先搭配好了饭盒一样，规定了一些密码技术的“推荐套餐”，这种推荐套餐成密码套件。

SSL/TLS的区别

SSL（Secure Socket Layer，安全套接字）是1994年由网景（Netscape）公司设计的一种协议，并在该公司的Web浏览器Netscape Navigator中进行了事先。随后，很多Web浏览器都采用了这一协议，使其成为了事实上行业标准。SSL已经于1995年发布了3.0版本，但是在2014年，SSL3.0协议就被发现可能导致POODLEDE安全漏洞（CVE-2014-3566），因此SSL3.0已经不安全了。
TLS（Transport Layer Security，传输层安全）是IETF在3.0基础上设计的协议。在1999年作为RFC2246
发布的TLS，实际上相当于SSL3.1。
2006年，TLS1.1以RFC4346的形式发布，这个版本中增加了针对CBC攻击的策略，并加入了AES对称密码算法。TLS1.2中新增了对GCM、CCM认证加密的支持，此外，还新增了HMAC-SHA256，并删除了IDEA和DES，将伪随机数函数改为基于SHA-256来实现。

使用SSL/TLS进行通信

层次化的协议

TLS协议是由TLS记录协议（TLS record protocol）和TLS握手协议（TLS handshake protocol）这两层协议叠加而成的。位于底层的TLS记录协议负责进行加密，而位于上层的TLS握手协议则负责除了加密以外的其他各种操作。上层的TLS握手协议又可以分为4个子协议。TLS协议层次结构如图。

TLS协议的层次结构.png

TLS记录协议
TLS记录协议位于TLS握手协议的下层，是负责使用对称密码对消息进行加密通信的部分。
TLS记录协议中使用了对称密码和消息认证码，但是具体的算法那和共享密钥则是通过握手写在服务器和客户端之间协商决定的。
TLS握手协议
2.1 握手协议
握手协议是TLS握手协议的一部分，负责在客户端和服务器端之间协商决定密码算法和共享密钥。基于证书的认证操作也在这个协议中完成。是最复杂的一个。
这个协议相当于下面这段对话
客户端：“你好。我能够理解的密码套件有RSA/3DES，或者DSS/AES，请问我们使用哪一种密码套件来通信呢？”
服务器：“你好。我们就用RSA/3DES来进行通信吧，这是我的证书。”
在服务器端和客户端之间通过握手协议协商一致后，就会相互发出信号来切换密码。负责发出信号的就是下面要介绍的密码规格变更协议。
2.2 密码规格变更协议
密码规格变更协议是TLS握手协议的一部分，负责向同学对象传达变更密码方式的信号。简单说，就跟对方喊“1、2、3！”差不多。
这个协议所发送的消息，大致相当于下面的对话
客户端：“好，我们按照刚才的约定切换密码吧。1、2、3！”
当协议中途发生错误时，就会通过下面的警告协议传达给对方。
2.3 警告协议
警告协议是TLS握手协议的一部分。警告协议负责在发生错误时将错误传达给对方。
这个协议所发送的消息，大致相当于下面的对话。
服务器：“刚才的消息无法正确解密哦！”
如果没有发生错误，则会使用下面的应用数据协议进行通信。
2.4 应用数据协议
应用数据协议是TLS握手协议的一部分。应用数据协议是将TLS上面承载的应用数据传达给通信对象的协议。

TLS中使用密码的技术小结

TLS握手协议中使用密码技术.png

TLS记录协议中使用的密码技术.png

对SSL/TLS的攻击

针对SSL/TLS中使用各个密码技术的攻击，会直接成为SSL/TLS的攻击，例如，如果能够找到SSL/TLS中所使用对称密码的弱点，就相当于找到SSL/TLS通信机密性的弱点。
然而，SSL/TLS作为框架的特性也正是在这里能够得以体现。SSL/TLS并不依赖某种特定的密码技术，当发现某种对称密码存在弱点时，今后只要选择不包含该对称密码的密码套件就可以了。就好像一台机器零件损坏，只要更换这个损坏零件就可以了。

OpenSSL的心脏出血漏洞

2014年，Google的Neel Mehta 发现了广泛使用的密码学工具包OpenSSL中存在一个bug，这个漏洞称为心脏出血。心脏出血并不是SSL/TLS协议本身的漏洞，而是OpenSSL这一实现上的漏洞。
具体来说，由于OpenSSL在TLS心跳扩展功能中对于请求的数据大小没有进行检查，从而导致误将内存中与该请求无关的信息返回给请求者，这就是心脏出血漏洞。攻击者通过访问使用了包含该漏洞的OpenSSL的服务器，就可以在一定范围内窃取服务器上的信息。
这一漏洞公布时，全世界有相当度偶的服务器都受到了影响，根据当时有17%的SSL/TLS服务器都具有这一漏洞。由于这一漏洞会造成原本需要安全通信的服务器上的数据泄露，因此称为了一个急需应对的严重漏洞。
要应对这一漏洞，可以将OpenSSL更新到已消除心脏出血漏洞的版本，或是加上禁止用心跳扩展的选项重新编译OpenSSL。

SSL3.0的漏洞与POODLE攻击

2014年，Google的Bodo Moller、Thai Duong 和Krzysztof Kotowicz发表了一篇题为This POODLE Bites ： Exploiting The SSL3.0 Fallback的论文，其中描述了一种针对SSL3.0漏洞的攻击——POODLE攻击。
SSL3.0中对CBC模式加密时的分组填充操作没有进行严格的规定，而且填充数据的完整性没有受到消息认证码的保护，POODLE攻击正是利用了这一漏洞来窃取秘密信息的。POODLE攻击的本质就是我们前面在CBC模式的介绍中提到的填充提示攻击。
更严重的问题是，在某些条件下，攻击者可以将通信协议的版本从TLS强制降级到SSL3.0，也就是说，尽管有些服务器使用了TLS协议，但仍然有可能被强制降级到SSL3.0，导致存在遭受POODLE的攻击风险。
因此，要有效抵御POODLE攻击，必须禁用SSL3.0。

FREAK攻击与密码产品出口管制

2015年，一些研究者发现SSL/TLS中存在的一个漏洞，利用这一漏洞的攻击被称为FREAK攻击。FREAK是Factoring RSA Export Keys（出口级RSA密钥质因数分解）的缩写，其攻击方法是强制SSL/TLS服务器使用一种名为RSA Export Suites的强度较低的密码套件。要实现FREAK攻击，除了需要SSL/TLS服务器具有该漏洞，同时还需要用户的Web浏览器接受使用RSA Export Suites来进行通信。
美国曾经将密码算法和软件作为武器来看待，因此历史上一度禁止将“高强度密码软件”出口到国外（密码产品管制），直到20世纪90年代后半期这一政策才有所缓和。RSA Export Suites就是一种配合当时的环境而故意弱化的密码套件。RSA Export Suites中使用512比特的RSA和40比特的DES，这一组合在当时还勉强够用，然而到了现在已经绝对不应该使用了。但实际上，现在全世界上还有很多Web服务器允许使用RSA Export Suites，就连OpenSSL等SSL/TLS工具包在实现上也没有禁用RSA Export Suites，这使得FREAK攻击称为了可能。
FREAK攻击也是一种中间人攻击，当浏览器与Web服务器协商SSL/TLS的密码套件时，攻击者Mallory可以介入其中，强制双方使用 RSA Export Suites，强制双方使方使用RSA Export Suites。如果浏览器和Web服务器双方都具备该漏洞，那么他们便会按照Mallory的指示开始使用RSA Export Suites进行通信。通常情况下，在密码套件确定之后，双方的通信就开始加密，这是Mallory应该无法窃听其中的内容，然而由于RSA Export Suites 的强度非常低，因此Mallory可以暴力破解共享密钥，从而能够对本应安全传输的数据进行解密。这一漏洞编号为CVE-2015-0204.
在密码产品出口管制实行20年后，FREAK漏洞威胁显现出来。

对伪随机数生成器的攻击

1995年，加州大学伯克利分校的研究生David Wagner 和Lan Goldberg发现了Netscape Navigator 浏览器的一个bug。而且他们并没有阅读浏览器的源代码，而是通过一般人都可以得到的程序文件找出这个bug的。他们将这个bug的危险性进行了广泛的告知。
这个bug存在于为随机数生成器中。由于SSL中使用的伪随机数生成器的种子都在时间和进程编号等可预测的范内，因此所得到的密钥范围实际上非常下。

利用证书的时间差进行攻击

SSL/TLS中，客户端会使用服务器端证书对服务器进行认证。在这个过程中，客户端需要使用合法认证机构的公钥对证书所附带的数字签名进行验证。
正如我们在签名提到那样，要验证证书需要使用最新的CRL，而Web浏览器如果没有获取最新版的CRL，即便使用SSL/TLS也无法保证通信安全。

SSL/TLS用户的注意事项

不要误解证书的含义

在SSL/TLS中，我们能够通过证书对服务器进行认证。然而这里的认证，只是确认了通信对象是经过认证机构确认的服务器，而并不能确认是否可以和该通信对象进行安全的在线购物交易。更直白说，就是即便对方拥有合法的证书，也不代表你就可以放心地发送信用卡号，因为仅仅通过SSL/TLS是无法确认对方是否在从事信用卡咋骗的。
此外，认证机构所进行的本人身份确认也分为不同的等级，需要咨询确认一下认证机构的业务规则。
为了提高SSL运用的可靠性，一个名为CA/Browser论坛的组织制定了EV SSL证书规范。

密码通信之前的数据是不受保护的

这个很好理解，比如，Alice在浏览器中输入敏感信息时，背后有人偷看，这个SSL/TLS是无法保护的。

密码通信指挥的数据是不受保护的。

这个也很好理解，如果Bob服务器对于客户的数据存储，保护没有做好，就会发生客户敏感信息泄露的的风险。

该系列的主要内容来自《图解密码技术第三版》
我只是知识的搬运工
文章中的插图来源于原著