On Thu, 17 Oct 2024 17:46:39 GMT, Artur Barashev <abaras...@openjdk.org> wrote:
> > Currently, if an alter message cannot be decrypted, exception thrown. When > > alert is received, if it is not decryptable, treat it as an alert and close > > the connection accordingly, without sending more message to peers. > > * For SSLSocket usage: aren't connection closed upstream anyhow when we throw > an exception? Yes. But what's the problem we want to address for this PR? If I read your patch correctly, you want to fix the exception for a gracefully close, right? I think you are on the right direction. > * For SSLEngine usage: SSLEngine has no notion of connection. SSLEngine's way is to use status and messages to guide connection. The logic should be the same as what do you in the patch. > * For both usages: `SSLCipher` and `SSLSocketInputRecord` have no context, we > don't know if we are at handshake stage or not , etc. We check for all this > at SSLTransport that has the context. Besides, it's better to process the > alert and finish the handshake nicely than just cut the connection. Sorry for the confusing, we may refer connection as two different things. I meant TLS connections. Close the TLS connection could be nicely, and follow the TLS specification. SSLCipher has contentType. If I read your patch correctly, you are creating a different Plaintext for further processes. Is it doable in SSLCipher so that you don't have to cash input record? I think you are on the right direction, I was just wondering if it is possible to simplify the implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21043#issuecomment-2420290613
