《计算机网络安全原理》第7章 传输层安全

本PPT是电子工业出版社出版的教材《计算机网络安全原理》配套教学PPT（部分内容的深度和广度在教材的基础上有所扩展），作者：吴礼发本PPT可能直接或间接采用了网上资源、公开学术报告中的部分PPT页面、图片、文字，引用时我们力求在该PPT的备注栏或标题栏中注明出处，如果有疏漏之处，敬请谅解。同时对被引用资源或报告的作者表示诚挚的谢意！本PPT可免费使用、修改，使用时请保留此页。声明第七章传输层安全内容提纲SSL2TLS3SSL/TLSVPN4传输层安全问题1传输层安全为保证网络应用间，特别是应用广泛的Web应用数据传输的安全性（机密性、完整性和真实性），可以在多个网络层次上采取安全措施。

IP/IPSec

TCP

HTTPFTPSMTP

IP

TCP

HTTPFTPSMTP

IP

UDP

SSLorTLS

TCP

Kerberos

SMTP

HTTP

S/MIME

(a)网络层(b)传输层(c)应用层UDP协议源端口目的端口长度检验和数据数据首部首部UDP用户数据报IP数据报2222字节发送在前UDP协议可用于风暴型DDoS。由于UDP协议不需要与目标建立连接，因此攻击者很容易通过伪造源地址的方式向目标发送攻击报文，非常简单易行攻击者利用控制的僵尸网络中的大量主机向攻击目标（主机或网络设备）发送大量的UDP数据包，使其忙于处理和回应UDP报文，导致目标设备不能提供正常服务或者直接死机，严重的会造成全网瘫痪。UDP协议TCP协议TCP协议TCP协议安全性分析网络扫描拒绝服务（DoS）攻击TCP会话劫持攻击TCP协议端口扫描TCP协议端口扫描：TCPConnect扫描TCPSYN扫描TCPFIN扫描Xmas扫描和Null扫描TCP协议DDoS攻击：TCPSYNFloodingTCP协议连接劫持：TCP协议只要TCP包中的源端口、目的端口、Seq、Ack正确，即可被正确接收。当得到入侵者构造的TCP数据包，协议会假设数据包是来源于TCP连接中另一方的合法数据包，并且发送响应包到（入侵者构造的数据包中设置的IP地址）。随后，原来的TCP连接会由于计数器不匹配而断开连接。连接劫持：TCP协议关键：猜测Seq、Ack，如果是旁路劫持还需猜测源端口号连接劫持：TCP协议连接劫持：TCP协议连接劫持：TCP协议连接劫持：TCP协议连接劫持：TCP协议连接劫持：TCP协议连接劫持：TCP协议连接劫持：TCP协议连接劫持：TCP协议连接劫持：TCP协议USENIXSECURITY2016连接劫持：TCP协议USENIXSECURITY2016RFC5961连接劫持：TCP协议USENIXSECURITY2016连接劫持：TCP协议USENIXSECURITY2016GeekPwn2016连接劫持：TCP协议USENIXSECURITY2018连接劫持：TCP协议USENIXSECURITY2018连接劫持：TCP协议USENIXSECURITY2018连接劫持：TCP协议USENIXSECURITY2018连接劫持：TCP协议USENIXSECURITY2018连接劫持：TCP协议USENIXSECURITY2018连接劫持：TCP协议USENIXSECURITY2018连接劫持：TCP协议USENIXSECURITY2018连接劫持：TCP协议USENIXSECURITY2018GeekPwn2017内容提纲SSL2TLS3SSL/TLSVPN4传输层安全问题1由于Web应用协议主要通过传输层的TCP协议来传输其协议报文，而TCP协议不支持加密和认证，因此并不能保证Web应用传输上的安全网景公司（Netscape）于1994年开发了安全套接字（SecuritySocketLayer,SSL）协议SSL版本：2.0(1995年)、3.0(1996年，2011年RFC6101)Web安全需求Web安全需求SSL利用TCP协议为上层应用提供端到端的安全传输服务，包括认证和加密SSL体系结构

IP

TCP

SSL握手协议

SSL记录协议SSL密码变更规格协议SSL告警协议HTTP协议SSL体系结构SSL体系结构SSL几个协议之间的关系是：使用握手协议协商加密和MAC算法以及保密密钥，以及身份认证使用密码变更规格协议变更连接上使用的密码机制使用记录协议对交换的数据进行加密和签名使用告警协议定义数据传输过程中出现的问题并通知相关方SSL体系结构SSL两个重要概念连接（connection）：是指一种能够提供合适服务类型的传输通道。对SSL来说，这种连接是点对点、暂时的。每条连接都与一个会话关联会话（session）：是指客户与服务器之间的一种关联，由握手协议创建，定义了一组多个连接共享的密码安全参数。定义会话的目的主要是避免为每次建立连接而进行复杂的密码参数协商过程SSL体系结构SSL两个重要概念任何一对通信实体（如客户和服务器上的HTTP应用）之间可以有多条安全连接，理论上也允许一对实体之间同时有多个会话，实际上很少出现每个会话有多种状态一旦会话建立，就进入当前操作（发送和接收）状态。在握手协议执行期间，会进入读（接收）挂起状态和写（发送）挂起状态。握手完成，挂起状态又回到当前操作状态SSL体系结构SSL连接状态参数SSL体系结构SSL会话状态参数SSL体系结构SSL保障的安全属性：机密性：SSL客户机和服务器之间传送加密数据。完整性：SSL可避免服务器和客户机之间的信息被破坏。认证性：SSL握手时要求交换证书，通过验证证书来保证对方身份的合法性。SSL实现的安全服务一、SSL记录协议记录协议在SSL握手协议完成客户端和服务器之间的握手过程后使用，即客户端和服务器完成双方的身份鉴别并确定安全信息交换使用的算法后执行保密性：使用握手协议得到的传统加密共享密钥来加密SSL载荷来实现保密性完整性：使用握手协议得到的MAC共享密钥对SSL载荷进行消息完整性检验SSL记录协议报文格式SSL记录协议明文（压缩可选）内容类型MAC（0,

16或20字节）主版本次版本压缩后的长度加密记录协议对应用数据的处理过程SSL记录协议

应用数据分段压缩添加MAC加密添加SSL首部记录协议支持的加密算法SSL记录协议SSL采用的是链式加密（数字信封）方法：采用对称加密算法加密消息（SSL记录协议），用公开密码算法交换对加密算法的对称密钥（SSL握手协议）SSL记录协议二、SSL密码变更规格协议协议由一个仅包含1字节且值为1的消息组成，使得连接从挂起状态改变到当前状态，用于更新此连接使用的密码组问题：为什么不作为其它协议（如握手协议）的一条报文而要独立成一个协议？密码变更规格协议1(a)密码更改规范协议报文格式1

B三、Alert协议当客户端和服务器发现错误时，需要通过告警协议向对方发送一个告警消息同应用数据一样，SSL告警协议报文同样交由SSL记录协议进行压缩和加密处理后发送告警协议协议格式：第1个字节表示告警类型：值1表示告警，值2表示致命错误。如果是致命错误，则SSL立即关闭SSL连接，而会话中的其它连接将继续进行，但不会再在此会话中建立新连接第2个字节包含指定告警信息的代码告警协议类型(b)告警协议报文格式1

B告警1

B告警协议四、握手协议SSL握手协议是客户端和服务器用SSL连接通信时使用的第一个子协议，在开始传输上层应用数据之前使用。该协议允许服务器和客户端相互验证，协商加密和MAC算法以及加密密钥，用来保护在SSL记录协议中发送的数据握手协议协议格式握手协议类型长度内容1

B3

B≥0

B(c)握手协议报文格式协议格式握手协议客户端与服务器之间建立逻辑连接的初始交换过程包括四个阶段握手协议握手协议为了更好理解SSL协议的握手过程，结合实例，使用Wireshark抓包分析SSL握手过程中客户端与服务器间的交互过程。下面以访问为例，使用Wireshark抓包分析SSL/TLS握手过程中客户端与服务器间的交互过程。本例中服务器/（72），客户端为本机浏览器（2）。握手协议ClientHello消息握手协议：阶段1ClientHello消息握手协议：阶段1ServerHello消息握手协议：阶段1Certificate消息握手协议：阶段2Certificate消息握手协议：阶段2Certificate消息握手协议：阶段2Certificate消息握手协议：阶段2服务器发送完Certificate消息后继续发送ServerKeyExchange和ServerHelloDone消息，ServerKeyExchange消息中包含有密钥交换算法所需要的额外参数。ServerHelloDone消息表示服务器已发送完此阶段的全部信息握手协议：阶段3与4客户端发送ClientKeyExchange和ChangeCipherSpec消息握手协议：阶段3与4接着服务器同样发送ChangeCipherSpec消息通知服务器到客户端的握手过程结束，并发送一个加密的握手消息EncryptedHandshakeMessage握手协议：阶段3与4之后，服务端也会使用SessionSecret加密一段

Finished消息发送给客户端，以验证之前通过握手建立起来的加密通道是否成功。根据之前的握手信息，如果客户端和服务端都能对Finished信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的SessionSecret对数据进行加密传输了。握手协议：阶段3与4五、密钥生成共享主密钥是利用安全密钥交换为此会话建立的一个一次性48字节的值，生成过程分两步：第一步交换预备主密钥（握手协议的“阶段3”）第二步双方计算主密钥。密钥生成计算主密钥计算主密钥‘A’PMCRCS‘BB’PMCRCS‘CCC’PMCRCSSHA-1SHA-1SHA-1PM散列PM散列PM散列MD5MD5MD5散列散列散列PM：预备主密钥SR：服务器随机数CR：客户端随机数主密钥（48字节）密钥参数生成‘A’MCRCS‘BB’MCRCS‘···’MCRCSSHA-1SHA-1SHA-1M散列M散列M散列MD5MD5MD5散列散列散列M：主密钥SR：服务器随机数CR：客户端随机数密钥参数······六、SSL安全性分析SSL的安全性分析SSL协议的安全性隐患1）预主密钥master_secretSSL会话密钥2）能否保证随机数质量也是SSL的安全隐患。3）有可能遭受中间人攻击。4）利用SSL的攻击无法被IDS检测和FW过滤到。5）Web服务器使用SSL时，吞吐量会显著下降。6）不能保证Web浏览器和服务器自身安全。2023/11/2486增强SSL安全性

增强master_secret的保密性预主密钥的口令加密方法和硬件加密方法。提高随机数的质量用硬件随机数发生器产生的随机数作为产生随机数的软件方法PRNG的种子，进行高强度处理。提高证书CA的可靠性在服务器认证阶段，CA控制所有证书的颁发和有效性判断。2023/11/2487内容提纲SSL2TLS3SSL/TLSVPN4传输层安全问题1IETF在SSL3.0版本的基础上制定了SSL的互联网标准版本，称为“传输层安全”(TransportLayerSecurity，TLS)，使SSL更安全、协议规范更精确和完善。2011年发布的RFC6167中建议禁用SSL2.0,2015年发布的RFC7568中建议禁用SSL3.0TLS版本：TLS1.0(RFC2246,1999)，TLS1.1(RFC4346,2006)，TLS1.2(RFC5246,2008)，TLS1.3(RFC8446,2018)。其中，TLS1.0对应SSL的3.0版名称：SSL,SSL/TLSTLS版本号TLS1.0的主版本为3,次版本为1，而与之对应的SSL3.0的主版本为3，次版本为0。TLS1.1的主版本为3，次版本为2消息认证码TLS的MAC与SSL3.0的MAC有两点不同：TLS使用RFC2104中定义的HMAC算法；TLS使用称为“PRF”的伪随机函数TLS与SSL的差异告警码除no_certificate外，TLS继承了SSL3.0中定义的所有告警码。另外，还定义了新的告警码密码套件TLS和SSL3.0存在细小差别，即TLS不支持Fortezza密钥交换、加密算法，而SSL3.0是支持的TLS与SSL的差异客户端证书类型在CertificateRequest消息中，TLS支持SSL3.0中定义的rsa_sign,dss_sign,rsa_fixed_dh和dss_fixed_dh证书，但不支持SSL3.0支持的rsa_ephemeral_dh,dss_ephemeral和fortezza_kea证书TLS与SSL的差异CertificateVerify消息TLS在CertificateVerify消息中计算MD5和SHA-1散列码时，计算的输入与SSL3.0有少许差别，但安全性相当仅对handshake_message进行MD5或SHA-1散列值计算，而在SSL3.0中散列值计算还包括主密钥和填充，但这些额外信息似乎并没有增加安全性TLS与SSL的差异Finished消息TLS在Finished消息中计算MD5和SHA-1散列码时，计算的输入与SSL3.0有少许差别，但安全性相当TLS与SSL的差异密码计算TLS和SSL3.0在计算主密钥值（mastersecret）时采用的方式不同，过程如下：TLS与SSL的差异填充在SSL中，填充后的数据长度正好是分组加密算法中分组长度的最小整数倍。而TLS填充后的数据长度可以是分组长度的任意整数倍（但填充最大长度为255字节）。例如，如果明文（如果使用了压缩算法则是压缩后的明文）加MAC再加上表示填充长度的1个字节共79字节，则填充长度按字节计算时可以是1、9、17、25等，直到249。这种可变填充长度可以防止基于对报文长度进行分析的攻击TLS与SSL的差异2018年8月，经过28次草案后，IETF正式发布了TLS1.3版（RFC8446），这也是TLS演进史上最大的一次改变。改变主要集中在性能和安全性上TLS1.3首先是安全上的考虑TLS广泛的应用使得其成为了攻击者的“众矢之的”，这些攻击或利用TLS设计本身存在的不足（如幸运十三攻击、三次握手攻击、跨协议攻击等），或利用TLS所用密码原语本身的缺陷（如RC4加密、RSA-PKCS#1v1.5加密等），或利用TLS实现库中的漏洞（如心脏出血攻击等）TLS1.3其次是性能上的考虑近年来，对网络上所有通信使用加密传输已经成为了主流趋势，很多Web应用都开始强制使用基于TLS的HTTPS，而不是采用明文传输的HTTP。这对保护我们在网络上传输的数据避免被窃听和注入攻击有积极影响，但是不足之处在于交互双方必须运行复杂的TLS握手协议才能开始传输信息。TLS1.3禁止使用RSA密钥交换算法“RSA密钥交换”和基于Diffie-Hellman协议的匿名Diffie-Hellman交换和瞬时Diffie-Hellman交换，这两种模式都可以让客户端和服务器得到共享秘钥，但是RSA模式有一个严重的缺陷：它不满足前向保密（forwardsecret），以及“百万消息攻击”等攻击仅保留瞬时Diffie-Hellman作为唯一的秘钥交换机制TLS1.3减少不安全的Diffie-Hellman参数选项选择Diffie-Hellman参数时，提供太多的选项会导致选择出错误的选项。TLS1.3删除不安全的认证加密方法CBC模式和填充之间的交互也是SSL3.0和一些TLS实现中出现的著名的POODLE漏洞的成因。TLS1.3中允许的唯一认证加密方法是AEAD（AuthenticatedEncryptionwithAdditionalData），它将机密性和完整性整合到一个无缝操作中TLS1.3POODLE漏洞禁止一些安全性较弱的密码原语TLS1.3已删除所有可能存在问题的密码组件和密码模式，包括CBC模式密码或不安全的流式密码，如RC4。建议用SHA-2，不建议使用安全性较弱的MD5和SHA-1TLS1.3对整个握手过程签名在TLS1.2及更早版本中，服务器的签名仅涵盖部分握手协议报文，其它使用对称MAC来确保握手未被篡改。这种疏忽导致了许多严重的安全漏洞，如FREAK、LogJam攻击等。FREAK攻击也称为降级攻击TLS1.3服务器对整个握手记录进行签名，包括密钥协商，避免三次握手攻击。此外，还实现了握手协议和记录协议的密钥分离。TLS1.3性能上的改进SSL：“2-RTT(RoundTripTime)”，200msTLS1.3舍弃了RSA的密钥协商过程，然后基于ECDH密钥协商算法（EC即椭圆曲线，DH是指“Diffie-Hellman”）优化了整个过程，改为“1-RTT

”TLS1.3除了对新建连接过