bugfix: reject settrustedstore on already-handshaked cosocket#1
Merged
Conversation
Calling tcpsock:settrustedstore() after sslhandshake() has completed silently stashed the new X509_STORE into u->ssl_trusted_store, but the next sslhandshake() short-circuits via the c->ssl->handshaked check and never reaches the SSL_set1_verify_cert_store() block, so peer verification kept using the original trust anchor. Reject the call at the FFI entry when the underlying TLS connection is already established so callers get a clear error instead of a silently ineffective trust-anchor swap. The fix is contained to the FFI argument validation path and does not touch the handshake state machine.
Verifies that calling tcpsock:settrustedstore() on an already-handshaked cosocket now fails with a clear error message instead of silently stashing an X509_STORE that never takes effect, and that the rejected call leaves the existing TLS connection usable for subsequent I/O.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
tcpsock:settrustedstore()called on a cosocket whose TLS handshake has already completed silently became a no-op, while appearing to succeed. The newX509_STOREwas stashed intou->ssl_trusted_store, but a subsequenttcpsock:sslhandshake()short-circuits via thec->ssl->handshakedearly return inngx_http_lua_ffi_socket_tcp_sslhandshakeand never reaches theSSL_set1_verify_cert_store()block atsrc/ngx_http_lua_socket_tcp.c:1942. The connection therefore kept verifying the peer against the trust anchor configured before the first handshake.Fix
Reject the call at the FFI entry when the underlying TLS connection is already established, so callers get a clear error instead of a silently ineffective swap. Scope is intentionally narrow — only
ngx_http_lua_ffi_socket_tcp_settrustedstore. The handshake state machine and session-reuse semantics are unchanged. ReturningNGX_ERRORhere is the existing FFI argument-validation path; it does not close the connection.Tests
Adds
TEST 6int/193-ssl-trusted-store.t:settrustedstore + sslhandshakesucceeds (positive path unchanged).settrustedstoreon the already-handshaked cosocket returnsnil, "ssl handshake already done; trusted store cannot be changed on an established TLS connection".send/receiveafter the rejected call.Mirrors the upstream PR openresty#2505.