网络与系统安全关于SSL/TSL协议的分析

Posted 2020-10-14

前言

TSL协议的前身是由网景（Netscape）公司于1994年研发的安全套接字（Secure Socket Layer）协议。它建立在TCP协议栈的传输层，用于保护面向连接的TCP通信。实际TSL1.0就是SSL3.1，因此文献中常用SSL/TSL统称它们，下文仅用TSL。
TSL工作在TCP之上，应用层之下。而在TSL中又分为上下两层，所以用一个简单的示意图描述它们在协议栈中的位置如下图，想要更了解SSL/TSL可以查看图解SSL/TSL：

实验

本次实验是在windows7下完成，采用的工具是wireshark1.8，浏览器为IE10。
任意选择一个采用https协议的网站，我这里选择的是www.baidu.com。
开启wireshark抓包模式，然后再浏览器中输入百度的url，等待百度首页加载完成，停止抓包，筛选器的字段为ip.addr == 61.135.169.125 && tcp。
首先是我们熟悉的TCP三次握手过程，绿框圈住的部分，之前分析过TCP三次握手过程，所以就不再仔细剖析它了：

然后就是TLS协议，先从整体上看一下TSL握手的整个过程。用五颜六色框住的就是跟TSL握手过程有关的数据包（右侧有标注，由于wireshark数据包本身就有颜色，所以这里标注的颜色难免有些受影响，仔细看还是可以看清楚的）。：

大体上看下来，得出的结论就是百度采用的TSL握手协议为单向认证的握手，即只验证服务器端，而不验证客户端。百度肯定希望尽可能多的用户使用，所以肯定不会采用双向验证，所以推测我们常用的网站都是采用单向验证。
接下来我们把这6个包都来分析一下：

客户端向服务器端say hello，当三次握手完成后，紧接着客户端就向服务器端发送ClientHello消息，该消息包括客户端推荐的密码算法标识、参数和一个在密钥协商中协议需要的一个随机数。图中被黄颜色框住的为重要信息。其中Random和Cipher Suites没有被框出来，压缩算法为空。

服务器端向客户端say hello。一方面是为了回应客户端发来的握手请求，另一方面也携带了一些必要的信息，比如：某个随机数，服务器选定的加密算法等。图中用红色框住的就是关于该数据包的关键信息。密钥交换算法为RSA，数据加密为128位密钥的AES算法，数据校验算法为SHA256（下面可以看到为什么是256）。

服务器端向客户端发送certificate消息，该消息包含服务器的公钥证书。

接下来就是服务器端向服务端发送的ServerHelloDone消息，表示响应完毕。有一个问题就是在这个包中还包含一个ServerKeyExchange，在单向认证过程中应该没有这条消息的，不知道为什么会出现，还望老师帮忙解释。

随后就是ClientKeyExchange和ChangeCipherSpec消息，由客户端在收到服务器端响应后，对服务器的公钥证书进行验证，验证不通过就会出现TLS警告；验证通过后向服务器端发送。其中ChangeCipherSpec表示客户端已经按照商定的算法改变了加密策略。这里密钥交换算法为DH（Diffie-Hellman），如图中被蓝色框住的部分；红色框住的为该数据包中包含的TSL握手消息。

最后是服务器端发送给客户端的ChangeCipherSpec，表示确认。至此整个单向验正的TLS握手过程完成，接下来双方开始进行加密数据传输连接，即以后所有的数据都被加密传输。

总结：

上面的过程是采用单向认证的TLS握手协议过程，所以我想找一个采用双向握手的，双向认证需要使用客户端的公钥，而我接触到要用到自己公钥的网站和应用就只有git（国外和国内oschina都可以），而且公钥还是自己生成的，而且而且只有使用git等命令推送或拷贝代码时才会验证公钥，鉴于限制条件比较多，所以我就没有测试。
TLS容易遭受某些 DoS 攻击。例如，攻击者创建很多TCP连接，就可以让服务器忙于做 RSA 解密计算。其实TSL协议本身就需要很长的计算时间，由于现今服务器端的升级以及网速地提高正好可以弥补这些消耗带来的不便。任何事情的发展都符合这个规律，没有的时候，有就是发展的目标，有了之后质量更高就会成为新的目标。比如我们国家从“站起来”到“富起来”的转变。尽管TLS有很大的不便，但相比HTTP协议，HTTPS协议更符合当下时代的要求。