(高清版)GBT 41868-2022 Modbus TCP安全协议规范

ModbusTCP安全协议规范2022-10-12发布国家标准化管理委员会GB/T41868—2022前言 I引言 Ⅱ1范围 2规范性引用文件 3术语和定义 4缩略语 5规范性陈述 26概述 26.1mbap概述 26.2mbaps概述 36.3传输层安全性概述 37服务定义 78协议规范 78.1TLS协议 78.2TLS握手 78.3密码套件选择 8.4mbaps基于角色的客户端授权 9系统依赖性 10.1TLS版本 10.4TLS压缩 10.5TLS会话重新协商 附录A(规范性)mbaps数据包结构 参考文献 I本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由中国机械工业联合会提出。本文件由全国工业过程测量控制和自动化标准化技术委员会(SAC/TC124)归口。本文件起草单位：机械工业仪器仪表综合技术经济研究所、施耐德电气(中国)有限公司上海分公司、重庆信安网络安全等级测评有限公司、国能智深控制技术有限公司、浙江中控技术股份有限公司、中国科学院沈阳自动化研究所、东方电气集团科学技术研究院有限公司、北京卓识网安技术股份有限公Ⅱ目前已经发布的Modbus协议国家标准包括：GB/T19582.1—2008《基于Modbus协议的工业自动化网络规范第1部分：Modbus应用协议》;GB/T19582.2—2008《基于Modbus协议的工业自动化网络规范第2部分：Modbus协议在串行链路上的实现指南》;GB/T19582.3—2008《基于Modbus协议的工业自动化网络规范第3部分：Modbus协议在TCP/IP上的实现指南》;Modbus协议最初于1979年用于工业控制器与计算机或其他上位机通信的串行协议。1996年，Modbus协议进行了以太网的扩展，使用了IANA登记的502号端口，支持ModbusTCP基于以太网的协议。同时，ModbusTCP保持了与ModbusRTU串行协议的一致与兼容，这使得Modbus串行设备通过ModbusTCP实现桥接通信变得十分容易。2002年，Modbus抽象出适用于串行和以太网的Modbus应用层，开始使用ModbusPDU的概念，发布了Modbus应用层规范，针对串行和TCP不同的ADU,也发布了串行和以太网的规范。同时，Modbus也加入了IEC61784作为行规之一。基于转化IEC61784中的Modbus协议规范，我国发布了GB/T19582Modbus系列推荐性国家标准。也是由于国家标准的发布，这使得依照规范标准进行互操作性测试成为可能。后来制定发布了GB/T25919系列标准，这极大地改善了大量Modbus应用的一致性和互操作性，有利于工业自动化系统的开发和集成。像所有的工业通信协议一样，Modbus最初没有设计信息安全功能。随着工业通信及应用对数据保密和完整性、设备身份识别等要求的需求增加，本文件使用通用的TLS传输层加密技术，对Modbus协议进行了扩充，使加密的Modbus通信能够增加抵抗比如重放和中间人等常见攻击的能力。ModbusTCP安全保持了与ModbusTCP一致的ADU,这样能够使ModbusTCP通信能够容易地迁移到ModbusSecurity。ModbusTCP安全使用了IANA登记的802号端口用于安全通信。Mod-bussecurity仅允许使用TLS1.2及以上版本。ModbusTCP安全还采用了X.509v3的数字签名证书，在客户端和服务器进行TLS协商握手时使用双向认证。同时，在证书中使用了OID扩展，设备厂家可以利用这个扩展指定客户端的角色和权限，可以实现工业信息安全所需要的用户识别及基于角色的控制。随着ModbusTCP安全标准的推出，为现有大量使用Modbus的设备，提供了一种简洁且直接的升级路径。1ModbusTCP安全协议规范1范围本文件规定了ModbusTCP安全协议的服务定义、协议说明、系统依赖性以及TLS要求等内容。本文件适用于开发或检测Modbus产品的相关机构。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。RFC4492用于传输层安全(TLS)的椭圆曲线密码(ECC)加密套件[EllipticCurveCryptography(ECC)CipherSuitesforTransportLayerSecurity(TLS)]RFC5246传输层安全协议规范，第1.2版[TheTransportLayerSecurity(TLS)Protocol,V1.2]RFC5280互联网X.509公钥基础设施证书和证书吊销列表(CRL)配置文件[Internetx.509PublicKeyInfrastructureCertificateandCertificateRevocationList(CRL)profile]RFC6066传输层安全(TLS)扩展：扩展定义(TISextensions.Extensiondefinitions)3术语和定义本文件没有需要界定的术语和定义。下列缩略语适用于本文件。ADU:应用数据单元(ApplicationDataUnit)AuthZ:授权(Authorization)BER:基本编码规则(BasicEncodingRules)CDP:CRL分发点(CRLDistributionPoint)CRL:证书吊销列表(CertificateRevocationList)HMAC:密钥哈希消息认证码(Keyed-hashMessageAuthenticationCode)IANA:互联网号码分配机构(InternetAssignedNumbersAuthority)ICS:工业控制系统(IndustrialControlSystem)IEC:国际电工委员会(InternationalElectrotechnicalCommission)MAC:消息认证码(MessageAuthenticationCode)mbaps:Modbus安全应用协议(ModbusSecurityApplicationProtocol)OID:国际电信联盟标准化的物联网域名(ObjectIdentifierstandardizedbytheInternationalTele-2communicationsUnion)PDU:协议数据单元(ProtocolDataUnit)PKI:公钥基础设施(PublicKeyInfrastructure)PRF:伪随机函数族(PseudorandomFunctionFamily)RA:登记机关(RegistrationAuthority)SSL:安全套接字层(SecureSocketLayer)TCP:传输控制协议(TransportControlProtocol)TLS:传输层安全协议(TransportLayerSecurity)5规范性陈述本文件中的规范性陈述明确规定如下：R-n.m:这里是规范性声明文本。其中“n.m”被需求声明语句标记号替换，该标记号可以是分层次的编号数字，例如R-1.2.3或简单ModbusTCP协议广泛应用于工业控制系统(ICS)。ModbusTCP规范定义了应用数据单元(ADU)。此ADU定义见图1。数据mbap报头功能码数据传统的Modbus协议数据单元(PDU)和ModbusTCP应用数据单元(ADU)间的区别是在帧的前面添加了mbap报头(mbapheader)。1996年，ModbusTCP协议在IANA(互联网号码分配机构)注册并分配给了系统端口号502。在IANA的注册过程中，由于ModbusTCPADU中的mbap报头，ModbusTCP协议被称为mbap协议。mbap协议这个名称持续使用，并且仍然以mbap/TCP的名称用于IANA注册的502端口。本文件所述的ModbusTCP安全协议是使用传输层安全性(TLS)的ModbusTCP协议的一个以安全为中心的变体。IANA已将系统端口号802分配给ModbusTCP安全协议。在M网站已注册的名称为网络通信安全应用协议，在端口802与IANA登记为mbap/TLS/TCP协议。选择TLS作为安全传输协议是在GB/T35673—2017和IEC62443-4-2应用场景下分析来自行业域的代表性数据流的结果。表1上下文特定术语列出了在不同上下文中用于mbap通信配置文件的名称，如通信配置文件，M,IANA注册表和本文件。为简洁起见，本文件的其余部分将用mbap和mbaps分别表示3ModbusTCP和ModbusTCP安全协议。表1上下文特定术语协议类型M本文件(为简洁起见)mbap/TCPModbusTCP系统端口502的Modbus应用协议mbapmbap/TLS/TCPModbusTCP安全协议系统端口802的Modbus安全应用协议mbapsModbusTCP协议安全原则：a)ModbusTCP安全协议使用端口号802;b)通过TLS使用X.509V3进行身份识别和认证；c)客户端/服务器端双向TLS认证；d)通过证书传输的角色进行授权；e)授权规则是产品特定的；f)没有更改mbap,在Modbus协议的传统中，mbaps要求保持简单，允许供应商围绕协议开发其他的基础架构，并允许传统设备和现场总线向后兼容。mbaps扩展了GB/T19582.1和GB/T19582.3中原始定义的mbap协议。mbaps定义了一个客户端-服务器端(C-S)协议，它是完整安全系统结构的一部分。TLS通过添加数据的机密传输、数据完整性、防重播保护、通过证书进行端点身份验证以及通过证书中嵌入的信息(如用户和设备角色)进行授权，提供了一种以安全为中心的协议来替代mbap.协议mbap和mbaps的区别类似于http及其安全变体https的区别。在mbaps中，mbap协议通过TLS传输。TLS通过x.509v3证书提供身份验证功能。应为mbaps客户端和服务器进行配置，这些证书才能进行TLS身份验证功能。mbap和mbaps之间的一个重要区别是，mbaps提供服务器调用授权的能力，该授权功能的规则由供应商或客户驱动，使用通过x.509v3证书中的扩展字段提供的角色数据。该扩展名已在M的IANAOID上注册。TLS提供使用预共享密钥建立安全连接，但本文件不考虑使用，因为它不允许角色信息传输提供授权功能。6.3传输层安全性概述mbaps/TLS/TCP配置文件使用RFC5246中定义的安全TLS传输协议。RFC5246定义了本文件发布时最新的TLS版本TLSv1.2,并为早期版本中已知的漏洞提供对策和缓解措施。此文件基于TLSv1.2,当更新的TLS版本被广泛应用时，将考虑使用它们。TLS由一组协议组成，见图2。该集合中的主要协议是TLS记录协议。其余的协议是由TLS记录协议承载的子协议。它们由一个TLS中间件管理。4TLSTLS密码更改规范协议20TLS记录协议'TCPIP协议23协议23TLS握手协议22TLS警报协议21图2TLS通信协议栈mbapADU在mbaps中未更改，封装在TLS应用协议报文中，见图3。ILS应用协议23mbapADU!ILS记录协议TLS握手协议见图4的ModbusTCP安全概念图，其主要完成下列功能：——在端点之间协商安全通道的加密，包括算法，密钥等；——提供基于x.509v3证书的双向客户端/服务器身份验证；——从证书中提取客户端角色OID;——建立TLS会话。在建立TLS会话之后，正常的Modbus请求和响应序列在安全的TLS应用协议通道中传输。在处理请求的过程中，mbaps协议处理程序调用特定于供应商的授权功能。此授权功能使用来自mbapADU的输入和从连接的x.509客户端证书中提取的角色来评估角色到权限算法。该算法根据对等方的角色确定是否可以处理ADU。如果授权功能不能处理mbapADU代码，则mbap处理程序返回01—lllegalFunctionCode的Modbus异常码。此授权过程发生在每个请求上，确保请求流的全面验证。5mbaps:GetClientCertcritical[TLSFullHandsh服圣器功能角色到权限功能角色到权限一loop[ApplicationProtocolMessageExchange]—5:TIsSendMbapReqAdu6:AuthorizeMbapReqPduF'-----8;Authorized----------9:Authorized---12:TLSSendMbapRespAdu-卡-1:ADUResp14:AuthorizeMbapReqPdur'--16;NOTAuthorized----17:NOTAuthorized--k18:TLSSendModbusExceptionCode图4ModbusTCP安全概念图带有角色扩展的x.509v3证书示例见图5,示例中角色值为“Operator”,角色的OID由M私有MIB定义，其PEN(私有企业编码)是50316。mbaps的开发及其在设备中的部署遵循以下规则：a)R-01:mbaps设备的安全传输协议应使用由RFC5246定义的TLS协议v1.2或更新版本；b)R-02:与mbaps设备的安全通信应使用由TLS握手协议提供的双向客户端/服务器身份验证；c)R-03:mbaps设备的TLS协议身份标识/认证应使用由RFC5280定义的x.509v3证书；d)R-04:如果执行授权功能，应使用通过x.509v3证书扩展中传输的角色；e)R-05:mbap协议仅通过安全传输进行封装，不应对其进行任何更改。6Certificate:Data:Version:3(0x2)SerialNumber:4135(0x1027)SignatureAlgorithm:sha256WithRSAEncryptionIssuer:C-US,ST-STATE.L-LOCAL,O-ORG,OU-SLBORG,CN-INTER-CAValidityNotBefore:Oct2712:58:272017GMTSubjcctPublicKcyInfo:PublicKeyAlgorithm:rsaEncryptionPublic-Key:(2048bit)Modulus:58:3ecl:dc:a7:21:ca:c0:90:c9:e5:80:70:2b:8d:4d:0a:78:96:c0:9e:lffl:ld:e7:e8:24:be:06:al:d1:c2:c7:52:dc:ch:9d:b0:60:bl:73:62:24:ac:ha:X509v3extensions:X509v3BasicConstraints:CA:FALSEX509v3SubjectKeyIdentifier:B3:09:92:H3:60:44:DF:H5:5B:30:8BX509v3KeyUsage:criticalDigitalSignature,NonRepudiation,KeyEnciphermentX509v3SubjeclAltemaliveName:IPAddress:2,IPAddress:192168.2.22SignatureAlgorithm:sha256WithRSAEncryptiond7:le:25:8c:dh:cb:f1:54:23:9a:ce:39:c4:dd:96:5f:ce:2a:8c:4a:bl:7c:11:d7:17:a6:81:d4:1c:bb:86:af:d5:20:fe:05:bc:c6:21:94:dd:55:ee:90:3fad:18:15;22:16:99;cf:3{:bc;2f:af:aa:04:16:0d:e6:89:c2:[4:af:cb:0e:27:fc:5c:d9:3f:df:bf:6a:b7图5带有角色扩展的x.509v3证书示例77服务定义在GB/T19582.1—2008和GB/T19582.3—2008中详细描述了Modbus应用层协议上使用的标准功能码。本文件中的标准功能码没有修改。8协议规范mbapADU的通信使用传输层安全协议(TLS)进行保护，该协议在RFC5246中定义。图3为封装在TLS中的mbapADU,说明了如何通过TLS应用协议传输mbapADU。mbapADU数据包结构应符合附录A的规定。TLS在两个端点之间提供传输层安全协议。为此，TLS端点执行TLS握手协议协商安全参数并创建TLS会话。为了让两个mbaps终端设备使用TLS安全通信，应在TLS连接的端点之间建立安全上下文。TLS握手协议建立安全上下文，即TLS会话。TLS会话具有会话标识符，安全上下文是由RFC5246A.6中定义的一组安全参数描述。双向身份验证要求每个端点都将其域证书链发送到远程端点。从远程对等端收到证书链后，TLS端点将使用链中的下一个CA证书，验证每个证书签名，直到它可以验证链的根。TLS完整握手协议见表2,TLS完整握手协议见图6,定义见RFC5246中的7.3。8GB/T41868—2022-11:ChangeCipherSpec()-——12:Finished()———13:ChangeCipherSpec()———15+n:ApplData(-—15+n+1:ApplData()—图6TLS完整握手协议TLS还提供会话恢复功能。服务器端缓存最后一次会话的已知安全状态，并将其与客户端和服务器端中使用的会话ID配对。如果客户端缓存安全上下文和会话ID,它可以将此会话ID呈现给下一个ClientHello上的服务器。如果此会话ID与服务器上的缓存会话ID匹配，则服务器将立即更改密码规范，见图7,连接将恢复，TLS恢复握手见表3。这将TLS协商时间减少到1个应用往返时间，并省掉了授权新端所需的公钥/私钥密码验证的过程。使用TLS恢复功能时，服务器应缓存与客户端证书相关联的角色RoleID,并将它与会话ID相关联。如果ClientHello提供的sessionID与已知的服务器会话不匹配，则会在ServerHello消息中返回新的sessionID,并执行图6所示的TLS完整握手协议。表2TLS完整握手协议消息描述TlsClient(TLS客户端)向TlsServer(TLS服务器端)发送ClientHello消息以开始协商过程。TlsClient消息中包含密码套件列表。该列表按客户端的偏好进行排序TlsServer发送ServerHello消息以响应ClientHello。该消息标识一组可接受的加密算法，并返回一个新的sessionID(会话ID)9消息描述3:ServerCertificateTlsServer将其证书链作为证书消息的有效负载发送。此链包含服务器设备的域证书，以及每个颁发CA的证书到根CA。此服务器的域证书也可能包含服务器的角色。包含的话客户端也不使用此角色信息4:VerifyServerCertSig当收到远程的证书时，会检查它的：——使用颁发者CA的公钥验证链中的每个证书的签名；——验证受信任的根证书路径；——检查链中每个证书的撤销状态5:ServerKeyExchangeTlsServer向TlsClient发送ServerKeyExchange消息，以提供用于设置预主密钥的数据6:CertificateRequestTlsServer向TlsClient发送CertificateRequest消息以获取客户端证书TlsServer向TlsClient发送ServerHelloDone消息，以指示ServerHello和相关消息的结束8:ClientCertificateTlsClient将其证书链作为证书消息的有效负载发送。此链包含客户端设备的域证书，以及每个颁发CA到根CA的证书。此客户端的结束证书还包含客户端的角色。服务器使用它来授权之后的应用级请求9:VerifyClientCertSig当收到远程的证书时，会检查它：——使用颁发者CA的公钥验证链中的每个证书的签名；——验证受信任的根证书路径；——检查链中每个证书的撤销状态TlsClient向TlsServer发送ClientKeyExchange消息。通过此消息，设置预主密钥TlsClient向TlsServer发送ChangeCipherSpec消息，以指示客户端发送的后续消息将使用新协商的密码规范和密钥发送TlsClient向TlsServer发送Finished消息。此消息是第一条使用刚刚协商的算法、密钥和秘密进行保护的消息TlsServer向TlsClient发送ChangeCipherSpec消息，以指示服务器发送的后续消息将使用新协商的密码规范和密钥发送TlsServer向TlsClient发送Finished消息。此消息使用刚刚协商的算法、密钥和秘密进行保护n::={1..m}n::={1..m}mbapsTlsServercritical[TLSFullHandshak1:ClientHello()SavedSessionID2:ServerHello)ChangeCipherSpec()-Finished()3:ChangeCipherSpec()Finished()4+n+1:mbapsResponse消息描述TlsClient向TlsServer发送ClientHello消息以开始协商过程。TlsClient在消息中提供密码套件列表。它还提供缓存的非零sessionIDTlsServer发送ServerHello消息以响应ClientHello。该消息标识可接受的密码套件，返回相同的sessionID,并包含ChangeCipherSpec记录2:ChangeCipherSpecTlsServer向TlsClient发送ChangeCipherSpec消息，以指示服务器发送的后续消息将使用新协商的密码规范和密钥TlsServer向TlsClient发送Finished消息。此消息是第一条使用刚刚协商的算法、密钥和秘密保护的消息3:ChangeCipherSpecTlsClient向TlsServer发送ChangeCipherSpec消息，以指示客户端发送的后续消息将使用新协商的密码规范和密钥发送TlsClient向TlsServer发送Finished消息。此消息是使用刚刚协商的算法、密钥和秘密进行保护的消息4[1..n]:ApplData()n::={1..m}5[1..n]:ApplData()n::={1..m}mbaps在TLS握手时遵循以下规则：a)R-06:mbaps终端设备在执行TLS握手协议时应提供双向身份认证用于创建TLS会话；b)R-07:TlsServer应在TLS握手期间发送CertificateRequest消息；c)R-08:TlsClient在收到包含客户端证书的请求时应发送客户端证书消息；d)R-10:如果TlsClient没有发送ClientCertificate消息，那么TlsServer应向TlsClient发送一个“fatalalert”消息并终止连接；e)R-11:根据RFC5246-7.2.2,在“fatalalert”之后，不应恢复TLS连接。8.3密码套件选择TLS会话的安全强度取决于在TLS端点之间协商的密码套件。密码套件指定将使用何种加密方法为TLS会话提供一定级别的安全性。只有在IANA注册且当前无已知弱点的密码套件才能用在mbaps中。mbaps在密码套件选择时遵循以下规则：a)R-12:用于mbaps的TLS的密码套件应在IANA注册列表中列出；注：密码套件见/assignments/tls-parameters/tls-parameters.xhtml。b)R-13:用于mbaps的TLS的密码应适应于x.509v3证书；c)R-14:mbaps设备当使用RSA为私钥时，应至少提供以下TLSv1.2密码套件：1)TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。d)R-66:具有数据传输加密和数据加密为NULL的密码套件的客户端宜将数据加密为NULL的密码套件放在密码套件优先级列表的最后一位；e)R-67:服务器设备宜提供支持仅含有认证部分的密码套件TLS_RSA_WITH_NULL_SHA256的能力。8.4mbaps基于角色的客户端授权mbaps协议提供执行基于角色的客户端授权(AuthZ)的能力。客户端角色数据在其x.509v3域证书的扩展中传输。带有角色扩展的证书示例见图5。mbaps的基于角色的客户端授权见图8。mbaps客户端mbaps服务器端协议处理程序mbaps客户端协议处理程序授权算法x.509v3客户端域证书角色对应权限的规则库图8基于角色的客户端授权基于角色的授权是指：a)x.509v3证书扩展包含角色编码；b)授权功能取决于供应商；c)授权角色对应权限的规则取决于供应商，并在授权功能中配置。在两个TLS端点之间建立了一个TLS会话后，基于角色的客户端授权的执行过程分为两步。在第一步中，当mbaps服务器接收到图6所示的消息8时，mbaps服务器获取x.509v3客户端的域证书，从x.509v3证书中提取角色并缓存。如果在会话恢复的情况下，则此角色应与恢复的会话关联。角色扩展为ASN1编码的UTF8字符串。在角色(Role)扩展示例(如图9所示)中，角色值是“Operator”。图9角色扩展示例在第二步中，mbaps基于角色的客户端授权功能提取的客户端的Role和Modbus请求代码。这两个字段都输入到mbaps授权算法。授权算法确定客户端是AUTHORIZED(被授权)或者NOT_AUTHORIZED(未被授权)在指定资源上执行指定的功能，该资源在mbaps服务器为角色对应权限规则库提供接收的Modbus功能码中指定。如果请求是NOT_AUTHORIZED,则返回Modbus异常码01—lllegalFunctioncode。如果请求AUTHORIZED,则mbap服务器将正常处理该请求。授权功能和角色对应权限规则库可以在服务器设备上，也可能是远程的，需要单独的协议来确定请求的授权状态。这超出了本文件的范围。两步过程见图4。mbaps有关角色授权遵循以下规则。a)R-16:mbaps服务器设备宜提供基于角色的客户端授权，如本条所述。b)R-17:如果mbaps服务器设备提供基于角色的客户端授权，它应符合本条中确定的要求。c)R-18:要提供mbaps基于角色的客户端授权能力，以下要素是需要的：2)mbaps服务器授权算法；3)mbaps服务器角色对应权限规则库。d)R-19:mbaps客户端设备应预置x.509v3域证书。e)R-20:x.509v3客户端域证书宜包含角色扩展。f)R-21:x.509v3证书中的角色应使用MPEMOID.4.1.50316.802.1。g)R-22:x.509v3证书中的角色应使用ASN1:UTF8String编码。h)R-65:每个证书应仅定义一个角色。整个字符串将被视为一个角色。i)R-23:如果在x.509v3证书中没有指定角色，则mbaps服务器应为授权算法提供NULL角色。j)R-24:mbaps授权算法应由设备厂商定义和提供。k)R-25:角色对应权限规则库设计，包括语法和语义，应由设备厂商定义。1)R-26:特定应用的角色对应权限规则库应根据设备厂商的设计进行配置，并由最终用户在mbaps服务器中预置。m)R-27:特定应用程序的角色对应权限规则库应是最终用户可配置的。n)R-28:特定应用程序的角色对应权限规则库禁止具有不可变更的硬编码默认角色。o)R-29:x.509v3客户端域证书中使用的角色值应与设备厂商的角色对应权限规则库的设计一致。p)R-30:mbaps服务器应从收到的x.509v3客户端域证书中提取客户端角色。q)R-31:如果用于授权的mbap协议处理程序拒绝请求，则应使用异常码01-Illegalfunction9系统依赖性在解决方案架构中，mbaps设备依赖于公钥基础设施(PKI)的证书管理服务，其具体细节对于mbaps服务器或客户端行为的实现并不重要。mbaps有关TLS版本遵循以下规则：a)R-32:mbaps设备应提供TLSv1.2或更高版本；b)R-33:mbaps设备应符合RFC5246的要求；c)R-34:mbaps设备禁止协商降级到TLSv1.1,TLSv1.0或SSLV3.0;d)R-35:mbaps设备禁止根据RFC6176协商使用SSLv2.0和SSLv1.0。mbaps有关密码套件遵循以下规则。a)R-36:mbaps设备宜提供计数器模式密码套件。计数器模式密码套件包括：b)R-37:mbaps设备禁止协商使用TLS_NULL_WITH_NULL_NULL密码套件。c)R-38:由mbaps设备使用并在TLS握手协议交换中协商的任何密码套件应是在IANATLS密码套件注册表中列出的。注：密码套件见/assignments/tls-parameters/tls-parameters.xhtmlmbaps有关密钥交换遵循以下规则。a)R-39:mbaps设备应提供基于RSA技术的TLS客户端-服务器密钥交换，见RFC5246所描述的强制密码套件。b)R-40mbaps设备宜提供基于ECC技术的TLS客户端-服务器的密钥交换。c)R-61使用ECC技术的mbaps设备应至少支持P-256NIST曲线。d)R-62使用ECC技术的mbaps设备应至少支持密码套件：1)TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256。e)R-63使用ECC技术的mbaps设备应在ClientHello指定使用RFC4492支持的椭圆曲线扩展中的曲线。f)R-64使用ECC技术的mbaps设备应在ClientHello指定RFC4492中的“支持的点格式”扩展支持的点格式。可以使用自签名设备证书来完成对信任锚的身份认证。宜使用由证书颁发机构签名的证书进行身份认证。宜支持使用会话票证或恢复会话ID进行会话恢复，以减少连接的握手时间。会话恢复首选使用会话ID。在会话恢复中，服务器负责缓存和维护会话信息以供以后使用，这样对客户端管理与其对端的会话信息的支持更好，需求也更少。会话票证将会话信息的负担置于客户端上。这个信息是由服务器加密并传输到客户端。在新会话中，此信息将被传回服务器，并用于重新建立连接。对服务器资源需求减少了，但网络资源被浪费，同时由于信息的传输，重新建立连接需要更长的时间。mbaps有关TLS认证遵循以下规则：a)R-41:mbaps设备应支持TLS客户端-服务器端双向身份认证握手；b)R-42:mbaps设备宜支持客户端和服务器上的TLS恢复会话握手；c)R-43:mbaps设备可支持客户端和服务器上的TLS会话票证恢复；d)R-44:如果客户端没有用证书响应服务器端证书请求，则mbaps服务器应拒绝TLS握手；e)R-45:mbaps设备宜提供由证书颁发机构签署的x.509v3证书；f)R-46:mbaps设备在发送证书时应发送包含向下到根CA的整个证书链；g)R-47:mbaps设备提供的x.509v3证书应符合RFC5280的要求。mbaps有关TLS加密遵循以下规则：a)R-48:如果要在需要加密的情况下使用mbaps设备，则应从IANA的TLS密码套件注册表中选择具有所需加密指示符的密码套件；b)R-49:如果要在不需要加密的情况下使用mbaps设备，则应从IANA的TLS密码套件注册表中选择数据加密指示符为NULL的密码套件。mbaps有关TLSMAC遵循以下规则：a)R-50:mbaps设备禁止使用HMAC-MD5哈希算法；b)R-51:mbaps设备禁止使用HMAC-SHA-1哈希算法；c)R-52:mbaps设备应提供