sm: accept Inband-Security-Id=1 when TLS is already established - #242
Merged
Merged
Conversation
Per RFC 6733 §5.3.1, a peer may include Inband-Security-Id=1 in CER to declare TLS capability. When the connection is already TLS-secured, this should be accepted (security requirement already satisfied) rather than rejected with NO_COMMON_SECURITY. Add ParseWithSecurity() to CER parser that accepts a tlsActive flag. The existing Parse() method preserves backwards-compatible behavior (rejects Inband-Security-Id=1 on plain connections). The server CER handler now passes c.TLS() != nil to the parser. Fixes fiorix#236
Owner
|
LGTM. The |
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
2 participants
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.
Per RFC 6733 §5.3.1, a peer may include Inband-Security-Id=1 in CER to declare TLS capability. When the connection is already TLS-secured, this should be accepted rather than rejected with NO_COMMON_SECURITY.
Changes
ParseWithSecurity(msg, role, tlsActive)to CER parserParse()preserves backwards-compatible behavior (rejects on plain TCP)handleCERto passc.TLS() != nilto the parserRFC Reference
RFC 6733 §5.3.1, §6.2: When TLS is already established on the transport, Inband-Security-Id=1 simply declares the peer's TLS capability — the security requirement is already satisfied.
All existing tests pass (including TestHandleCER_InbandSecurity which verifies rejection on plain TCP).
Fixes #236