[
https://issues.apache.org/jira/browse/IGNITE-29256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignite TC Bot updated IGNITE-29256:
-----------------------------------
Release Note: SSL: New TCP connections now use the current SSL context from
the configured factory after reload. Removed protected TcpDiscoverySpi SSL
socket-factory fields; subclasses must be adapted and rebuilt.
> Use the factory's current SSL context for new TCP connections
> -------------------------------------------------------------
>
> Key: IGNITE-29256
> URL: https://issues.apache.org/jira/browse/IGNITE-29256
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> IGNITE-29209 lets a factory replace its cached SSL context. Outgoing
> communication already obtains that context for each connection. Discovery,
> incoming communication, the client connector and binary REST retain the
> startup context, so replacing the factory cache does not change the keys or
> trust used by their new connections. The Java thin client also retains the
> context obtained at client startup.
> Make these transports use the replacement. The administrator command follows
> in IGNITE-29210; this ticket verifies reload through the factory API.
> h3. What to change
> # Obtain the context from the configured {{Factory<SSLContext>}} for every
> new TCP connection. Cover both directions of discovery and communication,
> plus the client connector and binary REST.
> # Keep established connections open. While {{AbstractSslContextFactory}}
> loads replacement material, or if loading fails, new connections must use its
> previous context. Preserve server mode, client authentication, handshake
> timeouts, protocols, cipher suites and startup validation.
> # Make the Java thin client obtain its context from its configured factory
> for each new connection. Without a configured factory, keep loading the
> context from client settings only once.
> # Use one discovery socket path for all factory types.
> # Treat discovery context lookup and TLS setup failures as connection
> failures, keeping the original cause. An incoming failure must close only the
> accepted socket; an outgoing failure must leave discovery retries available.
> # In NIO, a context lookup failure must close only the affected session and
> leave the worker running. Count it once in the existing
> {{RejectedSslSessionsCount}} metric.
> h3. Custom factories and compatibility
> Node transports call the configured {{Factory<SSLContext>}} at startup. All
> affected transports, including the Java thin client, call {{create()}} for
> new connections, including on NIO threads. The thin client first calls its
> factory when connecting; a failure must be reported as a connection error
> with the original cause. Calls can run concurrently. Factories control
> context reuse; slow loading in {{create()}} delays network processing.
> Custom discovery contexts must support unconnected SSL sockets, TLS wrapping
> of an accepted socket and server mode. Settings supplied only by a custom
> server socket factory no longer affect discovery connections.
> Remove the protected {{TcpDiscoverySpi.sslSockFactory}} and
> {{sslSrvSockFactory}} fields; connections no longer use them. This breaks
> source and binary compatibility for subclasses that access them. Those
> subclasses must be adapted and rebuilt.
> h3. Done when
> * A factory exposed as {{Factory<SSLContext>}} supplies replacement keys and
> trust on every TCP transport, including both directions of discovery and
> communication.
> * Established connections stay usable. New connections use the old material
> while {{AbstractSslContextFactory}} loads a replacement or after loading
> fails.
> * Invalid discovery TLS parameters prevent even the first node from starting,
> before a peer connection is needed.
> * After an injected lookup or socket-setup failure, discovery can accept or
> create the next connection. An NIO lookup failure leaves the worker usable
> and increases the rejection counter exactly once.
> * The same Java thin client reconnects using replacement keys and trust from
> its factory. A client without a configured factory reconnects without
> rereading its key store.
> Depends on IGNITE-29209. The command, scheduling and HTTP REST are separate
> tickets.
> [Implementation plan in PR #13795|https://github.com/apache/ignite/pull/13795]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
