计算机网络安全原理（第2版）课件 第6、7章 IP与路由安全、传输层安全

第六章IP与路由安全内容提纲IPsec2

IPv6协议及其安全性分析3路由安全4

IPv4协议及其安全性分析1IPv4安全性分析IPv4协议没有认证机制：没有消息源认证：源地址假冒没有完整性认证：篡改IPv4安全性分析IPv4协议没有认证机制：没有消息源认证：源地址假冒没有完整性认证：篡改IPv4安全性分析IPv4协议没有认证机制：没有消息源认证：源地址假冒没有完整性认证：篡改IPv4安全性分析IPv4协议没有认证机制：没有消息源认证：源地址假冒没有完整性认证：篡改IPv4没有加密机制无机密性：监听应用数据泄露拓扑等信息：网络侦察无带宽控制：DDoS攻击IPv4内容提纲IPsec2

IPv6协议及其安全性分析3路由安全4

IPv4协议及其安全性分析1IPsec

(IPSecurity)端到端的确保IP通信安全：认证、加密及密钥管理为IPv6制定（必选），支持IPv4（可选）IPsecIPsec标准内容IPsecIPSec安全体系AH协议ESP协议加密算法验证算法DOI密钥管理（IKE协议）RFC4301RFC4303RFC4302RFC5996IPsec标准内容IPsecIPsec标准内容IPsec通过允许系统选择所需的安全协议（AH协议或ESP协议），决定服务所使用的加密或认证算法，提供任何服务需要的密钥来提供IP级的安全服务。RFC4301中列出的安全服务包括：访问控制、无连接完整性、数据源认证、重放检测与拒绝（部分顺序完整性）、保密性（通过加密）以及有限的流量保密性IPsec一、IPsec安全策略IPsec操作的基础是应用于每一个从源端到目的端传输的IP包上的安全策略。IPsec安全策略主要由两个交互的数据库，安全关联数据库（SecurityAssociationDatabase,SAD）和安全策略数据库（SecurityPolicyDatabase,SPD)来确定安全策略IPsec操作的基础是应用于每一个从源端到目的端传输的IP包上的安全策略。安全策略IKEv2SPD安全策略数据库SAD密钥交换安全关联数据库IKE

SAIPsecv3SAD安全关联数据库IPsecv3IKEv2SPD安全策略数据库IPsecSA对ESP保护数据IPsec安全体系安全关联（SecurityAssociation,SA）一个SA：发送端和接收端之间的单向逻辑连接，为数据流提供安全服务；经过同一SA的数据流会得到相同的安全服务，如AH或ESPSA对：双向安全数据交换同时支持AH、ESP且双向：需两对SA安全关联SA一个SA由以下参数确定安全参数索引（SecurityParametersIndex,SPI）：32位，，接收方根据SPI选择合适的SA处理接收到的数据包IP目的地址：仅允许单播地址安全协议标识（SecurityProtocolIdentifier）：AH

/ESP安全关联SASAD定义了所有SA相关的参数，每个SA：安全参数索引序列号计算器序列计数器溢出反重放窗口AH信息ESP信息安全关联的生存期IPsec协议模式：：隧道、传输或通配符最大传输单元路径（pathMTU）安全关联SASAD定义了所有SA相关的参数，每个SA：安全关联SA不同SA可以用多种方式组合以获得理想的用户配置。此外，IPsec对需要IPsec保护的流量和不需要IPsec保护的流量提供多种粒度的控制安全关联SA安全策略（SecurityPolicy,SP）指定对IP数据包提供何种保护，并以何种方式实施保护主要根据源IP、目的IP、入数据还是出数据等来标识用户设定自己的安全策略的粒度：IP地址，传输层协议，TCP/UDP端口号操作：Discard、Bypass、Protect安全策略SPSPD中的每一条SP包括：本地IP远程IP下一层协议名称本地或远程端口安全策略SP基于SAD和SPD，IPsec对IP包的处理IP包处理过程

外向IP包（来自TCP或UDP）丢弃报文查询SPD确定策略发现匹配丢弃查询SAD保护网络密钥交换无匹配匹配处理(AH/ESP)通过IP传输报文通过无匹配外向(Outboud)IP包处理过程基于SAD和SPD，IPsec对IP包的处理IP包处理过程内向(Inboud)IP包处理过程将报文传输到上层（如TCP、UDP）查询SPD丢弃

报文查询SAD报文类型不通过处理(AH/ESP)匹配无匹配IPIPsec

内向IP包（来自因特网）通过二、IPsec运行模式两种模式：传输模式和隧道模式IPsec运行模式传输模式隧道模式传输模式和隧道模式比较三、AH协议学习AH和ESP要关注以下几个问题:加密、认证的范围（即对IP协议报文的哪些部分进行保护）传输模式与隧道模式在保护对象、性能、适用场景等方面的差别与NAT的兼容性问题AH协议AH协议功能：IP包的数据完整性、数据来源认证和抗重放攻击服务完整性：采用HMAC算法：HMAC-MD5（必须）、HMAC-SHA1（必须）、HAMC-RIPEMD-160等抗重放：序列号AH协议AH首部AH协议下一个首部

认证数据（变长）载荷长度保留SPI

序列号

071531AH运行模式：传输模式AH协议IP首部（含选项字段）TCP首部（含选项字段）数据IP首部（含选项字段）TCP首部（含选项字段）数据AH首部认证区域（可变字段除外）（a）应用AH之前（b）应用AH（传输模式）之后AH运行模式：传输模式AH协议AH运行模式：隧道模式AH协议IP首部（含选项字段）TCP首部（含选项字段）数据IP首部（含选项字段）TCP首部（含选项字段）数据AH首部认证区域（可变字段除外）（a）应用AH之前（b）应用AH（隧道模式）之后新IP首部（含选项字段）AH运行模式：隧道模式AH协议抗重放攻击：序列号+滑动窗口机制AH协议…NN+1N－

W接收到有效包时标记未接收到有效包时不标记固定窗口大小W若接收到右边的有效包，则窗口前进完整性检验算法：在SA中指定AH协议完整性检验哪些字段参与计算？如何处理IPv4和IPv6首部中的三种字段：不变字段，可变但可预测字段，可变不可预测字段？AH协议完整性检验值ICVIPv4首部三种字段：AH协议完整性检验值ICVIPv6基本首部三种字段：IPv6扩展首部三种字段：AH协议讨论：AH传输模式和隧道模式的区别AH与NAT的兼容性问题AH协议四、ESP协议ESP协议功能：除了提供IP包的数据完整性、数据来源认证和抗重放攻击服务，还提供数据包加密和数据流加密服务完整性：采用HMAC算法：HMAC-MD5（必须）、HMAC-SHA1（必须）、HAMC-RIPEMD-160，NULL（无认证）等；ESP认证的数据范围要小于AH协议加密：对称密码，必须支持：DES-CBC和NULL算法（认证和加密不能同时为NULL）ESP协议ESP首部ESP协议填充长度

载荷数据（变长）填充（0～255字节）SPI

序列号

071531

认证数据（变长）

下一个首部ESP运行模式：传输模式ESP协议ESP运行模式：传输模式ESP协议ESP运行模式：传输模式ESP协议ESP运行模式：传输模式ESP协议ESP协议ESP运行模式：隧道模式ESP协议ESP运行模式：隧道模式ESP协议ESP运行模式：隧道模式ESP协议讨论：ESP传输模式和隧道模式的区别ESP传输模式下：如果修改了IP包的首部，IPsec是否能检测出来这种修改ESP与NAT的兼容性问题ESP与AH的区别ESP协议ESP传输模式与隧道模式对比隧道模式对整个IP包进行认证和加密，因此可以提供数据流加密服务，而传输模式由于IP包首部不被加密，因此无法提供数据流加密服务。但是，隧道模式由于增加了一个新IP首部，降低了链路的带宽利用率。传输模式适合于保护支持ESP协议的主机之间的通信连接，而隧道模式则在包含防火墙或其它用于保护可信内网不受外网攻击的安全网关的配置中比较有效ESP协议与NAT兼容问题：AH与NAT不兼容，而ESP不对IP包首部（含选项字段）进行认证，因此不存在和NAT不兼容的问题。如果通信的任何一方具有私有地址或在安全网关后面，仍然可以用ESP来保护其安全，因为NAT网关或安全网关可以修改IP首部中的源／目的IP地址来确保双方的通信不受影响ESP协议AH与ESP比较ESP协议ESP与AH比较

IPsec体系结构文档中指出，当两个传输模式SA被绑定，在同一个端对端流中允许AH和ESP两种协议，但认为只有先施ESP协议再实施AH协议才合适，为什么？讨论五、网络密钥交换IPsec支持以下两种密钥管理方式：手动（manual）：管理员为每个系统手动配置所需密钥，只适用于规模相对较小且结点配置相对稳定的环境自动（automated）：系统通过IKE（InternetKeyExchange）协议自动为SA创建密钥，适用于大型分布式系统中的密钥管理IPsec密钥管理IKEv1：默认的IPsec自动型密钥管理协议是ISAKMP/Oakley，包括：互联网安全关联和密钥管理协议（InternetSecurityAssociationandKeyManagementProtocol,ISAKMP）Oakley密钥确定协议（OakleyKeyDeterminationProtocol），基于Diffie-Hellman算法的密钥交换协议IKE在IKEv2中，不再使用术语ISAKMP和Oakley，并且对ISAKMP和Oakley的使用方式也发生了变化，但是基本功能还是相同的。后面介绍的内容是IKEv2IKEDiffie-Hellman回顾两个优点：①仅当需要时才生成密钥，减小了将密钥存储很长一段时间而致使遭受攻击的机会；②除对全局参数的约定外，密钥交换不需要事先存在的基础设施两个缺点：①没有提供双方身份的任何信息，因此易受中间人攻击；②算法是计算密集型的，容易遭受阻塞性攻击密钥确定协议IKE对Diffie-Hellman的改进：采用Cookie机制来防止拥塞攻击；允许双方协商得到一个组（group），相录于Diffie-Hellman密钥交换的全局参数；使用现时值来阻止重放攻击；允许交换Diffie-Hellman的公钥值；对Diffie-Hellman交换进行身份认证，以阻止中间人攻击密钥确定协议Cookie交换（Cookieexchange）要求各方在初始消息中发送一个伪随机数Cookie，并要求对方确认。此确认必须在Diffie-Hellman密钥交换的第一条消息中重复。如果源地址被伪造，则攻击者就不会收到应答。这样，攻击者仅能让用户产生应答而不会进行Diffie-Hellman计算Cookie机制ISAKMP规定Cookie的产生必须满足：Cookie必须依赖于特定的通信方，从而防止攻击者得到一个正在使用真正的IP地址和UDP端口的Cookie时，也无法用该Cookie向目标主机发送大量的来自随机选取的IP地址和端口号的请求来浪费目标主机的资源Cookie机制ISAKMP规定Cookie的产生必须满足：除了发起实体以外的任何实体都不可能产生被它承认的Cookie。这就意味着发起实体在产生和验证Cookie时，要使用本地的秘密信息，而且根据任何特定的Cookie都不可能推断出该秘密信息Cookie机制ISAKMP规定Cookie的产生必须满足：Cookie的产生和验证必须尽可能地快速完成，从而阻止企图通过占用处理器资源的阻塞攻击一种产生Cookie的方法是对以下信息进行HASH运算后，取前64位：

源IP地址+目的IP地址+UDP源端口+UDP目的端口+

随机数+当前日期+当前时间Cookie机制使用不同的组（group）进行Diffie-Hellman密钥交换。每个组包含两个全局参数的定义和算法标识。当前的规范包括如下几个组：GroupIKE使用现时值（nonce）来反重放攻击。每个现时值是本地产生的伪随机数，在应答中出现，并在交换时被加密以保护它的可用性防重放攻击IKE使用三种不同的身份认证方法：数字签名：用双方均可以得到的散列值进行签名来进行身份认证，每一方都用自己的私钥加密散列值。散列值使用重要的身份参数（如用户ID、现时值）来生成。公钥加密：利用对方公钥对用户身份参数（如用户ID、现时值）加密来进行身份认证。对称密钥加密：通过带外机制得到密钥，并且该密钥对交换的身份参数进行加密。身份认证IKEv1密钥交换过程密钥交换过程发送IKE安全提议接受提议发送密钥生成信息生成密钥发送身份和验证数据身份验证和交换过程验证查找匹配的提议发送确认的IKE安全提议生成密钥发送密钥生成消息身份验证和交换过程验证发送身份和验证数据协商发起方协商响应方①②③④⑤⑥发送IKE安全提议、密钥生成和身份信息查找匹配的提议算法，生成密钥和身份验证协商发起方协商响应方①接受提议和生成密钥发送密钥生成信息、身份信息和验证数据②发送验证数据交换过程验证③（a）主模式（b）积极模式IKEv2密钥交换过程密钥交换过程密钥交换过程发送IKE安全提议接受参数发送身份信息身份验证和交换过程验证查找匹配的提议发送确认的IKE安全参数身份验证和交换过程验证发送身份信息协商发起方协商响应方①②③④发送控制信息根据控制信息进行相应操作协商发起方协商响应方①接受信息回应控制信息②（a）初始交换过程（b）信息交换过程IKE协议定义了建立、协商、修改和删除安全关联的过程和报文格式。IKE报文由首部和一个或多个载荷组成，并包含在传输协议（规范要求在实现时必须支持UDP协议）IKE消息格式IKE消息格式

发起方SPI

应答方SPI

071531消息ID邻接载荷主版本次版本交换类型标记23长度

07

81531邻接载荷C保留载荷长度(a)

IKE首部(b)一般载荷首部载荷类型IKE消息格式载荷类型IKE消息格式IPsecv3和IKEv3协议依赖于多种密码算法。每种应用可能需要使用多种密码算法，而每种密码算法也有很多参数。为了提高互操作性，IETF通过RFC4308和RFC4869定义了各种应用的推荐密码算法和参数IKE密码组件RFC4308IKE密码组件RFC4869IKE密码组件同RFC4308一样，使用的密钥算法包括：加密：对于ESP，认证加密使用128位或256位的AES密码的GCM模式；对于IKE加密，与VPN密码组一样，使用密码分组链（CBC）模式；消息认证：对于ESP，如果只认证，则用GMAC；对于IKE，消息认证由使用SHA-3的HMAC来提供。伪随机数：同VPN密码组一样，IKEv2通过对重复使用消息认证的MAC来产生伪随机数。IKE密码组件对于Diffie-Hellman算法，规定使用椭圆曲线群上对素数求模。对于认证，也使用了椭圆曲线上的数字签名。早期的IKEv2文档使用的是基于RSA的数字签名。与RSA相比，使用ECC可以用更短的密钥就能达到相当或更高的安全强度IKE密码组件IKE交互过程抓包分析主模式第1条报文（6->4）IKE交互过程抓包分析主模式第2条报文（4->6）IKE交互过程抓包分析主模式的第3条报文（6->4）：密钥交换（KeyExchange）IKE交互过程抓包分析主模式第4条报文（4->6）IKE交互过程抓包分析主模式的第5条报文（6->4）IKE交互过程抓包分析主模式第6条报文（4->6）IKE交互过程抓包分析快速模式第1条报文（6->4）IKE交互过程抓包分析快速模式第2条报文（4->6）IKE交互过程抓包分析快速模式第3条报文（6->4）IKE交互过程抓包分析快速模式第4条报文（4->6）IKE交互过程抓包分析六、SA组合为什么要组合SA？单个SA只能实现AH协议或ESP协议，而不能同时实现这两者。但在实际应用中，一些流量需要同时调用由AH和ESP提供的服务，某些流量可能需要主机间的IPsec服务的同时还需要在安全网关（如防火墙）间得到IPsec提供的服务。在这些情况下，同一个流量可能需要多个SA才能获得想要的IPsec服务SA组合提供特定IPsec服务集而组合在一起的SA系列称为“安全关联束（SecurityAssociationBundle）”安全关联束中的SA可以在不同节点上终止，也可在同一个节点上终止两种方式将多个SA组合成安全关联束：传输邻接（transportadjacency）与隧道迭代（IteratedTunneling）SA组合在组合多个SA形成安全关联束时，需要考虑认证和加密的顺序问题先加密后认证先认证后加密SA组合SA组合SA组合SA组合SA组合SA组合七、IPsec的应用IPsec在IP层对所有流量进行加密和/或认证，因此能够保护各种基于IP的应用终端用户通过互联网实现安全的远程访问分支机构通过互联网构建一个安全的虚拟专用网络与合作者建立企业间联网和企业内联网接入将IPsec应用于上述场景的实质就是构建基于IPsec的虚拟专用网（VirtualPrivateNetwork,VPN）IPsec的应用VPN定义及分类VPNIPsec安全接入场景：网关到网关IPsec的应用IPsec安全接入场景：网关到网关IPsec的应用IPsec安全接入场景：终端到网关IPsec的应用IPsec安全接入场景：典型应用逻辑图IPsec的应用IPsec安全接入场景：典型应用一IPsec的应用IPsec安全接入场景：典型应用二IPsec的应用IPsec安全接入场景：典型应用三IPsec的应用IPsec应用IPsec的应用IPsec的应用利用IPsec实现安全通信有以下优点：当在路由器或防火墙等边界设备中启用IPsec时，认证和加密过程均在路由器或防火墙中进行，而其后面的公司或者工作组内部的通信不会引起与安全相关的开销IPsec位于传输层之下，所以对应用是透明的IPsec对终端用户是透明的若有必要，IPsec给个人用户提供安全性IPsec的应用内容提纲IPsec2

IPv6协议及其安全性分析3路由安全4

IPv4协议及其安全性分析1IPv6IPv6从IPv4向IPv6过渡采用逐步演进的方法，IETF推荐的过渡方案主要有：双协议栈(dualstack)隧道(tunneling)网络地址转换IPv6IPv6部署情况（APNIC，2019.6）：IPv6IPv6通过IPsec来保证IP层的传输安全，提高了网络传输的保密性、完整性、可控性和抗否认性IPv6安全安全问题IPv4向IPv6过渡技术的安全风险无状态地址自动配置的安全风险IPv6中PKI管理系统的安全风险IPv6编址机制的隐患IPv6安全安全问题IPv6的安全机制对网络安全体系的挑战所带来的安全风险：正在服役的IDS/IPS/WAF不一定支持，于是可以畅行无阻IPv6安全IPv6安全内容提纲IPsec2

IPv6协议及其安全性分析3路由安全4

IPv4协议及其安全性分析1路由协议R1H1H2内部网关协议IGP（例如，RIP）自治系统A自治系统B自治系统CIGPIGPIGPIGPIGPIGPIGPIGPIGPIGPIGPIGPEGPEGPEGP内部网关协议IGP（例如，OSPF）外部网关协议EGP（例如，BGP-4）IGPR3R2路由协议的脆弱性：协议设计上的问题，即协议机制上的不完善（如认证机制、防环路机制、路由度量机制等）导致的安全问题协议实现上的问题，即许多协议规范中的协议行为在实际网络环境中并没有实现或做的不够完善而导致的安全问题管理配置产生的安全问题，很多网络管理员在配置路由协议器时，没有或错误地配置相应的加密和认证机制，带来了很多安全风险路由协议BadNeighboronFreeBSD-FreeBSDIPv6协议栈路由协议相关4个漏洞分析IPv6路由协议栈实现安全路由协议的安全保障：IPv4网络中，路由安全主要依靠路由协议本身提供的安全机制来保障，如认证和加密机制。而在IPv6网络中，路由安全则主要依靠前面介绍的IPsec协议提供的认证和加密服务来保障路由协议一、RIP协议及其安全性分析RIP一种内部网关协议分布式的基于距离向量的路由选择三个版本：RIPv1（RFC1058）、RIPv2（RFC1723）和RIPng。RIPv2新增了变长子网掩码的功能，支持无类域间路由、支持组播、支持认证功能，同时对RIP路由器具有后向兼容性。RIPng主要用于IPv6网络RIP协议路由策略和哪些路由器交换信息？仅和相邻路由器交换信息交换什么信息？当前本路由器所知道的全部信息，即自己的路由表在什么时候交换信息？按固定的时间间隔交换路由信息RIP协议协议报文两类报文：更新报文和请求报文。更新报文用于路由表的分发，请求报文用于路由器发现网上其它运行RIP协议的路由器。RIP协议报文使用UDP协议进行传送RIP协议RIPv1不支持认证，且使用不可靠的UDP协议作为传输协议，安全性较差。如果在没有认证保护的情况下，攻击者可以轻易伪造RIP路由更新信息，并向邻居路由器发送，伪造内容为目的网络地址、子网掩码地址与下一条地址，经过若干轮的路由更新，网络通信将面临瘫痪的风险RIP协议安全RIPv2在其报文格式中增加了一个可以设置16个字符的认证选项字段，支持明文认证和MD5加密认证两种认证方式，字段值分别是16个字符的明文密码字符串或者MD5签名。RIP认证以单向为主，R2发送出的路由被R1授受，反之无法接受。另外，RIPv2协议路由更新需要配置统一的密码明文认证的安全性仍然较弱RIP协议安全对于不安全的RIP协议，中小型网络通常可采取的防范措施包括：①将路由器的某些接口配置为被动接口，配置为被动接口后，该接口停止向它所在的网络广播路由更新报文，但是允许它接收来自其他路由器的更新报文；②配置路由器的访问控制列表，只允许某些源IP地址的路由更新报文进入列表RIP协议安全RIPng为IPv6环境下运行的RIP协议，采用和RIPv2完全不同的安全机制。RIPng使用和RIPv1相似的报文格式，充分利用IPv6中IPsec提供的安全机制，包括AH认证、ESP加密以及伪报头校验等，保证了RIPng路由协议交换路由信息的安全。RIP协议安全二、OSPF协议及其安全性分析路由策略和哪些路由器交换信息？向本自治系统中所有路由器发送信息，通常洪泛法交换什么信息？与本路由器相邻的所有路由器的链路状态，只是路由器所知部分信息表在什么时候交换信息？当链路状态发生变化时，路由器向所有路由器发送此信息；定期同步链路状态OSPF协议OSPF使用分布式链路状态协议(linkstateprotocol)由于OSPF依靠各路由器之间频繁地交换链路状态信息，因此所有的路由器都能建立一个链路状态数据库（LinkStateDatabase,LSDB），这个数据库实际上就是全网拓扑结构图每一个路由器使用LSDB中的数据，构造自己的路由表（例如，使用Dijkstra算法）OSPF协议OSPF协议报文类型1，问候(Hello)报文，用来发现和维持邻站的可达性类型2，数据库描述(DatabaseDescription)报文，向邻站给出自己的链路状态数据库中的所有链路状态项目的摘要信息类型3，链路状态请求(LinkStateRequest,LSR)报文，向对方请求发送某些链路状态项目的详细信息OSPF协议OSPF协议报文类型4，链路状态更新(LinkStateUpdate,LSU)报文，用洪泛法向全网发送更新的链路状态类型5，链路状态确认(LinkStateAcknowledgment,LSAck)报文，对链路更新报文的确认OSPF协议OSPF不用UDP而是直接用IP数据报传送（其IP数据报首部的协议字段值为89）其报文OSPF协议OSPF协议可以对接口、区域、虚链路进行认证接口认证要求在两个路由器之间必须配置相同的认证口令。区域认证是指所有属于该区域的接口都要启用认证，因为OSPF以接口作为区域分界。区域认证接口与邻接路由器建立邻居需要有相同的认证方式与口令，但在同一区域中不同网络类型可以有不同的认证方式和认证口令。配置区域认证的接口可以与配置接口认证的接口互相认证，使用MD5认证口令ID要相同OSPF安全OSPF认证方式空认证（NULL，即不认证，类型为0），默认认证方式简单口令认证（类型为1）MD5加密身份认证（类型为2）OSPF报文格式中有二个与认证有关的字段：认证类型（AuType,16位）、认证数据（Authentication,64位）OSPF安全同RIPng一样，OSPFv3协议自身不再有加密认证机制，取而代之的是通过IPv6的IPsec协议来保证安全性，路由协议必须运行在支持IPsec的路由器上。IPsec可确保路由器报文来自于授权的路由器；重定向报文来自于被发送给初始包的路由器；路由更新未被伪造OSPF安全OSPF攻击方式最大年龄（MaxAgeattack）攻击序列号加1（Sequence++）攻击最大序列号攻击重放攻击篡改攻击OSPF安全三、BGP协议及其安全性分析BGP协议是一种应用于AS之间的边界路由协议，而且运行边界网关协议的路由器一般都是网络上的骨干路由器运行BGP协议的路由器相互之间需要建立TCP连接以交换路由信息，这种连接称为BGP会话(Session)BGP协议BGP定义了四种主要报文，即：打开(Open)报文，用来与相邻的另一个BGP发言人建立关系更新(Update)报文，用来发送某一路由的信息以及列出要撤消的多条路由保活(KeepAlive)报文，用来确认打开报文和周期性地证实邻站关系通知(Notification)报文，用来发送检测到的差错BGP协议BGP协议BGP发言人BGP发言人BGP发言人BGP发言人BGP发言人AS1AS3AS2AS5AS4BGP协议BGP协议最主要的安全问题在于缺乏一个安全可信的路由认证机制，即BGP无法对所传播的路由信息的安全性进行验证。每个自治系统向外通告自己所拥有的CIDR地址块，并且协议无条件信任对等系统的路由通告，这将就导致一个自治系统向外通告不属于自己的前缀时，也会被BGP用户认为合法，从而接受和传播，导致路由攻击的发生BGP安全由于BGP协议使用TCP作为其传输协议，因此同样会面临很多因为使用TCP而导致的安全问题，如SYNFlood攻击、序列号预测等BGP安全BGP协议的路由更新机制也存在被攻击的威胁。2011年美国明尼苏达大学M.Schuchard等人在NDSS2011国际会议上提出了一种基于BGP协议漏洞的CXPST（CoordinatedCrossPlaneSessionTermination）攻击方法，俗称“数字大炮”BGP安全：数字大炮数字大炮BGP安全：数字大炮ABR1R2关键路径关键路径BGP协议数字大炮BGP安全：数字大炮BGP系统是一个信誉系统，它几乎完全依赖自治系统（运营商）之间的信任与协作如果某个运营商有意或无意地把不属于自己地址范围的路由信息（路由前缀）宣告给网络邻居（这种现象被称为路由劫持或路由泄露），那么邻居的网络可能把去往该网络的数据包全部转发给这个捣乱的运营商，从而导致路由劫持攻击BGP安全：路由劫持BGP劫持BGP安全：路由劫持/articles/5042BGP安全：路由劫持BGP安全：路由劫持BGP安全：路由劫持BGP安全：路由劫持尽管正在研究的路由安全机制（如RPKI、BGPSec等）可以在防范这种路由劫持或路由泄露攻击，但是这些技术离大规模部署还有很长的路要走。短期内，我们仍然还只能相信运营商大部分都是诚实的，不会故意滥用别人的信任。BGP安全：路由劫持2018年9月，NIST与DHS团队共同发布了其BGP路由来源验证（ROV）标准的初稿，此项标准将帮助互联网服务供应商与云服务供应商抵御BGP劫持攻击IETF网站上还以RFC8210与RFC8206的形式发布了BGPRPKI与BGPsec两项SIDR协议标准BGP安全RPKIBGP安全BGPSECBGP安全国际政治对BGP安全的影响（2022俄乌战争）BGP安全本章小结作业第七章传输层安全内容提纲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协议内容提纲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几个协议之间的关系是：使用握手协议协商加密和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记录协议ProtocolTypeProtocolVersionLengthMessageTypeLengthProtocolVersionRandom0135691143ByteOffset记录协议首部载荷协议报文(示例为握手协议报文)20：密码变更规格协议21：告警协议22：握手协议23：上层应用协议（HTTP）报文格式（载荷为上层协议报文）SSL记录协议记录协议对应用数据的处理过程SSL记录协议

应用数据分段压缩添加MAC加密添加SSL首部1、如何得知采用的加密算法、MAC算法、压缩算法？2、如何得到对称加密密钥？记录协议支持的加密算法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)握手协议报文格式协议格式握手协议客户端与服务器之间建立逻辑连接的初始交换过程包括四个阶段握手协议握手协议不需要CA实时参与，也不需要实时查询证书库密码套件（CipherSuite）：SSL/TLS握手期间协商安全设置的算法（密钥交换算法、认证算法、加密算法及密钥长度、校验算法）的组合握手协议为了更好理解SSL协议的握手过程，结合实例，使用Wireshark抓包分析SSL握手过程中客户端与服务器间的交互过程。下面以访问为例，使用Wireshark抓包分析SSL握手过程中客户端与服务器间的交互过程。本例中服务器/（72），客户端为本机浏览器（2）。例中协议版本为TLS1.2，过程与SSL类似。握手协议ClientHello消息握手协议：阶段1TLS第1次握手TLS第2次握手TLS第3次握手TLS第4次握手ClientHello消息握手协议：阶段1TLS版本端户端随机数密码套件列表ServerHello消息握手协议：阶段1服务器随机数服务器选择的密码套件服务器确认的TLS版本Certificate消息握手协议：阶段2服务器证书Certificate消息握手协议：阶段2Certificate消息握手协议：阶段2Certificate消息握手协议：阶段2服务器发送完Certificate消息后继续发送ServerKeyExchange和ServerHelloDone消息，ServerKeyExchange消息中包含有密钥交换算法所需要的额外参数。ServerHelloDone消息表示服务器已发送完此阶段的全部信息握手协议：阶段3与4椭圆曲线公钥签名算法服务器端椭圆曲线公钥客户端发送ClientKeyExchange和ChangeCipherSpec消息握手协议：阶段3与4这里有客户器端椭圆曲线公钥接着服务器同样发送ChangeCipherSpec消息通知服务器到客户端的握手过程结束，并发送一个加密的握手消息EncryptedHandshakeMessage握手协议：阶段3与4之后，服务端也会使用SessionSecret加密一段Finished消息发送给客户端，以验证之前通过握手建立起来的加密通道是否成功。根据之前的握手信息，如果客户端和服务端都能对Finished信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的SessionSecret对数据进行加密传输了。握手协议：阶段3与4五、密钥生成采用非对称密码算法进行身份鉴别（认证）和密钥交换，身份鉴别通过后协商预（备）主密钥，双方各自计算主密钥，进而推导出工作密钥（会话密钥）。使用工作密钥进行数据加解密和完整性检验密钥种类服务端密钥：为非对称密码算法的密钥对，包括签名密钥对（用于握手过程中服务端身份鉴别）和加密密钥对（用于预主密钥的协商）客户端密钥：为非对称密码算法的密钥对，包括签名密钥对（用于握手过程中服务端身份鉴别）和加密密钥对（用于预主密钥的协商）预主密钥（pre_master_secret,PM）：双方协商生成的密钥素材，用于生成主密钥密钥种类主密钥（master_secret）：由预主密钥（PM）、客户端随机数（CR）、服务端随机数（SR）、常量字符串，经计算生成的48字节密钥素材，用于生成工作密钥工作密钥：包括数据加密密钥（用于数据的加密和解密）和校验密钥（用于数据的完整性计算和校验）。发送方用的工作密钥称为写密钥，接收方使用的工作密钥称为读密钥密钥种类共享主密钥是利用安全密钥交换为此会话建立的一个一次性48字节的值，生成过程分两步：第一步交换预主密钥（握手协议的“阶段3”）第二步双方计算主密钥。密钥生成计算主密钥‘A’PMCRSR‘BB’PMCRSR‘CCC’PMCRSRSHA-1SHA-1SHA-1PM散列PM散列PM散列MD5MD5MD5散列散列散列PM：预备主密钥SR：服务器随机数CR：客户端随机数主密钥（48字节）计算主密钥计算数据加密密钥（会话密钥）和校验密钥及相关参数计算工作密钥‘A’MCRSR‘BB’MCRSR‘···’MCRSRSHA-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浏览器和服务器自身安全。2024/7/22243增强SSL安全性

增强master_secret的保密性预主密钥的口令加密方法和硬件加密方法。提高随机数的质量用硬件随机数发生器产生的随机数作为产生随机数的软件方法PRNG的种子，进行高强度处理。提高证书CA的可靠性在服务器认证阶段，CA控制所有证书的颁发和有效性判断。2024/7/22244内容提纲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交换，这两种模式都可以让客户端和服务器得到共享密钥，但是RSA模式有一个严重的缺陷：它不满足前向保密（forwardsecret），以及“百万消息攻击”等攻击仅保留瞬时Diffie-Hellman作为唯一的秘钥交换机制TLS1.3：密钥交换密钥交换TLS1.3：密钥交换密钥交换：TLS1.2vs.TLS1.3TLS1.3：密钥交换密钥交换：TLS1.2vs.TLS1.3TLS1.3：密钥交换减少不安全的Diffie-Hellman参数选项选择Diffie-Hellman参数时，提供太多的选项会导致选择出错误的选项。TLS1.3：密钥交换删除不安全的认证加密方法CBC模式和填充之间的交互也是SSL3.0和一些TLS实现中出现的著名的POODLE漏洞的成因。TLS1.3中允许的唯一认证加密方法是AEAD（AuthenticatedEncryptionwithAdditionalData），它将机密性和完整性整合到一个无缝操作中TLS1.3：认证加密方法POODLE漏洞禁止一些安全性较弱的密码原语TLS1.3已删除所有可能存在问题的密码组件和密码模式，包括CBC模式密码或不安全的流式密码，如RC4。建议用SHA-2，不建议使用安全性较弱的MD5和SHA-1TLS1.3：删除不安全的密码套件对整个握手过程签名在TLS1.2及更早版本中，服务器的签名仅涵盖部分握手协议报文，其它使用对称MAC来确保握手未被篡改。这种疏忽导致了许多严重的安全漏洞，如FREAK、LogJam攻击等。FREAK攻击也称为降级攻击TLS1.3服务器对整个握手记录进行签名，包括密钥协商，避免三次握手攻击。此外，还实现了握手协议和记录协议的密钥分离。TLS1.3：全过程签名对整个握手过程签名TLS1.3：全过程签名TLSv1.2对整个握手过程签名TLS1.3：全过程签名TLSv1.2TLSv1.3性能上的改进SSL：“2-RTT(RoundTripTime)”，200msTLS1.3舍弃了RSA的密钥协商过程，然后基于ECDH密钥协商算法（EC即椭圆曲线，DH是指“Diffie-Hellman”）优化了整个过程，改为“1-RTT

”TLS1.3除了对新建连接过程进行优化之外，对连接恢复过程也进行了优化，做到了零次往返（0-RTT）TLS1.3：性能改进性能上的考虑：握手过程的改进TLS1.3：性能改进性能上的考虑：握手过程的改进TLS1.3：性能改进性能上的考虑：握手过程的改进TLS1.3：性能改进性能上的改进TLS1.3：性能改进TLS1.22-RTTTLS1.31-RTT查看目标网站支持的TLS版本RFC8998：定义了两个TLS1.3中的国密加密套件：SM2椭圆曲线ID，SM2-SM3的签名⽅法TLS支持国密算法内容提纲SSL2TLS3SSL/TLSVPN4传输层安全问题1IPsecVPN也有一些不足之处：无法实现基于用户的授权可能泄露内部网络结构利用基于SSL/TLS的V