David Handermann created NIFI-9761:
--------------------------------------
Summary: Correct Load-Balanced Connection Handling for TLS 1.3
Key: NIFI-9761
URL: https://issues.apache.org/jira/browse/NIFI-9761
Project: Apache NiFi
Issue Type: Bug
Components: Core Framework
Affects Versions: 1.15.3, 1.8.0
Reporter: David Handermann
Assignee: David Handermann
Fix For: 1.16.0
Load-Balanced Connections leverage Java NIO to implement a custom protocol for
distributing FlowFiles across NiFi cluster nodes. The {{PeerChannel}} class in
{{nifi-framework-core}} handles communication using a {{SocketChannel}} and
also interacts with {{SSLEngine}} to support encrypted connections using TLS.
TLS 1.3 introduced the concept of a post-handshake message in [RFC 8446 Section
4.6|https://datatracker.ietf.org/doc/html/rfc8446#section-4.6] which can cause
problems with {{SSLEngine}} handling when not processed. Following the
completion of a TLS 1.3 handshake, {{SSLEngine.unwrap()}} returns a result that
has a status of {{OK}} and a handshake status of {{{}FINISHED{}}}. The result
indicates that {{SSLEngine.unwrap()}} should be called again so that the
handshake status of {{SSLEngine}} moves to {{{}NOT_HANDSHAKING{}}}.
The {{PeerChannel.decrypt()}} does not check the handshake status, resulting in
unprocessed socket stream bytes remaining in the buffer. On a subsequent
{{PeerChannel.read()}} invocation, the method attempts to read more bytes from
the socket channel when buffered bytes are already available for processing.
This can cause numerous unnecessary calls to {{PeerChannel.read()}} leading to
timeouts or other unexpected behavior.
The {{PeerChannel}} class should be corrected to handle the TLS 1.3
post-handshake message so that the initial call to {{read()}} returns the same
application data as it would when using TLS 1.2.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
