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 <ale...@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 <ale...@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
