[
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. 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]
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. 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 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]
> 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. 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)
