尧图网站建设 
这条和 6.3.1 是双胞胎只把版本从 1.1 换成 1.0判定逻辑一模一样对端提 1.0设备 PICS 里声明支持 1.0那就报Warning: Insecure TLS version握手做完连接留着。TLS 1.0 比 1.1 还老安全性更差。标准依然把它归到警告但不拒绝这一档理由还是那个既然设备声明了支持就按支持处理安全风险通过事件日志暴露给运维而不是由协议层替运维做决定。这一点和很多人的直觉相反值得单独记一笔。我们这台 DUT 是 TLS 1.2 only1.0 也没勾所以这条对我们是 NA。适用时怎么测前提同样是先翻 PICS 的 5.2.3确认勾了 TLS 1.0。然后用 1.0 连openssl s_client-connect127.0.0.1:19998\-tls1-cipherDEFAULT:SECLEVEL0\-certclient.crt-keyclient.key\-CAfileca.crt-tls1就是 TLS 1.0别和-tls1_1弄混。新版本 openssl 同样需要SECLEVEL0才肯放行。判定检查项通过标准握手结果成功协商出版本 TLS 1.0安全事件Warning: Insecure TLS version连接保持不因版本老而断开和 6.3.3 的分界这三条摆在一起最容易搞混一句话记法设备支持的弱版本给警告设备不支持的弱版本给报警。1.1 和 1.0 只有在 PICS 声明支持时才走警告这条路一旦设备不支持对端硬提这个版本就落到 6.3.3处理方式立刻变成Alarm: Unsecure communication加断链。测的时候如果发现设备对声明支持的版本也直接断链说明它没区分这两种情况。 6.3.2 远端提议 TLS 1.0，而设备说它支持
这条和 6.3.1 是双胞胎只把版本从 1.1 换成 1.0判定逻辑一模一样对端提 1.0设备 PICS 里声明支持 1.0那就报Warning: Insecure TLS version握手做完连接留着。TLS 1.0 比 1.1 还老安全性更差。标准依然把它归到警告但不拒绝这一档理由还是那个既然设备声明了支持就按支持处理安全风险通过事件日志暴露给运维而不是由协议层替运维做决定。这一点和很多人的直觉相反值得单独记一笔。我们这台 DUT 是 TLS 1.2 only1.0 也没勾所以这条对我们是 NA。适用时怎么测前提同样是先翻 PICS 的 5.2.3确认勾了 TLS 1.0。然后用 1.0 连openssl s_client-connect127.0.0.1:19998\-tls1-cipherDEFAULT:SECLEVEL0\-certclient.crt-keyclient.key\-CAfileca.crt-tls1就是 TLS 1.0别和-tls1_1弄混。新版本 openssl 同样需要SECLEVEL0才肯放行。判定检查项通过标准握手结果成功协商出版本 TLS 1.0安全事件Warning: Insecure TLS version连接保持不因版本老而断开和 6.3.3 的分界这三条摆在一起最容易搞混一句话记法设备支持的弱版本给警告设备不支持的弱版本给报警。1.1 和 1.0 只有在 PICS 声明支持时才走警告这条路一旦设备不支持对端硬提这个版本就落到 6.3.3处理方式立刻变成Alarm: Unsecure communication加断链。测的时候如果发现设备对声明支持的版本也直接断链说明它没区分这两种情况。