maskit opened a new pull request, #13998: URL: https://github.com/apache/trafficserver/pull/13998
Under `verify_server_policy: PERMISSIVE`, an origin that a `TS_SSL_VERIFY_SERVER_HOOK` plugin rejects should still be used, with a warning. Instead, the rejection set the handshake status to error, which `getSSLHandShakeComplete()` counts as complete. Over TLS 1.2 the hook always runs before the handshake finishes, because the client still waits for the origin's final flight. Traffic Server therefore handed the connection to the HTTP state machine before the handshake finished, and the handshake-completion steps in `sslClientHandShakeEvent()` never ran. Over TLS 1.3 the handshake usually finishes in the same `SSL_connect()` call that ran the hook, and the TLS 1.3 cases were not affected in testing. ## Effect Observed in debug logs with another Traffic Server as the origin: - The negotiated ALPN protocol is never recorded, so the origin session is created as HTTP/1.1 even when the origin agreed to HTTP/2. On Linux the request went out as HTTP/1.1, the origin closed the connection, and every retry failed the same way until the client got a 502. A retry only succeeded when it resumed a cached TLS session, because a resumed handshake runs no verify hook. - The request write is attempted before the handshake has finished. On Linux, a write that needed to read first was retried after the read and succeeded. On macOS it was never retried: the read finished the handshake inside the TLS library without returning any data, and the connection stalled until the client gave up. The cause of this platform difference is not established; it may lie in how the epoll and kqueue backends report readiness. ## Approach `SSLNetVConnection::_verify_certificate()` now reports a hook rejection only through its return value and restores the handshake status it found. Every caller already acts on that return value: inbound verification and ENFORCED fail the handshake through the TLS library, and PERMISSIVE logs the failure and continues. The comments in `verify_callback()` and `ssl_verify_client_callback()`, and `TSVConnReenable.en.rst`, are updated to match. Two side effects on handshakes that are rejected anyway: a rejected ENFORCED or inbound handshake now stays ongoing rather than error, so closing it no longer attempts a TLS shutdown on a handshake that never completed. Also, the PERMISSIVE warning, which the logs showed twice for one rejection, is now logged once. ## Validation - New `test_tls_hooks_verify_rejection_with_tls_origin` uses another Traffic Server as the origin, with PERMISSIVE and ENFORCED over TLS 1.3 and 1.2, offering HTTP/1.1 or HTTP/2. The PERMISSIVE request must be served, over an HTTP/2 origin session when HTTP/2 was offered, and the ENFORCED one refused. The edge's origin session cache is off, so a retry cannot resume its way past the bug. - Without this change, on Linux (the CI Fedora image), the PERMISSIVE TLS 1.2 HTTP/2 case fails with a 502 and the other cases pass. On macOS the PERMISSIVE TLS 1.2 HTTP/1.1 case times out; the HTTP/2 case was not run there without the change. - With this change, all cases and the existing `test_tls_hooks_verify` pass on Linux, and on macOS with BoringSSL. ## Notes - #13846, still open, changes the same status handling for inbound connections and deliberately leaves outbound ones alone. Its `test_tls_hooks_verify_tls12` covers a PERMISSIVE TLS 1.2 rejection with the test microserver as an HTTP/1.1 origin; it passes in CI on Linux, consistent with the write retry seen there, and stalled on macOS in local runs against master. If both land, that test overlaps with the one added here. - A plugin that rejects by reenabling after its verify hook has returned is not covered: the rejection then arrives after the verification result was decided. That behavior is unchanged by this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
