BCJSSE: client call - error after renegotiation

[vjinochProfinit]

Hi,

in the master is added commit 18e1c3106bcfab7f646f993f56027fea7af24357 with acceptance of Renegotiation. I'm happy about that, cause I'm missing this functionality in one of our projects.

I tested this functionality during a call of server with a client certificate (tls 1.2 on Java 7) and it fixed the issue described here: https://github.com/bcgit/bc-java/issues/593#issuecomment-533518845 -->

ProvTlsClient - Client raised warning(1) no_renegotiation(100) alert: Renegotiation not supported`

But the communication still ends with:

ProvTlsClient notifyAlertRaised
WARNING: Client raised fatal(2) internal_error(80) alert: Failed to read record'.

I sought the reason and I found that the error is caused by validation in the completeHandshake() method in the TlsProtocol class. There is validation on 'appDataReady' if is this property set on true then the method throws an exception otherwise application sets the property on true and continues. The reason for the error is, that during the renegotiation is method completeHandshake() is called twice.

I tried to fix this issue by improving the appDataReady check about the ignore of this check during renegotiation, but I'm not sure if it is the correct way, to solve it.

After this update communication starts to work correctly.

Original check:

if (appDataReady ||
                    null == securityParameters.getLocalVerifyData() ||
                    null == securityParameters.getPeerVerifyData())
            {
                throw new TlsFatalAlert(AlertDescription.internal_error);
            }

Updated check:

if ((!(RenegotiationPolicy.ACCEPT == getRenegotiationPolicy() && securityParameters.isRenegotiating()) && appDataReady) ||
                null == securityParameters.getLocalVerifyData() ||
                null == securityParameters.getPeerVerifyData())
            {
                throw new TlsFatalAlert(AlertDescription.internal_error);
            }

Please, is it possible to check if is this solution correct? Otherwise, is possible to guide me in the right direction of a solution?

Kindly regards, Vlastimil

[peterdettman]

I agree there is a bug here and your fix correctly addresses the immediate problem, although I will have to review it more fully.

[peterdettman]

@vjinochProfinit Are you able to confirm that this issue is fixed by the 1.70 release?