COMM-003 - 基础安全 [C, A, S]

COMM-003 - Basic Security [C, A, S]

目的

Purpose

验证客户端是否能够使用 HTTPS 和 IEEE 2030.5 允许的加密套件连接到服务器。
Verify ability to connect to server using HTTPS and IEEE 2030.5 permissible cypher suite.
基础安全测试验证客户端是否可以根据基础安全要求正确地与 IEEE 2030.5 服务器通信。
The basic security test verifies that the Client can correctly communicate with an IEEE 2030.5 server using basic security requirements.
例如，使用 HTTPS、TLS 1.2、TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 加密套件。
For example, the HTTPS, TLS 1.2, TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite.
TLS 身份验证根据 IEEE 2030.5 应用协议规范中指定的要求进行测试。
TLS authentications are tested based on requirements specified in the IEEE 2030.5 Application Protocol Specification.

测试环境设置

Setup

  1. 服务器和客户端支持基于 TLS 的 HTTP 通信，符合规范要求，包括使用强制的 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 加密套件。
      2. Server and Client support the TLS based HTTP communication as specified in the Requirements, including the use of mandatory TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite.
  1. 服务器配置使用默认的 TLS 端口（443）或其他端口。客户端配置使用来自服务器的受支持的 TLS 端口和 IP 地址。
      2. Server is configured to use either the default TLS port (443) or another port. Client is configured to use the supported TLS port and IP address from the Server.
  1. 客户端可以发送和接收基于 TLS 的 HTTPS 消息，符合规范要求，包括使用强制的 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 加密套件。
      2. Client can send and receive TLS based HTTPS messages as specified in the requirements, including the use of mandatory TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite.

测试步骤

Procedure

  1. [T] 记录客户端与服务器的通信。
      2. [T] Record the Client/Server communications.
  1. [C] 使用已知的 IP 地址、端口号和 DeviceCapability URI，向服务器发送基于 TLS 的 HTTP GET 请求。
      2. [C] Using the known IP address, port number, and DeviceCapability URI, send a TLS based HTTP GET request to the Server.
  1. [S] 成功接收该 TLS 基础的 HTTP GET 请求，并通过 TLS 端口返回 DeviceCapability 资源负载。
      2. [S] Successfully receive the TLS based HTTP GET request and respond with the DeviceCapability resource payload through the TLS port number.

通过/失败判定标准

Pass/Fail Criteria

  • [C] 客户端成功建立了一个符合 RFC 5246 第 7.4 节规定的 TLS HTTP 会话。
      • The Client successfully established a TLS HTTP session by conforming to the requirements specified in RFC 5246, section 7.4.
  • 通过检查 TLS 数据包确认，包括使用了 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 加密套件。
      • Verify by inspecting the TLS packets, including verification that TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite was used.
  • 使用已知的 IP 地址、端口号和 DeviceCapability URI 成功发送了基于 TLS 的 HTTP GET 请求。
      • Successfully sent a TLS based HTTP GET request to the Server DeviceCapability resource using the known IP address, port number, and DeviceCapability URI.
  • [S] 服务器成功建立了一个符合 RFC 5246 第 7.4 节规定的 TLS HTTP 会话。
      • Server successfully established a TLS HTTP session by conforming to the requirements specified in RFC 5246, section 7.4.
  • 通过检查 TLS 数据包确认，包括使用了 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 加密套件。
      • Verify by inspecting the TLS packets, including verification that TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite was used.
  • 成功接收到基于 TLS 的 HTTP GET 请求，并以 DeviceCapability 资源负载作为 HTTP GET 响应进行回复。
      • Successfully received the TLS based HTTP GET request and responded with the DeviceCapability resource payload as the HTTP GET response.
 

COMM-004 - 高级安全 [C, A, S]

COMM-004 - Advanced Security [C, A, S]

目的

Purpose

验证客户端是否有能力检测对端证书链中的错误并拒绝连接。
Verify ability to detect errors in certificate chain of peer and reject the connection.
高级安全测试验证客户端是否能够使用基本的 TLS/安全要求与 IEEE 2030.5 服务器通信，并且还能处理更具挑战性的要求，包括无效场景。例如，处理连接中断、无效证书以及无效根 CA。
The advanced security test verifies that the Client can communicate with the IEEE 2030.5 server using basic TLS/security requirements and can also handle more challenging requirements, including invalid scenarios. For example, handling broken connections, invalid certificates, and invalid root CA.

设置

Setup

本测试用例应实现为 7 个独立的子测试，编号为 COMM-004A 到 COMM-004G，以简化 TLS 证书认证和验证问题的定位。
This test case shall be implemented as 7 standalone sub-tests, numbered COMM-004A through COMM-004G, to simplify isolating problems with TLS certificate authentication and validation.
  1. 服务器和客户端支持基于 TLS 的 HTTP 通信，符合规范要求，包括使用强制的 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 加密套件，并在发生错误时发送 TLS 警报。
      2. Server and Client support the TLS based HTTP communication as specified in the Requirements, including the use of mandatory TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite and send TLS Alerts for error situations.
  1. 服务器被配置为使用默认的 TLS 端口（443）或其他端口。客户端被配置为使用来自服务器的受支持的 TLS 端口和 IP 地址。
      2. Server is configured to use either the default TLS port (443) or another port. Client is configured to use the supported TLS port and IP address from the Server.
  1. 客户端可以发送和接收基于 TLS 的 HTTPS 消息，符合规范要求，包括使用强制的 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 加密套件，并在出错时发送 TLS 警报。
      2. Client can send and receive TLS based HTTPS messages as specified in the requirements, including the use of mandatory TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite and send TLS Alerts for error situations.
  1. 服务器和客户端支持两级、三级和四级链长度的 TLS 证书，其中：
      2. Server and Client support two, three, and four chain length TLS certs where:
      • 证书链长度为二：SERCA -> 设备证书（COMM-004A）
          • Certificate chain length two: SERCA -> Device Certificate (COMM-004A)
      • 证书链长度为三：SERCA -> MICA -> 设备证书（COMM-004B）
          • Certificate chain length three: SERCA -> MICA -> Device Certificate (COMM-004B)
      • 证书链长度为四：SERCA -> MCA -> MICA -> 设备证书（COMM-004C）
          • Certificate chain length four: SERCA -> MCA -> MICA -> Device Certificate (COMM-004C)
      请参阅 IEEE 2030.5 标准的“证书管理”部分。
      Refer to the IEEE 2030.5 standard, Certificate Management section.
  1. 附加的 TLS 证书具有以下属性：
      2. Additional TLS certs with following attributes:
      • 无效的 MICA 扩展密钥关键值（COMM-004D）
          • Invalid MICA Extended Key Critical value (COMM-004D)
      • 无效的 MICA 名称非关键值（COMM-004E）
          • Invalid MICA Name Non-Critical Value (COMM-004E)
      • 无效的 MICA 策略映射非关键值（COMM-004F）
          • Invalid MICA Policy Mapping Non-Critical value (COMM-004F)
      • 自签名设备证书（COMM-004G）
          • Self-signed device certificate (COMM-004G)

流程

Procedure

  1. [T] 记录客户端/服务器通信。
      2. [T] Record the Client/Server communications.
  1. [T] 配置 TLS 证书，证书链长度为二：SERCA -> 设备证书，建立一个新的 TLS 会话。
      2. [T] Configure with TLS cert, chain length two: SERCA->Device Certificate, to establish a new TLS session.
  1. [C] 使用已知的 IP 地址、端口号和 DeviceCapability URI，向服务器发送基于 TLS 的 HTTP GET 请求。
      2. [C] Using the known IP address, port number, and DeviceCapability URI, send a TLS based HTTP GET request to the Server.
  1. [S] 成功接收该 TLS 基础的 HTTP GET 请求，并通过 TLS 端口号响应 DeviceCapability 资源负载。
      2. [S] Successfully receive the TLS based HTTP GET request and respond with the DeviceCapability resource payload through the TLS port number.
  1. [T] 配置 TLS 证书，链长度为三：SERCA->MICA->设备证书，开始一个新的 TLS 会话建立，并重复测试步骤 2 和 3。
      2. [T] Configure with TLS cert, chain length three: SERCA->MICA->Device Certificate, and start a new TLS session establishment and repeat test steps 2 and 3.
  1. [T] 配置 TLS 证书，链长度为四：SERCA->MCA->MICA->设备证书，开始新的 TLS 会话建立，并重复测试步骤 2 和 3。
      2. [T] Configure with TLS cert, chain length four: SERCA->MCA->MICA->Device certificate and start a new TLS session establishment and repeat test steps 2 and 3.
  1. [T] 配置 TLS 证书，使用无效的 MICA 扩展密钥关键值，开始新的 TLS 会话建立，并重复测试步骤 2 和 3。
      2. [T] Configure with TLS cert, Invalid MICA Extended Key Critical, and start a new TLS session establishment and repeat test steps 2 and 3.
  1. [T] 配置 TLS 证书，使用无效的 MICA 名称非关键值，开始新的 TLS 会话建立，并重复测试步骤 2 和 3。
      2. [T] Configure with TLS cert, Invalid MICA Name Non-Critical and start a new TLS session establishment and repeat test steps 2 and 3.
  1. [T] 配置 TLS 证书，使用无效的 MICA 策略映射非关键值，开始新的 TLS 会话建立，并重复测试步骤 2 和 3。
      2. [T] Configure with TLS cert, Invalid MICA Policy Mapping Non-Critical, and start a new TLS session establishment and repeat test steps 2 and 3.
  1. [T] 配置 TLS 证书，使用自签名证书，开始新的 TLS 会话建立，并重复测试步骤 2 和 3。
      2. [T] Configure with TLS cert, Self-signed Cert, and start a new TLS session establishment and repeat test steps 2 and 3.

通过/失败判定标准

Pass/Fail Criteria

  • [T] TCP 端口断开或 HTTP 403 响应应作为 TLS 警报通知无效证书的可接受替代方式。
      • A TCP port disconnect, or HTTP 403 shall be acceptable alternative to a TLS alert for notification of invalid certificates.
  • [T] 测试设备成功配置为使用证书链长度为二（SERCA->设备证书）。
      • The testing device successfully configured itself to use certificate chain length of two (SERCA->Device Certificate).
  • [C] 客户端通过使用链长度为二的 TLS 证书，成功建立 TLS HTTP 会话，符合 RFC 5246 第 7.4 节中的要求。通过检查 TLS 数据包确认使用了 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 加密套件和证书链长度。使用已知的 IP 地址、端口号和 DeviceCapability URI 成功发送基于 TLS 的 HTTP GET 请求。
      • The Client successfully established a TLS HTTP session using TLS cert chain length of two by conforming to the requirements specified in RFC 5246, section 7.4. Verify by inspecting the TLS packets, including verification that TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite was used and cert chain length. Successfully sent a TLS based HTTP GET request to the Server DeviceCapability resource using the known IP address, port number, and DeviceCapability URI.
  • [S] 服务器使用链长度为二的 TLS 证书，成功建立 TLS HTTP 会话，符合 RFC 5246 第 7.4 节中的要求。通过检查 TLS 数据包确认使用了 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 加密套件和证书链长度。成功接收 TLS GET 请求并以 DeviceCapability 资源作为 HTTP GET 响应返回。
      • Server successfully established a TLS HTTP session using TLS cert chain length of two by conforming to the requirements specified in RFC 5246, section 7.4. Verify by inspecting the TLS packets, including verification that TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite was used and cert chain length. Successfully received the TLS based HTTP GET request and responded with the DeviceCapability resource payload as the HTTP GET response.
  • [U] 测试设备成功配置为使用证书链长度为三（SERCA->MICA->设备证书）。客户端和服务器分别成功通过了条件 2 和 3（与链长为二时相同）。
      • The testing device successfully configured itself to use a certificate chain length of three (SERCA->MICA->Device Certificate). The Client and Server successfully passed Criteria 2 and 3, respectively, where chain length is three, instead of two.
  • [U] 测试设备成功配置为使用证书链长度为四（SERCA->MCA->MICA->设备证书）。客户端和服务器分别成功通过了条件 2 和 3。
      • The testing device successfully configured itself to use certificate chain length of four (SERCA->MCA->MICA->Device Certificate). The Client and Server successfully passed Criteria 2 and 3, respectively, where chain length is four, instead of two.
  • [U] 测试设备成功配置为使用无效的 MICA 扩展密钥关键证书，但未能建立 TLS 连接。被测设备响应 TLS 警报，指出证书无效，并未能与测试设备建立 TLS 连接。
      • The testing device successfully configured itself to use an Invalid MICA Extended Key Critical cert but failed to receive a TLS connection. The device under test responded with a TLS Alert indicating the invalid cert and failed to establish TLS connection with the testing device.
  • [U] 测试设备成功配置为使用无效的 MICA 名称非关键证书，但未能建立 TLS 连接。被测设备响应 TLS 警报，指出证书无效，并未能与客户端建立 TLS 连接。
      • The testing device successfully configured itself to use an Invalid MICA Name Non-Critical cert but failed to receive a TLS connection. The device under test responded with a TLS Alert indicating the invalid cert and failed to establish TLS connection with Client.
  • [U] 测试设备成功配置为使用无效的 MICA 策略映射非关键证书，但未能建立 TLS 连接。被测设备响应 TLS 警报，指出证书无效，并未能与测试设备建立 TLS 连接。
      • The testing device successfully configured itself to use an Invalid MICA Policy Mapping Non-Critical cert but failed to receive a TLS connection. The device under test responded with a TLS Alert indicating the invalid cert and failed to establish TLS connection with the testing device.
  • [U] 测试设备成功配置为使用自签名证书，但未能建立 TLS 连接。被测设备响应 TLS 警报，指出证书无效，并未能与测试设备建立 TLS 连接。
      • The testing device successfully configured itself to use a self-signed cert but failed to receive a TLS connection. The device under test responded with a TLS Alert indicating the invalid cert and failed to establish TLS connection with testing device.
相关文章
Lazy loaded image
一条配置查询，搞瘫了整个服务
Lazy loaded image
fastjson2 丢字段：不是 reader 吞了字段，是 writer 写错了路
Lazy loaded image
线上 4 个 RPC 参数丢了 3 个字段，到底谁干的
Lazy loaded image
Paho 设计思想与常见设计模式分析
Lazy loaded image
Paho 源码结构与基础使用实践
Lazy loaded image
Java 8 Stream 全面解析：从一个排序示例讲清「中间操作 vs 终端操作」与底层实现
SUNSPEC IEEE2030.5/CSIP认证-设备证书相关解读【案例分析】微服务异常重启排查
Loading...
Yibin
Yibin
一名平凡的程序员👨🏻‍💻
公告
📢 行远自迩，笃行不怠。
记录技术、工具和一些真实的折腾。
 
目录
0%