Skip to content

docs: document post-handshake session verification for TLS - #3462

Open
pjfanning wants to merge 1 commit into
apache:mainfrom
pjfanning:docs-ssl-session-verification
Open

docs: document post-handshake session verification for TLS#3462
pjfanning wants to merge 1 commit into
apache:mainfrom
pjfanning:docs-ssl-session-verification

Conversation

@pjfanning

Copy link
Copy Markdown
Member

Motivation

The Artery SSLEngineProvider trait exposes verifyClientSession and verifyServerSession. ArteryTcpTransport invokes them after every successful TLS handshake and fails the connection when they return Some(cause):

https://github.com/apache/pekko/blob/main/remote/src/main/scala/org/apache/pekko/remote/artery/tcp/ArteryTcpTransport.scala#L145
https://github.com/apache/pekko/blob/main/remote/src/main/scala/org/apache/pekko/remote/artery/tcp/ArteryTcpTransport.scala#L261

The mechanism works and needs no code change, but it was only described in the RotatingKeysSSLEngineProvider section of the docs. Users on the default JKS-based ConfigSSLEngineProvider (whose verify* methods return None) had no indication that overriding them is a supported extension point.

Changes

Adds a "Custom post-handshake session verification" subsection to remote-security.md, under the existing SSL/TLS configuration section:

  • Documents both callbacks and their return contract.
  • States that hostname-verification=on is preferred when peer hostnames are known, so the verifier is not presented as a substitute for it.
  • Explains the dependency on require-mutual-authentication — with it off, the accepting side gets no peer certificate and getPeerCertificates throws SSLPeerUnverifiedException.
  • Notes the callbacks run on every handshake and should avoid blocking I/O such as CRL/OCSP lookups.
  • Cross-references RotatingKeysSSLEngineProvider as the built-in user of the same mechanism.

The example is a compiled snippet (docs/src/test/scala/docs/remoting/SSLEngineProviderDocSpec.scala) pulled in with @@snip, following the convention used elsewhere in the docs, so it cannot silently rot. It covers the shared-internal-CA case: every node's certificate is signed by the same CA and therefore accepted by the trust-store, but only a subset should be allowed into a given cluster.

Docs only — no production code or configuration is changed.

Tests

  • sbt docs/Test/compile passes; the snippet compiles against the real ConfigSSLEngineProvider API.
  • sbt docs/scalafmt run; the snippet is unchanged by it.
  • sbt docs/headerCreateAll generated the license header on the new file.
  • sbt docs/paradox was not run locally; relying on CI to validate the @@snip reference and link rendering.
  • No MiMa run: no public API, binary shape, or serialization change.

References

  • SSLEngineProvider trait: remote/src/main/scala/org/apache/pekko/remote/artery/tcp/SSLEngineProvider.scala
  • Existing no-op implementations: remote/src/main/scala/org/apache/pekko/remote/artery/tcp/ConfigSSLEngineProvider.scala
  • Reference implementation using the hook: remote/src/main/scala/org/apache/pekko/remote/artery/tcp/ssl/RotatingKeysSSLEngineProvider.scala

The `SSLEngineProvider` trait exposes `verifyClientSession` and
`verifyServerSession`, which Artery invokes after every successful TLS
handshake and which fail the connection when they return `Some(cause)`.
This extension point was only described in the context of
`RotatingKeysSSLEngineProvider`, so users on the default JKS-based
`ConfigSSLEngineProvider` had no signpost that overriding these methods
is supported.

Add a section to remote-security.md covering the callbacks, when to
prefer `hostname-verification=on` instead, the interaction with
`require-mutual-authentication`, and a compiled example that scopes a
cluster to a subset of certificates issued by a shared internal CA.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant