[
https://issues.apache.org/jira/browse/IGNITE-29256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29256:
--------------------------------------
Description:
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.
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.
# Use one discovery socket path for all factory types.
# If context lookup or TLS setup fails on an accepted discovery socket, close
that socket and keep accepting connections. In NIO, a context lookup failure
must close only the affected session and leave the worker running.
h3. Custom factories and compatibility
Ignite calls {{create()}} on the configured {{Factory<SSLContext>}} at startup
and for every new connection, including on NIO threads. Calls can run
concurrently. Factories control context reuse; slow loading in {{create()}}
delays network processing.
Custom discovery contexts must support engine creation for startup checks, 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.
* After an injected lookup or socket-setup failure, discovery accepts the next
connection; an NIO lookup failure leaves the worker usable.
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]
was:
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.
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
# For {{AbstractSslContextFactory}}, obtain its current context for every new
connection. Cover both directions of discovery and communication, plus the
client connector and binary REST.
# Keep established connections open. During loading and after a failed reload,
new connections must still use the previous context. Preserve server mode,
client authentication, handshake timeouts, protocols, cipher suites and startup
validation.
# Use one discovery socket path for all factory types. Other factory types keep
their startup context for discovery and incoming connections; outgoing
communication keeps calling their factory for each connection.
# If context lookup or TLS setup fails on an accepted discovery socket, close
that socket and keep accepting connections. In NIO, a context lookup failure
must close only the affected session and leave the worker running.
h3. Custom factories and compatibility
Document that Ignite calls {{AbstractSslContextFactory.create()}} for every new
connection, including on NIO threads. Custom discovery contexts must support
engine creation for startup checks, 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 test reloads a running node's factory, then confirms 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
during loading and after a failed load.
* A shared factory and an ordinary factory work through the same discovery
path. After an injected lookup or socket-setup failure, discovery accepts the
next connection; an NIO lookup failure leaves the worker usable.
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]
> 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: 10m
> 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.
> 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.
> # Use one discovery socket path for all factory types.
> # If context lookup or TLS setup fails on an accepted discovery socket, close
> that socket and keep accepting connections. In NIO, a context lookup failure
> must close only the affected session and leave the worker running.
> h3. Custom factories and compatibility
> Ignite calls {{create()}} on the configured {{Factory<SSLContext>}} at
> startup and for every new connection, including on NIO threads. Calls can run
> concurrently. Factories control context reuse; slow loading in {{create()}}
> delays network processing.
> Custom discovery contexts must support engine creation for startup checks,
> 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.
> * After an injected lookup or socket-setup failure, discovery accepts the
> next connection; an NIO lookup failure leaves the worker usable.
> 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)
