TLS renegotiation

[donniedump]

Hi,
i found the following issue (#593), and i'm facing the same problem, that is, i'm trying to use bc tls (jsse provider) as a client when connecting to a server, using mutual certificate based authentication. The target server is not under my control, i cannot change the way it is implemented, and i cannot establish the tls channel, as the server is initiating a tls renegotiation, which the bc client won't tolerate. Is there a way to circumvent this behaviour even though its against security considerations? Should i try to make a custom BC fork, and comment out the line(s) causing the alert being raised, or is this modification something way more involved than that? Any other recommendations are welcome!
Thanks in advance, Alex

[peterdettman]

The TLS protocol allows the client to either ignore the renegotiation request or to explicity reject it, however the server is then free to abort the connection, so in that case there's no workaround. The main use of renegotiation is to upgrade to mutual authentication (from an initial server-auth-only connection), so it's not usually optional.

We currently attempt to support renegotiation under restricted (but common) conditions (to avoid known issues). After the fix that went in for #990, I understand that people are reporting it working. However you will need the latest beta version (currently 170b07) from https://downloads.bouncycastle.org/betas/, and since you are using BCJSSE, you'd have to enable renegotiation in the client by setting the system property org.bouncycastle.jsse.client.acceptRenegotiation to true.

[donniedump]

Hi Peter,
thank you for your response, i'll give it a try!
Thanks,
Alex

[donniedump]

Hi Peter,

after upgrading to this beta version some parts of our code (not regarded to tls) is giving as the following error when in comes to asn.1 parsing as a side effect: "object explicit - implicit expected". The previous version of the BC provider had no such problem. Do you have any clues why this happens?

Again, thanks for your help, best regards, Alex

[peterdettman]

Stack trace please, and if you can see this in a debugger then follow the stacktrace back up to the point where you can capture the full ASN.1 structure that is being parsed.

[donniedump]

Hi Peter,

sorry for the late reply. Here is the relevant part of the staktrace:

Caused by: java.lang.IllegalArgumentException: object explicit - implicit expected.
	at org.bouncycastle.asn1.ASN1TaggedObject.getBaseUniversal(ASN1TaggedObject.java:385)
	at org.bouncycastle.asn1.ASN1UniversalType.getContextInstance(ASN1UniversalType.java:50)
	at org.bouncycastle.asn1.ASN1ObjectIdentifier.getInstance(ASN1ObjectIdentifier.java:78)

being invoked as:
ASN1ObjectIdentifier.getInstance(new DERTaggedObject(true, 0, new DEROctetString(data)), false)

Again, the point is, that with the former version used (1.69), no such problem occured.

Regards,
Alex

[peterdettman]

Thanks, @donniedump . 1.70 will include an overhaul of tagged objects, which leads to catching more errors (and things like this which are more of a grey area). I've patched bc-java and opened an issue on cert-cvc to clarify things: Keyfactor/ejbca-cert-cvc#3 .

[donniedump]

Hi Peter,

thank you for the quick fix!

Regards,
Alex

[peterdettman]

Fixed in 1.70.