RFR JDK-8206925,,Support the certificate_authorities extension

[Xuelei Fan]

Hi Alexey,

Thanks for the reproducer. Would you mind add it to JDK-8206925 for 
further testing?

I think more about if a control number could be helpful.  If the 
certificate authorities can not be fully listed, it cannot be used to 
indicate the peer certificate selection accuracy.  For example, client 
support A, B and C, and is only able to indicate A and B.  If the server 
supports C, the connection cannot be established with this extension. 
This is not the expected behavior.  Maybe, it is no worse than without 
this extension.

The extension is not enabled in client side by default because of the 
compatibility issues as described in the CSR.  I don't expect this 
extension used a lot in client side in practice.  Maybe, turn off this 
extension could help to mitigate the impact for now.

I added more comments in the code and release note, to make sure 
developers understand the impact and take care of the issues.

I agree that there is still a gap to cover some other case that there is 
a log CAs and cannot survive without the extension.  Let's if it is a 
real problem in practice.  We can go back and rethink of the solution 
when needed.


Thanks,
Xuelei

On 5/14/2020 4:07 AM, Alexey Bakhtin wrote:
> Just fix a missprint:
> It should be -Djdk.tls.client.enableCAExtension=true in the reproducer:
> $JAVA_HOME/bin/java -Djdk.tls.client.enableCAExtension=true -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com
> 
> 
>> On 14 May 2020, at 13:52, Alexey Bakhtin <alexey at azul.com> wrote:
>>
>> Hello Xuelei,
>>
>> I’ve posted a reproducer for described issue:
>> http://cr.openjdk.java.net/~abakhtin/8206925/
>>
>> The test passed and returns code=200 from the server in case of CA extension disabled on the client side:
>> $JAVA_HOME/bin/java -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com
>>
>> The test fails with “fatal alert: illegal_parameter” in case of CA extension enabled on the client side:
>> java -Djavax.net.debug=none -Djdk.tls.client.enableCAExtension=false -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com
>>
>> I would suggest to control number of CA in the ClientHello message. It could be done with additional system property. Default value should allow to send ClientHello message in a single record. Application can enlarge it if the server supports ClientHello in several TLS records.
>>
>> Thank you
>> Alexey
>>
>>> On 13 May 2020, at 13:00, Alexey Bakhtin <alexey at azul.com> wrote:
>>>
>>> Hello Xuelei,
>>>
>>> I’m not a reviewer but I have some comment which could be helpful for your implementation.
>>> We’ve developed CA Extension in the OpenJSSE provider [1] and found an issue with a third party server implementations.
>>> According to RFC-8446 specification [2] the maximum size of the CA extension is 2^16 bytes. The maximum TLS record size is 2^14 bytes. In case of handshake message is bigger then maximum TLS record size, it should be splitted into several records. In fact, some server implementations does not allow ClientHello message bigger than the Maximum TLS record size and aborts connection immediately with “illegal_parameter” fatal alert.
>>> This issue can be easily reproduced on the client side:
>>> 1) put additional certificates into cacerts file, about 200 certs in total,
>>> 2) enable certificate_authorities extension in the ClientHello message
>>> 3) connect to https://www.google.com
>>>
>>> [1] - https://github.com/openjsse/openjsse/blob/master/src/main/java/org/openjsse/sun/security/ssl/CertificateAuthorityExtension.java
>>> [2] - https://tools.ietf.org/html/rfc8446#page-45
>>>
>>> Thank you
>>> Alexey
>>
>