
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Daniel,<div class=""><br class=""></div><div class="">Would you mind file a bug for the tracking?</div><div class=""><br class=""></div><div class="">Xuelei<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 31, 2020, at 5:45 AM, Daniel Jeliński <<a href="mailto:djelinski1@gmail.com" class="">djelinski1@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Verified that this behavior is still observed with JDK 16 EA 22.<div class=""><br class=""></div><div class="">Client side code responsible for server certificate validation is located in EndEntityChecker.checkTLSServer [1]. That code is not executed when the certificate is trusted [2]. I believe this is a bug - I wouldn't choose to accept a server certificate when that certificate was only meant for signing other certificates, for example.</div><div class=""><br class=""></div><div class="">Server side code responsible for cipher selection may need some refactoring; currently the server selects the first cipher that passes validation checks and for which keyManager.chooseServerAlias(keyType,...) returns a key. The key manager does not have information about the intended key usage (keyType is "EC" for both ECDH and ECDSA, and we don't know which cipher is being checked), so it returns the same certificate when querying for ECDH and ECDSA.</div><div class=""><br class=""></div><div class="">Fortunately ECDH is not popular, and most clients won't even try to negotiate it. Still, I believe this is a bug that should be addressed. </div><div class=""><br class=""></div><div class="">As far as I could tell, there were no bugs reported for this in the bug system. Should I report them there?</div><div class=""><br class=""></div><div class="">If someone is interested in the server code, here's the interesting portion of stack trace:</div><div class=""><pre class=""><pre class="">chooseServerAlias:260, SunX509KeyManagerImpl (sun.security.ssl)

createServerPossession:288, X509Authentication$X509PossessionGenerator (sun.security.ssl)

createPossession:214, X509Authentication$X509PossessionGenerator (sun.security.ssl)

createPossession:90, X509Authentication (sun.security.ssl)

createPossessions:51, SSLKeyExchange (sun.security.ssl)

chooseCipherSuite:443, ServerHello$T12ServerHelloProducer (sun.security.ssl)

</pre></pre></div><div class=""><br class=""></div><div class="">[1] <a href="http://hg.openjdk.java.net/jdk/jdk/file/ee1d592a9f53/src/java.base/share/classes/sun/security/validator/EndEntityChecker.java#l276" class="">http://hg.openjdk.java.net/jdk/jdk/file/ee1d592a9f53/src/java.base/share/classes/sun/security/validator/EndEntityChecker.java#l276</a><br class=""></div><div class="">[2] <a href="http://hg.openjdk.java.net/jdk/jdk/file/ee1d592a9f53/src/java.base/share/classes/sun/security/validator/Validator.java#l267" class="">http://hg.openjdk.java.net/jdk/jdk/file/ee1d592a9f53/src/java.base/share/classes/sun/security/validator/Validator.java#l267</a></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">wt., 27 paź 2020 o 18:44 Daniel Jeliński <<a href="mailto:djelinski1@gmail.com" class="">djelinski1@gmail.com</a>> napisał(a):<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">TL;DR: both SSL server and client ignore KeyUsage certificate extension when determining the list of available cipher suites. They shouldn't; KeyUsage is the only differentiator between ECDH and ECDSA certificates.</div><div class=""><br class=""></div><div class="">Long version:<br class=""><div class="">I'm experimenting with ECC certificates on my Jetty server; when I created an ECC certificate and tested the server with nmap, I found that both ECDSA and ECDH cipher suites are enabled. I don't want ECDH ciphers, but I don't want to add explicit excludes either.</div></div><div class=""><br class=""></div><div class="">Reading into NIST recommendations [1] I found that ECDSA certificates should define KeyUsage extension with value digitalSignature, vs ECDH which should use keyAgreement value.</div><div class="">I experimented with both combinations of KeyValue, both resulted in the same set of ciphers being offered by the server. The client doesn't seem to care about KeyUsage either - it accepts connections even when the selected cipher doesn't match KeyUsage.</div><div class=""><br class=""></div><div class="">Chrome browser doesn't support ECDH ciphers, but it does support ECDSA. When connecting to a Java server using ECDH certificate, it displays the error "<span style="color:rgb(95,99,104);font-family:"Segoe UI",Tahoma,sans-serif;font-size:12px;text-transform:uppercase" class="">ERR_SSL_KEY_USAGE_INCOMPATIBLE</span>"; the server offers an ECDSA cipher suite, which is rejected by the browser.</div><div class=""><br class=""></div><div class="">The issue was already reported by Bernd Eckenfels here [2], but as far as I can tell, it is not addressed yet; I was able to reproduce it using slightly modified code of this gist [3]. Certificates were generated using keytool commands:</div><div class=""><br class=""></div><div class="">ECDSA:<br class="">keytool -genkeypair -alias ec -keyalg EC -keysize 256 -sigalg SHA256withECDSA -validity 365 -dname "CN=localhost,OU=Unknown,O=Unknown,L=Unknown,S=Unknown,C=Unknown" -storetype JKS -keystore ectest.jks -storepass 123456 -ext KeyUsage:c=digitalSignature,keyCertSign<br class=""><br class=""></div><div class="">ECDH:<br class="">keytool -genkeypair -alias ec -keyalg EC -keysize 256 -sigalg SHA256withECDSA -validity 365 -dname "CN=localhost,OU=Unknown,O=Unknown,L=Unknown,S=Unknown,C=Unknown" -storetype JKS -keystore ectest.jks -storepass 123456 -ext KeyUsage:c=keyAgreement,keyCertSign<br class=""></div><div class=""><br class=""></div><div class="">I'm not sure if keyCertSign is required on self-signed certificates, added it just in case.</div><div class=""><br class=""></div><div class="">Tested on OpenJDK 11.0.6.</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Daniel Jeliński</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">[1] <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf" target="_blank" class="">https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf</a></div><div class="">[2] <a href="http://mail.openjdk.java.net/pipermail/security-dev/2017-May/015902.html" target="_blank" class="">http://mail.openjdk.java.net/pipermail/security-dev/2017-May/015902.html</a></div><div class="">[3] <a href="https://gist.github.com/djelinski/b4543a3eb7ea66306044c08b41bba00f" target="_blank" class="">https://gist.github.com/djelinski/b4543a3eb7ea66306044c08b41bba00f</a></div></div>

</blockquote></div>

</div></blockquote></div><br class=""></div></body></html>