Peter Dettman

Are you saying that there are multiple instances of some service using the BC providers and only one of these instances is having the issue?

If the service is under especially high load, I would guess a race condition is involved before suspecting packet corruption (and of course it would be helpful to rule out...

@oridool It might provide useful information to try the reproducer with the regular BC library (bcprov + bctls jars). I would be interested in results from both the latest release...

> I was trying to reproduce the issue with bcprov+bctls 1.71 and even 1.69 but with no success. > It doesn't occur when using these jars. @oridool That's interesting information....

@oridool TLS 1.1 doesn't support GCM cipher suites. For TLS 1.3, you need different cipher suite names, e.g. "TLS_AES_128_GCM_SHA256", so that might be the issue. Maybe post the exception you're...

> How can we proceed from here ? Can you disable GCM cipher suites in TLS 1.2 and try that please (e.g. configure your client so that only TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 is...

e.g. by setting jdk.tls.client.cipherSuites system property: `-Djdk.tls.client.cipherSuites="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"`

For a TLS server, it's jdk.tls.server.cipherSuites . You could try that instead and as long as the suite is also in the list the client offers it should work. I...

@oridool It's not clear to me that your tests with the non-FIPS BC providers would actually be using GCM cipher suites, since in that case our client offers CHACHA20_POLY1305 suites...

@oridool - A JVM (or JIT) error with 17 is still in the cards. Still, it seems a little weird to see such an error take an hour of heavy...