On Thu, 17 Oct 2024 15:55:29 GMT, Artur Barashev <abaras...@openjdk.org> wrote:
>> Does it happen in server side (server send plaintext) as well? I found some >> cases that the client decryption failed. > >> Does it happen in server side (server send plaintext) as well? I found some >> cases that the client decryption failed. > > Current reports indicate it happens on the server side only (server throws > the exception). Please share any cases when it happens on the client side. > This PR has a check to handle this scenario on the server side only. > > > @artur-oracle Thank you for update. > > > It may be too later, but if there is a chance it might worthy of an > > > update so that it can take care of more cases. In the SSLCipher decrypt() > > > implementation, the content type of the input record is already known. If > > > the content type is alert, and decryption failed or insufficient buffer, > > > does it sound reasonable to you to close the connection immediately? > > > > > > I'm not sure how it would be different from the current state, what do you > > mean by `close the connection immediately`? > > 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? - For SSLEngine usage: SSLEngine has no notion of connection. - 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21043#issuecomment-2420138869
