From barath.pg67 at gmail.com Mon Feb 3 05:48:17 2020 From: barath.pg67 at gmail.com (BHARATH P G) Date: Mon, 3 Feb 2020 11:18:17 +0530 Subject: Socket read timeout resulting in fatal tls alert in jdk 11 Message-ID: Hi, We are hitting following issue with openjdk11. Issue description: If there is socket read timeout exception, jdk11 is sending tls fatal alert causing client to close the socket connection. This was not the behavior with jdk8. Below is the ssl debug logs with jdk11(complete log is available in the attachment): javax.net.ssl|ERROR|01|main|2020-01-31 11:59:34.843 IST|TransportContext.java:312|Fatal (UNEXPECTED_MESSAGE): Read timed out ( "throwable" : { java.net.SocketTimeoutException: Read timed out at java.base/java.net.SocketInputStream.socketRead0(Native Method) at java.base/java.net.SocketInputStream.socketRead(SocketInputStream.java:115) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:168) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140) at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448) at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:799) at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) at java.base/java.io.InputStreamReader.read(InputStreamReader.java:185) at java.base/java.io.BufferedReader.fill(BufferedReader.java:161) at java.base/java.io.BufferedReader.readLine(BufferedReader.java:326) at java.base/java.io.BufferedReader.readLine(BufferedReader.java:392) at SimpleClient.startClient(SimpleClient.java:29) at SimpleClient.main(SimpleClient.java:36)} ) javax.net.ssl|DEBUG|01|main|2020-01-31 11:59:34.846 IST|SSLSocketOutputRecord.java:71|WRITE: TLS12 alert(unexpected_message), length = 2 For reference I have attached sample client and server to repro the issue and also ssl debug in the attachment. Thanks, Bharath -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- C:\jdk-11.0.6\bin\reproSSlIssue\reproSSlIssue>C:\jdk-11.0.6\bin\java.exe -Djavax.net.debug=ALL SimpleClient javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:11.982 IST|SSLContextImpl.java:427|System property jdk.tls.client.cipherSuites is set to 'null' javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.001 IST|SSLContextImpl.java:427|System property jdk.tls.server.cipherSuites is set to 'null' javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.040 IST|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.059 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.059 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.060 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.060 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.061 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.061 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.061 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.062 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.062 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.062 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.063 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.063 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.063 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.063 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.064 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_256_GCM_SHA384 javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.064 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_256_GCM_SHA384 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.065 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_128_GCM_SHA256 javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.065 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_128_GCM_SHA256 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.065 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA256 javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.066 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA256 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.066 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.067 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.068 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.068 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.068 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA256 javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.068 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA256 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.068 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_AES_128_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.073 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_AES_128_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.073 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.074 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.074 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.074 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.074 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.075 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.075 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.075 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.077 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.078 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.078 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.079 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.080 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.080 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.081 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.081 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.086 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_MD5 javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.093 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_MD5 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.095 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.097 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.098 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.105 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.109 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_DES_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.110 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_DES_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.118 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_DES_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.119 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_DES_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.121 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_DES_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.129 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_DES_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.131 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_WITH_DES_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.131 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_WITH_DES_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.138 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.141 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.142 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.149 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.150 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.153 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.154 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.162 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.163 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.164 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.171 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.172 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.176 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_RSA_WITH_NULL_SHA256 javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.182 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_RSA_WITH_NULL_SHA256 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.183 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.183 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.186 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.187 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.195 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.197 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.204 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.208 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.210 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.215 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.217 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.219 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.220 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_NULL_MD5 javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.228 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_NULL_MD5 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.234 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.235 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.238 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.238 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.239 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.240 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.249 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.250 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.251 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.252 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.255 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.262 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.264 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.265 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.277 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.278 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.279 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.286 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.289 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.296 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.297 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.300 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.300 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.309 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.311 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.311 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.318 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.319 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.324 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.328 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.331 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.331 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.339 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.342 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.343 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.349 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.350 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.353 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.361 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.364 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.370 IST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.371 IST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.376 IST|TrustStoreManager.java:112|trustStore is: clientTrustStore.key trustStore type is: pkcs12 trustStore provider is: the last modified time is: Fri Jan 31 15:18:42 IST 2020 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.377 IST|TrustStoreManager.java:311|Reload the trust store javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.400 IST|TrustStoreManager.java:318|Reload trust certs javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.401 IST|TrustStoreManager.java:323|Reloaded 1 trust certs javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.409 IST|X509TrustManagerImpl.java:79|adding as trusted certificates ( "certificate" : { "version" : "v3", "serial number" : "23 54 3E 06", "signature algorithm": "SHA256withDSA", "issuer" : "CN=localhost, OU=localhost, O=localhost, L=localhost, ST=localhost, C=in", "not before" : "2020-01-31 24:22:29.000 IST", "not after" : "2020-04-30 24:22:29.000 IST", "subject" : "CN=localhost, OU=localhost, O=localhost, L=localhost, ST=localhost, C=in", "subject public key" : "DSA", "extensions" : [ { ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 01 7D 37 9D AD 53 AB 56 D6 AA A2 9D C7 A9 96 72 ..7..S.V.......r 0010: AF 50 40 FE .P at . ] ] } ]} ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.411 IST|SSLContextImpl.java:1087|keyStore is : javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.417 IST|SSLContextImpl.java:1088|keyStore type is : pkcs12 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.418 IST|SSLContextImpl.java:1090|keyStore provider is : javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.418 IST|SSLContextImpl.java:1125|init keystore javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.420 IST|SSLContextImpl.java:1148|init keymanager of type SunX509 javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.422 IST|SSLContextImpl.java:115|trigger seeding of SecureRandom javax.net.ssl|ALL|01|main|2020-01-31 15:28:12.942 IST|SSLContextImpl.java:119|done seeding of SecureRandom javax.net.ssl|WARNING|01|main|2020-01-31 15:28:12.987 IST|ServerNameExtension.java:261|Unable to indicate server name javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.988 IST|SSLExtensions.java:256|Ignore, context unavailable extension: server_name javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.990 IST|SupportedGroupsExtension.java:840|Ignore inactive or disabled named group: secp256r1 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.991 IST|SupportedGroupsExtension.java:840|Ignore inactive or disabled named group: secp384r1 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.997 IST|SupportedGroupsExtension.java:840|Ignore inactive or disabled named group: secp521r1 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:12.998 IST|ECPointFormatsExtension.java:195|Need no ec_point_formats extension javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.000 IST|SSLExtensions.java:256|Ignore, context unavailable extension: ec_point_formats javax.net.ssl|WARNING|01|main|2020-01-31 15:28:13.014 IST|SignatureScheme.java:294|Signature algorithm, ed25519, is not supported by the underlying providers javax.net.ssl|WARNING|01|main|2020-01-31 15:28:13.015 IST|SignatureScheme.java:294|Signature algorithm, ed448, is not supported by the underlying providers javax.net.ssl|ALL|01|main|2020-01-31 15:28:13.019 IST|SignatureScheme.java:371|Ignore disabled signature scheme: rsa_md5 javax.net.ssl|INFO|01|main|2020-01-31 15:28:13.023 IST|AlpnExtension.java:161|No available application protocols javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.024 IST|SSLExtensions.java:256|Ignore, context unavailable extension: application_layer_protocol_negotiation javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.034 IST|ClientHello.java:651|Produced ClientHello handshake message ( "ClientHello": { "client version" : "TLSv1.2", "random" : "05 BE BD A2 A3 18 C7 F1 7A D1 C6 08 44 95 A8 BA DA 7C DD 97 D6 FD 3D D3 23 F5 C7 02 2E 00 A9 A6", "session id" : "", "cipher suites" : "[TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A)]", "compression methods" : "00", "extensions" : [ "status_request (5)": { "certificate status type": ocsp "OCSP status request": { "responder_id": "request extensions": { } } }, "supported_groups (10)": { "versions": [ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] }, "signature_algorithms (13)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] }, "signature_algorithms_cert (50)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] }, "status_request_v2 (17)": { "cert status request": { "certificate status type": ocsp_multi "OCSP status request": { "responder_id": "request extensions": { } } } }, "extended_master_secret (23)": { }, "supported_versions (43)": { "versions": [TLSv1.2] }, "renegotiation_info (65,281)": { "renegotiated connection": [] } ] } ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.035 IST|SSLSocketOutputRecord.java:241|WRITE: TLS12 handshake, length = 177 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.043 IST|SSLSocketOutputRecord.java:255|Raw write ( 0000: 16 03 03 00 B1 01 00 00 AD 03 03 05 BE BD A2 A3 ................ 0010: 18 C7 F1 7A D1 C6 08 44 95 A8 BA DA 7C DD 97 D6 ...z...D........ 0020: FD 3D D3 23 F5 C7 02 2E 00 A9 A6 00 00 02 00 6A .=.#...........j 0030: 01 00 00 82 00 05 00 05 01 00 00 00 00 00 0A 00 ................ 0040: 0C 00 0A 01 00 01 01 01 02 01 03 01 04 00 0D 00 ................ 0050: 22 00 20 04 03 05 03 06 03 08 04 08 05 08 06 08 ". ............. 0060: 09 08 0A 08 0B 04 01 05 01 06 01 04 02 02 03 02 ................ 0070: 01 02 02 00 32 00 22 00 20 04 03 05 03 06 03 08 ....2.". ....... 0080: 04 08 05 08 06 08 09 08 0A 08 0B 04 01 05 01 06 ................ 0090: 01 04 02 02 03 02 01 02 02 00 11 00 09 00 07 02 ................ 00A0: 00 04 00 00 00 00 00 17 00 00 00 2B 00 03 02 03 ...........+.... 00B0: 03 FF 01 00 01 00 ...... ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.053 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 16 03 03 00 55 ....U ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.056 IST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 85 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.058 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 02 00 00 51 03 03 A7 FB 54 69 53 5A 7D 5E FE 0D ...Q....TiSZ.^.. 0010: 2D BE 15 75 32 31 EB 00 33 EF 14 77 AE 98 AE B7 -..u21..3..w.... 0020: 26 9E F8 5F 2C AA 20 E9 15 23 DE 1A 22 C0 4A 31 &.._,. ..#..".J1 0030: 69 2B DC 6D 59 5C 94 56 54 FE 8E 01 BC 55 71 3C i+.mY\.VT....Uq< 0040: 18 E7 3E 95 66 A8 BA 00 6A 00 00 09 00 17 00 00 ..>.f...j....... 0050: FF 01 00 01 00 ..... ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.058 IST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 85 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.065 IST|ServerHello.java:884|Consuming ServerHello handshake message ( "ServerHello": { "server version" : "TLSv1.2", "random" : "A7 FB 54 69 53 5A 7D 5E FE 0D 2D BE 15 75 32 31 EB 00 33 EF 14 77 AE 98 AE B7 26 9E F8 5F 2C AA", "session id" : "E9 15 23 DE 1A 22 C0 4A 31 69 2B DC 6D 59 5C 94 56 54 FE 8E 01 BC 55 71 3C 18 E7 3E 95 66 A8 BA", "cipher suite" : "TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A)", "compression methods" : "00", "extensions" : [ "extended_master_secret (23)": { }, "renegotiation_info (65,281)": { "renegotiated connection": [] } ] } ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.065 IST|SSLExtensions.java:169|Ignore unavailable extension: supported_versions javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.067 IST|ServerHello.java:980|Negotiated protocol version: TLSv1.2 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.068 IST|SSLExtensions.java:188|Consumed extension: renegotiation_info javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.068 IST|SSLExtensions.java:169|Ignore unavailable extension: server_name javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.069 IST|SSLExtensions.java:169|Ignore unavailable extension: max_fragment_length javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.070 IST|SSLExtensions.java:169|Ignore unavailable extension: status_request javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.070 IST|SSLExtensions.java:169|Ignore unavailable extension: ec_point_formats javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.071 IST|SSLExtensions.java:169|Ignore unavailable extension: status_request_v2 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.073 IST|SSLExtensions.java:188|Consumed extension: extended_master_secret javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.077 IST|SSLExtensions.java:188|Consumed extension: renegotiation_info javax.net.ssl|ALL|01|main|2020-01-31 15:28:13.078 IST|SSLSessionImpl.java:216|Session initialized: Session(1580464693078|TLS_DHE_DSS_WITH_AES_256_CBC_SHA256) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.080 IST|SSLExtensions.java:203|Ignore unavailable extension: server_name javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.080 IST|SSLExtensions.java:203|Ignore unavailable extension: max_fragment_length javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.081 IST|SSLExtensions.java:203|Ignore unavailable extension: status_request javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.081 IST|SSLExtensions.java:203|Ignore unavailable extension: ec_point_formats javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.082 IST|SSLExtensions.java:203|Ignore unavailable extension: application_layer_protocol_negotiation javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.084 IST|SSLExtensions.java:203|Ignore unavailable extension: status_request_v2 javax.net.ssl|WARNING|01|main|2020-01-31 15:28:13.084 IST|SSLExtensions.java:211|Ignore impact of unsupported extension: extended_master_secret javax.net.ssl|WARNING|01|main|2020-01-31 15:28:13.085 IST|SSLExtensions.java:211|Ignore impact of unsupported extension: renegotiation_info javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.088 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 16 03 03 04 EB ..... ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.093 IST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 1259 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.098 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 0B 00 04 E7 00 04 E4 00 04 E1 30 82 04 DD 30 82 ..........0...0. 0010: 04 89 A0 03 02 01 02 02 04 23 54 3E 06 30 0D 06 .........#T>.0.. 0020: 09 60 86 48 01 65 03 04 03 02 05 00 30 71 31 0B .`.H.e......0q1. 0030: 30 09 06 03 55 04 06 13 02 69 6E 31 12 30 10 06 0...U....in1.0.. 0040: 03 55 04 08 13 09 6C 6F 63 61 6C 68 6F 73 74 31 .U....localhost1 0050: 12 30 10 06 03 55 04 07 13 09 6C 6F 63 61 6C 68 .0...U....localh 0060: 6F 73 74 31 12 30 10 06 03 55 04 0A 13 09 6C 6F ost1.0...U....lo 0070: 63 61 6C 68 6F 73 74 31 12 30 10 06 03 55 04 0B calhost1.0...U.. 0080: 13 09 6C 6F 63 61 6C 68 6F 73 74 31 12 30 10 06 ..localhost1.0.. 0090: 03 55 04 03 13 09 6C 6F 63 61 6C 68 6F 73 74 30 .U....localhost0 00A0: 1E 17 0D 32 30 30 31 33 30 31 38 35 32 32 39 5A ...200130185229Z 00B0: 17 0D 32 30 30 34 32 39 31 38 35 32 32 39 5A 30 ..200429185229Z0 00C0: 71 31 0B 30 09 06 03 55 04 06 13 02 69 6E 31 12 q1.0...U....in1. 00D0: 30 10 06 03 55 04 08 13 09 6C 6F 63 61 6C 68 6F 0...U....localho 00E0: 73 74 31 12 30 10 06 03 55 04 07 13 09 6C 6F 63 st1.0...U....loc 00F0: 61 6C 68 6F 73 74 31 12 30 10 06 03 55 04 0A 13 alhost1.0...U... 0100: 09 6C 6F 63 61 6C 68 6F 73 74 31 12 30 10 06 03 .localhost1.0... 0110: 55 04 0B 13 09 6C 6F 63 61 6C 68 6F 73 74 31 12 U....localhost1. 0120: 30 10 06 03 55 04 03 13 09 6C 6F 63 61 6C 68 6F 0...U....localho 0130: 73 74 30 82 03 42 30 82 02 35 06 07 2A 86 48 CE st0..B0..5..*.H. 0140: 38 04 01 30 82 02 28 02 82 01 01 00 8F 79 35 D9 8..0..(......y5. 0150: B9 AA E9 BF AB ED 88 7A CF 49 51 B6 F3 2E C5 9E .......z.IQ..... 0160: 3B AF 37 18 E8 EA C4 96 1F 3E FD 36 06 E7 43 51 ;.7......>.6..CQ 0170: A9 C4 18 33 39 B8 09 E7 C2 AE 1C 53 9B A7 47 5B ...39......S..G[ 0180: 85 D0 11 AD B8 B4 79 87 75 49 84 69 5C AC 0E 8F ......y.uI.i\... 0190: 14 B3 36 08 28 A2 2F FA 27 11 0A 3D 62 A9 93 45 ..6.(./.'..=b..E 01A0: 34 09 A0 FE 69 6C 46 58 F8 4B DD 20 81 9C 37 09 4...ilFX.K. ..7. 01B0: A0 10 57 B1 95 AD CD 00 23 3D BA 54 84 B6 29 1F ..W.....#=.T..). 01C0: 9D 64 8E F8 83 44 86 77 97 9C EC 04 B4 34 A6 AC .d...D.w.....4.. 01D0: 2E 75 E9 98 5D E2 3D B0 29 2F C1 11 8C 9F FA 9D .u..].=.)/...... 01E0: 81 81 E7 33 8D B7 92 B7 30 D7 B9 E3 49 59 2F 68 ...3....0...IY/h 01F0: 09 98 72 15 39 15 EA 3D 6B 8B 46 53 C6 33 45 8F ..r.9..=k.FS.3E. 0200: 80 3B 32 A4 C2 E0 F2 72 90 25 6E 4E 3F 8A 3B 08 .;2....r.%nN?.;. 0210: 38 A1 C4 50 E4 E1 8C 1A 29 A3 7D DF 5E A1 43 DE 8..P....)...^.C. 0220: 4B 66 FF 04 90 3E D5 CF 16 23 E1 58 D4 87 C6 08 Kf...>...#.X.... 0230: E9 7F 21 1C D8 1D CA 23 CB 6E 38 07 65 F8 22 E3 ..!....#.n8.e.". 0240: 42 BE 48 4C 05 76 39 39 60 1C D6 67 02 1D 00 BA B.HL.v99`..g.... 0250: F6 96 A6 85 78 F7 DF DE E7 FA 67 C9 77 C7 85 EF ....x.....g.w... 0260: 32 B2 33 BA E5 80 C0 BC D5 69 5D 02 82 01 00 16 2.3......i]..... 0270: A6 5C 58 20 48 50 70 4E 75 02 A3 97 57 04 0D 34 .\X HPpNu...W..4 0280: DA 3A 34 78 C1 54 D4 E4 A5 C0 2D 24 2E E0 4F 96 .:4x.T....-$..O. 0290: E6 1E 4B D0 90 4A BD AC 8F 37 EE B1 E0 9F 31 82 ..K..J...7....1. 02A0: D2 3C 90 43 CB 64 2F 88 00 41 60 ED F9 CA 09 B3 .<.C.d/..A`..... 02B0: 20 76 A7 9C 32 A6 27 F2 47 3E 91 87 9B A2 C4 E7 v..2.'.G>...... 02C0: 44 BD 20 81 54 4C B5 5B 80 2C 36 8D 1F A8 3E D4 D. .TL.[.,6...>. 02D0: 89 E9 4E 0F A0 68 8E 32 42 8A 5C 78 C4 78 C6 8D ..N..h.2B.\x.x.. 02E0: 05 27 B7 1C 9A 3A BB 0B 0B E1 2C 44 68 96 39 E7 .'...:....,Dh.9. 02F0: D3 CE 74 DB 10 1A 65 AA 2B 87 F6 4C 68 26 DB 3E ..t...e.+..Lh&.> 0300: C7 2F 4B 55 99 83 4B B4 ED B0 2F 7C 90 E9 A4 96 ./KU..K.../..... 0310: D3 A5 5D 53 5B EB FC 45 D4 F6 19 F6 3F 3D ED BB ..]S[..E....?=.. 0320: 87 39 25 C2 F2 24 E0 77 31 29 6D A8 87 EC 1E 47 .9%..$.w1)m....G 0330: 48 F8 7E FB 5F DE B7 54 84 31 6B 22 32 DE E5 53 H..._..T.1k"2..S 0340: DD AF 02 11 2B 0D 1F 02 DA 30 97 32 24 FE 27 AE ....+....0.2$.'. 0350: DA 8B 9D 4B 29 22 D9 BA 8B E3 9E D9 E1 03 A6 3C ...K)".........< 0360: 52 81 0B C6 88 B7 E2 ED 43 16 E1 EF 17 DB DE 03 R.......C....... 0370: 82 01 05 00 02 82 01 00 55 CB D5 CA 16 6F FC DB ........U....o.. 0380: 84 1F DB AA A2 F2 21 DA F4 E1 05 B3 41 90 9A 15 ......!.....A... 0390: 0E EC 76 4C E5 77 D2 6E EF 4D D5 63 84 91 87 56 ..vL.w.n.M.c...V 03A0: 2D 44 3F E7 1B B0 62 0A F0 92 27 24 5D 9F D1 21 -D?...b...'$]..! 03B0: DF A8 6D BD BD AD 56 60 B1 29 3C 29 B3 17 8D 79 ..m...V`.)<)...y 03C0: 27 DC 58 CF F9 C4 1C 62 50 98 0E 16 06 03 B3 B2 '.X....bP....... 03D0: AC 26 0C 2F 08 B1 A0 BE 8E 1B 8B 72 EF DF 47 F7 .&./.......r..G. 03E0: 8A F6 03 E8 99 94 1F 63 A4 F5 22 C3 00 91 C8 69 .......c.."....i 03F0: 52 37 29 99 A0 FE D4 77 AE 1E C3 C6 C6 7B 5B 3B R7)....w......[; ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.101 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 6E 42 0F 35 0A 67 4F E6 7F 39 74 1B 7B F5 76 03 nB.5.gO..9t...v. 0010: A5 2C 5C 2F 1B 34 2A E8 A7 73 D7 D2 C9 3E DB 6C .,\/.4*..s...>.l 0020: AB 03 CD 28 DB 11 2C 13 40 D1 AD 1D AB D2 0B 38 ...(..,. at ......8 0030: 44 8E BA 54 C6 64 88 E9 9F 90 91 B8 1C FF DE 4D D..T.d.........M 0040: 33 55 0C A6 4F B4 B3 8B 0B 75 FF 06 D5 B2 9A 3C 3U..O....u.....< 0050: 9B A6 84 C7 63 BF AA 46 B4 21 61 9D 80 D9 C9 F1 ....c..F.!a..... 0060: CA E0 13 E9 51 4F F1 55 FE FF 9B 0D 78 D0 D6 A8 ....QO.U....x... 0070: C2 A1 42 35 10 96 5C 64 A3 21 30 1F 30 1D 06 03 ..B5..\d.!0.0... 0080: 55 1D 0E 04 16 04 14 01 7D 37 9D AD 53 AB 56 D6 U........7..S.V. 0090: AA A2 9D C7 A9 96 72 AF 50 40 FE 30 0D 06 09 60 ......r.P at .0...` 00A0: 86 48 01 65 03 04 03 02 05 00 03 3F 00 30 3C 02 .H.e.......?.0<. 00B0: 1C 01 E7 2D 06 24 55 19 30 40 BD A4 5B 6D 1C DE ...-.$U.0 at ..[m.. 00C0: 7B E4 91 CF A8 FF A9 28 E4 1B EF 3B 9A 02 1C 56 .......(...;...V 00D0: A2 6D 76 69 89 8E 0B 9E 75 E3 E9 25 AC 33 5C 34 .mvi....u..%.3\4 00E0: AA 75 1C 9A F9 56 74 98 12 D9 D4 .u...Vt.... ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.109 IST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 1259 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.110 IST|CertificateMessage.java:358|Consuming server Certificate handshake message ( "Certificates": [ "certificate" : { "version" : "v3", "serial number" : "23 54 3E 06", "signature algorithm": "SHA256withDSA", "issuer" : "CN=localhost, OU=localhost, O=localhost, L=localhost, ST=localhost, C=in", "not before" : "2020-01-31 24:22:29.000 IST", "not after" : "2020-04-30 24:22:29.000 IST", "subject" : "CN=localhost, OU=localhost, O=localhost, L=localhost, ST=localhost, C=in", "subject public key" : "DSA", "extensions" : [ { ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 01 7D 37 9D AD 53 AB 56 D6 AA A2 9D C7 A9 96 72 ..7..S.V.......r 0010: AF 50 40 FE .P at . ] ] } ]} ] ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.194 IST|X509TrustManagerImpl.java:238|Found trusted certificate ( "certificate" : { "version" : "v3", "serial number" : "23 54 3E 06", "signature algorithm": "SHA256withDSA", "issuer" : "CN=localhost, OU=localhost, O=localhost, L=localhost, ST=localhost, C=in", "not before" : "2020-01-31 24:22:29.000 IST", "not after" : "2020-04-30 24:22:29.000 IST", "subject" : "CN=localhost, OU=localhost, O=localhost, L=localhost, ST=localhost, C=in", "subject public key" : "DSA", "extensions" : [ { ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 01 7D 37 9D AD 53 AB 56 D6 AA A2 9D C7 A9 96 72 ..7..S.V.......r 0010: AF 50 40 FE .P at . ] ] } ]} ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.195 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 16 03 03 02 4F ....O ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.198 IST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 591 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.202 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 0C 00 02 4B 01 00 FF FF FF FF FF FF FF FF AD F8 ...K............ 0010: 54 58 A2 BB 4A 9A AF DC 56 20 27 3D 3C F1 D8 B9 TX..J...V '=<... 0020: C5 83 CE 2D 36 95 A9 E1 36 41 14 64 33 FB CC 93 ...-6...6A.d3... 0030: 9D CE 24 9B 3E F9 7D 2F E3 63 63 0C 75 D8 F6 81 ..$.>../.cc.u... 0040: B2 02 AE C4 61 7A D3 DF 1E D5 D5 FD 65 61 24 33 ....az......ea$3 0050: F5 1F 5F 06 6E D0 85 63 65 55 3D ED 1A F3 B5 57 .._.n..ceU=....W 0060: 13 5E 7F 57 C9 35 98 4F 0C 70 E0 E6 8B 77 E2 A6 .^.W.5.O.p...w.. 0070: 89 DA F3 EF E8 72 1D F1 58 A1 36 AD E7 35 30 AC .....r..X.6..50. 0080: CA 4F 48 3A 79 7A BC 0A B1 82 B3 24 FB 61 D1 08 .OH:yz.....$.a.. 0090: A9 4B B2 C8 E3 FB B9 6A DA B7 60 D7 F4 68 1D 4F .K.....j..`..h.O 00A0: 42 A3 DE 39 4D F4 AE 56 ED E7 63 72 BB 19 0B 07 B..9M..V..cr.... 00B0: A7 C8 EE 0A 6D 70 9E 02 FC E1 CD F7 E2 EC C0 34 ....mp.........4 00C0: 04 CD 28 34 2F 61 91 72 FE 9C E9 85 83 FF 8E 4F ..(4/a.r.......O 00D0: 12 32 EE F2 81 83 C3 FE 3B 1B 4C 6F AD 73 3B B5 .2......;.Lo.s;. 00E0: FC BC 2E C2 20 05 C5 8E F1 83 7D 16 83 B2 C6 F3 .... ........... 00F0: 4A 26 C1 B2 EF FA 88 6B 42 38 61 28 5C 97 FF FF J&.....kB8a(\... 0100: FF FF FF FF FF FF 00 01 02 01 00 01 56 AB 76 1C ............V.v. 0110: 0C AB 63 A0 18 83 71 BF 10 52 F2 74 18 1C 3C FC ..c...q..R.t..<. 0120: 93 68 F3 20 98 78 3F D8 79 B0 D2 2E 4B 57 33 84 .h. .x?.y...KW3. 0130: 76 05 19 47 EC BE 51 82 EC 37 12 96 D5 72 23 2B v..G..Q..7...r#+ 0140: EE D7 66 BF 9B BD 1F B5 27 E8 D5 63 B7 84 15 3B ..f.....'..c...; 0150: C8 B6 93 D9 A0 52 44 37 91 2C 46 5D 31 47 5A B3 .....RD7.,F]1GZ. 0160: C2 4A 90 B2 52 1D 13 E8 EA 9A 2F 5B E8 41 C2 2C .J..R...../[.A., 0170: D0 88 77 4D 81 75 1D 03 7E 7A 04 C1 F7 57 61 E0 ..wM.u...z...Wa. 0180: 31 39 76 DC 1C 3D F4 3E 16 88 EB B4 D2 21 45 64 19v..=.>.....!Ed 0190: 87 74 50 3D 67 27 78 C4 0C 5D CD 33 8B 48 78 06 .tP=g'x..].3.Hx. 01A0: 21 84 47 62 ED 59 DD 40 F9 CC 42 DF 14 97 4B 7A !.Gb.Y. at ..B...Kz 01B0: B1 4B B1 4E 0F B5 63 51 F0 0D 01 8D AC DA 4A 97 .K.N..cQ......J. 01C0: 17 02 1A 7F 95 C4 65 5C 65 B7 17 D4 EC EB 99 6E ......e\e......n 01D0: 3C 45 B2 1C 14 85 4F 89 14 06 18 DB 56 3C 36 5C .....?....Q.... 0220: B9 AC C9 03 39 A8 4D E5 4D 80 13 35 6D 84 49 C1 ....9.M.M..5m.I. 0230: 02 1D 00 97 13 E9 EF 20 D4 6F EC DB 15 BC AF 67 ....... .o.....g 0240: 16 9A 6B 67 EE 61 40 60 85 B9 8F 05 53 F3 A2 ..kg.a@`....S.. ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.206 IST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 591 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.240 IST|DHServerKeyExchange.java:521|Consuming DH ServerKeyExchange handshake message ( "DH ServerKeyExchange": { "parameters": { "dh_p": { 0000: FF FF FF FF FF FF FF FF AD F8 54 58 A2 BB 4A 9A ..........TX..J. 0010: AF DC 56 20 27 3D 3C F1 D8 B9 C5 83 CE 2D 36 95 ..V '=<......-6. 0020: A9 E1 36 41 14 64 33 FB CC 93 9D CE 24 9B 3E F9 ..6A.d3.....$.>. 0030: 7D 2F E3 63 63 0C 75 D8 F6 81 B2 02 AE C4 61 7A ./.cc.u.......az 0040: D3 DF 1E D5 D5 FD 65 61 24 33 F5 1F 5F 06 6E D0 ......ea$3.._.n. 0050: 85 63 65 55 3D ED 1A F3 B5 57 13 5E 7F 57 C9 35 .ceU=....W.^.W.5 0060: 98 4F 0C 70 E0 E6 8B 77 E2 A6 89 DA F3 EF E8 72 .O.p...w.......r 0070: 1D F1 58 A1 36 AD E7 35 30 AC CA 4F 48 3A 79 7A ..X.6..50..OH:yz 0080: BC 0A B1 82 B3 24 FB 61 D1 08 A9 4B B2 C8 E3 FB .....$.a...K.... 0090: B9 6A DA B7 60 D7 F4 68 1D 4F 42 A3 DE 39 4D F4 .j..`..h.OB..9M. 00A0: AE 56 ED E7 63 72 BB 19 0B 07 A7 C8 EE 0A 6D 70 .V..cr........mp 00B0: 9E 02 FC E1 CD F7 E2 EC C0 34 04 CD 28 34 2F 61 .........4..(4/a 00C0: 91 72 FE 9C E9 85 83 FF 8E 4F 12 32 EE F2 81 83 .r.......O.2.... 00D0: C3 FE 3B 1B 4C 6F AD 73 3B B5 FC BC 2E C2 20 05 ..;.Lo.s;..... . 00E0: C5 8E F1 83 7D 16 83 B2 C6 F3 4A 26 C1 B2 EF FA ..........J&.... 00F0: 88 6B 42 38 61 28 5C 97 FF FF FF FF FF FF FF FF .kB8a(\......... }, "dh_g": { 0000: 02 . }, "dh_Ys": { 0000: 01 56 AB 76 1C 0C AB 63 A0 18 83 71 BF 10 52 F2 .V.v...c...q..R. 0010: 74 18 1C 3C FC 93 68 F3 20 98 78 3F D8 79 B0 D2 t..<..h. .x?.y.. 0020: 2E 4B 57 33 84 76 05 19 47 EC BE 51 82 EC 37 12 .KW3.v..G..Q..7. 0030: 96 D5 72 23 2B EE D7 66 BF 9B BD 1F B5 27 E8 D5 ..r#+..f.....'.. 0040: 63 B7 84 15 3B C8 B6 93 D9 A0 52 44 37 91 2C 46 c...;.....RD7.,F 0050: 5D 31 47 5A B3 C2 4A 90 B2 52 1D 13 E8 EA 9A 2F ]1GZ..J..R...../ 0060: 5B E8 41 C2 2C D0 88 77 4D 81 75 1D 03 7E 7A 04 [.A.,..wM.u...z. 0070: C1 F7 57 61 E0 31 39 76 DC 1C 3D F4 3E 16 88 EB ..Wa.19v..=.>... 0080: B4 D2 21 45 64 87 74 50 3D 67 27 78 C4 0C 5D CD ..!Ed.tP=g'x..]. 0090: 33 8B 48 78 06 21 84 47 62 ED 59 DD 40 F9 CC 42 3.Hx.!.Gb.Y. at ..B 00A0: DF 14 97 4B 7A B1 4B B1 4E 0F B5 63 51 F0 0D 01 ...Kz.K.N..cQ... 00B0: 8D AC DA 4A 97 17 02 1A 7F 95 C4 65 5C 65 B7 17 ...J.......e\e.. 00C0: D4 EC EB 99 6E 3C 45 B2 1C 14 85 4F 89 14 06 18 ....n.....?....Q... 0010: 06 B9 AC C9 03 39 A8 4D E5 4D 80 13 35 6D 84 49 .....9.M.M..5m.I 0020: C1 02 1D 00 97 13 E9 EF 20 D4 6F EC DB 15 BC AF ........ .o..... 0030: 67 16 9A 6B 67 EE 61 40 60 85 B9 8F 05 53 F3 A2 g..kg.a@`....S.. }, } } ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.243 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 16 03 03 00 04 ..... ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.248 IST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 4 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.251 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 0E 00 00 00 .... ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.252 IST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 4 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.253 IST|ServerHelloDone.java:151|Consuming ServerHelloDone handshake message ( ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.281 IST|DHClientKeyExchange.java:191|Produced DH ClientKeyExchange handshake message ( "DH ClientKeyExchange": { "parameters": { "dh_Yc": { 0000: 64 02 62 CC 28 B2 B8 29 A3 0A 0A 45 67 01 95 FD d.b.(..)...Eg... 0010: 73 5D CC 24 F9 D0 E8 E4 86 FE F9 EA FB 2D C5 10 s].$.........-.. 0020: 35 9A FD F8 F8 66 C4 0F E6 D6 57 2E 0B 89 2D 25 5....f....W...-% 0030: D3 1D 64 5D A0 00 36 28 23 C5 6E 71 05 33 F0 A3 ..d]..6(#.nq.3.. 0040: 46 65 C9 AE 30 35 0D E2 ED 38 31 0D 63 41 CF 44 Fe..05...81.cA.D 0050: DD FE C4 98 F0 1D 2C 30 07 03 22 6B DB 16 72 42 ......,0.."k..rB 0060: FE 6C EA 54 72 63 8A 25 4D 64 C1 5E 4B 36 32 02 .l.Trc.%Md.^K62. 0070: EF FB 98 FF D4 2A 61 87 37 0C 66 79 B6 08 DC CA .....*a.7.fy.... 0080: 38 62 0A A2 A6 D6 24 9F CA F3 71 09 8C 05 AE 95 8b....$...q..... 0090: 44 8E 19 63 FF 9A 69 E8 5F 0C AE 20 D0 12 A4 F2 D..c..i._.. .... 00A0: 71 DE 19 45 46 F5 35 1B FF CF F9 8A 65 FB A6 F9 q..EF.5.....e... 00B0: 5F 2B 52 C4 F5 91 5F BC 18 24 53 5E 7B C9 23 C2 _+R..._..$S^..#. 00C0: 46 8F 34 5C EE 36 AE 54 94 BC 80 B7 FE 8F 0B 76 F.4\.6.T.......v 00D0: 6E 3B 6F 8A A0 B8 F3 1D 83 E9 80 A2 8D 43 41 9D n;o..........CA. 00E0: DB E7 5C BD F3 E3 EE 78 E0 84 F0 87 D4 81 62 EF ..\....x......b. 00F0: AE F5 0F CC 5A 49 97 F9 D3 FC 7F 1B A9 A3 19 39 ....ZI.........9 }, } } ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.281 IST|SSLSocketOutputRecord.java:241|WRITE: TLS12 handshake, length = 262 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.289 IST|SSLSocketOutputRecord.java:255|Raw write ( 0000: 16 03 03 01 06 10 00 01 02 01 00 64 02 62 CC 28 ...........d.b.( 0010: B2 B8 29 A3 0A 0A 45 67 01 95 FD 73 5D CC 24 F9 ..)...Eg...s].$. 0020: D0 E8 E4 86 FE F9 EA FB 2D C5 10 35 9A FD F8 F8 ........-..5.... 0030: 66 C4 0F E6 D6 57 2E 0B 89 2D 25 D3 1D 64 5D A0 f....W...-%..d]. 0040: 00 36 28 23 C5 6E 71 05 33 F0 A3 46 65 C9 AE 30 .6(#.nq.3..Fe..0 0050: 35 0D E2 ED 38 31 0D 63 41 CF 44 DD FE C4 98 F0 5...81.cA.D..... 0060: 1D 2C 30 07 03 22 6B DB 16 72 42 FE 6C EA 54 72 .,0.."k..rB.l.Tr 0070: 63 8A 25 4D 64 C1 5E 4B 36 32 02 EF FB 98 FF D4 c.%Md.^K62...... 0080: 2A 61 87 37 0C 66 79 B6 08 DC CA 38 62 0A A2 A6 *a.7.fy....8b... 0090: D6 24 9F CA F3 71 09 8C 05 AE 95 44 8E 19 63 FF .$...q.....D..c. 00A0: 9A 69 E8 5F 0C AE 20 D0 12 A4 F2 71 DE 19 45 46 .i._.. ....q..EF 00B0: F5 35 1B FF CF F9 8A 65 FB A6 F9 5F 2B 52 C4 F5 .5.....e..._+R.. 00C0: 91 5F BC 18 24 53 5E 7B C9 23 C2 46 8F 34 5C EE ._..$S^..#.F.4\. 00D0: 36 AE 54 94 BC 80 B7 FE 8F 0B 76 6E 3B 6F 8A A0 6.T.......vn;o.. 00E0: B8 F3 1D 83 E9 80 A2 8D 43 41 9D DB E7 5C BD F3 ........CA...\.. 00F0: E3 EE 78 E0 84 F0 87 D4 81 62 EF AE F5 0F CC 5A ..x......b.....Z 0100: 49 97 F9 D3 FC 7F 1B A9 A3 19 39 I.........9 ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.331 IST|ChangeCipherSpec.java:117|Produced ChangeCipherSpec message javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.345 IST|SSLSocketOutputRecord.java:225|Raw write ( 0000: 14 03 03 00 01 01 ...... ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.347 IST|Finished.java:399|Produced client Finished handshake message ( "Finished": { "verify data": { 0000: 71 2D 36 D8 A5 C6 88 08 1C 4E A1 33 }'} ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.347 IST|SSLSocketOutputRecord.java:241|WRITE: TLS12 handshake, length = 32 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.348 IST|SSLCipher.java:1467|Padded plaintext before ENCRYPTION ( 0000: 8E 1E F6 BE EA 50 7D 2A FA BC EF 42 C8 57 F5 50 .....P.*...B.W.P 0010: 14 00 00 0C 71 2D 36 D8 A5 C6 88 08 1C 4E A1 33 ....q-6......N.3 0020: 81 FF 17 88 7D B0 D8 51 A7 AD C3 92 A1 BC 5F 20 .......Q......_ 0030: 17 B9 51 CF E9 03 B2 A8 BC 2A 78 65 FA E4 6F 30 ..Q......*xe..o0 0040: 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F ................ ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.355 IST|SSLSocketOutputRecord.java:255|Raw write ( 0000: 16 03 03 00 50 9B D6 44 65 AE EA 87 DF 68 79 6F ....P..De....hyo 0010: 9A 8E AD 04 61 C0 84 2C EB 36 F0 56 50 0A 3A 65 ....a..,.6.VP.:e 0020: 8C 45 47 2B F8 A2 68 53 F3 55 B0 C9 34 BA B5 80 .EG+..hS.U..4... 0030: 3B FC 36 9F DD E9 BD 7E 13 A0 53 84 EB A7 36 D7 ;.6.......S...6. 0040: 39 E7 96 BB A6 EB E3 7D BA 10 4C CF 60 4D FD FD 9.........L.`M.. 0050: A2 3D 0C 76 15 .=.v. ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.359 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 14 03 03 00 01 ..... ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.360 IST|SSLSocketInputRecord.java:213|READ: TLSv1.2 change_cipher_spec, length = 1 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.360 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 01 . ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.361 IST|SSLSocketInputRecord.java:249|READ: TLSv1.2 change_cipher_spec, length = 1 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.361 IST|ChangeCipherSpec.java:151|Consuming ChangeCipherSpec message javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.363 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 16 03 03 00 50 ....P ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.364 IST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 80 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.364 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 47 DD CA F4 D2 50 EB E5 B2 77 29 73 33 8D F8 47 G....P...w)s3..G 0010: E4 E7 77 1F 84 B4 1C 7D 1F C3 11 94 BD A4 E8 D3 ..w............. 0020: 69 07 AC 57 B7 8F 44 73 77 CC 92 3B E2 05 3A 5D i..W..Dsw..;..:] 0030: 4A B5 C8 01 CA 9F A0 62 9C D0 A7 89 B8 9D A9 D6 J......b........ 0040: 5C E4 D1 1C 41 B6 D4 60 C1 72 E6 1A 04 BB DD C9 \...A..`.r...... ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.366 IST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 80 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.368 IST|SSLCipher.java:1313|Padded plaintext after DECRYPTION ( 0000: 2F 06 FA D4 45 E9 BA EF 52 F7 C6 9E 12 01 AB 7E /...E...R....... 0010: 14 00 00 0C E7 4D 51 81 9C 36 94 7C 57 5F 2F 48 .....MQ..6..W_/H 0020: E8 00 A5 73 1E E0 38 AC BF 67 58 3C EA FA 1E 98 ...s..8..gX<.... 0030: DF C5 1D 73 CF 8C F4 6D 9B 07 86 6D 5B 66 99 58 ...s...m...m[f.X 0040: 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F ................ ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.375 IST|Finished.java:536|Consuming server Finished handshake message ( "Finished": { "verify data": { 0000: E7 4D 51 81 9C 36 94 7C 57 5F 2F 48 }'} ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.377 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 17 03 03 00 40 ....@ ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.377 IST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 64 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.390 IST|SSLSocketInputRecord.java:458|Raw read ( 0000: 02 37 1B 4C F3 0A 2C D6 0E 15 22 16 87 94 9C 2C .7.L..,..."...., 0010: 1C CE D5 BE C0 F3 B5 D0 44 81 0E B3 33 72 26 05 ........D...3r&. 0020: EE 77 72 7A C2 66 10 C9 2A 56 2E 9A A8 33 D5 33 .wrz.f..*V...3.3 0030: 32 51 F4 FB 7D CE 1F E3 E3 92 05 57 65 87 CF 37 2Q.........We..7 ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.391 IST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 64 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.392 IST|SSLCipher.java:1313|Padded plaintext after DECRYPTION ( 0000: 59 85 DD C4 BC 97 73 1F 77 93 FB 5E 9E CA 9D A9 Y.....s.w..^.... 0010: 48 65 6C 6C 6F 20 57 6F 72 6C 64 21 0D 0A F9 58 Hello World!...X 0020: 0F 80 13 1D 49 9F 8B 03 68 C3 6A CE 2E 5D 3E D0 ....I...h.j..]>. 0030: 41 F7 C4 53 FD 72 41 AE A7 18 86 50 92 D4 01 01 A..S.rA....P.... ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.393 IST|SSLSocketImpl.java:473|duplex close of SSLSocket javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.397 IST|SSLSocketOutputRecord.java:71|WRITE: TLS12 alert(close_notify), length = 18 javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.401 IST|SSLCipher.java:1467|Padded plaintext before ENCRYPTION ( 0000: A0 09 8D 76 52 2F 80 A9 D5 50 E2 23 02 51 0F 54 ...vR/...P.#.Q.T 0010: 01 00 42 58 F9 1D 8C A7 32 5C 79 53 99 1E 7E F4 ..BX....2\yS.... 0020: 88 18 AE 8D C0 70 33 95 5B E1 7F 88 9D DA FE 4B .....p3.[......K 0030: 2B 22 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D +".............. ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.403 IST|SSLSocketOutputRecord.java:85|Raw write ( 0000: 15 03 03 00 40 49 02 BD 75 65 14 73 A8 A1 96 EC .... at I..ue.s.... 0010: 57 80 8D BA CF DC 5C 07 7F 34 55 EF AD 8A 8D FA W.....\..4U..... 0020: 1E 53 AE 67 FA FF 23 73 52 5D AE 4C 4F 16 2B 0D .S.g..#sR].LO.+. 0030: 9C 6F 05 E5 B3 13 C1 7B 78 B2 6D AD D3 A1 B8 A8 .o......x.m..... 0040: 67 D8 0D 9D 61 g...a ) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.408 IST|SSLSocketImpl.java:1360|close the underlying socket javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.409 IST|SSLSocketImpl.java:1379|close the SSL connection (initiative) javax.net.ssl|DEBUG|01|main|2020-01-31 15:28:13.415 IST|SSLSocketImpl.java:636|close inbound of SSLSocket javax.net.ssl|WARNING|01|main|2020-01-31 15:28:13.421 IST|SSLSocketImpl.java:494|SSLSocket duplex close failed ( "throwable" : { java.net.SocketException: Socket is closed at java.base/java.net.Socket.shutdownInput(Socket.java:1538) at java.base/sun.security.ssl.BaseSSLSocketImpl.shutdownInput(BaseSSLSocketImpl.java:216) at java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:651) at java.base/sun.security.ssl.SSLSocketImpl.bruteForceCloseInput(SSLSocketImpl.java:606) at java.base/sun.security.ssl.SSLSocketImpl.duplexCloseOutput(SSLSocketImpl.java:566) at java.base/sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:479) at SimpleClient.startClient(SimpleClient.java:30) at SimpleClient.main(SimpleClient.java:36)} ) Hello World! -------------- next part -------------- A non-text attachment was scrubbed... Name: reproSSlIssue.zip Type: application/x-zip-compressed Size: 18456 bytes Desc: not available URL: From xuelei.fan at oracle.com Mon Feb 3 06:16:17 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 2 Feb 2020 22:16:17 -0800 Subject: Socket read timeout resulting in fatal tls alert in jdk 11 In-Reply-To: References: Message-ID: <92bdded0-4627-cbed-9cd3-5f55c264965e@oracle.com> Per the attached debug log, it looks like that the exception is closure failure, but not the timeout exception. Did I missed something? Thanks & Regards, Xuelei On 2/2/2020 9:48 PM, BHARATH P G wrote: > Hi, > > We are hitting following issue with openjdk11. > > Issue description: > > If there is socket read timeout exception, jdk11 is sending tls fatal > alert causing client to close the socket connection. This was not the > behavior with jdk8. > > Below is the ssl debug logs with jdk11(complete log is available in the > attachment): > > javax.net.ssl|ERROR|01|main|2020-01-31 11:59:34.843 > IST|TransportContext.java:312|Fatal (UNEXPECTED_MESSAGE): Read timed out ( > > "throwable" : { > > ? java.net.SocketTimeoutException: Read timed out > > ??????? at java.base/java.net.SocketInputStream.socketRead0(Native Method) > > ??????? at > java.base/java.net.SocketInputStream.socketRead(SocketInputStream.java:115) > > ??????? at > java.base/java.net.SocketInputStream.read(SocketInputStream.java:168) > > ??????? at > java.base/java.net.SocketInputStream.read(SocketInputStream.java:140) > > ??????? at > java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448) > > ??????? at > java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165) > > ??????? at > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > > ??????? at > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) > > ??????? at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) > > ??????? at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > > ??????? at > java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716) > > ??????? at > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:799) > > ??????? at > java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) > > ??????? at > java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) > > ??????? at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) > > ??????? at > java.base/java.io.InputStreamReader.read(InputStreamReader.java:185) > > ??????? at java.base/java.io.BufferedReader.fill(BufferedReader.java:161) > > ??????? at > java.base/java.io.BufferedReader.readLine(BufferedReader.java:326) > > ??????? at > java.base/java.io.BufferedReader.readLine(BufferedReader.java:392) > > ??????? at SimpleClient.startClient(SimpleClient.java:29) > > ??????? at SimpleClient.main(SimpleClient.java:36)} > > ) > > javax.net.ssl|DEBUG|01|main|2020-01-31 11:59:34.846 > IST|SSLSocketOutputRecord.java:71|WRITE: TLS12 > alert(unexpected_message), length = 2 > > For reference I have attached sample client and server to repro the > issue and also ssl debug in the attachment. > > Thanks, > > Bharath > From matthias.baesken at sap.com Mon Feb 3 09:01:51 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 3 Feb 2020 09:01:51 +0000 Subject: RFR: 8237962: give better error output for invalid OCSP response intervals in CertPathValidator checks References: Message-ID: Sorry, had a typo in the last one , new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.4/ Best regards, Matthias > > > Hi Christoph, that sounds like a good idea . > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.3/ > > Thanks, Matthias > > > > > Hi Matthias, > > > > I'm wondering whether we should add cpve as cause of the > > RuntimeException in > > From barath.pg67 at gmail.com Mon Feb 3 09:30:38 2020 From: barath.pg67 at gmail.com (BHARATH P G) Date: Mon, 3 Feb 2020 15:00:38 +0530 Subject: Socket read timeout resulting in fatal tls alert in jdk 11 In-Reply-To: <92bdded0-4627-cbed-9cd3-5f55c264965e@oracle.com> References: <92bdded0-4627-cbed-9cd3-5f55c264965e@oracle.com> Message-ID: Sorry we attached logs from OracleJRE11 run. We are attaching here logs from openjdk 11. Looks like there is a gap between openjdk11 and OracleJDK11, in openjdk11 we could see tls1.2 alert(unexpected_message) after socket read timeout. Thanks, Bharath On Mon, 3 Feb 2020 at 11:46, Xuelei Fan wrote: > Per the attached debug log, it looks like that the exception is closure > failure, but not the timeout exception. Did I missed something? > > Thanks & Regards, > Xuelei > > On 2/2/2020 9:48 PM, BHARATH P G wrote: > > Hi, > > > > We are hitting following issue with openjdk11. > > > > Issue description: > > > > If there is socket read timeout exception, jdk11 is sending tls fatal > > alert causing client to close the socket connection. This was not the > > behavior with jdk8. > > > > Below is the ssl debug logs with jdk11(complete log is available in the > > attachment): > > > > javax.net.ssl|ERROR|01|main|2020-01-31 11:59:34.843 > > IST|TransportContext.java:312|Fatal (UNEXPECTED_MESSAGE): Read timed out > ( > > > > "throwable" : { > > > > java.net.SocketTimeoutException: Read timed out > > > > at java.base/java.net.SocketInputStream.socketRead0(Native > Method) > > > > at > > java.base/java.net > .SocketInputStream.socketRead(SocketInputStream.java:115) > > > > at > > java.base/java.net.SocketInputStream.read(SocketInputStream.java:168) > > > > at > > java.base/java.net.SocketInputStream.read(SocketInputStream.java:140) > > > > at > > > java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448) > > > > at > > > java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165) > > > > at > > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > > > > at > > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) > > > > at > > > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) > > > > at > > > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > > > > at > > > java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716) > > > > at > > > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:799) > > > > at > > java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) > > > > at > > java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) > > > > at > java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) > > > > at > > java.base/java.io.InputStreamReader.read(InputStreamReader.java:185) > > > > at java.base/java.io > .BufferedReader.fill(BufferedReader.java:161) > > > > at > > java.base/java.io.BufferedReader.readLine(BufferedReader.java:326) > > > > at > > java.base/java.io.BufferedReader.readLine(BufferedReader.java:392) > > > > at SimpleClient.startClient(SimpleClient.java:29) > > > > at SimpleClient.main(SimpleClient.java:36)} > > > > ) > > > > javax.net.ssl|DEBUG|01|main|2020-01-31 11:59:34.846 > > IST|SSLSocketOutputRecord.java:71|WRITE: TLS12 > > alert(unexpected_message), length = 2 > > > > For reference I have attached sample client and server to repro the > > issue and also ssl debug in the attachment. > > > > Thanks, > > > > Bharath > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.211 IST|SSLContextImpl.java:428|System property jdk.tls.client.cipherSuites is set to 'null' javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.234 IST|SSLContextImpl.java:428|System property jdk.tls.server.cipherSuites is set to 'null' javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.281 IST|SSLCipher.java:464|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.297 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.297 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.298 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.298 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.299 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.299 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.299 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.301 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.301 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.302 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.302 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.302 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.303 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.304 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.305 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_256_GCM_SHA384 javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.306 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_256_GCM_SHA384 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.306 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_128_GCM_SHA256 javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.307 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_128_GCM_SHA256 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.307 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA256 javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.308 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA256 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.309 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.310 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.312 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.313 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.314 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA256 javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.315 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA256 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.316 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_AES_128_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.317 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_AES_128_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.318 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.318 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.319 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.320 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.320 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.323 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.324 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.324 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.325 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.326 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.328 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.328 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.329 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.329 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.330 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.330 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.333 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_MD5 javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.333 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_MD5 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.334 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.335 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.335 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.336 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.337 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_RSA_WITH_DES_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.337 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_RSA_WITH_DES_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.338 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_DES_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.339 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_DES_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.339 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_DES_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.340 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_DES_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.340 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DH_anon_WITH_DES_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.341 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DH_anon_WITH_DES_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.341 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.344 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.345 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.345 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.346 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.346 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.347 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.347 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.348 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.348 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.349 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.350 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.350 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_RSA_WITH_NULL_SHA256 javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.351 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_RSA_WITH_NULL_SHA256 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.351 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.352 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.352 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.355 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.356 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_RSA_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.357 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_RSA_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.357 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.357 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.358 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.358 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.359 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_NULL_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.360 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_NULL_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.361 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_RSA_WITH_NULL_MD5 javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.361 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_RSA_WITH_NULL_MD5 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.365 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.366 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.366 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.367 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.367 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.368 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.369 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.369 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.370 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.370 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.371 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.372 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.373 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.373 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.378 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.379 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.380 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.380 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.381 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.381 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.382 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.382 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.383 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.383 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.384 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.384 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.385 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.385 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.389 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.389 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.390 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.390 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.391 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.391 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.392 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.392 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.393 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.394 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.395 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.395 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.396 IST|SSLContextImpl.java:402|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.396 IST|SSLContextImpl.java:411|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.400 IST|TrustStoreManager.java:112|trustStore is: clientTrustStore.key trustStore type is: pkcs12 trustStore provider is: the last modified time is: Fri Jan 31 00:22:52 IST 2020 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.401 IST|TrustStoreManager.java:311|Reload the trust store javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.422 IST|TrustStoreManager.java:318|Reload trust certs javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.423 IST|TrustStoreManager.java:323|Reloaded 1 trust certs javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.431 IST|X509TrustManagerImpl.java:79|adding as trusted certificates ( "certificate" : { "version" : "v3", "serial number" : "23 54 3E 06", "signature algorithm": "SHA256withDSA", "issuer" : "CN=localhost, OU=localhost, O=localhost, L=localhost, ST=localhost, C=in", "not before" : "2020-01-31 24:22:29.000 IST", "not after" : "2020-04-30 24:22:29.000 IST", "subject" : "CN=localhost, OU=localhost, O=localhost, L=localhost, ST=localhost, C=in", "subject public key" : "DSA", "extensions" : [ { ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 01 7D 37 9D AD 53 AB 56 D6 AA A2 9D C7 A9 96 72 ..7..S.V.......r 0010: AF 50 40 FE .P at . ] ] } ]} ) javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.432 IST|SSLContextImpl.java:1088|keyStore is : javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.434 IST|SSLContextImpl.java:1089|keyStore type is : pkcs12 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.434 IST|SSLContextImpl.java:1091|keyStore provider is : javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.435 IST|SSLContextImpl.java:1126|init keystore javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:15.436 IST|SSLContextImpl.java:1149|init keymanager of type SunX509 javax.net.ssl|ALL|01|main|2020-02-03 14:44:15.437 IST|SSLContextImpl.java:115|trigger seeding of SecureRandom javax.net.ssl|ALL|01|main|2020-02-03 14:44:16.340 IST|SSLContextImpl.java:119|done seeding of SecureRandom javax.net.ssl|WARNING|01|main|2020-02-03 14:44:16.403 IST|ServerNameExtension.java:261|Unable to indicate server name javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.403 IST|SSLExtensions.java:257|Ignore, context unavailable extension: server_name javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.405 IST|SupportedGroupsExtension.java:877|Ignore inactive or disabled named group: secp256r1 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.405 IST|SupportedGroupsExtension.java:877|Ignore inactive or disabled named group: secp384r1 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.405 IST|SupportedGroupsExtension.java:877|Ignore inactive or disabled named group: secp521r1 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.406 IST|ECPointFormatsExtension.java:195|Need no ec_point_formats extension javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.406 IST|SSLExtensions.java:257|Ignore, context unavailable extension: ec_point_formats javax.net.ssl|WARNING|01|main|2020-02-03 14:44:16.408 IST|SignatureScheme.java:296|Signature algorithm, ed25519, is not supported by the underlying providers javax.net.ssl|WARNING|01|main|2020-02-03 14:44:16.408 IST|SignatureScheme.java:296|Signature algorithm, ed448, is not supported by the underlying providers javax.net.ssl|ALL|01|main|2020-02-03 14:44:16.414 IST|SignatureScheme.java:373|Ignore disabled signature scheme: rsa_md5 javax.net.ssl|INFO|01|main|2020-02-03 14:44:16.415 IST|AlpnExtension.java:161|No available application protocols javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.415 IST|SSLExtensions.java:257|Ignore, context unavailable extension: application_layer_protocol_negotiation javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.419 IST|ClientHello.java:653|Produced ClientHello handshake message ( "ClientHello": { "client version" : "TLSv1.2", "random" : "C7 35 75 4D A7 39 75 A9 DE C8 F8 90 53 B3 77 A7 9C 2F 67 1A 70 D2 CB 18 1A 02 8E 31 CB CD 2E 2C", "session id" : "", "cipher suites" : "[TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A)]", "compression methods" : "00", "extensions" : [ "status_request (5)": { "certificate status type": ocsp "OCSP status request": { "responder_id": "request extensions": { } } }, "supported_groups (10)": { "versions": [ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] }, "signature_algorithms (13)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] }, "signature_algorithms_cert (50)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] }, "status_request_v2 (17)": { "cert status request": { "certificate status type": ocsp_multi "OCSP status request": { "responder_id": "request extensions": { } } } }, "extended_master_secret (23)": { }, "supported_versions (43)": { "versions": [TLSv1.2] }, "renegotiation_info (65,281)": { "renegotiated connection": [] } ] } ) javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.420 IST|SSLSocketOutputRecord.java:241|WRITE: TLS12 handshake, length = 177 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.438 IST|SSLSocketOutputRecord.java:255|Raw write ( 0000: 16 03 03 00 B1 01 00 00 AD 03 03 C7 35 75 4D A7 ............5uM. 0010: 39 75 A9 DE C8 F8 90 53 B3 77 A7 9C 2F 67 1A 70 9u.....S.w../g.p 0020: D2 CB 18 1A 02 8E 31 CB CD 2E 2C 00 00 02 00 6A ......1...,....j 0030: 01 00 00 82 00 05 00 05 01 00 00 00 00 00 0A 00 ................ 0040: 0C 00 0A 01 00 01 01 01 02 01 03 01 04 00 0D 00 ................ 0050: 22 00 20 04 03 05 03 06 03 08 04 08 05 08 06 08 ". ............. 0060: 09 08 0A 08 0B 04 01 05 01 06 01 04 02 02 03 02 ................ 0070: 01 02 02 00 32 00 22 00 20 04 03 05 03 06 03 08 ....2.". ....... 0080: 04 08 05 08 06 08 09 08 0A 08 0B 04 01 05 01 06 ................ 0090: 01 04 02 02 03 02 01 02 02 00 11 00 09 00 07 02 ................ 00A0: 00 04 00 00 00 00 00 17 00 00 00 2B 00 03 02 03 ...........+.... 00B0: 03 FF 01 00 01 00 ...... ) javax.net.ssl|ERROR|01|main|2020-02-03 14:44:16.445 IST|TransportContext.java:312|Fatal (UNEXPECTED_MESSAGE): Read timed out ( "throwable" : { java.net.SocketTimeoutException: Read timed out at java.base/java.net.SocketInputStream.socketRead0(Native Method) at java.base/java.net.SocketInputStream.socketRead(SocketInputStream.java:115) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:168) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140) at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448) at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:799) at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) at java.base/java.io.InputStreamReader.read(InputStreamReader.java:185) at java.base/java.io.BufferedReader.fill(BufferedReader.java:161) at java.base/java.io.BufferedReader.readLine(BufferedReader.java:326) at java.base/java.io.BufferedReader.readLine(BufferedReader.java:392) at SimpleClient.startClient(SimpleClient.java:29) at SimpleClient.main(SimpleClient.java:36)} ) javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.446 IST|SSLSocketOutputRecord.java:71|WRITE: TLS12 alert(unexpected_message), length = 2 javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.447 IST|SSLSocketOutputRecord.java:85|Raw write ( 0000: 15 03 03 00 02 02 0A ....... ) javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.448 IST|SSLSocketImpl.java:1360|close the underlying socket javax.net.ssl|DEBUG|01|main|2020-02-03 14:44:16.449 IST|SSLSocketImpl.java:1379|close the SSL connection (initiative) Exception in thread "main" javax.net.ssl.SSLException: Read timed out at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:320) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:258) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:137) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:799) at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) at java.base/java.io.InputStreamReader.read(InputStreamReader.java:185) at java.base/java.io.BufferedReader.fill(BufferedReader.java:161) at java.base/java.io.BufferedReader.readLine(BufferedReader.java:326) at java.base/java.io.BufferedReader.readLine(BufferedReader.java:392) at SimpleClient.startClient(SimpleClient.java:29) at SimpleClient.main(SimpleClient.java:36) Caused by: java.net.SocketTimeoutException: Read timed out at java.base/java.net.SocketInputStream.socketRead0(Native Method) at java.base/java.net.SocketInputStream.socketRead(SocketInputStream.java:115) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:168) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140) at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448) at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) ... 14 more From sean.mullan at oracle.com Mon Feb 3 13:21:24 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 3 Feb 2020 08:21:24 -0500 Subject: RFR: 8237962: give better error output for invalid OCSP response intervals in CertPathValidator checks In-Reply-To: References: Message-ID: <5206244d-192d-f9bd-dab8-a04436fcea2b@oracle.com> Looks good. --Sean On 2/3/20 4:01 AM, Baesken, Matthias wrote: > > Sorry, had a typo in the last one , new webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.4/ > > Best regards, Matthias > > > >> >> >> Hi Christoph, that sounds like a good idea . >> >> New webrev : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.3/ >> >> Thanks, Matthias >> >> >> >>> Hi Matthias, >>> >>> I'm wondering whether we should add cpve as cause of the >>> RuntimeException in >>> > From xuelei.fan at oracle.com Mon Feb 3 17:08:06 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 3 Feb 2020 09:08:06 -0800 Subject: Socket read timeout resulting in fatal tls alert in jdk 11 In-Reply-To: References: <92bdded0-4627-cbed-9cd3-5f55c264965e@oracle.com> Message-ID: On 2/3/2020 1:30 AM, BHARATH P G wrote: > Sorry we attached logs from OracleJRE11 run. > > We are attaching here logs from openjdk 11. > Thanks! > Looks like there is a gap between openjdk11 and OracleJDK11, in > openjdk11 we could see tls1.2 alert(unexpected_message) after socket > read timeout. > I agreed there is a gap. OpenJDK may want to fix the issue. Regards, Xuelei > Thanks, > Bharath > > On Mon, 3 Feb 2020 at 11:46, Xuelei Fan > wrote: > > Per the attached debug log, it looks like that the exception is closure > failure, but not the timeout exception.? Did I missed something? > > Thanks & Regards, > Xuelei > > On 2/2/2020 9:48 PM, BHARATH P G wrote: > > Hi, > > > > We are hitting following issue with openjdk11. > > > > Issue description: > > > > If there is socket read timeout exception, jdk11 is sending tls > fatal > > alert causing client to close the socket connection. This was not > the > > behavior with jdk8. > > > > Below is the ssl debug logs with jdk11(complete log is available > in the > > attachment): > > > > javax.net.ssl|ERROR|01|main|2020-01-31 11:59:34.843 > > IST|TransportContext.java:312|Fatal (UNEXPECTED_MESSAGE): Read > timed out ( > > > > "throwable" : { > > > > java.net .SocketTimeoutException: Read timed out > > > >? ??????? at java.base/java.net > .SocketInputStream.socketRead0(Native Method) > > > >? ??????? at > > java.base/java.net > .SocketInputStream.socketRead(SocketInputStream.java:115) > > > >? ??????? at > > java.base/java.net > .SocketInputStream.read(SocketInputStream.java:168) > > > >? ??????? at > > java.base/java.net > .SocketInputStream.read(SocketInputStream.java:140) > > > >? ??????? at > > > java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448) > > > >? ??????? at > > > java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165) > > > >? ??????? at > > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > > > >? ??????? at > > > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) > > > >? ??????? at > > > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) > > > >? ??????? at > > > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > > > >? ??????? at > > > java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716) > > > >? ??????? at > > > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:799) > > > >? ??????? at > > java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) > > > >? ??????? at > > java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) > > > >? ??????? at > java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) > > > >? ??????? at > > java.base/java.io > .InputStreamReader.read(InputStreamReader.java:185) > > > >? ??????? at java.base/java.io > .BufferedReader.fill(BufferedReader.java:161) > > > >? ??????? at > > java.base/java.io > .BufferedReader.readLine(BufferedReader.java:326) > > > >? ??????? at > > java.base/java.io > .BufferedReader.readLine(BufferedReader.java:392) > > > >? ??????? at SimpleClient.startClient(SimpleClient.java:29) > > > >? ??????? at SimpleClient.main(SimpleClient.java:36)} > > > > ) > > > > javax.net.ssl|DEBUG|01|main|2020-01-31 11:59:34.846 > > IST|SSLSocketOutputRecord.java:71|WRITE: TLS12 > > alert(unexpected_message), length = 2 > > > > For reference I have attached sample client and server to repro the > > issue and also ssl debug in the attachment. > > > > Thanks, > > > > Bharath > > > From matthias.baesken at sap.com Tue Feb 4 10:06:02 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 4 Feb 2020 10:06:02 +0000 Subject: RFR: 8237962: give better error output for invalid OCSP response intervals in CertPathValidator checks In-Reply-To: <5206244d-192d-f9bd-dab8-a04436fcea2b@oracle.com> References: <5206244d-192d-f9bd-dab8-a04436fcea2b@oracle.com> Message-ID: Sean, Christoph, thanks for the reviews ! > > Looks good. > > --Sean > From weijun.wang at oracle.com Tue Feb 4 12:56:26 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 4 Feb 2020 20:56:26 +0800 Subject: RFR 8237804: sun/security/mscapi tests fail with "Key pair not generated, alias already exists" Message-ID: <17E9B428-FA7E-43F0-BE06-4C9362A00B3E@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8237804/webrev.00/ It's probably that another test run has not cleaned up the entry. Thanks, Max From sean.mullan at oracle.com Tue Feb 4 13:04:02 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 4 Feb 2020 08:04:02 -0500 Subject: RFR 8237804: sun/security/mscapi tests fail with "Key pair not generated, alias already exists" In-Reply-To: <17E9B428-FA7E-43F0-BE06-4C9362A00B3E@oracle.com> References: <17E9B428-FA7E-43F0-BE06-4C9362A00B3E@oracle.com> Message-ID: Looks good. --Sean On 2/4/20 7:56 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8237804/webrev.00/ > > It's probably that another test run has not cleaned up the entry. > > Thanks, > Max > From bradford.wetmore at oracle.com Tue Feb 4 19:41:31 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 4 Feb 2020 11:41:31 -0800 Subject: RFR(jdk): 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION Message-ID: Simple review request. Weijun has provided the fix, so pushing for him. 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION Reviewed-by: wetmore, coffeys A JNI call isn't properly sizing its arguments, and is causing VM crashes. Brad From bradford.wetmore at oracle.com Tue Feb 4 19:42:47 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 4 Feb 2020 11:42:47 -0800 Subject: RFR(jdk): 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION Message-ID: (Sigh, forgot location) Simple review request. Weijun has provided the fix, so pushing for him. 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION Reviewed-by: wetmore, coffeys A JNI call isn't properly sizing its arguments, and is causing VM crashes. http://cr.openjdk.java.net/~wetmore/8238502/ Brad From sean.mullan at oracle.com Tue Feb 4 19:48:30 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 4 Feb 2020 14:48:30 -0500 Subject: RFR(jdk): 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION In-Reply-To: References: Message-ID: <219ee1de-9372-8017-f4d1-b2228898f2a7@oracle.com> Looks good. I assume this should be a Bug and not an Enhancement though? --Sean On 2/4/20 2:42 PM, Bradford Wetmore wrote: > (Sigh, forgot location) > > > Simple review request.? Weijun has provided the fix, so pushing for him. > > 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION > Reviewed-by: wetmore, coffeys > > A JNI call isn't properly sizing its arguments, and is causing VM crashes. > > http://cr.openjdk.java.net/~wetmore/8238502/ > > Brad From bradford.wetmore at oracle.com Tue Feb 4 21:11:04 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 4 Feb 2020 13:11:04 -0800 Subject: RFR(jdk): 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION In-Reply-To: <219ee1de-9372-8017-f4d1-b2228898f2a7@oracle.com> References: <219ee1de-9372-8017-f4d1-b2228898f2a7@oracle.com> Message-ID: <79b313ea-9533-ec98-4c5c-a1e9a11ddcfb@oracle.com> Ah yes, defaulted to enhancement. Thanks. Brad On 2/4/2020 11:48 AM, Sean Mullan wrote: > Looks good. I assume this should be a Bug and not an Enhancement though? > > --Sean > > On 2/4/20 2:42 PM, Bradford Wetmore wrote: >> (Sigh, forgot location) >> >> >> Simple review request.? Weijun has provided the fix, so pushing for him. >> >> 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION >> Reviewed-by: wetmore, coffeys >> >> A JNI call isn't properly sizing its arguments, and is causing VM >> crashes. >> >> http://cr.openjdk.java.net/~wetmore/8238502/ >> >> Brad From sean.coffey at oracle.com Tue Feb 4 21:17:21 2020 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 04 Feb 2020 21:17:21 +0000 Subject: RFR(jdk): 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION In-Reply-To: <79b313ea-9533-ec98-4c5c-a1e9a11ddcfb@oracle.com> References: <219ee1de-9372-8017-f4d1-b2228898f2a7@oracle.com> <79b313ea-9533-ec98-4c5c-a1e9a11ddcfb@oracle.com> Message-ID: <035FC590-892C-4B4A-9E59-FF72911057F8@oracle.com> Looks fine to me also. Thanks for handling. Sean. On 4 February 2020 21:11:04 GMT, Bradford Wetmore wrote: >Ah yes, defaulted to enhancement. Thanks. > >Brad > > >On 2/4/2020 11:48 AM, Sean Mullan wrote: >> Looks good. I assume this should be a Bug and not an Enhancement >though? >> >> --Sean >> >> On 2/4/20 2:42 PM, Bradford Wetmore wrote: >>> (Sigh, forgot location) >>> >>> >>> Simple review request.? Weijun has provided the fix, so pushing for >him. >>> >>> 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION >>> Reviewed-by: wetmore, coffeys >>> >>> A JNI call isn't properly sizing its arguments, and is causing VM >>> crashes. >>> >>> http://cr.openjdk.java.net/~wetmore/8238502/ >>> >>> Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Tue Feb 4 23:24:01 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 4 Feb 2020 15:24:01 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 Message-ID: I added a simple PSS 32-bit windows crash fix, which was previously reviewed in security-dev earlier today [0]. 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION The PSS webrev is now at version .01. Otherwise, everything is identical from last week's request below. The ALPN remains at version .00. [0] https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021203.html ---begin--- Good morning/afternoon/evening/night, As announced on jdk8u-dev[1], there is a Maintenance Release in progress for Java SE 8 (i.e. JSR 337) [2] to include two security features important for TLS 1.3: 1. Application-Layer Protocol Negotiation (ALPN) [3][4] 2. RSA Signature Scheme with Appendix: Probabilistic Signature Scheme (RSASSA-PSS) [5][6] As mentioned in [1], if it wasn't too much work then we would like to contribute the changes required by this MR to the next appropriate OpenJDK 8 release, most likely 8u252. Now that the MR3 balloting successfully concluded last night, I'd like to make that happen, and move the code into review. The code is essentially what was reviewed for 8u41[7][8] and internally for what we expect to be in Oracle's 8u251 JDK, except the code in this review is based on the current JDK 8u workspace. We also included code to allow the Windows platform to use PSS natively. The specific bugs/backports (requested by the JDK8u maintainers) follow: ALPN: ===== 8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension (Java SE 8) 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension 8170282: Enable ALPN parameters to be supplied during the TLS handshake 8145849: ALPN: getHandshakeApplicationProtocol() always return null 8158978: ALPN not working when values are set directly on a SSLServerSocket 8171443: (spec) An ALPN callback function may also ignore ALPN RSASSA-PSS: =========== 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) 8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) 8146293: Add support for RSASSA-PSS Signature algorithm 8205445: Add RSASSA-PSS Signature support to SunMSCAPI 8205720: KeyFactory#getKeySpec and translateKey throws NullPointerException with Invalid key 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized 8213009: Refactoring existing SunMSCAPI classes 8213010: Supporting keys created with certmgr.exe 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails 8215694: keytool cannot generate RSASSA-PSS certificates 8221407: Windows 32bit build error in libsunmscapi/security.cpp 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange 8223003: SunMSCAPI keys are not cleaned up 8223063: Support CNG RSA keys 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support 8225180: SignedObject with invalid Key not throwing the InvalidKeyException in Windows 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as AlgorithmId Reviewed-by: valeriep, weijun, coffeys, pkoppula Here are the reviews: 1. ALPN: http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN 2. RSASSA-PSS: http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS Most of these changes are direct copies of the changesets applied in JDK 9+, but adjusted for JDK 8u. Also, truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were added to the SUN Provider to support the corresponding truncated RSASSA-PSS Signatures. Thanks, Brad [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html [2] https://www.jcp.org/en/jsr/detail?id=337 [3] https://bugs.openjdk.java.net/browse/JDK-8230977 [4] https://bugs.openjdk.java.net/browse/JDK-8233417 [5] https://bugs.openjdk.java.net/browse/JDK-8230978 [6] https://bugs.openjdk.java.net/browse/JDK-8233418 [7] https://mail.openjdk.java.net/pipermail/security-dev/2019-November/020900.html [8] http://hg.openjdk.java.net/jdk8u/jdk8u41/ From weijun.wang at oracle.com Wed Feb 5 03:14:33 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 5 Feb 2020 11:14:33 +0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: Message-ID: I reviewed the windows/ changes. Looks fine except there is no need to update PRNG.java. Thanks, Max > On Feb 5, 2020, at 7:24 AM, Bradford Wetmore wrote: > > 2. RSASSA-PSS: > http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS From patrick at os.amperecomputing.com Wed Feb 5 12:53:01 2020 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Wed, 5 Feb 2020 12:53:01 +0000 Subject: RFR: JDK-8238388: libj2gss/NativeFunc.o "multiple definition" link errors with GCC10 Message-ID: Hi, Please help review this quick patch in order to resolve the libj2gss link errors caused by GCC10 default option -fno-common. More details, please see JDK-8238388 and its related JDK-8235903 [1]. Weijun, I saw your comments in the ticket, thanks. It is exactly the same way I am updating the code. In addition, could you please sponsor this patch (once approved)? Thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8238388 Webrev: http://cr.openjdk.java.net/~qpzhang/8238388/webrev.01/ Test: ran jtreg tier1, jdk built with GCC4.8.5, GCC9, and GCC10, no regression found [1] https://bugs.openjdk.java.net/browse/JDK-8235903 GCC default -fno-common exposes "multiple definition" link errors Regards Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Feb 5 13:25:59 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 5 Feb 2020 21:25:59 +0800 Subject: RFR: JDK-8238388: libj2gss/NativeFunc.o "multiple definition" link errors with GCC10 In-Reply-To: References: Message-ID: <22D86077-8992-46B7-B46F-AC8DABACA3AC@oracle.com> It's now live at https://hg.openjdk.java.net/jdk/jdk/rev/9e54ea7d9cd9. Thanks, Max > On Feb 5, 2020, at 8:53 PM, Patrick Zhang OS wrote: > > Hi, > > Please help review this quick patch in order to resolve the libj2gss link errors caused by GCC10 default option -fno-common. More details, please see JDK-8238388 and its related JDK-8235903 [1]. > > Weijun, I saw your comments in the ticket, thanks. It is exactly the same way I am updating the code. In addition, could you please sponsor this patch (once approved)? Thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8238388 > Webrev: http://cr.openjdk.java.net/~qpzhang/8238388/webrev.01/ > Test: ran jtreg tier1, jdk built with GCC4.8.5, GCC9, and GCC10, no regression found > > [1] https://bugs.openjdk.java.net/browse/JDK-8235903 GCC default -fno-common exposes "multiple definition" link errors > > Regards > Patrick From sean.mullan at oracle.com Wed Feb 5 15:31:02 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 5 Feb 2020 10:31:02 -0500 Subject: [15] RFR: 8191395: policy.allowSystemProperty and policy.expandProperties also apply to JAAS configurations In-Reply-To: References: <30c2ed46-52ac-613d-dcaa-bcf166e5b295@oracle.com> <387D67EA-1C90-4658-95E3-F58B425CEA86@oracle.com> Message-ID: I added a sentence about policy.expandProperties to the ConfigFile class description. In the java.security file, I also clarified that setting the policy.allowSystemProperty to false (in addition to commenting it out) would disable the feature. New webrev at http://cr.openjdk.java.net/~mullan/webrevs/8191395/webrev.01/ CSR: https://bugs.openjdk.java.net/browse/JDK-8238483 --Sean On 1/31/20 10:42 AM, Sean Mullan wrote: > On 1/30/20 7:27 PM, Weijun Wang wrote: >> Looks fine. Does this require a CSR? > > Hmm, I was on the fence about that. ConfigFile already mentions > policy.allowSystemProperty in the class description [1], so I think in > this case, we are just improving the documentation. > > I can't find any JAAS reference to policy.expandProperties though. I > suppose we should file one then since this would be the first time it is > documented. > > Let me draft up a CSR and reply back later. > > --Sean > > [1] > https://download.java.net/java/early_access/jdk14/docs/api/jdk.security.auth/com/sun/security/auth/login/ConfigFile.html > > >> >> Thanks, >> Max >> >>> On Jan 31, 2020, at 3:18 AM, Sean Mullan wrote: >>> >>> Please review this small change to the documentation of these two >>> security properties. >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191395/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8191395 >>> >>> Thanks, >>> Sean >> From mbalao at redhat.com Wed Feb 5 15:47:55 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 5 Feb 2020 12:47:55 -0300 Subject: RFR 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB Message-ID: Hi, I'd like to propose a solution for 8238555 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8238555/8238555.webrev.00/ Reproducing this issue requires manual configuration steps and there is not a single way of doing so. The ultimate goal for a reproduction is to initialize a SunPKCS11 provider with an NSSDB that has at least 1 external module configured in FIPS mode, with at least 1 opened slot. The 8238555_manual_reproducer_v0 code [2] provides a standalone SunPKCS11 initialization with an NSSDB that has a single internal FIPS module configured. That's not enough though because the external module is still missing in the NSSDB. There are two paths from this point: 1) Manually add an external module ("modutil" command) in FIPS mode to the NSSDB 2) Run the code in the latest Fedora/CentOS/RHEL Linux release -I'm not sure if other distributions work- where p11-kit-proxy PKCS#11 module is automatically added to every NSSDB. If you go this way, configure FIPS policy globally (fips-mode-setup --enable) and recompile the NSS library to artificially expose a slot for p11-kit-proxy module [3] (use LD_PRELOAD when running the reproducer code). If you don't want to recompile the NSS library, manually add a module to p11-kit (such as softHSM) so a slot is opened. In my own environment, I had the following output before the patch: Beginning test run ExternalFipsModules... Cannot resolve artifact, please check if JIB jar is present in classpath. nssLibDir: /usr/lib64/ Exception in thread "main" java.lang.RuntimeException: FIPS flag set for non-internal module: p11-kit-proxy.so, p11-kit-proxy at jdk.crypto.cryptoki/sun.security.pkcs11.Secmod$Module.(Secmod.java:418) at jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.nssGetModuleList(Native Method) at jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.getModules(Secmod.java:258) at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:219) at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:112) at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:109) at java.base/java.security.AccessController.doPrivileged(AccessController.java:554) at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:109) at PKCS11Test.getSunPKCS11(PKCS11Test.java:160) at PKCS11Test.testNSS(PKCS11Test.java:580) at PKCS11Test.main(PKCS11Test.java:220) at PKCS11Test.main(PKCS11Test.java:196) at ExternalFipsModules.main(ExternalFipsModules.java:31) And after the patch: Beginning test run ExternalFipsModules... Cannot resolve artifact, please check if JIB jar is present in classpath. nssLibDir: /usr/lib64/ Running test with provider SunPKCS11-NSS-FIPS (security manager disabled) ... Provider: SunPKCS11-NSS-FIPS version 15 TEST PASS - OK Completed test with provider SunPKCS11-NSS-FIPS (2 ms). Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8238555 [2] - http://cr.openjdk.java.net/~mbalao/webrevs/8238555/8238555_manual_reproducer_v0.tar.gz [3] - http://cr.openjdk.java.net/~mbalao/webrevs/8238555/emulate_p11-kit-proxy_with_slots.nss.patch From gnu.andrew at redhat.com Wed Feb 5 16:27:04 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 5 Feb 2020 16:27:04 +0000 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: Message-ID: On 04/02/2020 23:24, Bradford Wetmore wrote: > I added a simple PSS 32-bit windows crash fix, which was previously > reviewed in security-dev earlier today [0]. > > ??? 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION > > The PSS webrev is now at version .01. > > Otherwise, everything is identical from last week's request below.? The > ALPN remains at version .00. > > [0] > https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021203.html > > Thanks. Sorry for not getting to this just yet (work on 7u taking longer than expected), but I would still like to take a look before it goes in. I'll try and do that today. Thanks for your patience, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From mbalao at redhat.com Wed Feb 5 17:49:57 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 5 Feb 2020 14:49:57 -0300 Subject: RFR 8238264: Exception thrown when setting javax.net.ssl.keyStoreType = PKCS11 In-Reply-To: References: Message-ID: <68dec7ba-bceb-5942-9cc3-d2e6cd6928d5@redhat.com> On 1/30/20 9:23 PM, Martin Balao wrote: > Hi, > > I'd like to have a review for 8238264 [1]. > > Webrev.00: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8238264/8238264.webrev.00/ > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8238264 > Ping. This should be a trivial fix. Thanks! Martin.- From xuelei.fan at oracle.com Wed Feb 5 18:00:32 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 5 Feb 2020 10:00:32 -0800 Subject: RFR 8238264: Exception thrown when setting javax.net.ssl.keyStoreType = PKCS11 In-Reply-To: <68dec7ba-bceb-5942-9cc3-d2e6cd6928d5@redhat.com> References: <68dec7ba-bceb-5942-9cc3-d2e6cd6928d5@redhat.com> Message-ID: <45e63d41-1dab-e5db-38f4-d54aa55f6150@oracle.com> I may think it differently. If keyStoreType is PKCS11, then keyStore must be "NONE". It might be not necessary to allow default keyStore value for PKCS11 keyStoreType. Thanks, Xuelei On 2/5/2020 9:49 AM, Martin Balao wrote: > On 1/30/20 9:23 PM, Martin Balao wrote: >> Hi, >> >> I'd like to have a review for 8238264 [1]. >> >> Webrev.00: >> >> * http://cr.openjdk.java.net/~mbalao/webrevs/8238264/8238264.webrev.00/ >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8238264 >> > > Ping. This should be a trivial fix. > > Thanks! > > Martin.- > From mbalao at redhat.com Wed Feb 5 18:46:59 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 5 Feb 2020 15:46:59 -0300 Subject: RFR 8238264: Exception thrown when setting javax.net.ssl.keyStoreType = PKCS11 In-Reply-To: <45e63d41-1dab-e5db-38f4-d54aa55f6150@oracle.com> References: <68dec7ba-bceb-5942-9cc3-d2e6cd6928d5@redhat.com> <45e63d41-1dab-e5db-38f4-d54aa55f6150@oracle.com> Message-ID: Hi Xuelei, Thanks for having a look at this. On 2/5/20 3:00 PM, Xuelei Fan wrote: > I may think it differently.? If keyStoreType is PKCS11, then keyStore > must be "NONE".? It might be not necessary to allow default keyStore > value for PKCS11 keyStoreType. Why do you think that a non-set or empty keyStore system property won't work and we must enforce the "NONE" string value when keyStoreType is "PKCS11"? It's confusing as a user-interface that you set the keystore.type security property to "PKCS11" and then you must explicitly set "javax.net.ssl.keyStore=NONE" as JVM parameter in each run because empty/non-set is not considered the same than none. Looks to me that the original intention was to consider empty / non-set as equal to "NONE" because of the condition check here: http://hg.openjdk.java.net/jdk/jdk/file/085463e75652/src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java#l1010 Thanks, Martin.- From xuelei.fan at oracle.com Wed Feb 5 19:10:22 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 5 Feb 2020 11:10:22 -0800 Subject: RFR 8238264: Exception thrown when setting javax.net.ssl.keyStoreType = PKCS11 In-Reply-To: References: <68dec7ba-bceb-5942-9cc3-d2e6cd6928d5@redhat.com> <45e63d41-1dab-e5db-38f4-d54aa55f6150@oracle.com> Message-ID: <50266e1e-a574-fb37-8b20-192cd23fc2b4@oracle.com> For the property, the default key store is none. We may not want to introduce new compatibility risks by adding a new default value. If application want to use key store other than the default one, it is required to set it. Xuelei On 2/5/2020 10:46 AM, Martin Balao wrote: > Hi Xuelei, > > Thanks for having a look at this. > > On 2/5/20 3:00 PM, Xuelei Fan wrote: >> I may think it differently.? If keyStoreType is PKCS11, then keyStore >> must be "NONE".? It might be not necessary to allow default keyStore >> value for PKCS11 keyStoreType. > > Why do you think that a non-set or empty keyStore system property won't > work and we must enforce the "NONE" string value when keyStoreType is > "PKCS11"? It's confusing as a user-interface that you set the > keystore.type security property to "PKCS11" and then you must explicitly > set "javax.net.ssl.keyStore=NONE" as JVM parameter in each run because > empty/non-set is not considered the same than none. Looks to me that the > original intention was to consider empty / non-set as equal to "NONE" > because of the condition check here: > http://hg.openjdk.java.net/jdk/jdk/file/085463e75652/src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java#l1010 > > Thanks, > Martin.- > From aeubanks at google.com Wed Feb 5 20:49:24 2020 From: aeubanks at google.com (Arthur Eubanks) Date: Wed, 5 Feb 2020 12:49:24 -0800 Subject: RFR: 8238566: java.security.Provider$Service.supportsParameter() is racy Message-ID: Webrev: http://cr.openjdk.java.net/~aeubanks/8238566/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8238566 Found by TSAN, java.security.Provider$Service.supportsParameter() is racy. We haven't observed any actual bad behavior, but reasoning through it seems like bad behavior is possible. http://hg.openjdk.java.net/jdk/jdk/file/62b5bfef8d61/src/java.base/share/classes/java/security/Provider.java#l1927 The synchronized block seems to not have any effect on correctness. Example race: T1 in hasKeyAttributes() writes true to hasKeyAttributes and fills out supportedFormats/supportedClasses. T2 in hasKeyAttributes() racily reads hasKeyAttributes as true, but then in supportsKeyFormat() racily reads supportedFormats as null. It can then improperly return false from supportsParameter(). There is no synchronization between T1 and T2 because T2 never does any synchronization, so T2 can read what T1 writes in any order. Fix is to make all of hasKeyAttributes() synchronized. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Wed Feb 5 21:11:21 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 5 Feb 2020 18:11:21 -0300 Subject: RFR 8238264: Exception thrown when setting javax.net.ssl.keyStoreType = PKCS11 In-Reply-To: <50266e1e-a574-fb37-8b20-192cd23fc2b4@oracle.com> References: <68dec7ba-bceb-5942-9cc3-d2e6cd6928d5@redhat.com> <45e63d41-1dab-e5db-38f4-d54aa55f6150@oracle.com> <50266e1e-a574-fb37-8b20-192cd23fc2b4@oracle.com> Message-ID: On 2/5/20 4:10 PM, Xuelei Fan wrote: > For the property, the default key store is none. If "javax.net.ssl.keyStore" system property is not set, the default "keyStore" value is an empty string (not "NONE"). We may not want to > introduce new compatibility risks by adding a new default value. I don't intend to change the default value. The default will continue to be an empty string. All I want is to fix the ambiguity between empty string and string "NONE" when checking the condition. If > application want to use key store other than the default one, it is > required to set it. Yes, sure. I'm not discussing this. Thanks, Martin.- From xuelei.fan at oracle.com Wed Feb 5 21:20:40 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 5 Feb 2020 13:20:40 -0800 Subject: RFR 8238264: Exception thrown when setting javax.net.ssl.keyStoreType = PKCS11 In-Reply-To: References: <68dec7ba-bceb-5942-9cc3-d2e6cd6928d5@redhat.com> <45e63d41-1dab-e5db-38f4-d54aa55f6150@oracle.com> <50266e1e-a574-fb37-8b20-192cd23fc2b4@oracle.com> Message-ID: <52c9a42b-0492-d427-ef21-6afa8f22a895@oracle.com> On 2/5/2020 1:11 PM, Martin Balao wrote: > On 2/5/20 4:10 PM, Xuelei Fan wrote: >> For the property, the default key store is none. > > If "javax.net.ssl.keyStore" system property is not set, the default > "keyStore" value is an empty string (not "NONE"). > Yes, it is empty, no value, not the "NONE" string. > We may not want to >> introduce new compatibility risks by adding a new default value. > > I don't intend to change the default value. The default will continue to > be an empty string. All I want is to fix the ambiguity between empty > string and string "NONE" when checking the condition. > But with the patch, the value is indeed changed from none (empty) to "NONE" in logic. You would also need to change other code if yo really want it (have the property value return "NONE", check other code to make sure "NONE" is used when it is "empty", documentation the special value, etc). I don't think we want to the unnecessary conflicts and complex, for limited benefits. I'm fine if you want to update documentation to make it clear that one need to set the keyStore to "NONE" for PKCS11. Regards, Xuelei > If >> application want to use key store other than the default one, it is >> required to set it. > > Yes, sure. I'm not discussing this. > > Thanks, > Martin.- > From mbalao at redhat.com Wed Feb 5 21:46:59 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 5 Feb 2020 18:46:59 -0300 Subject: RFR 8238264: Exception thrown when setting javax.net.ssl.keyStoreType = PKCS11 In-Reply-To: <52c9a42b-0492-d427-ef21-6afa8f22a895@oracle.com> References: <68dec7ba-bceb-5942-9cc3-d2e6cd6928d5@redhat.com> <45e63d41-1dab-e5db-38f4-d54aa55f6150@oracle.com> <50266e1e-a574-fb37-8b20-192cd23fc2b4@oracle.com> <52c9a42b-0492-d427-ef21-6afa8f22a895@oracle.com> Message-ID: <68790222-b0b7-d4de-baa9-2c7af3ba885d@redhat.com> On 2/5/20 6:20 PM, Xuelei Fan wrote: > But with the patch, the value is indeed changed from none (empty) to > "NONE" in logic.? You would also need to change other code if yo really > want it (have the property value return "NONE", check other code to make > sure "NONE" is used when it is "empty", documentation the special value, > etc).? I don't think we want to the unnecessary conflicts and complex, > for limited benefits. Sorry but I'm unable to understand your point and why my change would imply such further changes. There is the following check condition: if (P11KEYSTORE.equals(defaultKeyStoreType) && !NONE.equals(defaultKeyStore)) { throw new IllegalArgumentException("if keyStoreType is " + P11KEYSTORE + ", then keyStore must be " + NONE); } That check is preventing keyStoreType to be PKCS11 and keyStore to be set to something other than "NONE". The concern is letting the user specify contradictory input: if your keystore is of PKCS11 type, you are not supposed to use keyStore to point to any file (because the file will obviously use other keystore formats such as PKCS12 or JKS). However, that check is also preventing all those cases in which keyStore is not even set (default case). That's odd to me, but I understand this change won't make it. Thanks for having a look anyways. Martin.- From xuelei.fan at oracle.com Wed Feb 5 21:58:26 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 5 Feb 2020 13:58:26 -0800 Subject: RFR 8238264: Exception thrown when setting javax.net.ssl.keyStoreType = PKCS11 In-Reply-To: <68790222-b0b7-d4de-baa9-2c7af3ba885d@redhat.com> References: <68dec7ba-bceb-5942-9cc3-d2e6cd6928d5@redhat.com> <45e63d41-1dab-e5db-38f4-d54aa55f6150@oracle.com> <50266e1e-a574-fb37-8b20-192cd23fc2b4@oracle.com> <52c9a42b-0492-d427-ef21-6afa8f22a895@oracle.com> <68790222-b0b7-d4de-baa9-2c7af3ba885d@redhat.com> Message-ID: Normally, we need to be consistent for the system property use. We don't use one spec in a place, and another spec in another place. Xuelei On 2/5/2020 1:46 PM, Martin Balao wrote: > On 2/5/20 6:20 PM, Xuelei Fan wrote: >> But with the patch, the value is indeed changed from none (empty) to >> "NONE" in logic.? You would also need to change other code if yo really >> want it (have the property value return "NONE", check other code to make >> sure "NONE" is used when it is "empty", documentation the special value, >> etc).? I don't think we want to the unnecessary conflicts and complex, >> for limited benefits. > Sorry but I'm unable to understand your point and why my change would > imply such further changes. > > There is the following check condition: > > if (P11KEYSTORE.equals(defaultKeyStoreType) && > !NONE.equals(defaultKeyStore)) { > throw new IllegalArgumentException("if keyStoreType is " > + P11KEYSTORE + ", then keyStore must be " + NONE); > } > > That check is preventing keyStoreType to be PKCS11 and keyStore to be > set to something other than "NONE". The concern is letting the user > specify contradictory input: if your keystore is of PKCS11 type, you are > not supposed to use keyStore to point to any file (because the file will > obviously use other keystore formats such as PKCS12 or JKS). However, > that check is also preventing all those cases in which keyStore is not > even set (default case). That's odd to me, but I understand this change > won't make it. > > Thanks for having a look anyways. > > Martin.- > From bradford.wetmore at oracle.com Thu Feb 6 00:24:58 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 5 Feb 2020 16:24:58 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: Message-ID: <0e689ca2-c2c6-9a04-b2f2-3875816bd55f@oracle.com> Thanks, I'll update it. Brad On 2/4/2020 7:14 PM, Weijun Wang wrote: > I reviewed the windows/ changes. Looks fine except there is no need to update PRNG.java. > > Thanks, > Max > >> On Feb 5, 2020, at 7:24 AM, Bradford Wetmore wrote: >> >> 2. RSASSA-PSS: >> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS > From weijun.wang at oracle.com Thu Feb 6 01:53:46 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 6 Feb 2020 09:53:46 +0800 Subject: [15] RFR: 8191395: policy.allowSystemProperty and policy.expandProperties also apply to JAAS configurations In-Reply-To: References: <30c2ed46-52ac-613d-dcaa-bcf166e5b295@oracle.com> <387D67EA-1C90-4658-95E3-F58B425CEA86@oracle.com> Message-ID: <4091FCCC-AEEB-4348-952C-F6BCCBBDB859@oracle.com> sun/security/provider/ConfigFile.java: private boolean expandProp = true; ... String expand = Security.getProperty("policy.expandProperties"); if (expand == null) { expand = System.getProperty("policy.expandProperties"); } if ("false".equals(expand)) { expandProp = false; } sun/security/provider/PolicyFile.java: expandProperties = "true".equalsIgnoreCase (Security.getProperty("policy.expandProperties")); -> default false So it looks like the default value for the property are different in these 2 places. Of course, it also happens that in java.security there is no "Comment out this line" for "policy.expandProperties". But this still feels uncomfortable. Thanks, Max > On Feb 5, 2020, at 11:31 PM, Sean Mullan wrote: > > I added a sentence about policy.expandProperties to the ConfigFile class description. In the java.security file, I also clarified that setting the policy.allowSystemProperty to false (in addition to commenting it out) would disable the feature. > > New webrev at http://cr.openjdk.java.net/~mullan/webrevs/8191395/webrev.01/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8238483 > > --Sean > > On 1/31/20 10:42 AM, Sean Mullan wrote: >> On 1/30/20 7:27 PM, Weijun Wang wrote: >>> Looks fine. Does this require a CSR? >> Hmm, I was on the fence about that. ConfigFile already mentions policy.allowSystemProperty in the class description [1], so I think in this case, we are just improving the documentation. >> I can't find any JAAS reference to policy.expandProperties though. I suppose we should file one then since this would be the first time it is documented. >> Let me draft up a CSR and reply back later. >> --Sean >> [1] https://download.java.net/java/early_access/jdk14/docs/api/jdk.security.auth/com/sun/security/auth/login/ConfigFile.html >>> >>> Thanks, >>> Max >>> >>>> On Jan 31, 2020, at 3:18 AM, Sean Mullan wrote: >>>> >>>> Please review this small change to the documentation of these two security properties. >>>> >>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191395/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8191395 >>>> >>>> Thanks, >>>> Sean >>> From gnu.andrew at redhat.com Thu Feb 6 05:40:57 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 6 Feb 2020 05:40:57 +0000 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: Message-ID: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> On 04/02/2020 23:24, Bradford Wetmore wrote: > I added a simple PSS 32-bit windows crash fix, which was previously > reviewed in security-dev earlier today [0]. > > ??? 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION > > The PSS webrev is now at version .01. > > Otherwise, everything is identical from last week's request below.? The > ALPN remains at version .00. > > [0] > https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021203.html > > > ---begin--- > > Good morning/afternoon/evening/night, > > As announced on jdk8u-dev[1], there is a Maintenance Release in progress > for Java SE 8 (i.e. JSR 337) [2] to include two security features > important for TLS 1.3: > > 1.? Application-Layer Protocol Negotiation (ALPN) [3][4] > 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme > (RSASSA-PSS) [5][6] > > As mentioned in [1], if it wasn't too much work then we would like to > contribute the changes required by this MR to the next appropriate > OpenJDK 8 release, most likely 8u252. > > Now that the MR3 balloting successfully concluded last night, I'd like > to make that happen, and move the code into review. > > The code is essentially what was reviewed for 8u41[7][8] and internally > for what we expect to be in Oracle's 8u251 JDK, except the code in this > review is based on the current JDK 8u workspace.? We also included code > to allow the Windows platform to use PSS natively. > > The specific bugs/backports (requested by the JDK8u maintainers) follow: > > ALPN: > ===== > 8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation > Extension (Java SE 8) > 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation > Extension > 8170282: Enable ALPN parameters to be supplied during the TLS handshake > 8145849: ALPN: getHandshakeApplicationProtocol() always return null > 8158978: ALPN not working when values are set directly on a SSLServerSocket > 8171443: (spec) An ALPN callback function may also ignore ALPN > > RSASSA-PSS: > =========== > 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) > 8175029: StackOverflowError in X509CRL and > X509Certificate.verify(PublicKey, Provider) > 8146293: Add support for RSASSA-PSS Signature algorithm > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI > 8205720: KeyFactory#getKeySpec and translateKey throws > NullPointerException with Invalid key > 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException > when not initialized > 8213009: Refactoring existing SunMSCAPI classes > 8213010: Supporting keys created with certmgr.exe > 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE > validation fails > 8215694: keytool cannot generate RSASSA-PSS certificates > 8221407: Windows 32bit build error in libsunmscapi/security.cpp > 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange > 8223003: SunMSCAPI keys are not cleaned up > 8223063: Support CNG RSA keys > 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with > RSASSA-PSS support > 8225180: SignedObject with invalid Key not throwing the > InvalidKeyException in Windows > 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as > AlgorithmId > Reviewed-by: valeriep, weijun, coffeys, pkoppula > > Here are the reviews: > > 1.? ALPN: > ???? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN > > 2.? RSASSA-PSS: > ???? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS > > Most of these changes are direct copies of the changesets applied > in JDK 9+, but adjusted for JDK 8u. > > Also, truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were > added to the SUN Provider to support the corresponding truncated > RSASSA-PSS Signatures. > > Thanks, > > Brad > > [1] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html > [2] https://www.jcp.org/en/jsr/detail?id=337 > [3] https://bugs.openjdk.java.net/browse/JDK-8230977 > [4] https://bugs.openjdk.java.net/browse/JDK-8233417 > [5] https://bugs.openjdk.java.net/browse/JDK-8230978 > [6] https://bugs.openjdk.java.net/browse/JDK-8233418 > [7] > https://mail.openjdk.java.net/pipermail/security-dev/2019-November/020900.html > > [8] http://hg.openjdk.java.net/jdk8u/jdk8u41/ > > Hi Brad, First of all, thanks again for posting these patches and also for the comprehensive list of issues for both of them. They pretty much matched up with what I saw when reviewing the patches. The ALPN one looks pretty clean. My only concern there is the use of "@since 8". Should this not be a reference to the maintenance release, as these methods were not part of 8 at GA? Same applies to the usage in the second patch too. With the RSA-PSS patch, it's hard to tell what's going on with the MSCAPI code, because they appear as new files in the patch. Why was it necessary to bring in JDK-8213009? I don't see an obvious reason for this. I know from the fix request on that bug for 11u that it's a dependency of 8213010, but again, it's not obvious why that's required here either. Some more details on why some of the less obvious bugs are required would be helpful here. If the refactoring is necessary, a Git-style patch which shows the moves as renames (hg diff -g) would help, so we can see what is actually being changed in these files. As you say, the RSA-PSS patch brings in truncated MessageDigests which are part of "8051408: NIST SP 800-90A SecureRandom implementations". It would be good if the summary field could be used to say "Contains truncated MessageDigests from JDK-8051408", so that it then shows up if someone is considering 8051408 at a later date. Otherwise, looks good. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From barath.pg67 at gmail.com Thu Feb 6 06:05:11 2020 From: barath.pg67 at gmail.com (BHARATH P G) Date: Thu, 6 Feb 2020 11:35:11 +0530 Subject: Socket read timeout resulting in fatal tls alert in jdk 11 In-Reply-To: References: <92bdded0-4627-cbed-9cd3-5f55c264965e@oracle.com> Message-ID: Thanks Xuelei, can you share with us any tracking bug related to this? I also would like to highlight that both oracle JDK11 and OpenJDK 11 are behaving the same way, we confirmed it with multiple runs on both oracle JDK11 and openjdk11, i.e tls fatal alert raised on ssl socket read timeout exception, and this wasn't the behavior with jdk8. Thanks, Bharath On Mon, 3 Feb 2020 at 22:39, Xuelei Fan wrote: > On 2/3/2020 1:30 AM, BHARATH P G wrote: > > Sorry we attached logs from OracleJRE11 run. > > > > We are attaching here logs from openjdk 11. > > > Thanks! > > > Looks like there is a gap between openjdk11 and OracleJDK11, in > > openjdk11 we could see tls1.2 alert(unexpected_message) after socket > > read timeout. > > > I agreed there is a gap. OpenJDK may want to fix the issue. > > Regards, > Xuelei > > > Thanks, > > Bharath > > > > On Mon, 3 Feb 2020 at 11:46, Xuelei Fan > > wrote: > > > > Per the attached debug log, it looks like that the exception is > closure > > failure, but not the timeout exception. Did I missed something? > > > > Thanks & Regards, > > Xuelei > > > > On 2/2/2020 9:48 PM, BHARATH P G wrote: > > > Hi, > > > > > > We are hitting following issue with openjdk11. > > > > > > Issue description: > > > > > > If there is socket read timeout exception, jdk11 is sending tls > > fatal > > > alert causing client to close the socket connection. This was not > > the > > > behavior with jdk8. > > > > > > Below is the ssl debug logs with jdk11(complete log is available > > in the > > > attachment): > > > > > > javax.net.ssl|ERROR|01|main|2020-01-31 11:59:34.843 > > > IST|TransportContext.java:312|Fatal (UNEXPECTED_MESSAGE): Read > > timed out ( > > > > > > "throwable" : { > > > > > > java.net .SocketTimeoutException: Read timed out > > > > > > at java.base/java.net > > .SocketInputStream.socketRead0(Native Method) > > > > > > at > > > java.base/java.net > > >.SocketInputStream.socketRead(SocketInputStream.java:115) > > > > > > at > > > java.base/java.net > > .SocketInputStream.read(SocketInputStream.java:168) > > > > > > at > > > java.base/java.net > > .SocketInputStream.read(SocketInputStream.java:140) > > > > > > at > > > > > > java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448) > > > > > > at > > > > > > java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165) > > > > > > at > > > > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > > > > > > at > > > > > > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) > > > > > > at > > > > > > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) > > > > > > at > > > > > > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > > > > > > at > > > > > > java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716) > > > > > > at > > > > > > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:799) > > > > > > at > > > > java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) > > > > > > at > > > > java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) > > > > > > at > > java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) > > > > > > at > > > java.base/java.io > > .InputStreamReader.read(InputStreamReader.java:185) > > > > > > at java.base/java.io > > .BufferedReader.fill(BufferedReader.java:161) > > > > > > at > > > java.base/java.io > > .BufferedReader.readLine(BufferedReader.java:326) > > > > > > at > > > java.base/java.io > > .BufferedReader.readLine(BufferedReader.java:392) > > > > > > at SimpleClient.startClient(SimpleClient.java:29) > > > > > > at SimpleClient.main(SimpleClient.java:36)} > > > > > > ) > > > > > > javax.net.ssl|DEBUG|01|main|2020-01-31 11:59:34.846 > > > IST|SSLSocketOutputRecord.java:71|WRITE: TLS12 > > > alert(unexpected_message), length = 2 > > > > > > For reference I have attached sample client and server to repro > the > > > issue and also ssl debug in the attachment. > > > > > > Thanks, > > > > > > Bharath > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Feb 6 21:40:53 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 6 Feb 2020 16:40:53 -0500 Subject: [15] RFR: 8191395: policy.allowSystemProperty and policy.expandProperties also apply to JAAS configurations In-Reply-To: <4091FCCC-AEEB-4348-952C-F6BCCBBDB859@oracle.com> References: <30c2ed46-52ac-613d-dcaa-bcf166e5b295@oracle.com> <387D67EA-1C90-4658-95E3-F58B425CEA86@oracle.com> <4091FCCC-AEEB-4348-952C-F6BCCBBDB859@oracle.com> Message-ID: <7c601c8a-5b6e-eede-fe87-88502130d4df@oracle.com> On 2/5/20 8:53 PM, Weijun Wang wrote: > sun/security/provider/ConfigFile.java: > > private boolean expandProp = true; > > ... > > String expand = Security.getProperty("policy.expandProperties"); > if (expand == null) { > expand = System.getProperty("policy.expandProperties"); > } > if ("false".equals(expand)) { > expandProp = false; > } > > sun/security/provider/PolicyFile.java: > > expandProperties = "true".equalsIgnoreCase > (Security.getProperty("policy.expandProperties")); -> default false > > So it looks like the default value for the property are different in these 2 places. Of course, it also happens that in java.security there is no "Comment out this line" for "policy.expandProperties". But this still feels uncomfortable. Good point, we should document the default values. I think trying to change them to be consistent at this point is not worth it, so I have added some wording to the java.security file noting that the defaults are different for policy and login files, and I also made some minor changes to the wording in other places. I also updated ConfigFile to state what the default value is. Let me know what you think. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191395/webrev.02/ --Sean From valerie.peng at oracle.com Thu Feb 6 23:13:34 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 6 Feb 2020 15:13:34 -0800 Subject: [15] RFR 8236512: PKCS11 Connection closed after Cipher.doFinal and NoPadding In-Reply-To: References: Message-ID: <3c3b8235-3556-41a6-cf8e-23022378984d@oracle.com> Ping~ Submitter confirmed that the current webrev addresses the issue. Thanks, Valerie On 1/24/2020 2:01 PM, Valerie Peng wrote: > Hi, > > Can someone help reviewing this? This can only be reproduced with 3rd > party HSM vendor, so there is no new regression test. To address this, > I removed the killSession() calls from PKCS11 Cipher, Mac, Signature > services and reverted to old behavior of finishing off the current > operation as a way of resetting the current object. Also fixed one > place missing the reset() call and another one with redundant reset() > call so the key id counting matches up. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236512 > > Webrev: http://cr.openjdk.java.net/~valeriep/8236512/webrev.00/ > > Mach5 run is clean. > > Thanks, > Valerie From valerie.peng at oracle.com Fri Feb 7 03:02:21 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 6 Feb 2020 19:02:21 -0800 Subject: [15] RFR 8238448: RSASSA-PSS signature verification fail when using certain odd key sizes Message-ID: <6aaa62f1-5373-65c8-c3aa-76cfa62a2518@oracle.com> Anyone can help reviewing this? There is a bug in RSASSA-PSS signature verification when the key size is multiples of 8 plus 1 bit. The verification on the encoded message is off by one and verification failed unexpectedly. I added a check and adjusted the starting index for the verification. I added 1025 and 2049 to existing PSS tests to verify this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8238448 Webrev: http://cr.openjdk.java.net/~valeriep/8238448/webrev.00/ Mach5 run is clean. Thanks, Valerie From xuelei.fan at oracle.com Fri Feb 7 06:14:30 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 6 Feb 2020 22:14:30 -0800 Subject: [15] RFR 8238448: RSASSA-PSS signature verification fail when using certain odd key sizes In-Reply-To: <6aaa62f1-5373-65c8-c3aa-76cfa62a2518@oracle.com> References: <6aaa62f1-5373-65c8-c3aa-76cfa62a2518@oracle.com> Message-ID: <27352882-43c2-6303-658d-9b40f5d43351@oracle.com> On 2/6/2020 7:02 PM, Valerie Peng wrote: > Anyone can help reviewing this? > > There is a bug in RSASSA-PSS signature verification when the key size is > multiples of 8 plus 1 bit. The verification on the encoded message is > off by one and verification failed unexpectedly. I added a check and > adjusted the starting index for the verification. I added 1025 and 2049 > to existing PSS tests to verify this fix. > Hm, is there really use of 1025/2049 bits RSA key in practice. But it's a nice catch! > Bug: https://bugs.openjdk.java.net/browse/JDK-8238448 > > Webrev: http://cr.openjdk.java.net/~valeriep/8238448/webrev.00/ > It looks good to me. Xuelei > Mach5 run is clean. > > Thanks, > Valerie From xuelei.fan at oracle.com Fri Feb 7 06:55:29 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 6 Feb 2020 22:55:29 -0800 Subject: [15] RFR 8236512: PKCS11 Connection closed after Cipher.doFinal and NoPadding In-Reply-To: <3c3b8235-3556-41a6-cf8e-23022378984d@oracle.com> References: <3c3b8235-3556-41a6-cf8e-23022378984d@oracle.com> Message-ID: Hi Valerie, The overall update looks straightforward to me. But I'm not sure the update that why you want to ignore cancel operation exception for verification/decryption? Thanks, Xuelei On 2/6/2020 3:13 PM, Valerie Peng wrote: > Ping~ > > Submitter confirmed that the current webrev addresses the issue. > > Thanks, > > Valerie > > On 1/24/2020 2:01 PM, Valerie Peng wrote: >> Hi, >> >> Can someone help reviewing this? This can only be reproduced with 3rd >> party HSM vendor, so there is no new regression test. To address this, >> I removed the killSession() calls from PKCS11 Cipher, Mac, Signature >> services and reverted to old behavior of finishing off the current >> operation as a way of resetting the current object. Also fixed one >> place missing the reset() call and another one with redundant reset() >> call so the key id counting matches up. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8236512 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8236512/webrev.00/ >> >> Mach5 run is clean. >> >> Thanks, >> Valerie From sha.jiang at oracle.com Fri Feb 7 10:51:15 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 7 Feb 2020 18:51:15 +0800 Subject: RFR[15] 8238677: java/net/httpclient/ssltest/CertificateTest.java should not specify TLS version Message-ID: <2910eb99-d8cd-84a5-3eab-049752923baf@oracle.com> Hi, java/net/httpclient/ssltest/CertificateTest.java shouldn't use a specific TLS version. And it would be better not to use binary key store files. Since DSA is not supported by TLSv1.3, this fix also updates the certificates to use RSA. Webrev: http://cr.openjdk.java.net/~jjiang/8238677/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8238677 Best regards, John Jiang From daniel.fuchs at oracle.com Fri Feb 7 11:29:13 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 7 Feb 2020 11:29:13 +0000 Subject: RFR[15] 8238677: java/net/httpclient/ssltest/CertificateTest.java should not specify TLS version In-Reply-To: <2910eb99-d8cd-84a5-3eab-049752923baf@oracle.com> References: <2910eb99-d8cd-84a5-3eab-049752923baf@oracle.com> Message-ID: Hi John, Looks good to me. Thanks for taking care of this! I'm glad to see the binary files go away :-) Would it be possible to include a comment in Cert.java that contains the command you used to generate the certificates? That will be a great help to future maintainers if the certificates ever needs to be re-generated (e.g. to update the expiry date etc...) best regards, -- daniel Disclaimer: I am not an expert in ssl/security On 07/02/2020 10:51, sha.jiang at oracle.com wrote: > Hi, > java/net/httpclient/ssltest/CertificateTest.java shouldn't use a > specific TLS version. > And it would be better not to use binary key store files. > Since DSA is not supported by TLSv1.3, this fix also updates the > certificates to use RSA. > > Webrev: http://cr.openjdk.java.net/~jjiang/8238677/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8238677 > > Best regards, > John Jiang > From prasadarao.koppula at oracle.com Fri Feb 7 11:32:47 2020 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Fri, 7 Feb 2020 03:32:47 -0800 (PST) Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role Message-ID: <939a2142-60b6-49e8-873f-3f3888293342@default> Hi, Could you please review this patch. Default server role mode was flipped in SSLEngine, to client role mode as part of SSL package code refactoring for TLSv1.3, this patch flips back default client role to server role in SSLEngine. webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8237474 CSR: https://bugs.openjdk.java.net/browse/JDK-8238593 Thanks, Prasad.K -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Fri Feb 7 12:18:19 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 7 Feb 2020 20:18:19 +0800 Subject: RFR[15] 8238677: java/net/httpclient/ssltest/CertificateTest.java should not specify TLS version In-Reply-To: References: <2910eb99-d8cd-84a5-3eab-049752923baf@oracle.com> Message-ID: Hi Daniel, On 2020/2/7 19:29, Daniel Fuchs wrote: > Hi John, > > Looks good to me. Thanks for taking care of this! > I'm glad to see the binary files go away :-) Thanks for your review! > > Would it be possible to include a comment in Cert.java that contains > the command you used to generate the certificates? > > That will be a great help to future maintainers if the certificates > ever needs to be re-generated (e.g. to update the expiry date > etc...) I'll do that. Best regards, John Jiang > > best regards, > > -- daniel > > Disclaimer: I am not an expert in ssl/security > > > On 07/02/2020 10:51, sha.jiang at oracle.com wrote: >> Hi, >> java/net/httpclient/ssltest/CertificateTest.java shouldn't use a >> specific TLS version. >> And it would be better not to use binary key store files. >> Since DSA is not supported by TLSv1.3, this fix also updates the >> certificates to use RSA. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8238677/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8238677 >> >> Best regards, >> John Jiang >> > From sean.coffey at oracle.com Fri Feb 7 12:49:41 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 7 Feb 2020 12:49:41 +0000 Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role In-Reply-To: <939a2142-60b6-49e8-873f-3f3888293342@default> References: <939a2142-60b6-49e8-873f-3f3888293342@default> Message-ID: <3d16220c-f3da-4baa-0e4f-28db9a61177c@oracle.com> Looks ok to me Prasad. This may also be worthy of highlighting via release note. You might be able to expand test coverage to capture the TLSContext scenario. Something like below patch might work ? --- a/test/jdk/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java +++ b/test/jdk/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -28,7 +28,7 @@ /* * @test - * @bug 4980882 8207250 + * @bug 4980882 8207250 8237474 * @summary SSLEngine should enforce setUseClientMode * @run main/othervm EngineEnforceUseClientMode * @author Brad R. Wetmore @@ -87,6 +87,9 @@ * Note, these are not initialized to client/server */ ssle3 = sslc.createSSLEngine(); + if (ssle3.getUseClientMode()) { + throw new RuntimeException("Expected default role to be server"); + } ssle4 = sslc.createSSLEngine(); ssle5 = sslc.createSSLEngine(); } Regards, Sean. On 07/02/20 11:32, Prasadrao Koppula wrote: > > Hi, > > Could you please review this patch. Default server role mode was > flipped in SSLEngine, to client role mode as part of SSL package code > refactoring for TLSv1.3, this patch flips back default client role to > server role in SSLEngine. > > webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/ > > > issue: https://bugs.openjdk.java.net/browse/JDK-8237474 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8238593 > > Thanks, > > Prasad.K > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Feb 7 13:09:44 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 7 Feb 2020 21:09:44 +0800 Subject: [15] RFR: 8191395: policy.allowSystemProperty and policy.expandProperties also apply to JAAS configurations In-Reply-To: <7c601c8a-5b6e-eede-fe87-88502130d4df@oracle.com> References: <30c2ed46-52ac-613d-dcaa-bcf166e5b295@oracle.com> <387D67EA-1C90-4658-95E3-F58B425CEA86@oracle.com> <4091FCCC-AEEB-4348-952C-F6BCCBBDB859@oracle.com> <7c601c8a-5b6e-eede-fe87-88502130d4df@oracle.com> Message-ID: <58D248A4-1804-46E8-8A04-6731E7B903BA@oracle.com> This is very complete. Thanks, Max > On Feb 7, 2020, at 5:40 AM, Sean Mullan wrote: > > On 2/5/20 8:53 PM, Weijun Wang wrote: >> sun/security/provider/ConfigFile.java: >> private boolean expandProp = true; >> ... >> String expand = Security.getProperty("policy.expandProperties"); >> if (expand == null) { >> expand = System.getProperty("policy.expandProperties"); >> } >> if ("false".equals(expand)) { >> expandProp = false; >> } >> sun/security/provider/PolicyFile.java: >> expandProperties = "true".equalsIgnoreCase >> (Security.getProperty("policy.expandProperties")); -> default false >> So it looks like the default value for the property are different in these 2 places. Of course, it also happens that in java.security there is no "Comment out this line" for "policy.expandProperties". But this still feels uncomfortable. > > Good point, we should document the default values. I think trying to change them to be consistent at this point is not worth it, so I have added some wording to the java.security file noting that the defaults are different for policy and login files, and I also made some minor changes to the wording in other places. I also updated ConfigFile to state what the default value is. Let me know what you think. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191395/webrev.02/ > > --Sean From prasadarao.koppula at oracle.com Fri Feb 7 14:28:24 2020 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Fri, 7 Feb 2020 06:28:24 -0800 (PST) Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role In-Reply-To: <3d16220c-f3da-4baa-0e4f-28db9a61177c@oracle.com> References: <939a2142-60b6-49e8-873f-3f3888293342@default> <3d16220c-f3da-4baa-0e4f-28db9a61177c@oracle.com> Message-ID: <3ec8144f-cb18-4e8d-8da2-38e79bcf6237@default> Thanks for review Sean, I will add test changes. ? Thanks, Prasad.K ? From: Se?n Coffey Sent: Friday, February 7, 2020 6:20 PM To: Prasadrao Koppula ; security-dev at openjdk.java.net Subject: Re: RFR[jdk] 8237474: Default SSLEngine should create in server role ? Looks ok to me Prasad. This may also be worthy of highlighting via release note. You might be able to expand test coverage to capture the TLSContext scenario. Something like below patch might work ? ? --- a/test/jdk/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java +++ b/test/jdk/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2004, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -28,7 +28,7 @@ ? ?/* ? * @test - * @bug 4980882 8207250 + * @bug 4980882 8207250 8237474 ? * @summary SSLEngine should enforce setUseClientMode ? * @run main/othervm EngineEnforceUseClientMode ? * @author Brad R. Wetmore @@ -87,6 +87,9 @@ ????????? * Note, these are not initialized to client/server ????????? */ ???????? ssle3 = sslc.createSSLEngine(); +??????? if (ssle3.getUseClientMode()) { +??????????? throw new RuntimeException("Expected default role to be server"); +??????? } ???????? ssle4 = sslc.createSSLEngine(); ???????? ssle5 = sslc.createSSLEngine(); ???? } Regards, Sean. On 07/02/20 11:32, Prasadrao Koppula wrote: Hi, ? Could you please review this patch. Default server role mode was flipped in SSLEngine, to client role mode as part of SSL package code refactoring for TLSv1.3, this patch flips back default client role to server role in SSLEngine. ? webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkoppula/8237474/webrev.00/"http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8237474 CSR: ?https://bugs.openjdk.java.net/browse/JDK-8238593 ? ? Thanks, Prasad.K ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Feb 7 15:02:17 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 7 Feb 2020 15:02:17 +0000 Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role In-Reply-To: <3ec8144f-cb18-4e8d-8da2-38e79bcf6237@default> References: <939a2142-60b6-49e8-873f-3f3888293342@default> <3d16220c-f3da-4baa-0e4f-28db9a61177c@oracle.com> <3ec8144f-cb18-4e8d-8da2-38e79bcf6237@default> Message-ID: <0a334ab5-77b7-63df-ce42-52716b660caa@oracle.com> Hi Prasad, On 07/02/2020 14:28, Prasadrao Koppula wrote: > Thanks for review Sean, I will add test changes. Not a review - but I just wanted to double check that you have run the :jdk_net tests too - especially the httpclient tests (which are part of :jdk_net) as the httpclient is a heavy user of TLS 1.3 and SSLEngine :-) best regards, -- daniel From valerie.peng at oracle.com Fri Feb 7 22:49:42 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 7 Feb 2020 14:49:42 -0800 Subject: [15] RFR 8236512: PKCS11 Connection closed after Cipher.doFinal and NoPadding In-Reply-To: References: <3c3b8235-3556-41a6-cf8e-23022378984d@oracle.com> Message-ID: <3a28d967-b0ae-8861-ecc9-d568ff972507@oracle.com> In general, cancelOperation() is not needed if the object went through the whole cycle, e.g. Cipher object and init/update/doFinal(...) calls. Same goes for signature object if it's called to verify the bytes. The cancelOperation is often called when the supplied data is incomplete or even lacking, say an Cipher object is initialized and updated with only part of the data and the operation is aborted and caller then re-init it again with a different key. Since we cannot simply kill the current session, we need to cancel the current operation by continuing calling doFinal() so the underlying native session will handle another init call. Thus, we have to ignore exceptions for cases where failure is somewhat expected. Hope it's clear? Valerie On 2/6/2020 10:55 PM, Xuelei Fan wrote: > Hi Valerie, > > The overall update looks straightforward to me.? But I'm not sure the > update that why you want to ignore cancel operation exception for > verification/decryption? > > Thanks, > Xuelei > > On 2/6/2020 3:13 PM, Valerie Peng wrote: >> Ping~ >> >> Submitter confirmed that the current webrev addresses the issue. >> >> Thanks, >> >> Valerie >> >> On 1/24/2020 2:01 PM, Valerie Peng wrote: >>> Hi, >>> >>> Can someone help reviewing this? This can only be reproduced with >>> 3rd party HSM vendor, so there is no new regression test. To address >>> this, I removed the killSession() calls from PKCS11 Cipher, Mac, >>> Signature services and reverted to old behavior of finishing off the >>> current operation as a way of resetting the current object. Also >>> fixed one place missing the reset() call and another one with >>> redundant reset() call so the key id counting matches up. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236512 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8236512/webrev.00/ >>> >>> Mach5 run is clean. >>> >>> Thanks, >>> Valerie From bradford.wetmore at oracle.com Sat Feb 8 00:10:53 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 7 Feb 2020 16:10:53 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> References: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> Message-ID: On 2/5/2020 9:40 PM, Andrew John Hughes wrote:> First of all, thanks again for posting these patches and also for the > comprehensive list of issues for both of them. They pretty much matched > up with what I saw when reviewing the patches Great. > The ALPN one looks pretty clean. My only concern there is the use of > "@since 8". Should this not be a reference to the maintenance release, > as these methods were not part of 8 at GA? Same applies to the usage in > the second patch too. I originally had this as "@since 8 MR 3" but during internal review it was requested to use @since 8 instead. This is what was presented/voted during the MR phase. > With the RSA-PSS patch, it's hard to tell what's going on with the > MSCAPI code, because they appear as new files in the patch. Why was it > necessary to bring in JDK-8213009? I don't see an obvious reason for > this. JDK-8213009 was mainly a refactor of the MSCAPI code to enhance the code layout, and to a lesser degree to better support Windows-native PSS calls using CNG (MS Windows Crypto Next Generation). The SunMSCAPI provider is a mix of mostly CAPI (Windows Crypto API) and a few CNG calls when CAPI couldn't support everything needed. The SunMSCAPI changes that followed would take significant effort to extricate these reorganization changes when backporting later changes (e.g. jdk/jdk). We could have forward ported/merged the 8u41 code into OpenJDK 8, but unfortunately I haven't been given a lot of cycles for OpenJDK code. > dependency of 8213010, but again, it's not obvious why that's required > here either. Some more details on why some of the less obvious bugs are > required would be helpful here. Ok, I've added details to a comment in JDK-8230978. > If the refactoring is necessary, a > Git-style patch which shows the moves as renames (hg diff -g) would > help, so we can see what is actually being changed in these files. I'm a bit confused, isn't the webrev already showing this: http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/ ---begin--- ...deleted... * src/windows/classes/sun/security/mscapi/CKey.java* /(was src/windows/classes/sun/security/mscapi/Key.java)/ ///138 lines changed: 54 ins; 64 del; 20 mod; 81 unchg/ ...deleted... * src/windows/classes/sun/security/mscapi/CSignature.java /(was src/windows/classes/sun/security/mscapi/RSASignature.java)/ ///676 lines changed: 507 ins; 77 del; 92 mod; 355 unchg/ ---end--- Looking at the index.html and subsequent "Frame" for this file, I can see both the rename and the old/new code side-by-side. > As you say, the RSA-PSS patch brings in truncated MessageDigests which > are part of "8051408: NIST SP 800-90A SecureRandom implementations". It > would be good if the summary field could be used to say "Contains > truncated MessageDigests from JDK-8051408", so that it then shows up if > someone is considering 8051408 at a later date There are several comments to make which won't fit in the summary field which is supposed to only be one short line [0]. Instead, I have added several items into the comment for JDK-8230978, which is the main umbrella bug for the PSS work, and I will add: Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and OpenJDK 8u to the changeset, which currently reads: ---begin--- 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) 8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) 8146293: Add support for RSASSA-PSS Signature algorithm 8205445: Add RSASSA-PSS Signature support to SunMSCAPI 8205720: KeyFactory#getKeySpec and translateKey throws NullPointerException with Invalid key 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized 8213009: Refactoring existing SunMSCAPI classes 8213010: Supporting keys created with certmgr.exe 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails 8215694: keytool cannot generate RSASSA-PSS certificates 8221407: Windows 32bit build error in libsunmscapi/security.cpp 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange 8223003: SunMSCAPI keys are not cleaned up 8223063: Support CNG RSA keys 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support 8225180: SignedObject with invalid Key not throwing the InvalidKeyException in Windows 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as AlgorithmId 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and OpenJDK 8u Reviewed-by: valeriep, weijun, coffeys, pkoppula ---end--- Did you want me to add you as a reviewer? > Otherwise, looks good. > > Thanks, Thanks, Brad [0] https://openjdk.java.net/guide/producingChangeset.html From xuelei.fan at oracle.com Sat Feb 8 00:22:17 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 7 Feb 2020 16:22:17 -0800 Subject: [15] RFR 8236512: PKCS11 Connection closed after Cipher.doFinal and NoPadding In-Reply-To: <3a28d967-b0ae-8861-ecc9-d568ff972507@oracle.com> References: <3c3b8235-3556-41a6-cf8e-23022378984d@oracle.com> <3a28d967-b0ae-8861-ecc9-d568ff972507@oracle.com> Message-ID: Got it. Thanks! I have no more comment. Xuelei On 2/7/2020 2:49 PM, Valerie Peng wrote: > > In general, cancelOperation() is not needed if the object went through > the whole cycle, e.g. Cipher object and init/update/doFinal(...) calls. > Same goes for signature object if it's called to verify the bytes. > > The cancelOperation is often called when the supplied data is incomplete > or even lacking, say an Cipher object is initialized and updated with > only part of the data and the operation is aborted and caller then > re-init it again with a different key. Since we cannot simply kill the > current session, we need to cancel the current operation by continuing > calling doFinal() so the underlying native session will handle another > init call. Thus, we have to ignore exceptions for cases where failure is > somewhat expected. > > Hope it's clear? > > Valerie > > On 2/6/2020 10:55 PM, Xuelei Fan wrote: >> Hi Valerie, >> >> The overall update looks straightforward to me.? But I'm not sure the >> update that why you want to ignore cancel operation exception for >> verification/decryption? >> >> Thanks, >> Xuelei >> >> On 2/6/2020 3:13 PM, Valerie Peng wrote: >>> Ping~ >>> >>> Submitter confirmed that the current webrev addresses the issue. >>> >>> Thanks, >>> >>> Valerie >>> >>> On 1/24/2020 2:01 PM, Valerie Peng wrote: >>>> Hi, >>>> >>>> Can someone help reviewing this? This can only be reproduced with >>>> 3rd party HSM vendor, so there is no new regression test. To address >>>> this, I removed the killSession() calls from PKCS11 Cipher, Mac, >>>> Signature services and reverted to old behavior of finishing off the >>>> current operation as a way of resetting the current object. Also >>>> fixed one place missing the reset() call and another one with >>>> redundant reset() call so the key id counting matches up. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236512 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8236512/webrev.00/ >>>> >>>> Mach5 run is clean. >>>> >>>> Thanks, >>>> Valerie From valerie.peng at oracle.com Sat Feb 8 00:59:35 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 7 Feb 2020 16:59:35 -0800 Subject: [15] RFR 8238448: RSASSA-PSS signature verification fail when using certain odd key sizes In-Reply-To: <27352882-43c2-6303-658d-9b40f5d43351@oracle.com> References: <6aaa62f1-5373-65c8-c3aa-76cfa62a2518@oracle.com> <27352882-43c2-6303-658d-9b40f5d43351@oracle.com> Message-ID: Thanks for the review~ The issue is reported externally, there is the answer to your question. ;) Valerie On 2/6/2020 10:14 PM, Xuelei Fan wrote: > On 2/6/2020 7:02 PM, Valerie Peng wrote: >> Anyone can help reviewing this? >> >> There is a bug in RSASSA-PSS signature verification when the key size >> is multiples of 8 plus 1 bit. The verification on the encoded message >> is off by one and verification failed unexpectedly. I added a check >> and adjusted the starting index for the verification. I added 1025 >> and 2049 to existing PSS tests to verify this fix. >> > Hm, is there really use of 1025/2049 bits RSA key in practice. But > it's a nice catch! > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8238448 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8238448/webrev.00/ >> > It looks good to me. > > Xuelei > >> Mach5 run is clean. >> >> Thanks, >> Valerie From sha.jiang at oracle.com Sat Feb 8 07:46:13 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Sat, 8 Feb 2020 15:46:13 +0800 Subject: RFR[15] 8238677: java/net/httpclient/ssltest/CertificateTest.java should not specify TLS version In-Reply-To: References: <2910eb99-d8cd-84a5-3eab-049752923baf@oracle.com> Message-ID: Hi Daniel, >> >> Would it be possible to include a comment in Cert.java that contains >> the command you used to generate the certificates? >> >> That will be a great help to future maintainers if the certificates >> ever needs to be re-generated (e.g. to update the expiry date >> etc...) > > I'll do that. Please review this updated webrev: http://cr.openjdk.java.net/~jjiang/8238677/webrev.01/ The script, exactly gen-certs.sh, can be used to generate the certs. Best regards, John Jiang > > Best regards, > John Jiang > >> >> best regards, >> >> -- daniel >> >> Disclaimer: I am not an expert in ssl/security >> >> >> On 07/02/2020 10:51, sha.jiang at oracle.com wrote: >>> Hi, >>> java/net/httpclient/ssltest/CertificateTest.java shouldn't use a >>> specific TLS version. >>> And it would be better not to use binary key store files. >>> Since DSA is not supported by TLSv1.3, this fix also updates the >>> certificates to use RSA. >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8238677/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8238677 >>> >>> Best regards, >>> John Jiang >>> >> From prasadarao.koppula at oracle.com Mon Feb 10 12:32:11 2020 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Mon, 10 Feb 2020 04:32:11 -0800 (PST) Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role In-Reply-To: <0a334ab5-77b7-63df-ce42-52716b660caa@oracle.com> References: <939a2142-60b6-49e8-873f-3f3888293342@default> <3d16220c-f3da-4baa-0e4f-28db9a61177c@oracle.com> <3ec8144f-cb18-4e8d-8da2-38e79bcf6237@default> <0a334ab5-77b7-63df-ce42-52716b660caa@oracle.com> Message-ID: > -----Original Message----- > From: Daniel Fuchs > Sent: Friday, February 7, 2020 8:32 PM > To: Prasadrao Koppula ; Sean Coffey > ; security-dev at openjdk.java.net > Subject: Re: RFR[jdk] 8237474: Default SSLEngine should create in server role > > Hi Prasad, > > On 07/02/2020 14:28, Prasadrao Koppula wrote: > > Thanks for review Sean, I will add test changes. > > Not a review - but I just wanted to double check that you have run the > :jdk_net tests too - especially the httpclient tests (which are part of :jdk_net) > as the httpclient is a heavy user of TLS 1.3 and SSLEngine :-) Hi Daniel, Yes, validated tier1, tier2, tier3 test groups, and jdk_net is part of tier2. Thanks for checking on this. Thanks, Prasad.K > > best regards, > > -- daniel > From daniel.fuchs at oracle.com Mon Feb 10 14:59:47 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 10 Feb 2020 14:59:47 +0000 Subject: RFR[15] 8238677: java/net/httpclient/ssltest/CertificateTest.java should not specify TLS version In-Reply-To: References: <2910eb99-d8cd-84a5-3eab-049752923baf@oracle.com> Message-ID: <4d4b8612-c7b2-409d-1e0c-048b5c95b9ba@oracle.com> On 08/02/2020 07:46, sha.jiang at oracle.com wrote: > Hi Daniel, >> I'll do that. > Please review this updated webrev: > http://cr.openjdk.java.net/~jjiang/8238677/webrev.01/ > The script, exactly gen-certs.sh, can be used to generate the certs. Looks good to me John! best regards, -- daniel From sean.mullan at oracle.com Mon Feb 10 19:14:21 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Feb 2020 14:14:21 -0500 Subject: RFR 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB In-Reply-To: References: Message-ID: <16482275-856f-1411-34ab-034605541866@oracle.com> Looks good to me, although I would also like Valerie to review it as she has the most experience with the PKCS11 code. This issue should probably also have a release note. Have you ever written one? Thanks, Sean On 2/5/20 10:47 AM, Martin Balao wrote: > Hi, > > I'd like to propose a solution for 8238555 [1]. > > Webrev.00: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8238555/8238555.webrev.00/ > > Reproducing this issue requires manual configuration steps and there is > not a single way of doing so. The ultimate goal for a reproduction is to > initialize a SunPKCS11 provider with an NSSDB that has at least 1 > external module configured in FIPS mode, with at least 1 opened slot. > > The 8238555_manual_reproducer_v0 code [2] provides a standalone > SunPKCS11 initialization with an NSSDB that has a single internal FIPS > module configured. That's not enough though because the external module > is still missing in the NSSDB. There are two paths from this point: > > 1) Manually add an external module ("modutil" command) in FIPS mode to > the NSSDB > > 2) Run the code in the latest Fedora/CentOS/RHEL Linux release -I'm not > sure if other distributions work- where p11-kit-proxy PKCS#11 module is > automatically added to every NSSDB. If you go this way, configure FIPS > policy globally (fips-mode-setup --enable) and recompile the NSS library > to artificially expose a slot for p11-kit-proxy module [3] (use > LD_PRELOAD when running the reproducer code). If you don't want to > recompile the NSS library, manually add a module to p11-kit (such as > softHSM) so a slot is opened. > > In my own environment, I had the following output before the patch: > > Beginning test run ExternalFipsModules... > Cannot resolve artifact, please check if JIB jar is present in classpath. > nssLibDir: /usr/lib64/ > Exception in thread "main" java.lang.RuntimeException: FIPS flag set for > non-internal module: p11-kit-proxy.so, p11-kit-proxy > at > jdk.crypto.cryptoki/sun.security.pkcs11.Secmod$Module.(Secmod.java:418) > at > jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.nssGetModuleList(Native > Method) > at > jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.getModules(Secmod.java:258) > at > jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:219) > at > jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:112) > at > jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:109) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:554) > at > jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:109) > at PKCS11Test.getSunPKCS11(PKCS11Test.java:160) > at PKCS11Test.testNSS(PKCS11Test.java:580) > at PKCS11Test.main(PKCS11Test.java:220) > at PKCS11Test.main(PKCS11Test.java:196) > at ExternalFipsModules.main(ExternalFipsModules.java:31) > > And after the patch: > > Beginning test run ExternalFipsModules... > Cannot resolve artifact, please check if JIB jar is present in classpath. > nssLibDir: /usr/lib64/ > Running test with provider SunPKCS11-NSS-FIPS (security manager > disabled) ... > Provider: SunPKCS11-NSS-FIPS version 15 > TEST PASS - OK > Completed test with provider SunPKCS11-NSS-FIPS (2 ms). > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8238555 > [2] - > http://cr.openjdk.java.net/~mbalao/webrevs/8238555/8238555_manual_reproducer_v0.tar.gz > [3] - > http://cr.openjdk.java.net/~mbalao/webrevs/8238555/emulate_p11-kit-proxy_with_slots.nss.patch > From ivan.gerasimov at oracle.com Mon Feb 10 23:49:23 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 10 Feb 2020 15:49:23 -0800 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k Message-ID: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> Hello! Current implementation of the method javax.smartcardio.CardChannel.transmit() has an internal limitation on the maximum allowed amount of the transmitted data. This limitation is dictated by the maximum number of iterations to transmit data from a card:? Each iteration can transmit up to 256 bytes of data, and we have a hardcoded limit of 32 iterations. Over time, we've received requests to increase this limit, as there are occasions when the effective limit of 8k is not enough. Would you please help review a proposal:? First, it is proposed to increase the default limit of iteration to 128 (so that up to 32k of data can be transmitted);? Second, the limit of iterations is made configurable via a System property.? This limit can be increased up to 4096 (so that the total amount of transmitted data can be made up to 1m). BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ If there is an agreement on the proposal, I'll file a CSR to document a new System property. Thanks in advance! -- With kind regards, Ivan Gerasimov From mstjohns at comcast.net Tue Feb 11 00:18:18 2020 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 10 Feb 2020 19:18:18 -0500 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> References: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> Message-ID: <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: > Hello! > > Current implementation of the method > javax.smartcardio.CardChannel.transmit() has an internal limitation on > the maximum allowed amount of the transmitted data. > > This limitation is dictated by the maximum number of iterations to > transmit data from a card:? Each iteration can transmit up to 256 > bytes of data, and we have a hardcoded limit of 32 iterations. > > Over time, we've received requests to increase this limit, as there > are occasions when the effective limit of 8k is not enough. > > Would you please help review a proposal:? First, it is proposed to > increase the default limit of iteration to 128 (so that up to 32k of > data can be transmitted);? Second, the limit of iterations is made > configurable via a System property.? This limit can be increased up to > 4096 (so that the total amount of transmitted data can be made up to 1m). > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 > WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ > > If there is an agreement on the proposal, I'll file a CSR to document > a new System property. > > Thanks in advance! > Given that the maximum length for an extended APDU is 64K (65536) (hmm +7 for the header and +2 for LE), and for its return is 64K + 2 bytes,? I'm not quite sure why you'd up the number to 4096/1M - I'd set the default and fixed value to 257? (64K) and leave it at that. Mike From ivan.gerasimov at oracle.com Tue Feb 11 01:07:54 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 10 Feb 2020 17:07:54 -0800 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> References: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> Message-ID: <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> Thank you Michael! It's a good point about maximum length. Here's the updated webrev with the new System property dropped and the increased number of iterations: http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ With kind regards, Ivan On 2/10/20 4:18 PM, Michael StJohns wrote: > On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: >> Hello! >> >> Current implementation of the method >> javax.smartcardio.CardChannel.transmit() has an internal limitation >> on the maximum allowed amount of the transmitted data. >> >> This limitation is dictated by the maximum number of iterations to >> transmit data from a card:? Each iteration can transmit up to 256 >> bytes of data, and we have a hardcoded limit of 32 iterations. >> >> Over time, we've received requests to increase this limit, as there >> are occasions when the effective limit of 8k is not enough. >> >> Would you please help review a proposal:? First, it is proposed to >> increase the default limit of iteration to 128 (so that up to 32k of >> data can be transmitted);? Second, the limit of iterations is made >> configurable via a System property.? This limit can be increased up >> to 4096 (so that the total amount of transmitted data can be made up >> to 1m). >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ >> >> If there is an agreement on the proposal, I'll file a CSR to document >> a new System property. >> >> Thanks in advance! >> > Given that the maximum length for an extended APDU is 64K (65536) (hmm > +7 for the header and +2 for LE), and for its return is 64K + 2 > bytes,? I'm not quite sure why you'd up the number to 4096/1M - I'd > set the default and fixed value to 257? (64K) and leave it at that. > > Mike > > > > > -- With kind regards, Ivan Gerasimov From valerie.peng at oracle.com Tue Feb 11 02:40:24 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 10 Feb 2020 18:40:24 -0800 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> References: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> Message-ID: Hi Ivan, You removed the "=", so the actual iteration count is reduced by one. Should the iteration count be 256 or 257? If the actual count should be 257, then may be the check needs to be changed to k++ from ++k? Valerie On 2/10/2020 5:07 PM, Ivan Gerasimov wrote: > Thank you Michael! > > It's a good point about maximum length. > > Here's the updated webrev with the new System property dropped and the > increased number of iterations: > > http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ > > With kind regards, > Ivan > > > On 2/10/20 4:18 PM, Michael StJohns wrote: >> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> Current implementation of the method >>> javax.smartcardio.CardChannel.transmit() has an internal limitation >>> on the maximum allowed amount of the transmitted data. >>> >>> This limitation is dictated by the maximum number of iterations to >>> transmit data from a card:? Each iteration can transmit up to 256 >>> bytes of data, and we have a hardcoded limit of 32 iterations. >>> >>> Over time, we've received requests to increase this limit, as there >>> are occasions when the effective limit of 8k is not enough. >>> >>> Would you please help review a proposal:? First, it is proposed to >>> increase the default limit of iteration to 128 (so that up to 32k of >>> data can be transmitted);? Second, the limit of iterations is made >>> configurable via a System property. This limit can be increased up >>> to 4096 (so that the total amount of transmitted data can be made up >>> to 1m). >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ >>> >>> If there is an agreement on the proposal, I'll file a CSR to >>> document a new System property. >>> >>> Thanks in advance! >>> >> Given that the maximum length for an extended APDU is 64K (65536) >> (hmm +7 for the header and +2 for LE), and for its return is 64K + 2 >> bytes,? I'm not quite sure why you'd up the number to 4096/1M - I'd >> set the default and fixed value to 257 (64K) and leave it at that. >> >> Mike >> >> >> >> >> From weijun.wang at oracle.com Tue Feb 11 11:52:58 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Feb 2020 19:52:58 +0800 Subject: RFR 8237218: Support NIST Curves verification in java implementation Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8237218/webrev.02/ A test is added that uses a patched ECDSASignature.java that exposes how the signature is verified. BTW, I also updated ECDSASignature.java a little to accept non SunEC keys, so that I can do some interop testing. If you believe this is unnecessary I can revert the change. Thanks, Max From Roger.Riggs at oracle.com Tue Feb 11 14:46:20 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 11 Feb 2020 09:46:20 -0500 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> References: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> Message-ID: <2e34a141-3df6-054b-99e2-60a8dc99a29c@oracle.com> Hi Ivan, Raising it to work up to the spec'd limit is a good approach. Do we have a way to test this?? Aka: There should be a test. Roger On 2/10/20 8:07 PM, Ivan Gerasimov wrote: > Thank you Michael! > > It's a good point about maximum length. > > Here's the updated webrev with the new System property dropped and the > increased number of iterations: > > http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ > > With kind regards, > Ivan > > > On 2/10/20 4:18 PM, Michael StJohns wrote: >> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> Current implementation of the method >>> javax.smartcardio.CardChannel.transmit() has an internal limitation >>> on the maximum allowed amount of the transmitted data. >>> >>> This limitation is dictated by the maximum number of iterations to >>> transmit data from a card:? Each iteration can transmit up to 256 >>> bytes of data, and we have a hardcoded limit of 32 iterations. >>> >>> Over time, we've received requests to increase this limit, as there >>> are occasions when the effective limit of 8k is not enough. >>> >>> Would you please help review a proposal:? First, it is proposed to >>> increase the default limit of iteration to 128 (so that up to 32k of >>> data can be transmitted);? Second, the limit of iterations is made >>> configurable via a System property. This limit can be increased up >>> to 4096 (so that the total amount of transmitted data can be made up >>> to 1m). >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ >>> >>> If there is an agreement on the proposal, I'll file a CSR to >>> document a new System property. >>> >>> Thanks in advance! >>> >> Given that the maximum length for an extended APDU is 64K (65536) >> (hmm +7 for the header and +2 for LE), and for its return is 64K + 2 >> bytes,? I'm not quite sure why you'd up the number to 4096/1M - I'd >> set the default and fixed value to 257 (64K) and leave it at that. >> >> Mike >> >> >> >> >> From mstjohns at comcast.net Tue Feb 11 17:34:23 2020 From: mstjohns at comcast.net (Mike StJohns) Date: Tue, 11 Feb 2020 12:34:23 -0500 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: <2e34a141-3df6-054b-99e2-60a8dc99a29c@oracle.com> References: <2e34a141-3df6-054b-99e2-60a8dc99a29c@oracle.com> Message-ID: To test this you?d have to have an applet and card and card reader or an applet and simulator. It?s possible you could build something using the java card simulator in the JCDK, but I don?t know if that would actually exercise the code. Mike Sent from my iPad > On Feb 11, 2020, at 09:47, Roger Riggs wrote: > > ?Hi Ivan, > > Raising it to work up to the spec'd limit is a good approach. > > Do we have a way to test this? Aka: There should be a test. > > Roger > > >> On 2/10/20 8:07 PM, Ivan Gerasimov wrote: >> Thank you Michael! >> >> It's a good point about maximum length. >> >> Here's the updated webrev with the new System property dropped and the increased number of iterations: >> >> http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ >> >> With kind regards, >> Ivan >> >> >>> On 2/10/20 4:18 PM, Michael StJohns wrote: >>> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> Current implementation of the method javax.smartcardio.CardChannel.transmit() has an internal limitation on the maximum allowed amount of the transmitted data. >>>> >>>> This limitation is dictated by the maximum number of iterations to transmit data from a card: Each iteration can transmit up to 256 bytes of data, and we have a hardcoded limit of 32 iterations. >>>> >>>> Over time, we've received requests to increase this limit, as there are occasions when the effective limit of 8k is not enough. >>>> >>>> Would you please help review a proposal: First, it is proposed to increase the default limit of iteration to 128 (so that up to 32k of data can be transmitted); Second, the limit of iterations is made configurable via a System property. This limit can be increased up to 4096 (so that the total amount of transmitted data can be made up to 1m). >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ >>>> >>>> If there is an agreement on the proposal, I'll file a CSR to document a new System property. >>>> >>>> Thanks in advance! >>>> >>> Given that the maximum length for an extended APDU is 64K (65536) (hmm +7 for the header and +2 for LE), and for its return is 64K + 2 bytes, I'm not quite sure why you'd up the number to 4096/1M - I'd set the default and fixed value to 257 (64K) and leave it at that. >>> >>> Mike >>> >>> >>> >>> >>> > From bradford.wetmore at oracle.com Tue Feb 11 19:23:20 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 11 Feb 2020 11:23:20 -0800 Subject: Fwd: Re: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: <4857368e-2f31-3dfe-94ae-a0a34a6d6cb3@oracle.com> References: <4857368e-2f31-3dfe-94ae-a0a34a6d6cb3@oracle.com> Message-ID: <9552cb36-40f3-98ab-f74b-1b07e1102e27@oracle.com> Forwarding to security-dev, was only posted to jdk8u-dev. Brad -------- Forwarded Message -------- Subject: Re: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 Date: Wed, 5 Feb 2020 14:31:14 -0800 From: Valerie Peng Organization: Oracle Corporation To: jdk8u-dev at openjdk.java.net, Bradford Wetmore Hi Brad, src/windows/classes/sun/security/mscapi/PRNG.java: take this file off the list of changes as it only contains copyright update. Rest looks good to me. Thanks, Valerie On 2/4/2020 5:08 PM, Xuelei Fan wrote: > > 1.? ALPN: > > http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN > I reviewed this part, which look good to me. > > Thanks, > Xuelei > > On 2/4/2020 3:24 PM, Bradford Wetmore wrote: >> I added a simple PSS 32-bit windows crash fix, which was previously >> reviewed in security-dev earlier today [0]. >> >> ???? 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION >> >> The PSS webrev is now at version .01. >> >> Otherwise, everything is identical from last week's request below. >> The ALPN remains at version .00. >> >> [0] >> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021203.html >> >> >> ---begin--- >> >> Good morning/afternoon/evening/night, >> >> As announced on jdk8u-dev[1], there is a Maintenance Release in progress >> for Java SE 8 (i.e. JSR 337) [2] to include two security features >> important for TLS 1.3: >> >> 1.? Application-Layer Protocol Negotiation (ALPN) [3][4] >> 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme >> (RSASSA-PSS) [5][6] >> >> As mentioned in [1], if it wasn't too much work then we would like to >> contribute the changes required by this MR to the next appropriate >> OpenJDK 8 release, most likely 8u252. >> >> Now that the MR3 balloting successfully concluded last night, I'd >> like to make that happen, and move the code into review. >> >> The code is essentially what was reviewed for 8u41[7][8] and >> internally for what we expect to be in Oracle's 8u251 JDK, except the >> code in this review is based on the current JDK 8u workspace.? We >> also included code to allow the Windows platform to use PSS natively. >> >> The specific bugs/backports (requested by the JDK8u maintainers) follow: >> >> ALPN: >> ===== >> 8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation >> Extension (Java SE 8) >> 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation >> Extension >> 8170282: Enable ALPN parameters to be supplied during the TLS handshake >> 8145849: ALPN: getHandshakeApplicationProtocol() always return null >> 8158978: ALPN not working when values are set directly on a >> SSLServerSocket >> 8171443: (spec) An ALPN callback function may also ignore ALPN >> >> RSASSA-PSS: >> =========== >> 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) >> 8175029: StackOverflowError in X509CRL and >> X509Certificate.verify(PublicKey, Provider) >> 8146293: Add support for RSASSA-PSS Signature algorithm >> 8205445: Add RSASSA-PSS Signature support to SunMSCAPI >> 8205720: KeyFactory#getKeySpec and translateKey throws >> NullPointerException with Invalid key >> 8206171: Signature#getParameters for RSASSA-PSS throws >> ProviderException when not initialized >> 8213009: Refactoring existing SunMSCAPI classes >> 8213010: Supporting keys created with certmgr.exe >> 8214096: sun.security.util.SignatureUtil passes null parameter, so >> JCE validation fails >> 8215694: keytool cannot generate RSASSA-PSS certificates >> 8221407: Windows 32bit build error in libsunmscapi/security.cpp >> 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange >> 8223003: SunMSCAPI keys are not cleaned up >> 8223063: Support CNG RSA keys >> 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with >> RSASSA-PSS support >> 8225180: SignedObject with invalid Key not throwing the >> InvalidKeyException in Windows >> 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as >> AlgorithmId >> Reviewed-by: valeriep, weijun, coffeys, pkoppula >> >> Here are the reviews: >> >> 1.? ALPN: >> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN >> >> 2.? RSASSA-PSS: >> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS >> >> Most of these changes are direct copies of the changesets applied >> in JDK 9+, but adjusted for JDK 8u. >> >> Also, truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were >> added to the SUN Provider to support the corresponding truncated >> RSASSA-PSS Signatures. >> >> Thanks, >> >> Brad >> >> [1] >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html >> [2] https://www.jcp.org/en/jsr/detail?id=337 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230977 >> [4] https://bugs.openjdk.java.net/browse/JDK-8233417 >> [5] https://bugs.openjdk.java.net/browse/JDK-8230978 >> [6] https://bugs.openjdk.java.net/browse/JDK-8233418 >> [7] >> https://mail.openjdk.java.net/pipermail/security-dev/2019-November/020900.html >> >> [8] http://hg.openjdk.java.net/jdk8u/jdk8u41/ >> >> From bradford.wetmore at oracle.com Tue Feb 11 19:23:23 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 11 Feb 2020 11:23:23 -0800 Subject: Fwd: Re: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: <78a077db-f2ef-c6cf-8fb0-fa07909c191b@oracle.com> References: <78a077db-f2ef-c6cf-8fb0-fa07909c191b@oracle.com> Message-ID: Forwarding to security-dev, was only posted to jdk8u-dev. Brad -------- Forwarded Message -------- Subject: Re: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 Date: Tue, 4 Feb 2020 17:08:59 -0800 From: Xuelei Fan Organization: Oracle Corporation To: jdk8u-dev at openjdk.java.net > 1. ALPN: > http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN I reviewed this part, which look good to me. Thanks, Xuelei On 2/4/2020 3:24 PM, Bradford Wetmore wrote: > I added a simple PSS 32-bit windows crash fix, which was previously > reviewed in security-dev earlier today [0]. > > ??? 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION > > The PSS webrev is now at version .01. > > Otherwise, everything is identical from last week's request below.?The > ALPN remains at version .00. > > [0] > https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021203.html > > > ---begin--- > > Good morning/afternoon/evening/night, > > As announced on jdk8u-dev[1], there is a Maintenance Release in progress > for Java SE 8 (i.e. JSR 337) [2] to include two security features > important for TLS 1.3: > > 1.? Application-Layer Protocol Negotiation (ALPN) [3][4] > 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme > (RSASSA-PSS) [5][6] > > As mentioned in [1], if it wasn't too much work then we would like to > contribute the changes required by this MR to the next appropriate > OpenJDK 8 release, most likely 8u252. > > Now that the MR3 balloting successfully concluded last night, I'd like > to make that happen, and move the code into review. > > The code is essentially what was reviewed for 8u41[7][8] and internally > for what we expect to be in Oracle's 8u251 JDK, except the code in this > review is based on the current JDK 8u workspace.? We also includedcode > to allow the Windows platform to use PSS natively. > > The specific bugs/backports (requested by the JDK8u maintainers) follow: > > ALPN: > ===== > 8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation > Extension (Java SE 8) > 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation > Extension > 8170282: Enable ALPN parameters to be supplied during the TLS handshake > 8145849: ALPN: getHandshakeApplicationProtocol() always return null > 8158978: ALPN not working when values are set directly on a SSLServerSocket > 8171443: (spec) An ALPN callback function may also ignore ALPN > > RSASSA-PSS: > =========== > 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) > 8175029: StackOverflowError in X509CRL and > X509Certificate.verify(PublicKey, Provider) > 8146293: Add support for RSASSA-PSS Signature algorithm > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI > 8205720: KeyFactory#getKeySpec and translateKey throws > NullPointerException with Invalid key > 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException > when not initialized > 8213009: Refactoring existing SunMSCAPI classes > 8213010: Supporting keys created with certmgr.exe > 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE > validation fails > 8215694: keytool cannot generate RSASSA-PSS certificates > 8221407: Windows 32bit build error in libsunmscapi/security.cpp > 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange > 8223003: SunMSCAPI keys are not cleaned up > 8223063: Support CNG RSA keys > 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with > RSASSA-PSS support > 8225180: SignedObject with invalid Key not throwing the > InvalidKeyException in Windows > 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as > AlgorithmId > Reviewed-by: valeriep, weijun, coffeys, pkoppula > > Here are the reviews: > > 1.? ALPN: > ???? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN > > 2.? RSASSA-PSS: > ???? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS > > Most of these changes are direct copies of the changesets applied > in JDK 9+, but adjusted for JDK 8u. > > Also, truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were > added to the SUN Provider to support the corresponding truncated > RSASSA-PSS Signatures. > > Thanks, > > Brad > > [1] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html > [2] https://www.jcp.org/en/jsr/detail?id=337 > [3] https://bugs.openjdk.java.net/browse/JDK-8230977 > [4] https://bugs.openjdk.java.net/browse/JDK-8233417 > [5] https://bugs.openjdk.java.net/browse/JDK-8230978 > [6] https://bugs.openjdk.java.net/browse/JDK-8233418 > [7] > https://mail.openjdk.java.net/pipermail/security-dev/2019-November/020900.html > > [8] http://hg.openjdk.java.net/jdk8u/jdk8u41/ > > From xuelei.fan at oracle.com Tue Feb 11 20:15:20 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Feb 2020 12:15:20 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: <78a077db-f2ef-c6cf-8fb0-fa07909c191b@oracle.com> References: <78a077db-f2ef-c6cf-8fb0-fa07909c191b@oracle.com> Message-ID: <3350d698-1f01-e65c-6db1-40f7869e5d3a@oracle.com> Missed security-dev. On 2/4/2020 5:08 PM, Xuelei Fan wrote: > > 1.? ALPN: > >?????? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN > I reviewed this part, which look good to me. > > Thanks, > Xuelei > > On 2/4/2020 3:24 PM, Bradford Wetmore wrote: >> I added a simple PSS 32-bit windows crash fix, which was previously >> reviewed in security-dev earlier today [0]. >> >> ???? 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION >> >> The PSS webrev is now at version .01. >> >> Otherwise, everything is identical from last week's request below. >> The ALPN remains at version .00. >> >> [0] >> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021203.html >> >> >> ---begin--- >> >> Good morning/afternoon/evening/night, >> >> As announced on jdk8u-dev[1], there is a Maintenance Release in progress >> for Java SE 8 (i.e. JSR 337) [2] to include two security features >> important for TLS 1.3: >> >> 1.? Application-Layer Protocol Negotiation (ALPN) [3][4] >> 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme >> (RSASSA-PSS) [5][6] >> >> As mentioned in [1], if it wasn't too much work then we would like to >> contribute the changes required by this MR to the next appropriate >> OpenJDK 8 release, most likely 8u252. >> >> Now that the MR3 balloting successfully concluded last night, I'd like >> to make that happen, and move the code into review. >> >> The code is essentially what was reviewed for 8u41[7][8] and >> internally for what we expect to be in Oracle's 8u251 JDK, except the >> code in this review is based on the current JDK 8u workspace.? We also >> included code to allow the Windows platform to use PSS natively. >> >> The specific bugs/backports (requested by the JDK8u maintainers) follow: >> >> ALPN: >> ===== >> 8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation >> Extension (Java SE 8) >> 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation >> Extension >> 8170282: Enable ALPN parameters to be supplied during the TLS handshake >> 8145849: ALPN: getHandshakeApplicationProtocol() always return null >> 8158978: ALPN not working when values are set directly on a >> SSLServerSocket >> 8171443: (spec) An ALPN callback function may also ignore ALPN >> >> RSASSA-PSS: >> =========== >> 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) >> 8175029: StackOverflowError in X509CRL and >> X509Certificate.verify(PublicKey, Provider) >> 8146293: Add support for RSASSA-PSS Signature algorithm >> 8205445: Add RSASSA-PSS Signature support to SunMSCAPI >> 8205720: KeyFactory#getKeySpec and translateKey throws >> NullPointerException with Invalid key >> 8206171: Signature#getParameters for RSASSA-PSS throws >> ProviderException when not initialized >> 8213009: Refactoring existing SunMSCAPI classes >> 8213010: Supporting keys created with certmgr.exe >> 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE >> validation fails >> 8215694: keytool cannot generate RSASSA-PSS certificates >> 8221407: Windows 32bit build error in libsunmscapi/security.cpp >> 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange >> 8223003: SunMSCAPI keys are not cleaned up >> 8223063: Support CNG RSA keys >> 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with >> RSASSA-PSS support >> 8225180: SignedObject with invalid Key not throwing the >> InvalidKeyException in Windows >> 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as >> AlgorithmId >> Reviewed-by: valeriep, weijun, coffeys, pkoppula >> >> Here are the reviews: >> >> 1.? ALPN: >> ????? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN >> >> 2.? RSASSA-PSS: >> ????? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS >> >> Most of these changes are direct copies of the changesets applied >> in JDK 9+, but adjusted for JDK 8u. >> >> Also, truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were >> added to the SUN Provider to support the corresponding truncated >> RSASSA-PSS Signatures. >> >> Thanks, >> >> Brad >> >> [1] >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html >> >> [2] https://www.jcp.org/en/jsr/detail?id=337 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230977 >> [4] https://bugs.openjdk.java.net/browse/JDK-8233417 >> [5] https://bugs.openjdk.java.net/browse/JDK-8230978 >> [6] https://bugs.openjdk.java.net/browse/JDK-8233418 >> [7] >> https://mail.openjdk.java.net/pipermail/security-dev/2019-November/020900.html >> >> [8] http://hg.openjdk.java.net/jdk8u/jdk8u41/ >> >> From ivan.gerasimov at oracle.com Tue Feb 11 20:18:40 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 11 Feb 2020 12:18:40 -0800 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: References: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> Message-ID: Hi Valerie! To be honest, the all these limitations are not quite clear to me. If the command is using an extended Le word to specify the expected length of the response data, then this length can be at most 65536. If a short Le was used, then the length can be at most 256. However, if we received 0x61 in the SW1, that means that more data bytes are available and they can be retrieved by issuing another transmit call with a short Le.? This next call can again potentially result in 0x61 in SW1, and so on. In the standard, I cannot see any explicit limitations on the number of retries.? So, I see it as it might be possible to retrieve more data than 65536 bytes. On the other hand, in the specification for CommandAPDU [1] we have hardcoded limit for the maximum response length, which is 65536.? So, even if it were possible to retrieve larger data, there's no point to try, as the current API prohibits it. Assuming that the 0x61 response can only be received when a short Le is used, the maximum RESPONSE_ITERATOR should be set to 256, and an exception should be thrown once that number is exceeded. I've updated the webrev in-place accordingly. [0] http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ [1] https://docs.oracle.com/en/java/javase/13/docs/api/java.smartcardio/javax/smartcardio/CommandAPDU.html#%3Cinit%3E(int,int,int,int,int) With kind regards, Ivan On 2/10/20 6:40 PM, Valerie Peng wrote: > Hi Ivan, > > You removed the "=", so the actual iteration count is reduced by one. > > Should the iteration count be 256 or 257? If the actual count should > be 257, then may be the check needs to be changed to k++ from ++k? > > Valerie > > On 2/10/2020 5:07 PM, Ivan Gerasimov wrote: >> Thank you Michael! >> >> It's a good point about maximum length. >> >> Here's the updated webrev with the new System property dropped and >> the increased number of iterations: >> >> http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ >> >> With kind regards, >> Ivan >> >> >> On 2/10/20 4:18 PM, Michael StJohns wrote: >>> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> Current implementation of the method >>>> javax.smartcardio.CardChannel.transmit() has an internal limitation >>>> on the maximum allowed amount of the transmitted data. >>>> >>>> This limitation is dictated by the maximum number of iterations to >>>> transmit data from a card:? Each iteration can transmit up to 256 >>>> bytes of data, and we have a hardcoded limit of 32 iterations. >>>> >>>> Over time, we've received requests to increase this limit, as there >>>> are occasions when the effective limit of 8k is not enough. >>>> >>>> Would you please help review a proposal:? First, it is proposed to >>>> increase the default limit of iteration to 128 (so that up to 32k >>>> of data can be transmitted);? Second, the limit of iterations is >>>> made configurable via a System property. This limit can be >>>> increased up to 4096 (so that the total amount of transmitted data >>>> can be made up to 1m). >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ >>>> >>>> If there is an agreement on the proposal, I'll file a CSR to >>>> document a new System property. >>>> >>>> Thanks in advance! >>>> >>> Given that the maximum length for an extended APDU is 64K (65536) >>> (hmm +7 for the header and +2 for LE), and for its return is 64K + 2 >>> bytes,? I'm not quite sure why you'd up the number to 4096/1M - I'd >>> set the default and fixed value to 257 (64K) and leave it at that. >>> >>> Mike >>> >>> >>> >>> >>> -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Tue Feb 11 20:24:51 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 11 Feb 2020 12:24:51 -0800 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: <2e34a141-3df6-054b-99e2-60a8dc99a29c@oracle.com> References: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> <2e34a141-3df6-054b-99e2-60a8dc99a29c@oracle.com> Message-ID: Thank you Roger! We do have a manual test that performs some sanity verification that a transmit call works [1]. I have also received a confirmation from a submitter of the bug that the patched JDK now allows to retrieve data larger than 32k, which was not possible before the fix. I'll add a noreg-hard label to the bug. [1] http://hg.openjdk.java.net/jdk/jdk/file/73bcb3e4e596/test/jdk/sun/security/smartcardio/TestTransmit.java With kind regards, Ivan On 2/11/20 6:46 AM, Roger Riggs wrote: > Hi Ivan, > > Raising it to work up to the spec'd limit is a good approach. > > Do we have a way to test this?? Aka: There should be a test. > > Roger > > > On 2/10/20 8:07 PM, Ivan Gerasimov wrote: >> Thank you Michael! >> >> It's a good point about maximum length. >> >> Here's the updated webrev with the new System property dropped and >> the increased number of iterations: >> >> http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ >> >> With kind regards, >> Ivan >> >> >> On 2/10/20 4:18 PM, Michael StJohns wrote: >>> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> Current implementation of the method >>>> javax.smartcardio.CardChannel.transmit() has an internal limitation >>>> on the maximum allowed amount of the transmitted data. >>>> >>>> This limitation is dictated by the maximum number of iterations to >>>> transmit data from a card:? Each iteration can transmit up to 256 >>>> bytes of data, and we have a hardcoded limit of 32 iterations. >>>> >>>> Over time, we've received requests to increase this limit, as there >>>> are occasions when the effective limit of 8k is not enough. >>>> >>>> Would you please help review a proposal:? First, it is proposed to >>>> increase the default limit of iteration to 128 (so that up to 32k >>>> of data can be transmitted);? Second, the limit of iterations is >>>> made configurable via a System property. This limit can be >>>> increased up to 4096 (so that the total amount of transmitted data >>>> can be made up to 1m). >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ >>>> >>>> If there is an agreement on the proposal, I'll file a CSR to >>>> document a new System property. >>>> >>>> Thanks in advance! >>>> >>> Given that the maximum length for an extended APDU is 64K (65536) >>> (hmm +7 for the header and +2 for LE), and for its return is 64K + 2 >>> bytes,? I'm not quite sure why you'd up the number to 4096/1M - I'd >>> set the default and fixed value to 257 (64K) and leave it at that. >>> >>> Mike >>> >>> >>> >>> >>> > -- With kind regards, Ivan Gerasimov From valerie.peng at oracle.com Wed Feb 12 00:47:14 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 11 Feb 2020 16:47:14 -0800 Subject: [15] RFR 8238898: Missing hash characters for header on license file Message-ID: Anyone can help with a quick review? This fix is for address typos in license header file. No behavior/impl changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8238898 Webrev: http://cr.openjdk.java.net/~valeriep/8238898/webrev.00/ Thanks, Valerie From weijun.wang at oracle.com Wed Feb 12 00:49:40 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 12 Feb 2020 08:49:40 +0800 Subject: [15] RFR 8238898: Missing hash characters for header on license file In-Reply-To: References: Message-ID: <725DC00F-3E77-44B1-9CF2-4D106F21E7E7@oracle.com> Change looks fine. I can see it matches the style of another file in the same directory. Thanks, Max > On Feb 12, 2020, at 8:47 AM, Valerie Peng wrote: > > Anyone can help with a quick review? This fix is for address typos in license header file. No behavior/impl changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8238898 > > Webrev: http://cr.openjdk.java.net/~valeriep/8238898/webrev.00/ > > Thanks, > Valerie From Roger.Riggs at oracle.com Wed Feb 12 14:43:47 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 12 Feb 2020 09:43:47 -0500 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: References: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> <2e34a141-3df6-054b-99e2-60a8dc99a29c@oracle.com> Message-ID: +1 On 2/11/20 3:24 PM, Ivan Gerasimov wrote: > Thank you Roger! > > We do have a manual test that performs some sanity verification that a > transmit call works [1]. > > I have also received a confirmation from a submitter of the bug that > the patched JDK now allows to retrieve data larger than 32k, which was > not possible before the fix. > > I'll add a noreg-hard label to the bug. > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/73bcb3e4e596/test/jdk/sun/security/smartcardio/TestTransmit.java > > With kind regards, > > Ivan > > > On 2/11/20 6:46 AM, Roger Riggs wrote: >> Hi Ivan, >> >> Raising it to work up to the spec'd limit is a good approach. >> >> Do we have a way to test this?? Aka: There should be a test. >> >> Roger >> >> >> On 2/10/20 8:07 PM, Ivan Gerasimov wrote: >>> Thank you Michael! >>> >>> It's a good point about maximum length. >>> >>> Here's the updated webrev with the new System property dropped and >>> the increased number of iterations: >>> >>> http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ >>> >>> With kind regards, >>> Ivan >>> >>> >>> On 2/10/20 4:18 PM, Michael StJohns wrote: >>>> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: >>>>> Hello! >>>>> >>>>> Current implementation of the method >>>>> javax.smartcardio.CardChannel.transmit() has an internal >>>>> limitation on the maximum allowed amount of the transmitted data. >>>>> >>>>> This limitation is dictated by the maximum number of iterations to >>>>> transmit data from a card:? Each iteration can transmit up to 256 >>>>> bytes of data, and we have a hardcoded limit of 32 iterations. >>>>> >>>>> Over time, we've received requests to increase this limit, as >>>>> there are occasions when the effective limit of 8k is not enough. >>>>> >>>>> Would you please help review a proposal:? First, it is proposed to >>>>> increase the default limit of iteration to 128 (so that up to 32k >>>>> of data can be transmitted);? Second, the limit of iterations is >>>>> made configurable via a System property. This limit can be >>>>> increased up to 4096 (so that the total amount of transmitted data >>>>> can be made up to 1m). >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ >>>>> >>>>> If there is an agreement on the proposal, I'll file a CSR to >>>>> document a new System property. >>>>> >>>>> Thanks in advance! >>>>> >>>> Given that the maximum length for an extended APDU is 64K (65536) >>>> (hmm +7 for the header and +2 for LE), and for its return is 64K + >>>> 2 bytes,? I'm not quite sure why you'd up the number to 4096/1M - >>>> I'd set the default and fixed value to 257 (64K) and leave it at that. >>>> >>>> Mike >>>> >>>> >>>> >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Wed Feb 12 23:10:39 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 12 Feb 2020 23:10:39 +0000 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> Message-ID: On 08/02/2020 00:10, Bradford Wetmore wrote: > On 2/5/2020 9:40 PM, Andrew John Hughes wrote:> First of all, thanks > again for posting these patches and also for the >> comprehensive list of issues for both of them. They pretty much matched >> up with what I saw when reviewing the patches > > Great. > >> The ALPN one looks pretty clean. My only concern there is the use of >> "@since 8". Should this not be a reference to the maintenance release, >> as these methods were not part of 8 at GA? Same applies to the usage in >> the second patch too. > > I originally had this as "@since 8 MR 3" but during internal review it > was requested to use @since 8 instead.? This is what was presented/voted > during the MR phase. > Ah ok. I personally think the original MR 3 version would have been better, but I guess we're stuck with this then. >> With the RSA-PSS patch, it's hard to tell what's going on with the >> MSCAPI code, because they appear as new files in the patch. Why was it >> necessary to bring in JDK-8213009? I don't see an obvious reason for >> this. > > JDK-8213009 was mainly a refactor of the MSCAPI code to enhance the code > layout, and to a lesser degree to better support Windows-native PSS > calls using CNG (MS Windows Crypto Next Generation).? The SunMSCAPI > provider is a mix of mostly CAPI (Windows Crypto API) and a few CNG > calls when CAPI couldn't support everything needed. > > The SunMSCAPI changes that followed would take significant effort to > extricate these reorganization changes when backporting later changes > (e.g. jdk/jdk).? We could have forward ported/merged the 8u41 code into > OpenJDK 8, but unfortunately I haven't been given a lot of cycles for > OpenJDK code. > Ok. Backporting 8213009 to make future backports easier is the route I would prefer anyway (and we've done similar in other cases). It's just hard to tell the motivation with everything in one patch. >> dependency of 8213010, but again, it's not obvious why that's required >> here either. Some more details on why some of the less obvious bugs are >> required would be helpful here. > > Ok, I've added details to a comment in JDK-8230978. > Thanks for this detailed list. It's very helpful. >> If the refactoring is necessary, a >> Git-style patch which shows the moves as renames (hg diff -g) would >> help, so we can see what is actually being changed in these files. > > I'm a bit confused, isn't the webrev already showing this: > > http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/ > ---begin--- > > ...deleted... > > *??? src/windows/classes/sun/security/mscapi/CKey.java* /(was > src/windows/classes/sun/security/mscapi/Key.java)/ > > ///138 lines changed: 54 ins; 64 del; 20 mod; 81 unchg/ > > ...deleted... > > *??? src/windows/classes/sun/security/mscapi/CSignature.java /(was > src/windows/classes/sun/security/mscapi/RSASignature.java)/ > > ///676 lines changed: 507 ins; 77 del; 92 mod; 355 unchg/ > ---end--- > > Looking at the index.html and subsequent "Frame" for this file, I can > see both the rename and the old/new code side-by-side. I wasn't looking at the web pages, but just at the patch file (https://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/jdk.patch) and comparing with the changesets from 11u. In the patch file, CKey.java (for example) appears as: --- /dev/null 2020-01-30 10:24:41.746000000 -0800 +++ new/src/windows/classes/sun/security/mscapi/CKey.java 2020-02-04 15:16:49.338689705 -0800 @@ -0,0 +1,155 @@ and same in https://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/src/windows/classes/sun/security/mscapi/CKey.java.patch so it wasn't clear what actual changes were applied after the file was moved. It seems like webrev should be running hg diff with the --git option to get a more useful diff in these cases. In a git format patch, the same diff would appear as: rename from src/windows/classes/sun/security/mscapi/Key.java rename to src/windows/classes/sun/security/mscapi/CKey.java and then the diff would be as if the move hadn't happened, just showing the differences between the original Key.java and the final CKey.java. > >> As you say, the RSA-PSS patch brings in truncated MessageDigests which >> are part of "8051408: NIST SP 800-90A SecureRandom implementations". It >> would be good if the summary field could be used to say "Contains >> truncated MessageDigests from JDK-8051408", so that it then shows up if >> someone is considering 8051408 at a later date > > There are several comments to make which won't fit in the summary field > which is supposed to only be one short line [0]. > > Instead, I have added several items into the comment for JDK-8230978, > which is the main umbrella bug for the PSS work, and I will add: > > ??? Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and > OpenJDK 8u > > to the changeset, which currently reads: > > ---begin--- > 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) > 8175029: StackOverflowError in X509CRL and > X509Certificate.verify(PublicKey, Provider) > 8146293: Add support for RSASSA-PSS Signature algorithm > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI > 8205720: KeyFactory#getKeySpec and translateKey throws > NullPointerException with Invalid key > 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException > when not initialized > 8213009: Refactoring existing SunMSCAPI classes > 8213010: Supporting keys created with certmgr.exe > 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE > validation fails > 8215694: keytool cannot generate RSASSA-PSS certificates > 8221407: Windows 32bit build error in libsunmscapi/security.cpp > 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange > 8223003: SunMSCAPI keys are not cleaned up > 8223063: Support CNG RSA keys > 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with > RSASSA-PSS support > 8225180: SignedObject with invalid Key not throwing the > InvalidKeyException in Windows > 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as > AlgorithmId > 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION > Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and > OpenJDK 8u > Reviewed-by: valeriep, weijun, coffeys, pkoppula > ---end--- > I'd still prefer it was something like: Summary: Contains elements of JDK-8051408 (see comments on JDK-8230978) the reason for this being that this changeset will then show up if someone searches the repository for 8051408, but won't trigger the database to create a backport issue for it. > Did you want me to add you as a reviewer? > Please. >> Otherwise, looks good. >> >> Thanks, > > Thanks, > > Brad > > [0] https://openjdk.java.net/guide/producingChangeset.html > Thanks again, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From valerie.peng at oracle.com Thu Feb 13 04:23:10 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 12 Feb 2020 20:23:10 -0800 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: References: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> Message-ID: <3c87015d-3d01-2450-7691-42cc4f35ed26@oracle.com> Hi, Ivan, I share your thought/confusion on the current impl as I am also not familiar with ISO/IEC 7816-4. Based on my reading of this standard and the CardImpl code, it looks like the while-true loop is for retrieving additional response data. Per the standard and javadoc, max length of the response data is 65536. Given that SW2 is only one byte, it would probably only return at most 256 byte response data at a time. Thus, the iteration count would be at most 256. So far we are on the same page. With the latest webrev (webrev.01), it seems that the loop will only be run 255 instead of 256 times as k is incremented before comparison. Thus, I think we should fix the check. Valerie On 2/11/2020 12:18 PM, Ivan Gerasimov wrote: > Hi Valerie! > > To be honest, the all these limitations are not quite clear to me. > > If the command is using an extended Le word to specify the expected > length of the response data, then this length can be at most 65536. > > If a short Le was used, then the length can be at most 256. > > However, if we received 0x61 in the SW1, that means that more data > bytes are available and they can be retrieved by issuing another > transmit call with a short Le.? This next call can again potentially > result in 0x61 in SW1, and so on. > > In the standard, I cannot see any explicit limitations on the number > of retries.? So, I see it as it might be possible to retrieve more > data than 65536 bytes. > > On the other hand, in the specification for CommandAPDU [1] we have > hardcoded limit for the maximum response length, which is 65536.? So, > even if it were possible to retrieve larger data, there's no point to > try, as the current API prohibits it. > > Assuming that the 0x61 response can only be received when a short Le > is used, the maximum RESPONSE_ITERATOR should be set to 256, and an > exception should be thrown once that number is exceeded. > > I've updated the webrev in-place accordingly. > > [0] http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ > > [1] > https://docs.oracle.com/en/java/javase/13/docs/api/java.smartcardio/javax/smartcardio/CommandAPDU.html#%3Cinit%3E(int,int,int,int,int) > > With kind regards, > > Ivan > > > On 2/10/20 6:40 PM, Valerie Peng wrote: >> Hi Ivan, >> >> You removed the "=", so the actual iteration count is reduced by one. >> >> Should the iteration count be 256 or 257? If the actual count should >> be 257, then may be the check needs to be changed to k++ from ++k? >> >> Valerie >> >> On 2/10/2020 5:07 PM, Ivan Gerasimov wrote: >>> Thank you Michael! >>> >>> It's a good point about maximum length. >>> >>> Here's the updated webrev with the new System property dropped and >>> the increased number of iterations: >>> >>> http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ >>> >>> With kind regards, >>> Ivan >>> >>> >>> On 2/10/20 4:18 PM, Michael StJohns wrote: >>>> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: >>>>> Hello! >>>>> >>>>> Current implementation of the method >>>>> javax.smartcardio.CardChannel.transmit() has an internal >>>>> limitation on the maximum allowed amount of the transmitted data. >>>>> >>>>> This limitation is dictated by the maximum number of iterations to >>>>> transmit data from a card:? Each iteration can transmit up to 256 >>>>> bytes of data, and we have a hardcoded limit of 32 iterations. >>>>> >>>>> Over time, we've received requests to increase this limit, as >>>>> there are occasions when the effective limit of 8k is not enough. >>>>> >>>>> Would you please help review a proposal:? First, it is proposed to >>>>> increase the default limit of iteration to 128 (so that up to 32k >>>>> of data can be transmitted);? Second, the limit of iterations is >>>>> made configurable via a System property. This limit can be >>>>> increased up to 4096 (so that the total amount of transmitted data >>>>> can be made up to 1m). >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ >>>>> >>>>> If there is an agreement on the proposal, I'll file a CSR to >>>>> document a new System property. >>>>> >>>>> Thanks in advance! >>>>> >>>> Given that the maximum length for an extended APDU is 64K (65536) >>>> (hmm +7 for the header and +2 for LE), and for its return is 64K + >>>> 2 bytes,? I'm not quite sure why you'd up the number to 4096/1M - >>>> I'd set the default and fixed value to 257 (64K) and leave it at that. >>>> >>>> Mike >>>> >>>> >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Thu Feb 13 05:23:11 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 12 Feb 2020 21:23:11 -0800 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: <3c87015d-3d01-2450-7691-42cc4f35ed26@oracle.com> References: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> <3c87015d-3d01-2450-7691-42cc4f35ed26@oracle.com> Message-ID: <03967cec-0b54-ce53-f274-f38885b8ee16@oracle.com> Ignore my earlier comment about fixing the check. Took a second look at the check and noticed that it's for throwing the exception. Your current webrev is fine. Regards, Valerie On 2/12/2020 8:23 PM, Valerie Peng wrote: > > Hi, Ivan, > > I share your thought/confusion on the current impl as I am also not > familiar with ISO/IEC 7816-4. > > Based on my reading of this standard and the CardImpl code, it looks > like the while-true loop is for retrieving additional response data. > Per the standard and javadoc, max length of the response data is > 65536. Given that SW2 is only one byte, it would probably only return > at most 256 byte response data at a time. Thus, the iteration count > would be at most 256. > > So far we are on the same page. > > With the latest webrev (webrev.01), it seems that the loop will only > be run 255 instead of 256 times as k is incremented before comparison. > Thus, I think we should fix the check. > > Valerie > > On 2/11/2020 12:18 PM, Ivan Gerasimov wrote: >> Hi Valerie! >> >> To be honest, the all these limitations are not quite clear to me. >> >> If the command is using an extended Le word to specify the expected >> length of the response data, then this length can be at most 65536. >> >> If a short Le was used, then the length can be at most 256. >> >> However, if we received 0x61 in the SW1, that means that more data >> bytes are available and they can be retrieved by issuing another >> transmit call with a short Le.? This next call can again potentially >> result in 0x61 in SW1, and so on. >> >> In the standard, I cannot see any explicit limitations on the number >> of retries.? So, I see it as it might be possible to retrieve more >> data than 65536 bytes. >> >> On the other hand, in the specification for CommandAPDU [1] we have >> hardcoded limit for the maximum response length, which is 65536.? So, >> even if it were possible to retrieve larger data, there's no point to >> try, as the current API prohibits it. >> >> Assuming that the 0x61 response can only be received when a short Le >> is used, the maximum RESPONSE_ITERATOR should be set to 256, and an >> exception should be thrown once that number is exceeded. >> >> I've updated the webrev in-place accordingly. >> >> [0] http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ >> >> [1] >> https://docs.oracle.com/en/java/javase/13/docs/api/java.smartcardio/javax/smartcardio/CommandAPDU.html#%3Cinit%3E(int,int,int,int,int) >> >> With kind regards, >> >> Ivan >> >> >> On 2/10/20 6:40 PM, Valerie Peng wrote: >>> Hi Ivan, >>> >>> You removed the "=", so the actual iteration count is reduced by one. >>> >>> Should the iteration count be 256 or 257? If the actual count should >>> be 257, then may be the check needs to be changed to k++ from ++k? >>> >>> Valerie >>> >>> On 2/10/2020 5:07 PM, Ivan Gerasimov wrote: >>>> Thank you Michael! >>>> >>>> It's a good point about maximum length. >>>> >>>> Here's the updated webrev with the new System property dropped and >>>> the increased number of iterations: >>>> >>>> http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ >>>> >>>> With kind regards, >>>> Ivan >>>> >>>> >>>> On 2/10/20 4:18 PM, Michael StJohns wrote: >>>>> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: >>>>>> Hello! >>>>>> >>>>>> Current implementation of the method >>>>>> javax.smartcardio.CardChannel.transmit() has an internal >>>>>> limitation on the maximum allowed amount of the transmitted data. >>>>>> >>>>>> This limitation is dictated by the maximum number of iterations >>>>>> to transmit data from a card:? Each iteration can transmit up to >>>>>> 256 bytes of data, and we have a hardcoded limit of 32 iterations. >>>>>> >>>>>> Over time, we've received requests to increase this limit, as >>>>>> there are occasions when the effective limit of 8k is not enough. >>>>>> >>>>>> Would you please help review a proposal:? First, it is proposed >>>>>> to increase the default limit of iteration to 128 (so that up to >>>>>> 32k of data can be transmitted); Second, the limit of iterations >>>>>> is made configurable via a System property. This limit can be >>>>>> increased up to 4096 (so that the total amount of transmitted >>>>>> data can be made up to 1m). >>>>>> >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 >>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ >>>>>> >>>>>> If there is an agreement on the proposal, I'll file a CSR to >>>>>> document a new System property. >>>>>> >>>>>> Thanks in advance! >>>>>> >>>>> Given that the maximum length for an extended APDU is 64K (65536) >>>>> (hmm +7 for the header and +2 for LE), and for its return is 64K + >>>>> 2 bytes,? I'm not quite sure why you'd up the number to 4096/1M - >>>>> I'd set the default and fixed value to 257 (64K) and leave it at >>>>> that. >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Thu Feb 13 05:43:23 2020 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 13 Feb 2020 00:43:23 -0500 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: <3c87015d-3d01-2450-7691-42cc4f35ed26@oracle.com> References: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> <3c87015d-3d01-2450-7691-42cc4f35ed26@oracle.com> Message-ID: <5bed26e1-be4e-da41-0d7a-059ca33e3deb@comcast.net> Hi - I needed to go take a quick look at 7816-3 to figure out what's what. Basically, this code is a bit problematic. 1) Since this code doesn't support extended length APDUs for T=0, you should never have to do multiple calls to get the responses - e.g. the max response handled here should be 256 bytes.? But this is the only case in which the GetResponse code should actually be active???? T=1 uses low level mapping of I-Blocks rather than an APDU mapping.? And looking at pcsc.c - you've got 8192 as the maximum size for a per-call return from SCardTransmit, and I'm not sure what SCardTransmit will do - I'm wondering if its returning the 6Cxx error code. 2) The iteration count should probably be set from the Le value in the transmitted CommandAPDU rather than set to a fixed value. Or even better, don't use an iteration count, but simply count down from the specified Le and stop when negative. I'm very confused now. What protocol is the customer using??? What's the actual APDU they're sending to get the data? (Mostly curious about Lc and Le here). If you changed the iteration loop to parse the Le field and use that to count down received data, would that break things? Mike On 2/12/2020 11:23 PM, Valerie Peng wrote: > > Hi, Ivan, > > I share your thought/confusion on the current impl as I am also not > familiar with ISO/IEC 7816-4. > > Based on my reading of this standard and the CardImpl code, it looks > like the while-true loop is for retrieving additional response data. > Per the standard and javadoc, max length of the response data is > 65536. Given that SW2 is only one byte, it would probably only return > at most 256 byte response data at a time. Thus, the iteration count > would be at most 256. > > So far we are on the same page. > > With the latest webrev (webrev.01), it seems that the loop will only > be run 255 instead of 256 times as k is incremented before comparison. > Thus, I think we should fix the check. > > Valerie > > On 2/11/2020 12:18 PM, Ivan Gerasimov wrote: >> Hi Valerie! >> >> To be honest, the all these limitations are not quite clear to me. >> >> If the command is using an extended Le word to specify the expected >> length of the response data, then this length can be at most 65536. >> >> If a short Le was used, then the length can be at most 256. >> >> However, if we received 0x61 in the SW1, that means that more data >> bytes are available and they can be retrieved by issuing another >> transmit call with a short Le.? This next call can again potentially >> result in 0x61 in SW1, and so on. >> >> In the standard, I cannot see any explicit limitations on the number >> of retries.? So, I see it as it might be possible to retrieve more >> data than 65536 bytes. >> >> On the other hand, in the specification for CommandAPDU [1] we have >> hardcoded limit for the maximum response length, which is 65536.? So, >> even if it were possible to retrieve larger data, there's no point to >> try, as the current API prohibits it. >> >> Assuming that the 0x61 response can only be received when a short Le >> is used, the maximum RESPONSE_ITERATOR should be set to 256, and an >> exception should be thrown once that number is exceeded. >> >> I've updated the webrev in-place accordingly. >> >> [0] http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ >> >> [1] >> https://docs.oracle.com/en/java/javase/13/docs/api/java.smartcardio/javax/smartcardio/CommandAPDU.html#%3Cinit%3E(int,int,int,int,int) >> >> With kind regards, >> >> Ivan >> >> >> On 2/10/20 6:40 PM, Valerie Peng wrote: >>> Hi Ivan, >>> >>> You removed the "=", so the actual iteration count is reduced by one. >>> >>> Should the iteration count be 256 or 257? If the actual count should >>> be 257, then may be the check needs to be changed to k++ from ++k? >>> >>> Valerie >>> >>> On 2/10/2020 5:07 PM, Ivan Gerasimov wrote: >>>> Thank you Michael! >>>> >>>> It's a good point about maximum length. >>>> >>>> Here's the updated webrev with the new System property dropped and >>>> the increased number of iterations: >>>> >>>> http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ >>>> >>>> With kind regards, >>>> Ivan >>>> >>>> >>>> On 2/10/20 4:18 PM, Michael StJohns wrote: >>>>> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: >>>>>> Hello! >>>>>> >>>>>> Current implementation of the method >>>>>> javax.smartcardio.CardChannel.transmit() has an internal >>>>>> limitation on the maximum allowed amount of the transmitted data. >>>>>> >>>>>> This limitation is dictated by the maximum number of iterations >>>>>> to transmit data from a card:? Each iteration can transmit up to >>>>>> 256 bytes of data, and we have a hardcoded limit of 32 iterations. >>>>>> >>>>>> Over time, we've received requests to increase this limit, as >>>>>> there are occasions when the effective limit of 8k is not enough. >>>>>> >>>>>> Would you please help review a proposal:? First, it is proposed >>>>>> to increase the default limit of iteration to 128 (so that up to >>>>>> 32k of data can be transmitted); Second, the limit of iterations >>>>>> is made configurable via a System property. This limit can be >>>>>> increased up to 4096 (so that the total amount of transmitted >>>>>> data can be made up to 1m). >>>>>> >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 >>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ >>>>>> >>>>>> If there is an agreement on the proposal, I'll file a CSR to >>>>>> document a new System property. >>>>>> >>>>>> Thanks in advance! >>>>>> >>>>> Given that the maximum length for an extended APDU is 64K (65536) >>>>> (hmm +7 for the header and +2 for LE), and for its return is 64K + >>>>> 2 bytes,? I'm not quite sure why you'd up the number to 4096/1M - >>>>> I'd set the default and fixed value to 257 (64K) and leave it at >>>>> that. >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>> >>>>> l -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Feb 13 11:06:31 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 13 Feb 2020 19:06:31 +0800 Subject: RFR 8237218: Support NIST Curves verification in java implementation In-Reply-To: References: Message-ID: <328A5FFB-A9EC-479A-B009-7C2D26CB9EF3@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/8237218/webrev.03/ The test is modified. Instead of adding a hacked ECDSASignature I'm using JDI to detect if the Java impl or the native impl is used. Two method names in ECDSASignature are modified to ease method lookup in the test. Thanks, Max > On Feb 11, 2020, at 7:52 PM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8237218/webrev.02/ > > A test is added that uses a patched ECDSASignature.java that exposes how the signature is verified. > > BTW, I also updated ECDSASignature.java a little to accept non SunEC keys, so that I can do some interop testing. If you believe this is unnecessary I can revert the change. > > Thanks, > Max > From weijun.wang at oracle.com Thu Feb 13 14:24:09 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 13 Feb 2020 22:24:09 +0800 Subject: RFR rev 57996 : Message-ID: <71D350BC-8341-4B41-A2D3-A6DAD4836C8E@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8160818/webrev.00 I haven't updated the server side to check the mutual state, for compatibility. Thanks, Max From weijun.wang at oracle.com Thu Feb 13 15:14:21 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 13 Feb 2020 23:14:21 +0800 Subject: RFR 8160818: GssKrb5Client violates RFC 4752 In-Reply-To: <71D350BC-8341-4B41-A2D3-A6DAD4836C8E@oracle.com> References: <71D350BC-8341-4B41-A2D3-A6DAD4836C8E@oracle.com> Message-ID: Correct the subject line. > On Feb 13, 2020, at 10:24 PM, Weijun Wang wrote: > > Please take a review at > > https://cr.openjdk.java.net/~weijun/8160818/webrev.00 > > I haven't updated the server side to check the mutual state, for compatibility. > > Thanks, > Max > From xuelei.fan at oracle.com Thu Feb 13 17:24:06 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 13 Feb 2020 09:24:06 -0800 Subject: RFR 8160818: GssKrb5Client violates RFC 4752 In-Reply-To: References: <71D350BC-8341-4B41-A2D3-A6DAD4836C8E@oracle.com> Message-ID: Do you want to declare the mutual variable as final object? Otherwise, looks fine to me. Xuelei On 2/13/2020 7:14 AM, Weijun Wang wrote: > Correct the subject line. > >> On Feb 13, 2020, at 10:24 PM, Weijun Wang wrote: >> >> Please take a review at >> >> https://cr.openjdk.java.net/~weijun/8160818/webrev.00 >> >> I haven't updated the server side to check the mutual state, for compatibility. >> >> Thanks, >> Max >> > From ivan.gerasimov at oracle.com Thu Feb 13 19:12:54 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 13 Feb 2020 11:12:54 -0800 Subject: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: <5bed26e1-be4e-da41-0d7a-059ca33e3deb@comcast.net> References: <42909117-0dc0-0dc2-81a3-e69f6b1619c2@oracle.com> <2d568e98-55a6-ecb0-6871-fd2730f3de5f@comcast.net> <0a33d0d6-1c9a-0850-ee6d-55745d8d7c69@oracle.com> <3c87015d-3d01-2450-7691-42cc4f35ed26@oracle.com> <5bed26e1-be4e-da41-0d7a-059ca33e3deb@comcast.net> Message-ID: Thank you Mike for the additional analysis! I would like to avoid any significant modifications to the code at this moment, as I have only limited resources to test them. The last proposed patch [1] takes a conservative approach and just increases the limit of the iterations. So, this is highly unlikely to break any existing code. Given that this patch was confirmed to resolve a problem in at least one existing scenario, I'd like to go ahead with this fix unless there are strong objections. I agree that it may make sense to revisit this code and make sure it conform to the standards and real hardware, but I think it should be done separately from this issue. Another reason to keep the fix as simple as possible is that we're planning for backporting the fix to the earlier releases of the JDK, so I'd rather keep it low-risk. With kind regards, Ivan On 2/12/20 9:43 PM, Michael StJohns wrote: > Hi - > > I needed to go take a quick look at 7816-3 to figure out what's what. > > Basically, this code is a bit problematic. > > 1) Since this code doesn't support extended length APDUs for T=0, you > should never have to do multiple calls to get the responses - e.g. the > max response handled here should be 256 bytes.? But this is the only > case in which the GetResponse code should actually be active???? T=1 > uses low level mapping of I-Blocks rather than an APDU mapping.? And > looking at pcsc.c - you've got 8192 as the maximum size for a per-call > return from SCardTransmit, and I'm not sure what SCardTransmit will do > - I'm wondering if its returning the 6Cxx error code. > > 2) The iteration count should probably be set from the Le value in the > transmitted CommandAPDU rather than set to a fixed value.? Or even > better, don't use an iteration count, but simply count down from the > specified Le and stop when negative. > > I'm very confused now. > > What protocol is the customer using??? What's the actual APDU they're > sending to get the data? (Mostly curious about Lc and Le here). > > If you changed the iteration loop to parse the Le field and use that > to count down received data, would that break things? > > Mike > > > On 2/12/2020 11:23 PM, Valerie Peng wrote: >> >> Hi, Ivan, >> >> I share your thought/confusion on the current impl as I am also not >> familiar with ISO/IEC 7816-4. >> >> Based on my reading of this standard and the CardImpl code, it looks >> like the while-true loop is for retrieving additional response data. >> Per the standard and javadoc, max length of the response data is >> 65536. Given that SW2 is only one byte, it would probably only return >> at most 256 byte response data at a time. Thus, the iteration count >> would be at most 256. >> >> So far we are on the same page. >> >> With the latest webrev (webrev.01), it seems that the loop will only >> be run 255 instead of 256 times as k is incremented before >> comparison. Thus, I think we should fix the check. >> >> Valerie >> >> On 2/11/2020 12:18 PM, Ivan Gerasimov wrote: >>> Hi Valerie! >>> >>> To be honest, the all these limitations are not quite clear to me. >>> >>> If the command is using an extended Le word to specify the expected >>> length of the response data, then this length can be at most 65536. >>> >>> If a short Le was used, then the length can be at most 256. >>> >>> However, if we received 0x61 in the SW1, that means that more data >>> bytes are available and they can be retrieved by issuing another >>> transmit call with a short Le.? This next call can again potentially >>> result in 0x61 in SW1, and so on. >>> >>> In the standard, I cannot see any explicit limitations on the number >>> of retries.? So, I see it as it might be possible to retrieve more >>> data than 65536 bytes. >>> >>> On the other hand, in the specification for CommandAPDU [1] we have >>> hardcoded limit for the maximum response length, which is 65536.? >>> So, even if it were possible to retrieve larger data, there's no >>> point to try, as the current API prohibits it. >>> >>> Assuming that the 0x61 response can only be received when a short Le >>> is used, the maximum RESPONSE_ITERATOR should be set to 256, and an >>> exception should be thrown once that number is exceeded. >>> >>> I've updated the webrev in-place accordingly. >>> >>> [0] http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ >>> >>> [1] >>> https://docs.oracle.com/en/java/javase/13/docs/api/java.smartcardio/javax/smartcardio/CommandAPDU.html#%3Cinit%3E(int,int,int,int,int) >>> >>> With kind regards, >>> >>> Ivan >>> >>> >>> On 2/10/20 6:40 PM, Valerie Peng wrote: >>>> Hi Ivan, >>>> >>>> You removed the "=", so the actual iteration count is reduced by one. >>>> >>>> Should the iteration count be 256 or 257? If the actual count >>>> should be 257, then may be the check needs to be changed to k++ >>>> from ++k? >>>> >>>> Valerie >>>> >>>> On 2/10/2020 5:07 PM, Ivan Gerasimov wrote: >>>>> Thank you Michael! >>>>> >>>>> It's a good point about maximum length. >>>>> >>>>> Here's the updated webrev with the new System property dropped and >>>>> the increased number of iterations: >>>>> >>>>> http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/ >>>>> >>>>> With kind regards, >>>>> Ivan >>>>> >>>>> >>>>> On 2/10/20 4:18 PM, Michael StJohns wrote: >>>>>> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote: >>>>>>> Hello! >>>>>>> >>>>>>> Current implementation of the method >>>>>>> javax.smartcardio.CardChannel.transmit() has an internal >>>>>>> limitation on the maximum allowed amount of the transmitted data. >>>>>>> >>>>>>> This limitation is dictated by the maximum number of iterations >>>>>>> to transmit data from a card:? Each iteration can transmit up to >>>>>>> 256 bytes of data, and we have a hardcoded limit of 32 iterations. >>>>>>> >>>>>>> Over time, we've received requests to increase this limit, as >>>>>>> there are occasions when the effective limit of 8k is not enough. >>>>>>> >>>>>>> Would you please help review a proposal:? First, it is proposed >>>>>>> to increase the default limit of iteration to 128 (so that up to >>>>>>> 32k of data can be transmitted); Second, the limit of iterations >>>>>>> is made configurable via a System property. This limit can be >>>>>>> increased up to 4096 (so that the total amount of transmitted >>>>>>> data can be made up to 1m). >>>>>>> >>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251 >>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/ >>>>>>> >>>>>>> If there is an agreement on the proposal, I'll file a CSR to >>>>>>> document a new System property. >>>>>>> >>>>>>> Thanks in advance! >>>>>>> >>>>>> Given that the maximum length for an extended APDU is 64K (65536) >>>>>> (hmm +7 for the header and +2 for LE), and for its return is 64K >>>>>> + 2 bytes,? I'm not quite sure why you'd up the number to 4096/1M >>>>>> - I'd set the default and fixed value to 257 (64K) and leave it >>>>>> at that. >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > l > -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Thu Feb 13 21:07:33 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 13 Feb 2020 13:07:33 -0800 Subject: RFR 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB In-Reply-To: <16482275-856f-1411-34ab-034605541866@oracle.com> References: <16482275-856f-1411-34ab-034605541866@oracle.com> Message-ID: <7fe474f9-ece2-3f70-cdbd-94355e56dfb3@oracle.com> I think it's fine to remove this check given the recent NSS changes as Martin mentioned. Second Sean's release note suggestion as well. Thanks, Valerie On 2/10/2020 11:14 AM, Sean Mullan wrote: > Looks good to me, although I would also like Valerie to review it as > she has the most experience with the PKCS11 code. > > This issue should probably also have a release note. Have you ever > written one? > > Thanks, > Sean > > On 2/5/20 10:47 AM, Martin Balao wrote: >> Hi, >> >> I'd like to propose a solution for 8238555 [1]. >> >> Webrev.00: >> >> ? * >> http://cr.openjdk.java.net/~mbalao/webrevs/8238555/8238555.webrev.00/ >> >> Reproducing this issue requires manual configuration steps and there is >> not a single way of doing so. The ultimate goal for a reproduction is to >> initialize a SunPKCS11 provider with an NSSDB that has at least 1 >> external module configured in FIPS mode, with at least 1 opened slot. >> >> The 8238555_manual_reproducer_v0 code [2] provides a standalone >> SunPKCS11 initialization with an NSSDB that has a single internal FIPS >> module configured. That's not enough though because the external module >> is still missing in the NSSDB. There are two paths from this point: >> >> 1) Manually add an external module ("modutil" command) in FIPS mode to >> the NSSDB >> >> 2) Run the code in the latest Fedora/CentOS/RHEL Linux release -I'm not >> sure if other distributions work- where p11-kit-proxy PKCS#11 module is >> automatically added to every NSSDB. If you go this way, configure FIPS >> policy globally (fips-mode-setup --enable) and recompile the NSS library >> to artificially expose a slot for p11-kit-proxy module [3] (use >> LD_PRELOAD when running the reproducer code). If you don't want to >> recompile the NSS library, manually add a module to p11-kit (such as >> softHSM) so a slot is opened. >> >> In my own environment, I had the following output before the patch: >> >> Beginning test run ExternalFipsModules... >> Cannot resolve artifact, please check if JIB jar is present in >> classpath. >> nssLibDir: /usr/lib64/ >> Exception in thread "main" java.lang.RuntimeException: FIPS flag set for >> non-internal module: p11-kit-proxy.so, p11-kit-proxy >> ????at >> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod$Module.(Secmod.java:418) >> >> ????at >> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.nssGetModuleList(Native >> Method) >> ????at >> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.getModules(Secmod.java:258) >> >> ????at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:219) >> >> ????at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:112) >> >> ????at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:109) >> >> ????at >> java.base/java.security.AccessController.doPrivileged(AccessController.java:554) >> >> ????at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:109) >> >> ????at PKCS11Test.getSunPKCS11(PKCS11Test.java:160) >> ????at PKCS11Test.testNSS(PKCS11Test.java:580) >> ????at PKCS11Test.main(PKCS11Test.java:220) >> ????at PKCS11Test.main(PKCS11Test.java:196) >> ????at ExternalFipsModules.main(ExternalFipsModules.java:31) >> >> And after the patch: >> >> Beginning test run ExternalFipsModules... >> Cannot resolve artifact, please check if JIB jar is present in >> classpath. >> nssLibDir: /usr/lib64/ >> Running test with provider SunPKCS11-NSS-FIPS (security manager >> disabled) ... >> Provider: SunPKCS11-NSS-FIPS version 15 >> TEST PASS - OK >> Completed test with provider SunPKCS11-NSS-FIPS (2 ms). >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8238555 >> [2] - >> http://cr.openjdk.java.net/~mbalao/webrevs/8238555/8238555_manual_reproducer_v0.tar.gz >> >> [3] - >> http://cr.openjdk.java.net/~mbalao/webrevs/8238555/emulate_p11-kit-proxy_with_slots.nss.patch >> >> From bradford.wetmore at oracle.com Thu Feb 13 22:32:23 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 13 Feb 2020 14:32:23 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> Message-ID: <1b194dc5-24e9-2b17-9f1a-a8b5d869bc8b@oracle.com> On 2/12/2020 3:10 PM, Andrew John Hughes wrote: >> I originally had this as "@since 8 MR 3" but during internal review it >> was requested to use @since 8 instead.? This is what was presented/voted >> during the MR phase. > > Ah ok. I personally think the original MR 3 version would have been > better, I personally agree with you. > but I guess we're stuck with this then. >>> JDK-8213009 was mainly a refactor of the MSCAPI code to enhance the code >> layout, and to a lesser degree to better support Windows-native PSS >> calls using CNG (MS Windows Crypto Next Generation).? The SunMSCAPI >> provider is a mix of mostly CAPI (Windows Crypto API) and a few CNG >> calls when CAPI couldn't support everything needed. >> >> The SunMSCAPI changes that followed would take significant effort to >> extricate these reorganization changes when backporting later changes >> (e.g. jdk/jdk).? We could have forward ported/merged the 8u41 code into >> OpenJDK 8, but unfortunately I haven't been given a lot of cycles for >> OpenJDK code. > > Ok. Backporting 8213009 to make future backports easier is the route I > would prefer anyway (and we've done similar in other cases). It's just > hard to tell the motivation with everything in one patch. Agreed, thanks. >>> dependency of 8213010, but again, it's not obvious why that's required >>> here either. Some more details on why some of the less obvious bugs are >>> required would be helpful here. >> >> Ok, I've added details to a comment in JDK-8230978. > > Thanks for this detailed list. It's very helpful. Sure. >>> If the refactoring is necessary, a >>> Git-style patch which shows the moves as renames (hg diff -g) would >>> help, so we can see what is actually being changed in these files. >> >> I'm a bit confused, isn't the webrev already showing this: >> >> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/ >> ---begin--- >> >> ...deleted... >> >> *??? src/windows/classes/sun/security/mscapi/CKey.java* /(was >> src/windows/classes/sun/security/mscapi/Key.java)/ >> >> ///138 lines changed: 54 ins; 64 del; 20 mod; 81 unchg/ >> >> ...deleted... >> >> *??? src/windows/classes/sun/security/mscapi/CSignature.java /(was >> src/windows/classes/sun/security/mscapi/RSASignature.java)/ >> >> ///676 lines changed: 507 ins; 77 del; 92 mod; 355 unchg/ >> ---end--- >> >> Looking at the index.html and subsequent "Frame" for this file, I can >> see both the rename and the old/new code side-by-side. > > I wasn't looking at the web pages, but just at the patch file > (https://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/jdk.patch) > and comparing with the changesets from 11u. I'm a hardcore webrev/frames guys, so I wouldn't have thought to closely look for this. I believe I've discovered a "bug" in webrev when specifying specific revisions. I use Mercurial Queues to handle my patches. With these revisions: r1 = current tip r2 = ALPN patch applied r3 = PSS patch applied If I have applied ALPN + PSS and I use: % webrev -r r2 -o webrev to generate the PSS-only changes, I don't get the git headers. If I don't specify -r, it defaults to r1 (current tip): % webrev -o webrev Then I do see the git changes, but unfortunately both ALPN+PSS show up in a unified webrev. >> ---begin--- >> 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) >> ...deleted... >> 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION >> Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and >> OpenJDK 8u >> Reviewed-by: valeriep, weijun, coffeys, pkoppula >> ---end--- >> > > I'd still prefer it was something like: > > Summary: Contains elements of JDK-8051408 (see comments on JDK-8230978) > > the reason for this being that this changeset will then show up if > someone searches the repository for 8051408, but won't trigger the > database to create a backport issue for it. Changed. >> Did you want me to add you as a reviewer? >> > > Please. Done. Brad From weijun.wang at oracle.com Fri Feb 14 04:41:53 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 14 Feb 2020 12:41:53 +0800 Subject: RFR 8160818: GssKrb5Client violates RFC 4752 In-Reply-To: References: <71D350BC-8341-4B41-A2D3-A6DAD4836C8E@oracle.com> Message-ID: It cannot be final because it was modified later on line 149. That said, this variable is only used inside the constructor and I can make it local. Does that sound better to you? Thanks, Max > On Feb 14, 2020, at 1:24 AM, Xuelei Fan wrote: > > Do you want to declare the mutual variable as final object? Otherwise, looks fine to me. > > Xuelei > > On 2/13/2020 7:14 AM, Weijun Wang wrote: >> Correct the subject line. >>> On Feb 13, 2020, at 10:24 PM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> https://cr.openjdk.java.net/~weijun/8160818/webrev.00 >>> >>> I haven't updated the server side to check the mutual state, for compatibility. >>> >>> Thanks, >>> Max >>> From xuelei.fan at oracle.com Fri Feb 14 06:13:37 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 13 Feb 2020 22:13:37 -0800 Subject: RFR 8160818: GssKrb5Client violates RFC 4752 In-Reply-To: References: <71D350BC-8341-4B41-A2D3-A6DAD4836C8E@oracle.com> Message-ID: <7b1ab55b-3e56-c293-d8b1-58197bc130fe@oracle.com> On 2/13/2020 8:41 PM, Weijun Wang wrote: > It cannot be final because it was modified later on line 149. > I think line 149 is in the same constructor, so it is possible to declare it as final. > That said, this variable is only used inside the constructor and I can make it local. Does that sound better to you? > It's a better update than using the final declaration. Thanks, Xuelei > Thanks, > Max > >> On Feb 14, 2020, at 1:24 AM, Xuelei Fan wrote: >> >> Do you want to declare the mutual variable as final object? Otherwise, looks fine to me. >> >> Xuelei >> >> On 2/13/2020 7:14 AM, Weijun Wang wrote: >>> Correct the subject line. >>>> On Feb 13, 2020, at 10:24 PM, Weijun Wang wrote: >>>> >>>> Please take a review at >>>> >>>> https://cr.openjdk.java.net/~weijun/8160818/webrev.00 >>>> >>>> I haven't updated the server side to check the mutual state, for compatibility. >>>> >>>> Thanks, >>>> Max >>>> > From weijun.wang at oracle.com Fri Feb 14 09:58:46 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 14 Feb 2020 17:58:46 +0800 Subject: RFR 8160818: GssKrb5Client violates RFC 4752 In-Reply-To: <7b1ab55b-3e56-c293-d8b1-58197bc130fe@oracle.com> References: <71D350BC-8341-4B41-A2D3-A6DAD4836C8E@oracle.com> <7b1ab55b-3e56-c293-d8b1-58197bc130fe@oracle.com> Message-ID: <64C9E565-DA97-4355-B481-00B8099DC0E1@oracle.com> Webrev updated at https://cr.openjdk.java.net/~weijun/8160818/webrev.01 > On Feb 14, 2020, at 2:13 PM, Xuelei Fan wrote: > > On 2/13/2020 8:41 PM, Weijun Wang wrote: >> It cannot be final because it was modified later on line 149. >> > I think line 149 is in the same constructor, so it is possible to declare it as final. javac does not like it. A final field can only be set once. Thanks, Max > >> That said, this variable is only used inside the constructor and I can make it local. Does that sound better to you? >> > It's a better update than using the final declaration. > > Thanks, > Xuelei > >> Thanks, >> Max >>> On Feb 14, 2020, at 1:24 AM, Xuelei Fan wrote: >>> >>> Do you want to declare the mutual variable as final object? Otherwise, looks fine to me. >>> >>> Xuelei >>> >>> On 2/13/2020 7:14 AM, Weijun Wang wrote: >>>> Correct the subject line. >>>>> On Feb 13, 2020, at 10:24 PM, Weijun Wang wrote: >>>>> >>>>> Please take a review at >>>>> >>>>> https://cr.openjdk.java.net/~weijun/8160818/webrev.00 >>>>> >>>>> I haven't updated the server side to check the mutual state, for compatibility. >>>>> >>>>> Thanks, >>>>> Max >>>>> From 1983-01-06 at gmx.net Fri Feb 14 13:42:14 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Fri, 14 Feb 2020 14:42:14 +0100 Subject: RFR 8160818: GssKrb5Client violates RFC 4752 In-Reply-To: <64C9E565-DA97-4355-B481-00B8099DC0E1@oracle.com> References: <71D350BC-8341-4B41-A2D3-A6DAD4836C8E@oracle.com> <7b1ab55b-3e56-c293-d8b1-58197bc130fe@oracle.com> <64C9E565-DA97-4355-B481-00B8099DC0E1@oracle.com> Message-ID: <87cfa2ce-eedf-3a0a-8c98-ef2320e13443@gmx.net> Am 2020-02-14 um 10:58 schrieb Weijun Wang: > Webrev updated at > > https://cr.openjdk.java.net/~weijun/8160818/webrev.01 This changes looks fine to me according to the RFC. Can this be backported to Java 8? Seems like a no-brainer. Michael From weijun.wang at oracle.com Fri Feb 14 14:53:35 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 14 Feb 2020 22:53:35 +0800 Subject: LDAP Channel Binding In-Reply-To: <3f09c638-1115-e765-a6f1-44b8be562f1d@gmx.net> References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> <3f09c638-1115-e765-a6f1-44b8be562f1d@gmx.net> Message-ID: > On Jan 22, 2020, at 6:31 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Am 2020-01-21 um 17:57 schrieb Bernd Eckenfels: >> Hello, >> >> I have now repeated the tests with LdapEnforceChannelBinding=2 and I >> could see the rejection with error code 80090346 for GSSAPI and >> DIGEST-MD5 with TLS. >> >> The simple bind with TLS and the GSSAPI or DIGEST-MD5 without TLS but >> with auth-int/conf all work with signing and binding required (I.e >> after Microsoft charged defaults in March) >> >> (Which makes the TLS binding a bit useless, but we should still think >> about supporting it.) >> >> Jgss seems to already allow to set it, so only JSSE needs to provide >> an api for sasl/jndi. > > How? I am confused! The Kerberos SaslClient does not use/set GSS channel > bindings. I don't see any in com.sun.security.sasl.gsskerb. Are you suggesting any change here? JGSS has channel binding method but the SASL mech has not called it. Thanks, Max > > The implication of LDAP channel binding is not to rely on mech binding, > but on the outer channel (TLS) binding. > > >> ________________________________ Von: Michael Osipov >> <1983-01-06 at gmx.net> Gesendet: Sonntag, Januar 19, 2020 11:15 AM An: >> Bernd Eckenfels Cc: security-dev at openjdk.java.net Betreff: Re: LDAP >> Channel Binding >> >> Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels: >>> You said it is confusing, but the bug you mentioned is only a >>> valid feature request, it does not talk about failing binds. I >>> would assume that Kerberos needs the binding token and the others >>> not. Unfortunatelly the doc from Microsoft is quite incomplete and >>> confusing. >> >> The problem is that JSSE Sun Impl documentation does not even >> mention TLS channel binding. To make things worse, I agree with you, >> Microsoft's documentation is horrible. It does not say whether we are >> talking about GSS-API channel binding or TLS channel biding. >> >> The best I have comeup with is >> https://github.com/WinRb/rubyntlm/issues/27 >> https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/dd639324(v=vs.90)?redirectedfrom=MSDN >> >> >>> So has anybody seeing failing TLS binds yet and if so, in which >>> condition? >> >> Yes, see https://stackoverflow.com/q/59756206/696632 >> >> What I can say is tht in our company auth-int has been mandatatory >> for several months now and my Java code always used auth-conf with >> GSSAPI mech w/o any flaws. >> >>> It is also not clear why AD proposes the auth. quality of >>> protection from digest-md5 if it is configured to reject it. So if >>> somebody can get Microsoft to look into this and provide details, >>> that would be great. >>> >>> Gruss Bernd >>> >>> >>> -- http://bernd.eckenfels.net ________________________________ >>> Von: Michael Osipov <1983-01-06 at gmx.net> Gesendet: Saturday, >>> January 18, 2020 9:39:08 PM An: Bernd Eckenfels >>> ; security-dev at openjdk.java.net >>> Betreff: Re: LDAP Channel Binding >>> >>> Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels: >>>> Hello, >>>> >>>> Some updates: >>>> >>>> Microsoft moved their automatic update of the LDAP policies in >>>> Windows Server updates to March 2020 (but still recommend to >>>> activate it earlier). >>>> >>>> And I did some tests: when you turn on the mandatory LDAP >>>> Signing, then simple binds or Digest-md5 binds over LDAP are >>>> rejected by NTDS. Both work over ldaps: (Implicite TLS, did not >>>> check STARTTLS). DIGEST-MD5 without TLS is also possible, but you >>>> have to request qop=auth-int. (Sidenode AD will reject digest-md5 >>>> with Auth-int over TLS). I did not Test GSSAPI or SPNEGO yet. >>>> >>>> The mandatory LDAP channel binding does not seem to make a >>>> problem/change. I suspect it only applies to Kerberos or NTLM >>>> which I still need to test. >>> >>> That is confusing because: >>> https://bugs.openjdk.java.net/browse/JDK-6491070 >>> >>> I am excited to see your GSSAPI mech results. You cannot test >>> SPENGO because the Java SASL factory does not suppor the GSS-SPNEGO >>> SASL mech. >>> >>>> PS: testcode >>>> https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0 >>> >>> You code looks wrong. Retrieving data from RootDSE does not >>> require a successful bind. It will work anonymously. You need to go >>> down the tree. >>> >>> Look at ldapsearch(1), if you don't provide -Y GSSAPI, it will >>> perform a simple search for supportedSASLMechanisms and pick the >>> best one it supports. This is the same as obtaining the root >>> naming contexts, this can be done anonymously too. >>> >>> Michael >>> >> >> > From xuelei.fan at oracle.com Fri Feb 14 17:05:30 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 14 Feb 2020 09:05:30 -0800 Subject: RFR 8160818: GssKrb5Client violates RFC 4752 In-Reply-To: <64C9E565-DA97-4355-B481-00B8099DC0E1@oracle.com> References: <71D350BC-8341-4B41-A2D3-A6DAD4836C8E@oracle.com> <7b1ab55b-3e56-c293-d8b1-58197bc130fe@oracle.com> <64C9E565-DA97-4355-B481-00B8099DC0E1@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 2/14/2020 1:58 AM, Weijun Wang wrote: > Webrev updated at > > https://cr.openjdk.java.net/~weijun/8160818/webrev.01 > >> On Feb 14, 2020, at 2:13 PM, Xuelei Fan wrote: >> >> On 2/13/2020 8:41 PM, Weijun Wang wrote: >>> It cannot be final because it was modified later on line 149. >>> >> I think line 149 is in the same constructor, so it is possible to declare it as final. > > javac does not like it. A final field can only be set once. > > Thanks, > Max > >> >>> That said, this variable is only used inside the constructor and I can make it local. Does that sound better to you? >>> >> It's a better update than using the final declaration. >> >> Thanks, >> Xuelei >> >>> Thanks, >>> Max >>>> On Feb 14, 2020, at 1:24 AM, Xuelei Fan wrote: >>>> >>>> Do you want to declare the mutual variable as final object? Otherwise, looks fine to me. >>>> >>>> Xuelei >>>> >>>> On 2/13/2020 7:14 AM, Weijun Wang wrote: >>>>> Correct the subject line. >>>>>> On Feb 13, 2020, at 10:24 PM, Weijun Wang wrote: >>>>>> >>>>>> Please take a review at >>>>>> >>>>>> https://cr.openjdk.java.net/~weijun/8160818/webrev.00 >>>>>> >>>>>> I haven't updated the server side to check the mutual state, for compatibility. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> > From RAJAN.HALADE at ORACLE.COM Fri Feb 14 21:14:55 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Fri, 14 Feb 2020 13:14:55 -0800 Subject: RFR: 8225128: Add exception for expiring DocuSign root to VerifyCACerts test Message-ID: May I request you to review this small update to add keynectisrootca to expiry check exempt list. JDK-8225068 will remove this certificate after expiry. diff -r af8e77a59bd8 test/jdk/sun/security/lib/cacerts/VerifyCACerts.java --- a/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Fri Feb 14 12:47:18 2020 -0800 +++ b/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Fri Feb 14 13:13:14 2020 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -259,6 +259,8 @@ { // Valid until: Tue Jul 09 14:40:36 EDT 2019 add("utnuserfirstobjectca [jdk]"); + // Valid until: Tue May 26 00:00:00 GMT 2020 + add("keynectisrootca [jdk]"); } }; Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1983-01-06 at gmx.net Sun Feb 16 10:02:16 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sun, 16 Feb 2020 11:02:16 +0100 Subject: LDAP Channel Binding In-Reply-To: References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> <3f09c638-1115-e765-a6f1-44b8be562f1d@gmx.net> Message-ID: <6e22c040-8ad1-2220-1037-5e2af260f538@gmx.net> Am 2020-02-14 um 15:53 schrieb Weijun Wang: > > >> On Jan 22, 2020, at 6:31 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: >> >> Am 2020-01-21 um 17:57 schrieb Bernd Eckenfels: >>> Hello, >>> >>> I have now repeated the tests with LdapEnforceChannelBinding=2 and I >>> could see the rejection with error code 80090346 for GSSAPI and >>> DIGEST-MD5 with TLS. >>> >>> The simple bind with TLS and the GSSAPI or DIGEST-MD5 without TLS but >>> with auth-int/conf all work with signing and binding required (I.e >>> after Microsoft charged defaults in March) >>> >>> (Which makes the TLS binding a bit useless, but we should still think >>> about supporting it.) >>> >>> Jgss seems to already allow to set it, so only JSSE needs to provide >>> an api for sasl/jndi. >> >> How? I am confused! The Kerberos SaslClient does not use/set GSS channel >> bindings. I don't see any in com.sun.security.sasl.gsskerb. > > Are you suggesting any change here? JGSS has channel binding method but the SASL mech has not called it. None yet, because we do not know what channel binding is actually used. We assume that MS uses TLS channel binding regardless of the underlying authentication scheme. M From christoph.langer at sap.com Sun Feb 16 21:52:01 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 16 Feb 2020 21:52:01 +0000 Subject: RFR: 8225128: Add exception for expiring DocuSign root to VerifyCACerts test In-Reply-To: References: Message-ID: Hi Rajan, looks good. Thanks for doing this. Best regards Christoph From: security-dev On Behalf Of Rajan Halade Sent: Freitag, 14. Februar 2020 22:15 To: security-dev at openjdk.java.net Subject: RFR: 8225128: Add exception for expiring DocuSign root to VerifyCACerts test May I request you to review this small update to add keynectisrootca to expiry check exempt list. JDK-8225068 will remove this certificate after expiry. diff -r af8e77a59bd8 test/jdk/sun/security/lib/cacerts/VerifyCACerts.java --- a/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Fri Feb 14 12:47:18 2020 -0800 +++ b/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Fri Feb 14 13:13:14 2020 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -259,6 +259,8 @@ { // Valid until: Tue Jul 09 14:40:36 EDT 2019 add("utnuserfirstobjectca [jdk]"); + // Valid until: Tue May 26 00:00:00 GMT 2020 + add("keynectisrootca [jdk]"); } }; Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Mon Feb 17 07:18:51 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 17 Feb 2020 07:18:51 +0000 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: <1b194dc5-24e9-2b17-9f1a-a8b5d869bc8b@oracle.com> References: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> <1b194dc5-24e9-2b17-9f1a-a8b5d869bc8b@oracle.com> Message-ID: <49c80d27-67c5-0977-c3f5-03a564364aac@redhat.com> On 13/02/2020 22:32, Bradford Wetmore wrote: snip... >> >> I wasn't looking at the web pages, but just at the patch file >> (https://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/jdk.patch) >> >> and comparing with the changesets from 11u. > > I'm a hardcore webrev/frames guys, so I wouldn't have thought to closely > look for this. > > I believe I've discovered a "bug" in webrev when specifying specific > revisions.? I use Mercurial Queues to handle my patches.? With these > revisions: > > ??? r1 = current tip > ??? r2 = ALPN patch applied > ??? r3 = PSS patch applied > > If I have applied ALPN + PSS and I use: > > ??? % webrev -r r2 -o webrev > > to generate the PSS-only changes, I don't get the git headers.? If I > don't specify -r, it defaults to r1 (current tip): > > ??? % webrev -o webrev > > Then I do see the git changes, but unfortunately both ALPN+PSS show up > in a unified webrev. > Yes, I've noticed this too when doing merges, as -r has to be used to avoid webrev bringing in everything along one branch of the merge. I'm not sure why though, as, in the script, the only difference when -r is specified seems to be the revision used. It does have its own logic for creating diffs so I can only imagine it doesn't correctly pick up the rename when -r is used. My best guess would be it doesn't pick up on renames correctly unless it can see them in hg status. >>> ---begin--- >>> 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) >>> ...deleted... >>> 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION >>> Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and >>> OpenJDK 8u >>> Reviewed-by: valeriep, weijun, coffeys, pkoppula >>> ---end--- >>> >> >> I'd still prefer it was something like: >> >> Summary: Contains elements of JDK-8051408 (see comments on JDK-8230978) >> >> the reason for this being that this changeset will then show up if >> someone searches the repository for 8051408, but won't trigger the >> database to create a backport issue for it. > > Changed. > >>> Did you want me to add you as a reviewer? >>> >> >> Please. > > Done. > > Brad > Thanks for the changes. Commits look good. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From anthony.scarpino at oracle.com Mon Feb 17 18:09:36 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 17 Feb 2020 10:09:36 -0800 Subject: RFR 8237218: Support NIST Curves verification in java implementation In-Reply-To: <328A5FFB-A9EC-479A-B009-7C2D26CB9EF3@oracle.com> References: <328A5FFB-A9EC-479A-B009-7C2D26CB9EF3@oracle.com> Message-ID: <08122126-c14c-ff12-bcbe-556b52cccfa8@oracle.com> The change looks fine. I'm trusting that the existing Known Answer Tests are proving your verifySignedDigest() is correct. You may want to comment in the code that your test depends on these method names. I was going to suggest simplifying the all the verifySigned*() methods until I saw the test was dependent on it. Tony On 2/13/20 3:06 AM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8237218/webrev.03/ > > The test is modified. Instead of adding a hacked ECDSASignature I'm using JDI to detect if the Java impl or the native impl is used. Two method names in ECDSASignature are modified to ease method lookup in the test. > > Thanks, > Max > >> On Feb 11, 2020, at 7:52 PM, Weijun Wang wrote: >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8237218/webrev.02/ >> >> A test is added that uses a patched ECDSASignature.java that exposes how the signature is verified. >> >> BTW, I also updated ECDSASignature.java a little to accept non SunEC keys, so that I can do some interop testing. If you believe this is unnecessary I can revert the change. >> >> Thanks, >> Max >> > From jamil.j.nimeh at oracle.com Mon Feb 17 18:31:26 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 17 Feb 2020 10:31:26 -0800 Subject: RFR 8239094: PKCS#9 ChallengePassword attribute does not allow for the UTF8String type Message-ID: <7c60d99f-608e-5b3e-4dc1-87c6de3abd76@oracle.com> Hello all, This is a quick fix to our handling of the PKCS#9 challengePassword attribute.? We currently conform to 1.1 of the spec, but RFC 2985 (PKCS#9 v2.0) has the type listed as a DirectoryString, which can be PrintableString, TeletexString, BMPString, UniversalString or UTF8String.? With this change, we'll be able to accommodate all those forms. I also took the liberty of cleaning up a few warnings that NetBeans had in the file, particularly the replacement of HashTable collections with HashMap since the former collection is obsolete and we really don't need a thread-safe collection for something private that's only written to in static initializers. Last question: Does anyone think we should be including IA5String as an allowed string encoding for challengePassword?? I know it is not a DirectoryString allowed type, but I have seen certain configurations for OpenSSL that would make challengePasswords with characters outside the PrintableString character set use IA5String.? Other than not being in line with the letter of the spec, I don't see the harm to allowing it given other sources for this attribute might encode it as IA5String, and you can't put anything in there that we wouldn't have to be able to handle otherwise in other string encodings (e.g. UTF8String). Right now, the review doesn't have IA5String, I'm adhering to the spec for this initial review. Bug: https://bugs.openjdk.java.net/browse/JDK-8239094 Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8239094/webrev.01/ Thanks, --Jamil From xuelei.fan at oracle.com Mon Feb 17 22:04:29 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Feb 2020 14:04:29 -0800 Subject: RFR JDK-8239264: Clearup the legacy ObjectIdentifier constructor from int array Message-ID: <04515ab0-4c1b-88bf-760b-06e47c86257a@oracle.com> Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8239264/webrev.00/ For historic reason, the JDK internal ObjectIdentifier instances are used to constructed with int arrays (ObjectIdentifier(int[])). It is not a performance and user friendly constructor. Removing this constructor could have a more clear coding style, and better performance, by using alternative constructors. Thanks, Xuelei From xuelei.fan at oracle.com Mon Feb 17 22:54:01 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Feb 2020 14:54:01 -0800 Subject: RFR 8239094: PKCS#9 ChallengePassword attribute does not allow for the UTF8String type In-Reply-To: <7c60d99f-608e-5b3e-4dc1-87c6de3abd76@oracle.com> References: <7c60d99f-608e-5b3e-4dc1-87c6de3abd76@oracle.com> Message-ID: <228603af-c85e-2603-463e-d5c459236678@oracle.com> On 2/17/2020 10:31 AM, Jamil Nimeh wrote: > Hello all, > > This is a quick fix to our handling of the PKCS#9 challengePassword > attribute.? We currently conform to 1.1 of the spec, but RFC 2985 > (PKCS#9 v2.0) has the type listed as a DirectoryString, which can be > PrintableString, TeletexString, BMPString, UniversalString or > UTF8String.? With this change, we'll be able to accommodate all those > forms. > > I also took the liberty of cleaning up a few warnings that NetBeans had > in the file, particularly the replacement of HashTable collections with > HashMap since the former collection is obsolete and we really don't need > a thread-safe collection for something private that's only written to in > static initializers. > > Last question: Does anyone think we should be including IA5String as an > allowed string encoding for challengePassword?? I know it is not a > DirectoryString allowed type, but I have seen certain configurations for > OpenSSL that would make challengePasswords with characters outside the > PrintableString character set use IA5String.? Other than not being in > line with the letter of the spec, I don't see the harm to allowing it > given other sources for this attribute might encode it as IA5String, and > you can't put anything in there that we wouldn't have to be able to > handle otherwise in other string encodings (e.g. UTF8String). > As IA5String is not included in the DirectoryString definition, I'm not sure if there are any potential ASN.1 encoding/decoding problems if it is included. I may not add it for now until there is a request. > Right now, the review doesn't have IA5String, I'm adhering to the spec > for this initial review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8239094 > Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8239094/webrev.01/ > It looks fine to me. Thanks, Xuelei From jamil.j.nimeh at oracle.com Mon Feb 17 23:30:37 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 17 Feb 2020 15:30:37 -0800 Subject: RFR JDK-8239264: Clearup the legacy ObjectIdentifier constructor from int array In-Reply-To: <04515ab0-4c1b-88bf-760b-06e47c86257a@oracle.com> References: <04515ab0-4c1b-88bf-760b-06e47c86257a@oracle.com> Message-ID: Looks good.? I like how this will simplify OID object generation for our internal uses. Nits: * V3Certificate.java: Copyright should use 2020. * AvaEqualsHashCode: Copyright should use 2020. * OidEquals & OidFormat: 2020 --Jamil On 2/17/2020 2:04 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > ?? http://cr.openjdk.java.net/~xuelei/8239264/webrev.00/ > > For historic reason, the JDK internal ObjectIdentifier instances are > used to constructed with int arrays (ObjectIdentifier(int[])).? It is > not a performance and user friendly constructor.? Removing this > constructor could have a more clear coding style, and better > performance, by using alternative constructors. > > Thanks, > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Feb 18 02:49:49 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Feb 2020 18:49:49 -0800 Subject: RFR JDK-8239264: Clearup the legacy ObjectIdentifier constructor from int array In-Reply-To: References: <04515ab0-4c1b-88bf-760b-06e47c86257a@oracle.com> Message-ID: Hi Jamil, Thanks for the review. I will update the copyright year before pushing. Xuelei On 2/17/2020 3:30 PM, Jamil Nimeh wrote: > Looks good.? I like how this will simplify OID object generation for our > internal uses. > > Nits: > > * V3Certificate.java: Copyright should use 2020. > * AvaEqualsHashCode: Copyright should use 2020. > * OidEquals & OidFormat: 2020 > > --Jamil > > On 2/17/2020 2:04 PM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> http://cr.openjdk.java.net/~xuelei/8239264/webrev.00/ >> >> For historic reason, the JDK internal ObjectIdentifier instances are >> used to constructed with int arrays (ObjectIdentifier(int[])).? It is >> not a performance and user friendly constructor.? Removing this >> constructor could have a more clear coding style, and better >> performance, by using alternative constructors. >> >> Thanks, >> Xuelei From matthias.baesken at sap.com Tue Feb 18 09:56:19 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Feb 2020 09:56:19 +0000 Subject: RFR [XS]: 8239333: test/jdk/security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java fails intermittent Message-ID: Hello, please review this small test change . AmazonCA.java fails intermittent In the discussion of https://bugs.openjdk.java.net/browse/JDK-8238157 it has been found that test AmazonCA.java fails intermittent . So to make this transparent we should add the intermittent key to the test (until this issue is resolved). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8239333 http://cr.openjdk.java.net/~mbaesken/webrevs/8239333.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Tue Feb 18 11:43:03 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 18 Feb 2020 11:43:03 +0000 Subject: LDAP Channel Binding In-Reply-To: <6e22c040-8ad1-2220-1037-5e2af260f538@gmx.net> References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> <3f09c638-1115-e765-a6f1-44b8be562f1d@gmx.net> , <6e22c040-8ad1-2220-1037-5e2af260f538@gmx.net> Message-ID: Hello Michael, I am not sure why you say so, when the channel binding option is turned on as Microsoft recommends and plans to default to in March the Java LDAP directory implementation will no longer be able to connect when using GSSAPI or DIGEST-MD5 over LDAPs. I think this should be possible. It will most likely require changes in JSSE, SASL, JNDI and JNDI-LDAP (both in implementations but also public APIs (in SASL maybe only properties?). It looks like JGSS might not need a new API. If there are also SPNEGO/NTLM external SASL mechanisms which are used with JNDI, that would be an additional check condition if the new APIs are enough to handle that. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Michael Osipov <1983-01-06 at gmx.net> Gesendet: Sunday, February 16, 2020 11:02:16 AM An: Weijun Wang Cc: Bernd Eckenfels ; security-dev at openjdk.java.net Betreff: Re: LDAP Channel Binding Am 2020-02-14 um 15:53 schrieb Weijun Wang: > > >> On Jan 22, 2020, at 6:31 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: >> >> Am 2020-01-21 um 17:57 schrieb Bernd Eckenfels: >>> Hello, >>> >>> I have now repeated the tests with LdapEnforceChannelBinding=2 and I >>> could see the rejection with error code 80090346 for GSSAPI and >>> DIGEST-MD5 with TLS. >>> >>> The simple bind with TLS and the GSSAPI or DIGEST-MD5 without TLS but >>> with auth-int/conf all work with signing and binding required (I.e >>> after Microsoft charged defaults in March) >>> >>> (Which makes the TLS binding a bit useless, but we should still think >>> about supporting it.) >>> >>> Jgss seems to already allow to set it, so only JSSE needs to provide >>> an api for sasl/jndi. >> >> How? I am confused! The Kerberos SaslClient does not use/set GSS channel >> bindings. I don't see any in com.sun.security.sasl.gsskerb. > > Are you suggesting any change here? JGSS has channel binding method but the SASL mech has not called it. None yet, because we do not know what channel binding is actually used. We assume that MS uses TLS channel binding regardless of the underlying authentication scheme. M -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Feb 18 14:18:03 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 18 Feb 2020 22:18:03 +0800 Subject: LDAP Channel Binding In-Reply-To: References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> <3f09c638-1115-e765-a6f1-44b8be562f1d@gmx.net> <6e22c040-8ad1-2220-1037-5e2af260f538@gmx.net> Message-ID: While JGSS has channel binding, the SASL/GSSAPI mech has not called it. I can add a SASL property which takes a byte[] value so when it's not null the implementation can set a ChannelBinding object using it as appData (with no addresses). But who will be setting the property? Whoever calls the SASL methods will need to provide the appData. Is it the TLS channel binding defined in RFC 5929? Then the TLS layer needs to provide a method to get the bytes. I've also read about the SASL/GS2 mech (RFC 5801) which claims to support channel binding. Do you know if Microsoft ever support it? Thanks, Max > On Feb 18, 2020, at 7:43 PM, Bernd Eckenfels wrote: > > Hello Michael, > > I am not sure why you say so, when the channel binding option is turned on as Microsoft recommends and plans to default to in March the Java LDAP directory implementation will no longer be able to connect when using GSSAPI or DIGEST-MD5 over LDAPs. > > I think this should be possible. It will most likely require changes in JSSE, SASL, JNDI and JNDI-LDAP (both in implementations but also public APIs (in SASL maybe only properties?). It looks like JGSS might not need a new API. > > If there are also SPNEGO/NTLM external SASL mechanisms which are used with JNDI, that would be an additional check condition if the new APIs are enough to handle that. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > Von: Michael Osipov <1983-01-06 at gmx.net> > Gesendet: Sunday, February 16, 2020 11:02:16 AM > An: Weijun Wang > Cc: Bernd Eckenfels ; security-dev at openjdk.java.net > Betreff: Re: LDAP Channel Binding > > Am 2020-02-14 um 15:53 schrieb Weijun Wang: > > > > > >> On Jan 22, 2020, at 6:31 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > >> > >> Am 2020-01-21 um 17:57 schrieb Bernd Eckenfels: > >>> Hello, > >>> > >>> I have now repeated the tests with LdapEnforceChannelBinding=2 and I > >>> could see the rejection with error code 80090346 for GSSAPI and > >>> DIGEST-MD5 with TLS. > >>> > >>> The simple bind with TLS and the GSSAPI or DIGEST-MD5 without TLS but > >>> with auth-int/conf all work with signing and binding required (I.e > >>> after Microsoft charged defaults in March) > >>> > >>> (Which makes the TLS binding a bit useless, but we should still think > >>> about supporting it.) > >>> > >>> Jgss seems to already allow to set it, so only JSSE needs to provide > >>> an api for sasl/jndi. > >> > >> How? I am confused! The Kerberos SaslClient does not use/set GSS channel > >> bindings. I don't see any in com.sun.security.sasl.gsskerb. > > > > Are you suggesting any change here? JGSS has channel binding method but the SASL mech has not called it. > > None yet, because we do not know what channel binding is actually used. > We assume that MS uses TLS channel binding regardless of the underlying > authentication scheme. > > M From jamil.j.nimeh at oracle.com Tue Feb 18 17:56:14 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 18 Feb 2020 09:56:14 -0800 Subject: RFR 8239094: PKCS#9 ChallengePassword attribute does not allow for the UTF8String type In-Reply-To: <7c60d99f-608e-5b3e-4dc1-87c6de3abd76@oracle.com> References: <7c60d99f-608e-5b3e-4dc1-87c6de3abd76@oracle.com> Message-ID: Code review updated to integrate changes from JDK-8239264: https://cr.openjdk.java.net/~jnimeh/reviews/8239094/webrev.02/ Thanks, --Jamil On 2/17/20 10:31 AM, Jamil Nimeh wrote: > Hello all, > > This is a quick fix to our handling of the PKCS#9 challengePassword > attribute.? We currently conform to 1.1 of the spec, but RFC 2985 > (PKCS#9 v2.0) has the type listed as a DirectoryString, which can be > PrintableString, TeletexString, BMPString, UniversalString or > UTF8String.? With this change, we'll be able to accommodate all those > forms. > > I also took the liberty of cleaning up a few warnings that NetBeans > had in the file, particularly the replacement of HashTable collections > with HashMap since the former collection is obsolete and we really > don't need a thread-safe collection for something private that's only > written to in static initializers. > > Last question: Does anyone think we should be including IA5String as > an allowed string encoding for challengePassword?? I know it is not a > DirectoryString allowed type, but I have seen certain configurations > for OpenSSL that would make challengePasswords with characters outside > the PrintableString character set use IA5String.? Other than not being > in line with the letter of the spec, I don't see the harm to allowing > it given other sources for this attribute might encode it as > IA5String, and you can't put anything in there that we wouldn't have > to be able to handle otherwise in other string encodings (e.g. > UTF8String). > > Right now, the review doesn't have IA5String, I'm adhering to the spec > for this initial review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8239094 > Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8239094/webrev.01/ > > > Thanks, > > --Jamil From ecki at zusammenkunft.net Tue Feb 18 18:02:20 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 18 Feb 2020 18:02:20 +0000 Subject: LDAP Channel Binding In-Reply-To: References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> <3f09c638-1115-e765-a6f1-44b8be562f1d@gmx.net> <6e22c040-8ad1-2220-1037-5e2af260f538@gmx.net> , Message-ID: Hello, > While JGSS has channel binding, the SASL/GSSAPI mech has not called it. > I can add a SASL property which takes a byte[] value so when it's not null the > implementation can set a ChannelBinding object using it as appData (with no addresses). I think this would be helpful in general, for sun-ldap this would probably need to set it itself, as it manages the sockets directly. If I understand correctly there are also different token formats, so it might need a way to request the Microsoft Format. Somewhere I read "Microsoft channel binding token ms-cbt" but I cant find it anymore. tls-unique is specified in rfc5929. > Then the TLS layer needs to provide a method to get the bytes. Yes JSSE would need a API to get to this, I think we discussed a handshake callback for this (and other applications like logging the master key). > I've also read about the SASL/GS2 mech (RFC 5801) which claims to support channel binding. Do you know if Microsoft ever support it? The AD implementation is fairly limited for years, the current documentation, specification (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e7d814a5-4cb5-4b0d-b408-09d79988b550) or rootDSE entries do not suggest this method is supported (At least I haven't seen it+). But on the other hand Microsoft might notice that they have neglected it and invest in interop, so... (I think OpenLDAP does support it). + I am not sure if it could actually happen by extending GSS-SPNEGO, but that would really be a strange layering of multiple security mechanisms. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Weijun Wang Gesendet: Dienstag, Februar 18, 2020 3:18 PM An: Bernd Eckenfels Cc: security-dev at openjdk.java.net Betreff: Re: LDAP Channel Binding While JGSS has channel binding, the SASL/GSSAPI mech has not called it. I can add a SASL property which takes a byte[] value so when it's not null the implementation can set a ChannelBinding object using it as appData (with no addresses). But who will be setting the property? Whoever calls the SASL methods will need to provide the appData. Is it the TLS channel binding defined in RFC 5929? Then the TLS layer needs to provide a method to get the bytes. I've also read about the SASL/GS2 mech (RFC 5801) which claims to support channel binding. Do you know if Microsoft ever support it? Thanks, Max > On Feb 18, 2020, at 7:43 PM, Bernd Eckenfels wrote: > > Hello Michael, > > I am not sure why you say so, when the channel binding option is turned on as Microsoft recommends and plans to default to in March the Java LDAP directory implementation will no longer be able to connect when using GSSAPI or DIGEST-MD5 over LDAPs. > > I think this should be possible. It will most likely require changes in JSSE, SASL, JNDI and JNDI-LDAP (both in implementations but also public APIs (in SASL maybe only properties?). It looks like JGSS might not need a new API. > > If there are also SPNEGO/NTLM external SASL mechanisms which are used with JNDI, that would be an additional check condition if the new APIs are enough to handle that. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > Von: Michael Osipov <1983-01-06 at gmx.net> > Gesendet: Sunday, February 16, 2020 11:02:16 AM > An: Weijun Wang > Cc: Bernd Eckenfels ; security-dev at openjdk.java.net > Betreff: Re: LDAP Channel Binding > > Am 2020-02-14 um 15:53 schrieb Weijun Wang: > > > > > >> On Jan 22, 2020, at 6:31 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > >> > >> Am 2020-01-21 um 17:57 schrieb Bernd Eckenfels: > >>> Hello, > >>> > >>> I have now repeated the tests with LdapEnforceChannelBinding=2 and I > >>> could see the rejection with error code 80090346 for GSSAPI and > >>> DIGEST-MD5 with TLS. > >>> > >>> The simple bind with TLS and the GSSAPI or DIGEST-MD5 without TLS but > >>> with auth-int/conf all work with signing and binding required (I.e > >>> after Microsoft charged defaults in March) > >>> > >>> (Which makes the TLS binding a bit useless, but we should still think > >>> about supporting it.) > >>> > >>> Jgss seems to already allow to set it, so only JSSE needs to provide > >>> an api for sasl/jndi. > >> > >> How? I am confused! The Kerberos SaslClient does not use/set GSS channel > >> bindings. I don't see any in com.sun.security.sasl.gsskerb. > > > > Are you suggesting any change here? JGSS has channel binding method but the SASL mech has not called it. > > None yet, because we do not know what channel binding is actually used. > We assume that MS uses TLS channel binding regardless of the underlying > authentication scheme. > > M -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Feb 19 07:48:24 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 19 Feb 2020 07:48:24 +0000 Subject: RFR [XS]: 8239333: test/jdk/security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java fails intermittent In-Reply-To: References: Message-ID: Hi Matthias, this makes sense. Change looks fine. Thanks for doing it. Cheers Christoph From: security-dev On Behalf Of Baesken, Matthias Sent: Dienstag, 18. Februar 2020 10:56 To: security-dev at openjdk.java.net Subject: [CAUTION] RFR [XS]: 8239333: test/jdk/security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java fails intermittent Hello, please review this small test change . AmazonCA.java fails intermittent In the discussion of https://bugs.openjdk.java.net/browse/JDK-8238157 it has been found that test AmazonCA.java fails intermittent . So to make this transparent we should add the intermittent key to the test (until this issue is resolved). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8239333 http://cr.openjdk.java.net/~mbaesken/webrevs/8239333.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Feb 19 12:54:49 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 19 Feb 2020 12:54:49 +0000 Subject: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect Message-ID: Hello, please review this small change to unix Java_sun_security_pkcs11_wrapper_PKCS11_connect . Here we miss a call to ReleaseStringUTFChars before early returns , e.g. these early returns . 127 // with the old JAR file jGetFunctionList is null, temporarily check for that 128 if (jGetFunctionList != NULL) { 129 getFunctionListStr = (*env)->GetStringUTFChars(env, jGetFunctionList, 0); 130 if (getFunctionListStr == NULL) { 131 return; 132 } ... 135 } 136 if (C_GetFunctionList == NULL) { 137 throwIOException(env, "ERROR: C_GetFunctionList == NULL"); 138 return; 139 } else if ( (systemErrorMessage = dlerror()) != NULL ){ 140 throwIOException(env, systemErrorMessage); 141 return; 142 } Fix is to move the last call to (*env)->ReleaseStringUTFChars(env, jPkcs11ModulePath, libraryNameStr); Some lines forward in the function Java_sun_security_pkcs11_wrapper_PKCS11_connect . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8239457 http://cr.openjdk.java.net/~mbaesken/webrevs/8239457.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Feb 19 13:35:31 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 19 Feb 2020 21:35:31 +0800 Subject: RFR 8237218: Support NIST Curves verification in java implementation In-Reply-To: <08122126-c14c-ff12-bcbe-556b52cccfa8@oracle.com> References: <328A5FFB-A9EC-479A-B009-7C2D26CB9EF3@oracle.com> <08122126-c14c-ff12-bcbe-556b52cccfa8@oracle.com> Message-ID: <8F9AA2DB-CBAC-4980-BDD0-69E0B80C4FD9@oracle.com> New webrev at http://cr.openjdk.java.net/~weijun/8237218/webrev.04/ Only test change. For each signature, modify it a little and check if verify fails. Thanks, Max > On Feb 18, 2020, at 2:09 AM, Anthony Scarpino wrote: > > The change looks fine. I'm trusting that the existing Known Answer Tests are proving your verifySignedDigest() is correct. > > You may want to comment in the code that your test depends on these method names. I was going to suggest simplifying the all the verifySigned*() methods until I saw the test was dependent on it. > > Tony > > > On 2/13/20 3:06 AM, Weijun Wang wrote: >> Webrev updated at >> http://cr.openjdk.java.net/~weijun/8237218/webrev.03/ >> The test is modified. Instead of adding a hacked ECDSASignature I'm using JDI to detect if the Java impl or the native impl is used. Two method names in ECDSASignature are modified to ease method lookup in the test. >> Thanks, >> Max >>> On Feb 11, 2020, at 7:52 PM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8237218/webrev.02/ >>> >>> A test is added that uses a patched ECDSASignature.java that exposes how the signature is verified. >>> >>> BTW, I also updated ECDSASignature.java a little to accept non SunEC keys, so that I can do some interop testing. If you believe this is unnecessary I can revert the change. >>> >>> Thanks, >>> Max >>> > From 1983-01-06 at gmx.net Wed Feb 19 21:54:49 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Wed, 19 Feb 2020 22:54:49 +0100 Subject: LDAP Channel Binding In-Reply-To: References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> <3f09c638-1115-e765-a6f1-44b8be562f1d@gmx.net> <6e22c040-8ad1-2220-1037-5e2af260f538@gmx.net> Message-ID: <8cff7a14-3c19-1cce-8ece-f698a8249e9d@gmx.net> After another research reading RFC 5929 as well as PostgreSQL support of CB with SASL SCRAM authentication mech, I believe we first need JDK-6491070 solved for tls-unique. That byte array has to be passed to org.ietf.jgss.ChannelBinding(byte[]). Addresses are not necessary because the outer context (TLS) has that data already. If so, the SASL layer needs to be changed to be aware of outside TLS context is present. Am 2020-02-18 um 15:18 schrieb Weijun Wang: > While JGSS has channel binding, the SASL/GSSAPI mech has not called it. I can add a SASL property which takes a byte[] value so when it's not null the implementation can set a ChannelBinding object using it as appData (with no addresses). This doesn't make any sense because the client does not have access to the SSLContext on the connection. LdapCtx needs to pass that data to SaslClient. We'd need a property to enable/disable channel binding. > But who will be setting the property? Whoever calls the SASL methods will need to provide the appData. Is it the TLS channel binding defined in RFC 5929? Then the TLS layer needs to provide a method to get the bytes. Correct. > I've also read about the SASL/GS2 mech (RFC 5801) which claims to support channel binding. Do you know if Microsoft ever support it? No, GS2 family, where auth-int and auth-conf have been dropped is *not* supported by AD. I believe that MS has simply modified SASL GS1 to support CB, to what extend that is unclear, e.g., gs2-cb-flag. Michael From michaelo at apache.org Tue Feb 18 18:17:20 2020 From: michaelo at apache.org (Michael Osipov) Date: Tue, 18 Feb 2020 19:17:20 +0100 Subject: LDAP Channel Binding In-Reply-To: References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> <3f09c638-1115-e765-a6f1-44b8be562f1d@gmx.net> <6e22c040-8ad1-2220-1037-5e2af260f538@gmx.net> Message-ID: <28180b5f-515d-aab7-b901-b74153964d86@apache.org> Since we don't know what type of channel binding is used, how do you want to fix that? Are we finally talking about TLS channel binding? But which tls-unique or tls-server-end-point? Can you provide a pcap from that comm as well as debug dump from JSSE and JNDI? Michael Am 2020-02-18 um 12:43 schrieb Bernd Eckenfels: > Hello Michael, > > I am not sure why you say so, when the channel binding option is turned on as Microsoft recommends and plans to default to in March the Java LDAP directory implementation will no longer be able to connect when using GSSAPI or DIGEST-MD5 over LDAPs. > > I think this should be possible. It will most likely require changes in JSSE, SASL, JNDI and JNDI-LDAP (both in implementations but also public APIs (in SASL maybe only properties?). It looks like JGSS might not need a new API. > > If there are also SPNEGO/NTLM external SASL mechanisms which are used with JNDI, that would be an additional check condition if the new APIs are enough to handle that. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > Von: Michael Osipov <1983-01-06 at gmx.net> > Gesendet: Sunday, February 16, 2020 11:02:16 AM > An: Weijun Wang > Cc: Bernd Eckenfels ; security-dev at openjdk.java.net > Betreff: Re: LDAP Channel Binding > > Am 2020-02-14 um 15:53 schrieb Weijun Wang: >> >> >>> On Jan 22, 2020, at 6:31 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: >>> >>> Am 2020-01-21 um 17:57 schrieb Bernd Eckenfels: >>>> Hello, >>>> >>>> I have now repeated the tests with LdapEnforceChannelBinding=2 and I >>>> could see the rejection with error code 80090346 for GSSAPI and >>>> DIGEST-MD5 with TLS. >>>> >>>> The simple bind with TLS and the GSSAPI or DIGEST-MD5 without TLS but >>>> with auth-int/conf all work with signing and binding required (I.e >>>> after Microsoft charged defaults in March) >>>> >>>> (Which makes the TLS binding a bit useless, but we should still think >>>> about supporting it.) >>>> >>>> Jgss seems to already allow to set it, so only JSSE needs to provide >>>> an api for sasl/jndi. >>> >>> How? I am confused! The Kerberos SaslClient does not use/set GSS channel >>> bindings. I don't see any in com.sun.security.sasl.gsskerb. >> >> Are you suggesting any change here? JGSS has channel binding method but the SASL mech has not called it. > > None yet, because we do not know what channel binding is actually used. > We assume that MS uses TLS channel binding regardless of the underlying > authentication scheme. > > M > From ecki at zusammenkunft.net Wed Feb 19 23:09:38 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 19 Feb 2020 23:09:38 +0000 Subject: LDAP Channel Binding In-Reply-To: <8cff7a14-3c19-1cce-8ece-f698a8249e9d@gmx.net> References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> <3f09c638-1115-e765-a6f1-44b8be562f1d@gmx.net> <6e22c040-8ad1-2220-1037-5e2af260f538@gmx.net> , <8cff7a14-3c19-1cce-8ece-f698a8249e9d@gmx.net> Message-ID: Just a small addition, cause I found some more details (but still not enough). there seems to be some precedence for tls-server-endpoint instead, which would be I guess a bit easier to produce: https://blogs.msdn.microsoft.com/openspecification/2013/03/26/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication/ https://docs.microsoft.com/en-us/windows/win32/secauthn/acceptsecuritycontext--kerberos The mentione QueryContextAttributes can provide both, endpoint or uniqueness attributes (but in some places like the HttpRequest I read that it only accepts endpoint type) It was also mentioned that the SPN is used in addition for binding, however I think this is already sent with GSSAPI and seems not to help (even when that would be fine in addition to proper cert checks) Somehow this thing seems like not have any additional protection property and is largely underdocumented. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Michael Osipov <1983-01-06 at gmx.net> Gesendet: Wednesday, February 19, 2020 10:54:49 PM Cc: security-dev at openjdk.java.net Betreff: Re: LDAP Channel Binding After another research reading RFC 5929 as well as PostgreSQL support of CB with SASL SCRAM authentication mech, I believe we first need JDK-6491070 solved for tls-unique. That byte array has to be passed to org.ietf.jgss.ChannelBinding(byte[]). Addresses are not necessary because the outer context (TLS) has that data already. If so, the SASL layer needs to be changed to be aware of outside TLS context is present. Am 2020-02-18 um 15:18 schrieb Weijun Wang: > While JGSS has channel binding, the SASL/GSSAPI mech has not called it. I can add a SASL property which takes a byte[] value so when it's not null the implementation can set a ChannelBinding object using it as appData (with no addresses). This doesn't make any sense because the client does not have access to the SSLContext on the connection. LdapCtx needs to pass that data to SaslClient. We'd need a property to enable/disable channel binding. > But who will be setting the property? Whoever calls the SASL methods will need to provide the appData. Is it the TLS channel binding defined in RFC 5929? Then the TLS layer needs to provide a method to get the bytes. Correct. > I've also read about the SASL/GS2 mech (RFC 5801) which claims to support channel binding. Do you know if Microsoft ever support it? No, GS2 family, where auth-int and auth-conf have been dropped is *not* supported by AD. I believe that MS has simply modified SASL GS1 to support CB, to what extend that is unclear, e.g., gs2-cb-flag. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Feb 20 13:01:59 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 20 Feb 2020 08:01:59 -0500 Subject: [15] RFR: 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property Message-ID: <90333e6e-ae45-85ff-83a7-5a77b3a4c2af@oracle.com> Please review this change to cleanup and consolidate the default value of the jdk.tls.legacyAlgorithms security property. The following changes have been made: 1. Changed K_NULL, C_NULL, M_NULL to NULL, which will cover all null cipher suites. The *_NULL algorithms were implementation details and not compliant with the specification of the property. 2. Changed DH_anon, ECDH_anon to anon, which will cover all cipher suites using anonymous authentication. 3. Changed RC4_128, RC4_40 to RC4, which will cover all cipher suites using RC4 for encryption. 4. Changed DES_CBC, DES40_CBC to DES, which will cover all cipher suites using DES for encryption. I also added a new regression test. CSR: https://bugs.openjdk.java.net/browse/JDK-8239377 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8238560/webrev.00/ Thanks, Sean From xuelei.fan at oracle.com Thu Feb 20 16:43:54 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 20 Feb 2020 08:43:54 -0800 Subject: [15] RFR: 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property In-Reply-To: <90333e6e-ae45-85ff-83a7-5a77b3a4c2af@oracle.com> References: <90333e6e-ae45-85ff-83a7-5a77b3a4c2af@oracle.com> Message-ID: <87dd2fde-f247-1002-ba19-bf7a16b315a3@oracle.com> Thanks for the cleanup. I added myself as reviewer for the CSR, and the webrev looks fine to me. Xuelei On 2/20/2020 5:01 AM, Sean Mullan wrote: > Please review this change to cleanup and consolidate the default value > of the jdk.tls.legacyAlgorithms security property. The following changes > have been made: > > 1. Changed K_NULL, C_NULL, M_NULL to NULL, which will cover all null > cipher suites. The *_NULL algorithms were implementation details and not > compliant with the specification of the property. > > 2. Changed DH_anon, ECDH_anon to anon, which will cover all cipher > suites using anonymous authentication. > > 3. Changed RC4_128, RC4_40 to RC4, which will cover all cipher suites > using RC4 for encryption. > > 4. Changed DES_CBC, DES40_CBC to DES, which will cover all cipher suites > using DES for encryption. > > I also added a new regression test. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8239377 > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8238560/webrev.00/ > > Thanks, > Sean From ecki at zusammenkunft.net Thu Feb 20 17:48:25 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 20 Feb 2020 17:48:25 +0000 Subject: [15] RFR: 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property In-Reply-To: <90333e6e-ae45-85ff-83a7-5a77b3a4c2af@oracle.com> References: <90333e6e-ae45-85ff-83a7-5a77b3a4c2af@oracle.com> Message-ID: Hello Sean, Are the separate entries for 3DES and DES needed or can they also be collapsed? BTW i am always unsre about the interactions of setting the Protocol and the enabled ciphers so I am in the habit to set the protocols before using getEnabled or setting enabled ciphers. I guess it makes no difference but for that reason I would move line 76 before 73 in the test. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Sean Mullan Gesendet: Thursday, February 20, 2020 2:01:59 PM An: security Dev OpenJDK Betreff: [15] RFR: 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property Please review this change to cleanup and consolidate the default value of the jdk.tls.legacyAlgorithms security property. The following changes have been made: 1. Changed K_NULL, C_NULL, M_NULL to NULL, which will cover all null cipher suites. The *_NULL algorithms were implementation details and not compliant with the specification of the property. 2. Changed DH_anon, ECDH_anon to anon, which will cover all cipher suites using anonymous authentication. 3. Changed RC4_128, RC4_40 to RC4, which will cover all cipher suites using RC4 for encryption. 4. Changed DES_CBC, DES40_CBC to DES, which will cover all cipher suites using DES for encryption. I also added a new regression test. CSR: https://bugs.openjdk.java.net/browse/JDK-8239377 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8238560/webrev.00/ Thanks, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1983-01-06 at gmx.net Thu Feb 20 18:41:24 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Thu, 20 Feb 2020 19:41:24 +0100 Subject: RFR 8160818: GssKrb5Client violates RFC 4752 In-Reply-To: References: <71D350BC-8341-4B41-A2D3-A6DAD4836C8E@oracle.com> <7b1ab55b-3e56-c293-d8b1-58197bc130fe@oracle.com> <64C9E565-DA97-4355-B481-00B8099DC0E1@oracle.com> <87cfa2ce-eedf-3a0a-8c98-ef2320e13443@gmx.net> <62078744-D9C2-4534-9233-AE75D21E5F98@oracle.com> Message-ID: Am 2020-02-20 um 03:57 schrieb Weijun Wang:> Ping again. > >> On Feb 14, 2020, at 10:51 PM, Weijun Wang wrote: >> >> >> >>> On Feb 14, 2020, at 9:42 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: >>> >>> Am 2020-02-14 um 10:58 schrieb Weijun Wang: >>>> Webrev updated at >>>> >>>> https://cr.openjdk.java.net/~weijun/8160818/webrev.01 >>> >>> This changes looks fine to me according to the RFC. >>> >>> Can this be backported to Java 8? Seems like a no-brainer. >> >> I'll ask the sustaining team. >> >> At the same time, can you tell me why this is suddenly urgent? I don't know which item in [1] is enforcing the check. I'll be happy to use your explanation as a justification for the backport. Yes, sure. JDK-8160818 existed eversince I have engaged with JNDI and LDAP. I am the reporter of the bug. The problem is two-fold: 1. The SASL GSSAPI mech requires at least auth-int to be present 2. "Signing" as called by MS is auth-int. If this is enabled via GPO on all domain controllers people's code will start to fail because the default mech configuration is faulty. Most will not start to analyze with Wireshark because it is too complex. The will start to panic. To avoid such a situation a proper/correct default needs to be set. For that reason, I have added a workaround in my public wrapper lib [1] until this is fixed. [1] http://dirctxsrc.sourceforge.net/xref/net/sf/michaelo/dirctxsrc/DirContextSource.html#L289 Michael From 1983-01-06 at gmx.net Thu Feb 20 18:44:16 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Thu, 20 Feb 2020 19:44:16 +0100 Subject: Re Re: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> Message-ID: Has there been any progress on this? I can see that JDK-8162628 is targeted for 15, but not fixed yet. This would be a tremendous improvement in JDK 15 and in 8/11 if backported. I don't expect PEM to be the default in 8/11, but configurable for PEM. Michael Am 2019-08-16 um 03:36 schrieb Weijun Wang: > > >> On Aug 16, 2019, at 2:49 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: >> >>>>> https://cr.openjdk.java.net/~weijun/8162628/webrev.00 >>>>> > >>>> KeyStoreDelegator: >>>> * Please avoid iterating a list like an array and using List#get(int). >>> >>> But I have 2 lists. It is a Pair but Java does not have it, and I don't like Map::Entry very much. >> >> Granted, by why not use two iterators then? > > How? > >> >>>> >>>> I will also pass a pretty large cacerts with public CA and our CAs and >>>> see wether your parser doesn't choke on it. >> >> Did you get a change to parse the file I have sent you? > > Yes I tried. keytool -list accepts it and is using SHA-256 fingerprint as aliases. > >> >>> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. >> >> Commons Codec has a Base64InputStream. Maybe the entire file should be read as a stream with specific substreams >> for the base64 parts? That is, of course, much more coding work. > > If the certs are to be parsed at loading, I'll see if I can inline a BASE64 decoder inside so it recognizes everything from BASE64 chars, -----'s, and @alias. If the cert parsing can be delayed I'll see if there is a quicker way to find the end of the cert (maybe read the first few bytes and get the length). > >> >> Looking forward for your improvements. >> >> Do you see a change to backport this code to 11 and 8, but not changing the default keystore type? With that >> this great change could be available way earlier than Java 17 for most LTS people. > > There is no need to change the default keystore type if keystore.type.compat=true and we allows a PEM keystore to be loadable as a JKS keystore. > > I cannot say if this can be backported. It depends on the policy. On the other hand, you also know there are other vendors of JDK that could have different policies. > > Thanks, > Max > >> >> Regards, >> >> Michael > > From sean.mullan at oracle.com Thu Feb 20 20:59:56 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 20 Feb 2020 15:59:56 -0500 Subject: [15] RFR: 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property In-Reply-To: References: <90333e6e-ae45-85ff-83a7-5a77b3a4c2af@oracle.com> Message-ID: <0f2176eb-5cc6-228b-7c10-ac69a004813e@oracle.com> Hi Bernd, On 2/20/20 12:48 PM, Bernd Eckenfels wrote: > Hello Sean, > > Are the separate entries for 3DES and DES needed or can they also be > collapsed? DES will not match 3DES if that's what you mean, so yes the separate entries are needed. > BTW i am always unsre about the interactions of setting the Protocol and > the enabled ciphers so I am in the habit to set the protocols before > using getEnabled or setting enabled ciphers. I guess it makes no > difference but for that reason I would move line 76 before 73 ?in the test. I don't think it matters, but I switched it in any case. Also, your comment made me realize I missed testing a 3DES suite, so I added "TLS_RSA_WITH_3DES_EDE_CBC_SHA" to the list of LEGACY_SUITES in the test. It's a minor change, so I'm not posting another webrev. --Sean > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Sean Mullan > *Gesendet:* Thursday, February 20, 2020 2:01:59 PM > *An:* security Dev OpenJDK > *Betreff:* [15] RFR: 8238560: Cleanup and consolidate algorithms in the > jdk.tls.legacyAlgorithms security property > Please review this change to cleanup and consolidate the default value > of the jdk.tls.legacyAlgorithms security property. The following changes > have been made: > > 1. Changed K_NULL, C_NULL, M_NULL to NULL, which will cover all null > cipher suites. The *_NULL algorithms were implementation details and not > compliant with the specification of the property. > > 2. Changed DH_anon, ECDH_anon to anon, which will cover all cipher > suites using anonymous authentication. > > 3. Changed RC4_128, RC4_40 to RC4, which will cover all cipher suites > using RC4 for encryption. > > 4. Changed DES_CBC, DES40_CBC to DES, which will cover all cipher suites > using DES for encryption. > > I also added a new regression test. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8239377 > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8238560/webrev.00/ > > Thanks, > Sean From anthony.scarpino at oracle.com Fri Feb 21 04:03:25 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 20 Feb 2020 20:03:25 -0800 Subject: RFR 8237218: Support NIST Curves verification in java implementation In-Reply-To: <8F9AA2DB-CBAC-4980-BDD0-69E0B80C4FD9@oracle.com> References: <328A5FFB-A9EC-479A-B009-7C2D26CB9EF3@oracle.com> <08122126-c14c-ff12-bcbe-556b52cccfa8@oracle.com> <8F9AA2DB-CBAC-4980-BDD0-69E0B80C4FD9@oracle.com> Message-ID: <3d566a78-ac9b-d14a-9ca5-d252d2288f2d@oracle.com> I'm ok with this update Tony On 2/19/20 5:35 AM, Weijun Wang wrote: > New webrev at > > http://cr.openjdk.java.net/~weijun/8237218/webrev.04/ > > Only test change. For each signature, modify it a little and check if verify fails. > > Thanks, > Max > >> On Feb 18, 2020, at 2:09 AM, Anthony Scarpino wrote: >> >> The change looks fine. I'm trusting that the existing Known Answer Tests are proving your verifySignedDigest() is correct. >> >> You may want to comment in the code that your test depends on these method names. I was going to suggest simplifying the all the verifySigned*() methods until I saw the test was dependent on it. >> >> Tony >> >> >> On 2/13/20 3:06 AM, Weijun Wang wrote: >>> Webrev updated at >>> http://cr.openjdk.java.net/~weijun/8237218/webrev.03/ >>> The test is modified. Instead of adding a hacked ECDSASignature I'm using JDI to detect if the Java impl or the native impl is used. Two method names in ECDSASignature are modified to ease method lookup in the test. >>> Thanks, >>> Max >>>> On Feb 11, 2020, at 7:52 PM, Weijun Wang wrote: >>>> >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8237218/webrev.02/ >>>> >>>> A test is added that uses a patched ECDSASignature.java that exposes how the signature is verified. >>>> >>>> BTW, I also updated ECDSASignature.java a little to accept non SunEC keys, so that I can do some interop testing. If you believe this is unnecessary I can revert the change. >>>> >>>> Thanks, >>>> Max >>>> >> > From weijun.wang at oracle.com Fri Feb 21 07:22:49 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 21 Feb 2020 15:22:49 +0800 Subject: Re Re: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> Message-ID: > On Feb 21, 2020, at 2:44 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Has there been any progress on this? No. There might be some performance impact. Also, we thought about embedding the certs inside JDK code. Users can still add their own trusted CA cert to the cacerts file, but this means one cannot just read this file and list all of them. Thanks, Max > > I can see that JDK-8162628 is targeted for 15, but not fixed yet. > This would be a tremendous improvement in JDK 15 and in 8/11 if > backported. I don't expect PEM to be the default in 8/11, but > configurable for PEM. > > Michael > > > Am 2019-08-16 um 03:36 schrieb Weijun Wang: >> >> >>> On Aug 16, 2019, at 2:49 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: >>> >>>>>> https://cr.openjdk.java.net/~weijun/8162628/webrev.00 >>>>>> >> >>>>> KeyStoreDelegator: >>>>> * Please avoid iterating a list like an array and using List#get(int). >>>> >>>> But I have 2 lists. It is a Pair but Java does not have it, and I don't like Map::Entry very much. >>> >>> Granted, by why not use two iterators then? >> >> How? >> >>> >>>>> >>>>> I will also pass a pretty large cacerts with public CA and our CAs and >>>>> see wether your parser doesn't choke on it. >>> >>> Did you get a change to parse the file I have sent you? >> >> Yes I tried. keytool -list accepts it and is using SHA-256 fingerprint as aliases. >> >>> >>>> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. >>> >>> Commons Codec has a Base64InputStream. Maybe the entire file should be read as a stream with specific substreams >>> for the base64 parts? That is, of course, much more coding work. >> >> If the certs are to be parsed at loading, I'll see if I can inline a BASE64 decoder inside so it recognizes everything from BASE64 chars, -----'s, and @alias. If the cert parsing can be delayed I'll see if there is a quicker way to find the end of the cert (maybe read the first few bytes and get the length). >> >>> >>> Looking forward for your improvements. >>> >>> Do you see a change to backport this code to 11 and 8, but not changing the default keystore type? With that >>> this great change could be available way earlier than Java 17 for most LTS people. >> >> There is no need to change the default keystore type if keystore.type.compat=true and we allows a PEM keystore to be loadable as a JKS keystore. >> >> I cannot say if this can be backported. It depends on the policy. On the other hand, you also know there are other vendors of JDK that could have different policies. >> >> Thanks, >> Max >> >>> >>> Regards, >>> >>> Michael >> >> > From weijun.wang at oracle.com Fri Feb 21 07:40:53 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 21 Feb 2020 15:40:53 +0800 Subject: RFR 8160818: GssKrb5Client violates RFC 4752 In-Reply-To: References: <71D350BC-8341-4B41-A2D3-A6DAD4836C8E@oracle.com> <7b1ab55b-3e56-c293-d8b1-58197bc130fe@oracle.com> <64C9E565-DA97-4355-B481-00B8099DC0E1@oracle.com> <87cfa2ce-eedf-3a0a-8c98-ef2320e13443@gmx.net> <62078744-D9C2-4534-9233-AE75D21E5F98@oracle.com> Message-ID: > On Feb 21, 2020, at 2:41 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Am 2020-02-20 um 03:57 schrieb Weijun Wang:> Ping again. > > > >> On Feb 14, 2020, at 10:51 PM, Weijun Wang > wrote: > >> > >> > >> > >>> On Feb 14, 2020, at 9:42 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: > >>> > >>> Am 2020-02-14 um 10:58 schrieb Weijun Wang: > >>>> Webrev updated at > >>>> > >>>> https://cr.openjdk.java.net/~weijun/8160818/webrev.01 > >>> > >>> This changes looks fine to me according to the RFC. > >>> > >>> Can this be backported to Java 8? Seems like a no-brainer. > >> > >> I'll ask the sustaining team. > >> > >> At the same time, can you tell me why this is suddenly urgent? I > don't know which item in [1] is enforcing the check. I'll be happy to > use your explanation as a justification for the backport. > Yes, sure. JDK-8160818 existed eversince I have engaged with JNDI and > LDAP. I am the reporter of the bug. The problem is two-fold: > > 1. The SASL GSSAPI mech requires at least auth-int to be present Why? > 2. "Signing" as called by MS is auth-int. If this is enabled via GPO on > all domain controllers people's code will start to fail because the > default mech configuration is faulty. Most will not start to analyze > with Wireshark because it is too complex. The will start to panic. To > avoid such a situation a proper/correct default needs to be set. Has the fix for this bug avoided this problem? "auth" is still the default. It looks this requires the default qop for SASL to be auth-int, or at least for the GSSAPI mechanism. Thanks, Max > > For that reason, I have added a workaround in my public wrapper lib [1] > until this is fixed. > > [1] > https://urldefense.com/v3/__http://dirctxsrc.sourceforge.net/xref/net/sf/michaelo/dirctxsrc/DirContextSource.html*L289__;Iw!!GqivPVa7Brio!IqTwdzAHnBvdqVVo_XepmDXCME5i6IpCfpwzy8ge2GmSZ7cZNnUb7jJH-zCEpaoURw$ > Michael From matthias.baesken at sap.com Fri Feb 21 12:17:32 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 21 Feb 2020 12:17:32 +0000 Subject: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect Message-ID: Ping - any reviews please ? Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 19. Februar 2020 13:55 To: security-dev at openjdk.java.net Subject: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect Hello, please review this small change to unix Java_sun_security_pkcs11_wrapper_PKCS11_connect . Here we miss a call to ReleaseStringUTFChars before early returns , e.g. these early returns . 127 // with the old JAR file jGetFunctionList is null, temporarily check for that 128 if (jGetFunctionList != NULL) { 129 getFunctionListStr = (*env)->GetStringUTFChars(env, jGetFunctionList, 0); 130 if (getFunctionListStr == NULL) { 131 return; 132 } ... 135 } 136 if (C_GetFunctionList == NULL) { 137 throwIOException(env, "ERROR: C_GetFunctionList == NULL"); 138 return; 139 } else if ( (systemErrorMessage = dlerror()) != NULL ){ 140 throwIOException(env, systemErrorMessage); 141 return; 142 } Fix is to move the last call to (*env)->ReleaseStringUTFChars(env, jPkcs11ModulePath, libraryNameStr); Some lines forward in the function Java_sun_security_pkcs11_wrapper_PKCS11_connect . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8239457 http://cr.openjdk.java.net/~mbaesken/webrevs/8239457.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Feb 21 12:47:15 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Feb 2020 12:47:15 +0000 Subject: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect In-Reply-To: References: Message-ID: Hi Matthias, this looks correct. Thanks for taking care of it. Best regards Christoph From: Baesken, Matthias Sent: Freitag, 21. Februar 2020 13:18 To: security-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect Ping - any reviews please ? Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 19. Februar 2020 13:55 To: security-dev at openjdk.java.net Subject: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect Hello, please review this small change to unix Java_sun_security_pkcs11_wrapper_PKCS11_connect . Here we miss a call to ReleaseStringUTFChars before early returns , e.g. these early returns . 127 // with the old JAR file jGetFunctionList is null, temporarily check for that 128 if (jGetFunctionList != NULL) { 129 getFunctionListStr = (*env)->GetStringUTFChars(env, jGetFunctionList, 0); 130 if (getFunctionListStr == NULL) { 131 return; 132 } ... 135 } 136 if (C_GetFunctionList == NULL) { 137 throwIOException(env, "ERROR: C_GetFunctionList == NULL"); 138 return; 139 } else if ( (systemErrorMessage = dlerror()) != NULL ){ 140 throwIOException(env, systemErrorMessage); 141 return; 142 } Fix is to move the last call to (*env)->ReleaseStringUTFChars(env, jPkcs11ModulePath, libraryNameStr); Some lines forward in the function Java_sun_security_pkcs11_wrapper_PKCS11_connect . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8239457 http://cr.openjdk.java.net/~mbaesken/webrevs/8239457.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Fri Feb 21 13:01:08 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 21 Feb 2020 13:01:08 +0000 Subject: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect In-Reply-To: References: Message-ID: Thanks ! May I get a second review ? Best regards, Matthias From: Langer, Christoph Sent: Freitag, 21. Februar 2020 13:47 To: Baesken, Matthias ; security-dev at openjdk.java.net Subject: RE: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect Hi Matthias, this looks correct. Thanks for taking care of it. Best regards Christoph From: Baesken, Matthias > Sent: Freitag, 21. Februar 2020 13:18 To: security-dev at openjdk.java.net Cc: Langer, Christoph > Subject: RE: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect Ping - any reviews please ? Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 19. Februar 2020 13:55 To: security-dev at openjdk.java.net Subject: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect Hello, please review this small change to unix Java_sun_security_pkcs11_wrapper_PKCS11_connect . Here we miss a call to ReleaseStringUTFChars before early returns , e.g. these early returns . 127 // with the old JAR file jGetFunctionList is null, temporarily check for that 128 if (jGetFunctionList != NULL) { 129 getFunctionListStr = (*env)->GetStringUTFChars(env, jGetFunctionList, 0); 130 if (getFunctionListStr == NULL) { 131 return; 132 } ... 135 } 136 if (C_GetFunctionList == NULL) { 137 throwIOException(env, "ERROR: C_GetFunctionList == NULL"); 138 return; 139 } else if ( (systemErrorMessage = dlerror()) != NULL ){ 140 throwIOException(env, systemErrorMessage); 141 return; 142 } Fix is to move the last call to (*env)->ReleaseStringUTFChars(env, jPkcs11ModulePath, libraryNameStr); Some lines forward in the function Java_sun_security_pkcs11_wrapper_PKCS11_connect . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8239457 http://cr.openjdk.java.net/~mbaesken/webrevs/8239457.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Feb 21 13:09:59 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Feb 2020 13:09:59 +0000 Subject: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect In-Reply-To: References: Message-ID: On 21/02/2020 13:01, Baesken, Matthias wrote: > > Thanks ! May I get a second review ? > > Looks okay to me too. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kusrinivasan at vmware.com Fri Feb 21 17:24:26 2020 From: kusrinivasan at vmware.com (Kumar Srinivasan) Date: Fri, 21 Feb 2020 17:24:26 +0000 Subject: OpenJDK11u: Backward incompatible behavior Message-ID: Hi security-folk, At VMware while upgrading our application to OpenJDK11u, we have encountered what seems to be a serious behavior issue. The issue AFAICT seems to have stemmed from the work for TLS1.3 and JDK-8196584. Overview: With OpenJDK11 the end-points are closed immediately with TLS alerts raised when an exception is received. This is not the case with JDK8 the socket is not closed allowing retries. I have filed: JDK-8239798 (with a reproducer), this issue was also reported to Azul and they have filed: JDK-8239788. Can you please evaluate this at the earliest, this is a serious show stopper for VMware. Thank Kumar Srinivasan VMware -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Feb 21 18:14:51 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 21 Feb 2020 10:14:51 -0800 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: Message-ID: <011a9bca-3e60-fa37-af13-bc495acaee23@oracle.com> I will look into the issue. BTW, I closed JDK-8239788 as duplicate of JDK-8239798. Thanks, Xuelei On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: > Hi security-folk, > > At VMware while upgrading our application to OpenJDK11u, we have > encountered what seems to be a serious behavior issue. > The issue AFAICT seems to have stemmed from the work for TLS1.3 and > JDK-8196584 . > > Overview: > With OpenJDK11 the end-points are closed immediately with TLS alerts > raised when an exception is received. > This is not the case with JDK8 the socket is not closed allowing retries. > > I have filed: JDK-8239798 (with a reproducer), this issue was also > reported ?to Azul and they have filed: JDK-8239788. > > Can you please evaluate this at the earliest, this is a serious show > stopper for VMware. > > Thank > Kumar Srinivasan > VMware From xuelei.fan at oracle.com Sat Feb 22 19:20:14 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 22 Feb 2020 11:20:14 -0800 Subject: RFR JDK-8233619: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 Message-ID: <3c88d9b8-5a94-1038-5433-afc0d3d403f9@oracle.com> Hi, Could I have the following update reviewed? http://cr.openjdk.java.net/~xuelei/8233619/webrev.01/ For TLS 1.2 and previous versions, the ChangeCipherSpec message is always delivered before the Finished handshake message. ChangeCipherSpec is not a handshake message,and cannot be wrapped in one TLS record. The processing of Finished handshake message is unlikely to be delegated. However, for TLS 1.3 there it no non-handshake messages delivered immediately before Finished message. Then, the delegated task could happen before consuming the Finished message, and then the Finished message is handled in the delegated action, together with other handshake message in the flight. The FINISHED does not present in such situation. It would be complicated to consume the Finished message separately after the delegated tasks. Luckily, currently the post-handshake NewSessionTicket message is always used, immediately after the handshake message. The FINISHED status could present for producing and consuming the NewSessionTicket post-handshake message. Thanks, Xuelei From alexey at azul.com Mon Feb 24 15:58:21 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 24 Feb 2020 15:58:21 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: Message-ID: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> Hello, I have been working on this issue for some time already. The patch below adds java.net.SocketTimeoutException handling during TLS handshake negotiation. This functionality seems to have been missed during the TLSv1.3 implementation ( JDK-8196584 ) Tested with JDK11 and higher. JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and https://bugs.openjdk.java.net/browse/JDK-8239788 Thank you, Alexey > On 22 Feb 2020, at 15:00, security-dev-request at openjdk.java.net wrote: > > I will look into the issue. > > BTW, I closed JDK-8239788 as duplicate of JDK-8239798. > > Thanks, > Xuelei > > On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: >> Hi security-folk, >> >> At VMware while upgrading our application to OpenJDK11u, we have >> encountered what seems to be a serious behavior issue. >> The issue AFAICT seems to have stemmed from the work for TLS1.3 and >> JDK-8196584 . >> >> Overview: >> With OpenJDK11 the end-points are closed immediately with TLS alerts >> raised when an exception is received. >> This is not the case with JDK8 the socket is not closed allowing retries. >> >> I have filed: JDK-8239798 (with a reproducer), this issue was also >> reported ?to Azul and they have filed: JDK-8239788. >> >> Can you please evaluate this at the earliest, this is a serious show >> stopper for VMware. >> >> Thank >> Kumar Srinivasan >> VMware > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From kusrinivasan at vmware.com Mon Feb 24 16:32:03 2020 From: kusrinivasan at vmware.com (Kumar Srinivasan) Date: Mon, 24 Feb 2020 16:32:03 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> Message-ID: Hi Alexey, Thanks for the update. I glossed over the changes. Observation: I don?t see a regression test in your webrev, is this still a work in progress ? I am very surprised, how a simple socket feature such as this, escape the JSN-test dragnet in the first place ? Kumar On Feb 24, 2020, at 7:58 AM, Alexey Bakhtin > wrote: Hello, I have been working on this issue for some time already. The patch below adds java.net.SocketTimeoutException handling during TLS handshake negotiation. This functionality seems to have been missed during the TLSv1.3 implementation ( JDK-8196584 ) Tested with JDK11 and higher. JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and https://bugs.openjdk.java.net/browse/JDK-8239788 Thank you, Alexey On 22 Feb 2020, at 15:00, security-dev-request at openjdk.java.net wrote: I will look into the issue. BTW, I closed JDK-8239788 as duplicate of JDK-8239798. Thanks, Xuelei On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: Hi security-folk, At VMware while upgrading our application to OpenJDK11u, we have encountered what seems to be a serious behavior issue. The issue AFAICT seems to have stemmed from the work for TLS1.3 and JDK-8196584 . Overview: With OpenJDK11 the end-points are closed immediately with TLS alerts raised when an exception is received. This is not the case with JDK8 the socket is not closed allowing retries. I have filed: JDK-8239798 (with a reproducer), this issue was also reported ?to Azul and they have filed: JDK-8239788. Can you please evaluate this at the earliest, this is a serious show stopper for VMware. Thank Kumar Srinivasan VMware -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Feb 24 18:41:50 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 24 Feb 2020 10:41:50 -0800 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> Message-ID: Hi Alexey, Thanks for working on this issue. Do you plan to fix it for JDK 15, the current JDK reposiroty? I need more time for evaluate the fix. For example, I'm not sure if we could always throw InterruptedIOException to applications, even for getSession(). Regards, Xuelei On 2/24/2020 7:58 AM, Alexey Bakhtin wrote: > Hello, > > I have been working on this issue for some time already. > The patch below adds ?java.net.SocketTimeoutException handling during > TLS handshake negotiation.?This functionality seems to have been missed > during the TLSv1.3 implementation ( JDK-8196584?) > Tested with JDK11 and higher. > > JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ > > jbs: https://bugs.openjdk.java.net/browse/JDK-8239798?and > https://bugs.openjdk.java.net/browse/JDK-8239788 > > Thank you, > Alexey > >> On 22 Feb 2020, at 15:00, security-dev-request at openjdk.java.net >> wrote: >> >> I will look into the issue. >> >> BTW, I closed JDK-8239788 as duplicate of JDK-8239798. >> >> Thanks, >> Xuelei >> >> On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: >>> Hi security-folk, >>> >>> At VMware while upgrading our application to OpenJDK11u, we have >>> encountered what seems to be a serious behavior issue. >>> The issue AFAICT seems to have stemmed from the work for TLS1.3 and >>> JDK-8196584 . >>> >>> Overview: >>> With OpenJDK11 the end-points are closed immediately with TLS alerts >>> raised when an exception is received. >>> This is not the case with JDK8 the socket is not closed allowing retries. >>> >>> I have filed: JDK-8239798 (with a reproducer), this issue was also >>> reported ?to Azul and they have filed: JDK-8239788. >>> >>> Can you please evaluate this at the earliest, this is a serious show >>> stopper for VMware. >>> >>> Thank >>> Kumar Srinivasan >>> VMware >> > From alexey at azul.com Mon Feb 24 19:04:02 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 24 Feb 2020 19:04:02 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> Message-ID: <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> Hi Xuelei, Thank you. It would be glad if you can review this fix. The patch almost cleanly applied to JDK15. Also, As Kumar mentioned, the patch does not include regression test. I?m going to add regression test and patch for JDK15 tomorrow. Thank you. Alexey > On 24 Feb 2020, at 21:41, Xuelei Fan wrote: > > Hi Alexey, > > Thanks for working on this issue. Do you plan to fix it for JDK 15, the current JDK reposiroty? > > I need more time for evaluate the fix. For example, I'm not sure if we could always throw InterruptedIOException to applications, even for getSession(). > > Regards, > Xuelei > > On 2/24/2020 7:58 AM, Alexey Bakhtin wrote: >> Hello, >> I have been working on this issue for some time already. >> The patch below adds java.net.SocketTimeoutException handling during TLS handshake negotiation. This functionality seems to have been missed during the TLSv1.3 implementation ( JDK-8196584 ) >> Tested with JDK11 and higher. >> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >> jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and https://bugs.openjdk.java.net/browse/JDK-8239788 >> Thank you, >> Alexey >>> On 22 Feb 2020, at 15:00, security-dev-request at openjdk.java.net wrote: >>> >>> I will look into the issue. >>> >>> BTW, I closed JDK-8239788 as duplicate of JDK-8239798. >>> >>> Thanks, >>> Xuelei >>> >>> On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: >>>> Hi security-folk, >>>> >>>> At VMware while upgrading our application to OpenJDK11u, we have >>>> encountered what seems to be a serious behavior issue. >>>> The issue AFAICT seems to have stemmed from the work for TLS1.3 and >>>> JDK-8196584 . >>>> >>>> Overview: >>>> With OpenJDK11 the end-points are closed immediately with TLS alerts >>>> raised when an exception is received. >>>> This is not the case with JDK8 the socket is not closed allowing retries. >>>> >>>> I have filed: JDK-8239798 (with a reproducer), this issue was also >>>> reported ?to Azul and they have filed: JDK-8239788. >>>> >>>> Can you please evaluate this at the earliest, this is a serious show >>>> stopper for VMware. >>>> >>>> Thank >>>> Kumar Srinivasan >>>> VMware >>> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From bradford.wetmore at oracle.com Mon Feb 24 23:29:58 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 24 Feb 2020 15:29:58 -0800 Subject: RFR[jdk]: JDK-8239815: Update ECC legal file Message-ID: Minor codereview to add a couple sentences about the high-level impact of removing the ECC native library. https://bugs.openjdk.java.net/browse/JDK-8239815 http://cr.openjdk.java.net/~wetmore/8239815/webrev.00/ More details to come in the Oracle Provider documentation. Plus a few markdown style cleanups. Brad From Alan.Bateman at oracle.com Tue Feb 25 13:26:48 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Feb 2020 13:26:48 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> Message-ID: On 24/02/2020 16:32, Kumar Srinivasan wrote: > Hi Alexey, > > Thanks for the update. I glossed over the changes. > > Observation: I don?t see a regression test in your webrev, is this > still a work in progress ? > > I am very surprised, how a simple socket feature such as this, escape > the JSN-test dragnet in the first place ? > TLS 1.3 was a massive project. It went into jdk/jdk around June 2018. It's really important for changes like this to get as much testing, and interop testing, as possible. Several projects and individuals contributed by testing the EA builds and providing timing feedback and bug reports. We need more of this to be able to identify behavior changes like you reported because it's impossible for tests to catch everything. -Alan From alexey at azul.com Tue Feb 25 13:43:15 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 25 Feb 2020 13:43:15 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> Message-ID: Hi Alan, It seems this issue could be related to jtreg test jdk/sun/security/ssl/SSLSocketImpl/ClientTimeout.java This test passed on JDK8 but fails on JDK11. The test was disabled by JDK-8196584 ( TLS 1.3 Implementation ) With patch provided this test works better but still fails. I?m trying to figure out if it is test or jdk issue. Alexey > On 25 Feb 2020, at 16:26, Alan Bateman wrote: > > On 24/02/2020 16:32, Kumar Srinivasan wrote: >> Hi Alexey, >> >> Thanks for the update. I glossed over the changes. >> >> Observation: I don?t see a regression test in your webrev, is this still a work in progress ? >> >> I am very surprised, how a simple socket feature such as this, escape the JSN-test dragnet in the first place ? >> > TLS 1.3 was a massive project. It went into jdk/jdk around June 2018. It's really important for changes like this to get as much testing, and interop testing, as possible. Several projects and individuals contributed by testing the EA builds and providing timing feedback and bug reports. We need more of this to be able to identify behavior changes like you reported because it's impossible for tests to catch everything. > > -Alan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From kusrinivasan at vmware.com Tue Feb 25 16:36:47 2020 From: kusrinivasan at vmware.com (Kumar Srinivasan) Date: Tue, 25 Feb 2020 16:36:47 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> Message-ID: <0B4D6840-200A-496A-9905-94406AA8E34E@vmware.com> Hi Alexey, Good catch, this kinda answers my question wrt. "Escape from Alcatraz? comment. I vaguely remembered some discussions around this in the Mantis/Tiger era in the Deployment team. https://bugs.openjdk.java.net/browse/JDK-4836493 The reason I was asking for a regression test, are all the possible Exceptions being considered and tested besides SocketTimeoutException ? Thinking of the use-case of someone implementing non-blocking IO using Threads, in which case one would get InterruptedException ? Thanks Kumar On Feb 25, 2020, at 5:43 AM, Alexey Bakhtin > wrote: 8196584 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Feb 25 16:42:55 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 25 Feb 2020 08:42:55 -0800 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> Message-ID: > JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ Maybe, the getSession() could throw InterruptedIOException as well. I may try to catch the InterruptedIOException, rather than handle it in the IOException catching block. Thanks, Xuelei On 2/24/2020 11:04 AM, Alexey Bakhtin wrote: > Hi Xuelei, > > Thank you. It would be glad if you can review this fix. > The patch almost cleanly applied to JDK15. > Also, As Kumar mentioned, the patch does not include regression test. > I?m going to add regression test and patch for JDK15 tomorrow. > > Thank you. > Alexey > >> On 24 Feb 2020, at 21:41, Xuelei Fan wrote: >> >> Hi Alexey, >> >> Thanks for working on this issue. Do you plan to fix it for JDK 15, the current JDK reposiroty? >> >> I need more time for evaluate the fix. For example, I'm not sure if we could always throw InterruptedIOException to applications, even for getSession(). >> >> Regards, >> Xuelei >> >> On 2/24/2020 7:58 AM, Alexey Bakhtin wrote: >>> Hello, >>> I have been working on this issue for some time already. >>> The patch below adds java.net.SocketTimeoutException handling during TLS handshake negotiation. This functionality seems to have been missed during the TLSv1.3 implementation ( JDK-8196584 ) >>> Tested with JDK11 and higher. >>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and https://bugs.openjdk.java.net/browse/JDK-8239788 >>> Thank you, >>> Alexey >>>> On 22 Feb 2020, at 15:00, security-dev-request at openjdk.java.net wrote: >>>> >>>> I will look into the issue. >>>> >>>> BTW, I closed JDK-8239788 as duplicate of JDK-8239798. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: >>>>> Hi security-folk, >>>>> >>>>> At VMware while upgrading our application to OpenJDK11u, we have >>>>> encountered what seems to be a serious behavior issue. >>>>> The issue AFAICT seems to have stemmed from the work for TLS1.3 and >>>>> JDK-8196584 . >>>>> >>>>> Overview: >>>>> With OpenJDK11 the end-points are closed immediately with TLS alerts >>>>> raised when an exception is received. >>>>> This is not the case with JDK8 the socket is not closed allowing retries. >>>>> >>>>> I have filed: JDK-8239798 (with a reproducer), this issue was also >>>>> reported ?to Azul and they have filed: JDK-8239788. >>>>> >>>>> Can you please evaluate this at the earliest, this is a serious show >>>>> stopper for VMware. >>>>> >>>>> Thank >>>>> Kumar Srinivasan >>>>> VMware >>>> > From anthony.scarpino at oracle.com Tue Feb 25 20:49:22 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 25 Feb 2020 12:49:22 -0800 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) Message-ID: Hi I need a code review for the EdDSA support in JEP 339. The code builds on the existing java implemented constant time classes used for XDH and the NIST curves. The change also adds classes to the public API to support EdDSA operations. All information about the JEP is located at: JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231 CSR: https://bugs.openjdk.java.net/browse/JDK-8190219 webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony From amy.lu at oracle.com Wed Feb 26 02:48:10 2020 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 26 Feb 2020 10:48:10 +0800 Subject: [JDK 15] RFR 8239979: sun/security/tools/keytool/ExtOptionCamelCase.java is not run Message-ID: <8c5a9d3e-f3a2-887e-368a-fdd70d34600b@oracle.com> sun/security/tools/keytool/ExtOptionCamelCase.java This is not a compile-only test, but due to the missed @run tag, test is not run. Please review the patch to fix this issue. The patch also fixed @modules. Test performs deep reflection setAccessible(true) on a non-public member, `open` added to the module. bug: https://bugs.openjdk.java.net/browse/JDK-8239979 webrev: http://cr.openjdk.java.net/~amlu/8239979/webrev.00/index.html Thanks, Amy --- old/test/jdk/sun/security/tools/keytool/ExtOptionCamelCase.java 2020-02-26 10:36:19.000000000 +0800 +++ new/test/jdk/sun/security/tools/keytool/ExtOptionCamelCase.java 2020-02-26 10:36:18.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -24,11 +24,13 @@ /* * @test * @bug 8231950 + * @summary keytool -ext camel-case shorthand not working * @modules java.base/sun.security.tools.keytool + * java.base/sun.security.tools.keytool:open * java.base/sun.security.util * java.base/sun.security.x509 * @compile -XDignore.symbol.file ExtOptionCamelCase.java - * @summary keytool -ext camel-case shorthand not working + * @run main/othervm ExtOptionCamelCase */ import sun.security.tools.keytool.Main; -------------- next part -------------- An HTML attachment was scrubbed... URL: From RAJAN.HALADE at ORACLE.COM Wed Feb 26 03:02:10 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Tue, 25 Feb 2020 19:02:10 -0800 Subject: [JDK 15] RFR 8239979: sun/security/tools/keytool/ExtOptionCamelCase.java is not run In-Reply-To: <8c5a9d3e-f3a2-887e-368a-fdd70d34600b@oracle.com> References: <8c5a9d3e-f3a2-887e-368a-fdd70d34600b@oracle.com> Message-ID: Thanks Amy for the fix! Any reason for using othervm to run this test? Otherwise your fix looks good to me. Thanks, Rajan > On Feb 25, 2020, at 6:48 PM, Amy Lu wrote: > > sun/security/tools/keytool/ExtOptionCamelCase.java > > This is not a compile-only test, but due to the missed @run tag, test is not run. > > Please review the patch to fix this issue. > > The patch also fixed @modules. Test performs deep reflection setAccessible(true) on a non-public member, `open` added to the module. > > bug: https://bugs.openjdk.java.net/browse/JDK-8239979 > webrev: http://cr.openjdk.java.net/~amlu/8239979/webrev.00/index.html > > Thanks, > Amy > > > --- old/test/jdk/sun/security/tools/keytool/ExtOptionCamelCase.java 2020-02-26 10:36:19.000000000 +0800 > +++ new/test/jdk/sun/security/tools/keytool/ExtOptionCamelCase.java 2020-02-26 10:36:18.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -24,11 +24,13 @@ > /* > * @test > * @bug 8231950 > + * @summary keytool -ext camel-case shorthand not working > * @modules java.base/sun.security.tools.keytool > + * java.base/sun.security.tools.keytool:open > * java.base/sun.security.util > * java.base/sun.security.x509 > * @compile -XDignore.symbol.file ExtOptionCamelCase.java > - * @summary keytool -ext camel-case shorthand not working > + * @run main/othervm ExtOptionCamelCase > */ > > import sun.security.tools.keytool.Main; -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Wed Feb 26 06:24:04 2020 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 26 Feb 2020 14:24:04 +0800 Subject: [JDK 15] RFR 8239979: sun/security/tools/keytool/ExtOptionCamelCase.java is not run In-Reply-To: References: <8c5a9d3e-f3a2-887e-368a-fdd70d34600b@oracle.com> Message-ID: <915b9aac-2226-c82a-9b2b-1616710ae6cf@oracle.com> Removed othervm: http://cr.openjdk.java.net/~amlu/8239979/webrev.01/index.html Thanks, Amy On 2/26/20 11:02 AM, Rajan Halade wrote: > Thanks Amy for the fix! > > Any reason for using othervm to run this test? Otherwise your fix > looks good to me. > > Thanks, > Rajan > >> On Feb 25, 2020, at 6:48 PM, Amy Lu > > wrote: >> >> sun/security/tools/keytool/ExtOptionCamelCase.java >> >> This is not a compile-only test, but due to the missed @run tag, test >> is not run. >> >> Please review the patch to fix this issue. >> >> The patch also fixed @modules. Test performs deep reflection >> setAccessible(true) on a non-public member, `open` added to the module. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8239979 >> webrev: http://cr.openjdk.java.net/~amlu/8239979/webrev.00/index.html >> >> Thanks, >> Amy >> >> >> --- old/test/jdk/sun/security/tools/keytool/ExtOptionCamelCase.java 2020-02-26 10:36:19.000000000 +0800 >> +++ new/test/jdk/sun/security/tools/keytool/ExtOptionCamelCase.java 2020-02-26 10:36:18.000000000 +0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -24,11 +24,13 @@ >> /* >> * @test >> * @bug 8231950 >> + * @summary keytool -ext camel-case shorthand not working >> * @modules java.base/sun.security.tools.keytool >> + * java.base/sun.security.tools.keytool:open >> * java.base/sun.security.util >> * java.base/sun.security.x509 >> * @compile -XDignore.symbol.file ExtOptionCamelCase.java >> - * @summary keytool -ext camel-case shorthand not working >> + * @run main/othervm ExtOptionCamelCase >> */ >> >> import sun.security.tools.keytool.Main; > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravi.k.reddy at oracle.com Wed Feb 26 09:54:21 2020 From: ravi.k.reddy at oracle.com (Ravi Reddy) Date: Wed, 26 Feb 2020 01:54:21 -0800 (PST) Subject: RFR[15] JDK-8238452 : Keytool generates wrong expiration date if validity is set to 2050/01/01 Message-ID: <8a3a8232-22ba-47c7-a3de-baeb85b18f2b@default> Hello All, Could you please review this patch. This patch fixes the "Keytool generates wrong expiration date if validity is set to 2050/01/01". This Issue was introduced with fix for https://bugs.openjdk.java.net/browse/JDK-4086008 in jdk-1.2. In the fix YR_2050 variable which is introduced to check if the date is JAN01 00:00 2050 GMT has been set to wrong value JAN01 00:00 2050 PST. In certificate notBefore and notAfter time are set to either UTC or Generalized time depending on whether time is less than YR_2050 or greater. Since the value of YR_2050 is set wrongly , there is an issue in certificate time also. Webrev: http://cr.openjdk.java.net/~pkoppula/ravire/8238452/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8238452 Thanks, Ravi -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Feb 26 10:11:14 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 26 Feb 2020 18:11:14 +0800 Subject: RFR[15] JDK-8238452 : Keytool generates wrong expiration date if validity is set to 2050/01/01 In-Reply-To: <8a3a8232-22ba-47c7-a3de-baeb85b18f2b@default> References: <8a3a8232-22ba-47c7-a3de-baeb85b18f2b@default> Message-ID: The code change looks fine to me. Thanks for taking care of this. --Max > On Feb 26, 2020, at 5:54 PM, Ravi Reddy wrote: > > Hello All, > > Could you please review this patch. This patch fixes the ?Keytool generates wrong expiration date if validity is set to 2050/01/01?. > > This Issue was introduced with fix for https://bugs.openjdk.java.net/browse/JDK-4086008 in jdk-1.2. > > In the fix YR_2050 variable which is introduced to check if the date is JAN01 00:00 2050 GMT has been set to wrong value JAN01 00:00 2050 PST. > > In certificate notBefore and notAfter time are set to either UTC or Generalized time depending on whether time is less than YR_2050 or greater. Since the value of YR_2050 is set wrongly , there is an issue in certificate time also. > > Webrev: http://cr.openjdk.java.net/~pkoppula/ravire/8238452/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8238452 > > > Thanks, > Ravi From alexey at azul.com Wed Feb 26 12:22:47 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 26 Feb 2020 12:22:47 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> Message-ID: Hello Xuelei, Thank you for review. getSession() method is implemented identically to JDK8, so it's behaviour is backward compatible to JDK8 I have updated review with some modifications: 1) Enabled sun/security/ssl/SSLSocketImpl/ClientTimeout.java jtreg test. This test emulates socket timeout during handshake and app data transfer. 2) I have added cache for incoming data received from socket (sun.security.ssl.SSLSocketInputRecord class). Socket timeout could happen while reading single handshake message by small chunks. It is implemented similarly to JDK8 and allows to pass sun/security/ssl/SSLSocketImpl/ClientTimeout test 3) I have added SocketTimeoutException handling into sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java jtreg test. This test also verifies SocketExceptions during handshake. Webrev for JDK11 : http://cr.openjdk.java.net/~yan/8239788/webrev.1/ Webrev for JDK15 : http://cr.openjdk.java.net/~yan/8239788/webrev.2/ Tested with sun/security/ssl and javax/net/ssl jtreg tests Thank you Alexey > On 25 Feb 2020, at 19:42, Xuelei Fan wrote: > > > JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ > Maybe, the getSession() could throw InterruptedIOException as well. > > I may try to catch the InterruptedIOException, rather than handle it in the IOException catching block. > > Thanks, > Xuelei > > On 2/24/2020 11:04 AM, Alexey Bakhtin wrote: >> Hi Xuelei, >> Thank you. It would be glad if you can review this fix. >> The patch almost cleanly applied to JDK15. >> Also, As Kumar mentioned, the patch does not include regression test. >> I?m going to add regression test and patch for JDK15 tomorrow. >> Thank you. >> Alexey >>> On 24 Feb 2020, at 21:41, Xuelei Fan wrote: >>> >>> Hi Alexey, >>> >>> Thanks for working on this issue. Do you plan to fix it for JDK 15, the current JDK reposiroty? >>> >>> I need more time for evaluate the fix. For example, I'm not sure if we could always throw InterruptedIOException to applications, even for getSession(). >>> >>> Regards, >>> Xuelei >>> >>> On 2/24/2020 7:58 AM, Alexey Bakhtin wrote: >>>> Hello, >>>> I have been working on this issue for some time already. >>>> The patch below adds java.net.SocketTimeoutException handling during TLS handshake negotiation. This functionality seems to have been missed during the TLSv1.3 implementation ( JDK-8196584 ) >>>> Tested with JDK11 and higher. >>>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and https://bugs.openjdk.java.net/browse/JDK-8239788 >>>> Thank you, >>>> Alexey >>>>> On 22 Feb 2020, at 15:00, security-dev-request at openjdk.java.net wrote: >>>>> >>>>> I will look into the issue. >>>>> >>>>> BTW, I closed JDK-8239788 as duplicate of JDK-8239798. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: >>>>>> Hi security-folk, >>>>>> >>>>>> At VMware while upgrading our application to OpenJDK11u, we have >>>>>> encountered what seems to be a serious behavior issue. >>>>>> The issue AFAICT seems to have stemmed from the work for TLS1.3 and >>>>>> JDK-8196584 . >>>>>> >>>>>> Overview: >>>>>> With OpenJDK11 the end-points are closed immediately with TLS alerts >>>>>> raised when an exception is received. >>>>>> This is not the case with JDK8 the socket is not closed allowing retries. >>>>>> >>>>>> I have filed: JDK-8239798 (with a reproducer), this issue was also >>>>>> reported ?to Azul and they have filed: JDK-8239788. >>>>>> >>>>>> Can you please evaluate this at the earliest, this is a serious show >>>>>> stopper for VMware. >>>>>> >>>>>> Thank >>>>>> Kumar Srinivasan >>>>>> VMware >>>>> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From xuelei.fan at oracle.com Wed Feb 26 22:04:59 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 26 Feb 2020 14:04:59 -0800 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> Message-ID: > Webrev for JDK15 : http://cr.openjdk.java.net/~yan/8239788/webrev.2/ For the SSLSocketInputRecord.java update, is it possible that the read() implementation interrupted before reading the exact specified bytes of data? The received data may be lost if it is interrupted. BTW, it might not be effective to use three fields to store the data, temporary, header and inputBuffer. Is it possible to use just one buffer (temporary, for example) and one integer to remember the received data length? Thanks, Xuelei On 2/26/2020 4:22 AM, Alexey Bakhtin wrote: > Hello Xuelei, > > Thank you for review. > > getSession() method is implemented identically to JDK8, so it's behaviour is backward compatible to JDK8 > > I have updated review with some modifications: > 1) Enabled sun/security/ssl/SSLSocketImpl/ClientTimeout.java jtreg test. This test emulates socket timeout during handshake and app data transfer. > 2) I have added cache for incoming data received from socket (sun.security.ssl.SSLSocketInputRecord class). Socket timeout could happen while reading single handshake message by small chunks. It is implemented similarly to JDK8 and allows to pass sun/security/ssl/SSLSocketImpl/ClientTimeout test > 3) I have added SocketTimeoutException handling into sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java jtreg test. This test also verifies SocketExceptions during handshake. > > Webrev for JDK11 : http://cr.openjdk.java.net/~yan/8239788/webrev.1/ > > Webrev for JDK15 : http://cr.openjdk.java.net/~yan/8239788/webrev.2/ > > Tested with sun/security/ssl and javax/net/ssl jtreg tests > > Thank you > Alexey > > >> On 25 Feb 2020, at 19:42, Xuelei Fan wrote: >> >>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >> Maybe, the getSession() could throw InterruptedIOException as well. >> >> I may try to catch the InterruptedIOException, rather than handle it in the IOException catching block. >> >> Thanks, >> Xuelei >> >> On 2/24/2020 11:04 AM, Alexey Bakhtin wrote: >>> Hi Xuelei, >>> Thank you. It would be glad if you can review this fix. >>> The patch almost cleanly applied to JDK15. >>> Also, As Kumar mentioned, the patch does not include regression test. >>> I?m going to add regression test and patch for JDK15 tomorrow. >>> Thank you. >>> Alexey >>>> On 24 Feb 2020, at 21:41, Xuelei Fan wrote: >>>> >>>> Hi Alexey, >>>> >>>> Thanks for working on this issue. Do you plan to fix it for JDK 15, the current JDK reposiroty? >>>> >>>> I need more time for evaluate the fix. For example, I'm not sure if we could always throw InterruptedIOException to applications, even for getSession(). >>>> >>>> Regards, >>>> Xuelei >>>> >>>> On 2/24/2020 7:58 AM, Alexey Bakhtin wrote: >>>>> Hello, >>>>> I have been working on this issue for some time already. >>>>> The patch below adds java.net.SocketTimeoutException handling during TLS handshake negotiation. This functionality seems to have been missed during the TLSv1.3 implementation ( JDK-8196584 ) >>>>> Tested with JDK11 and higher. >>>>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and https://bugs.openjdk.java.net/browse/JDK-8239788 >>>>> Thank you, >>>>> Alexey >>>>>> On 22 Feb 2020, at 15:00, security-dev-request at openjdk.java.net wrote: >>>>>> >>>>>> I will look into the issue. >>>>>> >>>>>> BTW, I closed JDK-8239788 as duplicate of JDK-8239798. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: >>>>>>> Hi security-folk, >>>>>>> >>>>>>> At VMware while upgrading our application to OpenJDK11u, we have >>>>>>> encountered what seems to be a serious behavior issue. >>>>>>> The issue AFAICT seems to have stemmed from the work for TLS1.3 and >>>>>>> JDK-8196584 . >>>>>>> >>>>>>> Overview: >>>>>>> With OpenJDK11 the end-points are closed immediately with TLS alerts >>>>>>> raised when an exception is received. >>>>>>> This is not the case with JDK8 the socket is not closed allowing retries. >>>>>>> >>>>>>> I have filed: JDK-8239798 (with a reproducer), this issue was also >>>>>>> reported ?to Azul and they have filed: JDK-8239788. >>>>>>> >>>>>>> Can you please evaluate this at the earliest, this is a serious show >>>>>>> stopper for VMware. >>>>>>> >>>>>>> Thank >>>>>>> Kumar Srinivasan >>>>>>> VMware >>>>>> > From RAJAN.HALADE at ORACLE.COM Wed Feb 26 23:23:03 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Wed, 26 Feb 2020 15:23:03 -0800 Subject: [JDK 15] RFR 8239979: sun/security/tools/keytool/ExtOptionCamelCase.java is not run In-Reply-To: <915b9aac-2226-c82a-9b2b-1616710ae6cf@oracle.com> References: <8c5a9d3e-f3a2-887e-368a-fdd70d34600b@oracle.com> <915b9aac-2226-c82a-9b2b-1616710ae6cf@oracle.com> Message-ID: <9602CA7D-788F-4550-8F69-01A97B55AAF3@ORACLE.COM> Thanks! looks good. Thanks, Rajan > On Feb 25, 2020, at 10:24 PM, Amy Lu wrote: > > Removed othervm: http://cr.openjdk.java.net/~amlu/8239979/webrev.01/index.html > > Thanks, > Amy > > On 2/26/20 11:02 AM, Rajan Halade wrote: >> Thanks Amy for the fix! >> >> Any reason for using othervm to run this test? Otherwise your fix looks good to me. >> >> Thanks, >> Rajan >> >>> On Feb 25, 2020, at 6:48 PM, Amy Lu > wrote: >>> >>> sun/security/tools/keytool/ExtOptionCamelCase.java >>> >>> This is not a compile-only test, but due to the missed @run tag, test is not run. >>> >>> Please review the patch to fix this issue. >>> >>> The patch also fixed @modules. Test performs deep reflection setAccessible(true) on a non-public member, `open` added to the module. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8239979 >>> webrev: http://cr.openjdk.java.net/~amlu/8239979/webrev.00/index.html >>> >>> Thanks, >>> Amy >>> >>> >>> --- old/test/jdk/sun/security/tools/keytool/ExtOptionCamelCase.java 2020-02-26 10:36:19.000000000 +0800 >>> +++ new/test/jdk/sun/security/tools/keytool/ExtOptionCamelCase.java 2020-02-26 10:36:18.000000000 +0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -24,11 +24,13 @@ >>> /* >>> * @test >>> * @bug 8231950 >>> + * @summary keytool -ext camel-case shorthand not working >>> * @modules java.base/sun.security.tools.keytool >>> + * java.base/sun.security.tools.keytool:open >>> * java.base/sun.security.util >>> * java.base/sun.security.x509 >>> * @compile -XDignore.symbol.file ExtOptionCamelCase.java >>> - * @summary keytool -ext camel-case shorthand not working >>> + * @run main/othervm ExtOptionCamelCase >>> */ >>> >>> import sun.security.tools.keytool.Main; >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey at azul.com Thu Feb 27 17:05:55 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 27 Feb 2020 17:05:55 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> Message-ID: <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> Hello Xuelei, You are right, SSLSocketInputRecord.read() method could be interrupted before all requested data is received. I have updated SSLSocketInputRecord class to use single buffer for incoming data. Also I?ve updated read() method to take into account every chunk of incoming data. It should prevent possible loss of data if socket timed out. Webrev JDK11: http://cr.openjdk.java.net/~bae/8239788/webrev.v3/ Tested with sun/security/ssl and javax/net/ssl jtreg tests Thank you Alexey > On 27 Feb 2020, at 01:04, Xuelei Fan wrote: > > > Webrev for JDK15 : http://cr.openjdk.java.net/~yan/8239788/webrev.2/ > For the SSLSocketInputRecord.java update, is it possible that the read() implementation interrupted before reading the exact specified bytes of data? The received data may be lost if it is interrupted. > > BTW, it might not be effective to use three fields to store the data, temporary, header and inputBuffer. Is it possible to use just one buffer (temporary, for example) and one integer to remember the received data length? > > Thanks, > Xuelei > > > On 2/26/2020 4:22 AM, Alexey Bakhtin wrote: >> Hello Xuelei, >> Thank you for review. >> getSession() method is implemented identically to JDK8, so it's behaviour is backward compatible to JDK8 >> I have updated review with some modifications: >> 1) Enabled sun/security/ssl/SSLSocketImpl/ClientTimeout.java jtreg test. This test emulates socket timeout during handshake and app data transfer. >> 2) I have added cache for incoming data received from socket (sun.security.ssl.SSLSocketInputRecord class). Socket timeout could happen while reading single handshake message by small chunks. It is implemented similarly to JDK8 and allows to pass sun/security/ssl/SSLSocketImpl/ClientTimeout test >> 3) I have added SocketTimeoutException handling into sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java jtreg test. This test also verifies SocketExceptions during handshake. >> Webrev for JDK11 : http://cr.openjdk.java.net/~yan/8239788/webrev.1/ >> Webrev for JDK15 : http://cr.openjdk.java.net/~yan/8239788/webrev.2/ >> Tested with sun/security/ssl and javax/net/ssl jtreg tests >> Thank you >> Alexey >>> On 25 Feb 2020, at 19:42, Xuelei Fan wrote: >>> >>>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >>> Maybe, the getSession() could throw InterruptedIOException as well. >>> >>> I may try to catch the InterruptedIOException, rather than handle it in the IOException catching block. >>> >>> Thanks, >>> Xuelei >>> >>> On 2/24/2020 11:04 AM, Alexey Bakhtin wrote: >>>> Hi Xuelei, >>>> Thank you. It would be glad if you can review this fix. >>>> The patch almost cleanly applied to JDK15. >>>> Also, As Kumar mentioned, the patch does not include regression test. >>>> I?m going to add regression test and patch for JDK15 tomorrow. >>>> Thank you. >>>> Alexey >>>>> On 24 Feb 2020, at 21:41, Xuelei Fan wrote: >>>>> >>>>> Hi Alexey, >>>>> >>>>> Thanks for working on this issue. Do you plan to fix it for JDK 15, the current JDK reposiroty? >>>>> >>>>> I need more time for evaluate the fix. For example, I'm not sure if we could always throw InterruptedIOException to applications, even for getSession(). >>>>> >>>>> Regards, >>>>> Xuelei >>>>> >>>>> On 2/24/2020 7:58 AM, Alexey Bakhtin wrote: >>>>>> Hello, >>>>>> I have been working on this issue for some time already. >>>>>> The patch below adds java.net.SocketTimeoutException handling during TLS handshake negotiation. This functionality seems to have been missed during the TLSv1.3 implementation ( JDK-8196584 ) >>>>>> Tested with JDK11 and higher. >>>>>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and https://bugs.openjdk.java.net/browse/JDK-8239788 >>>>>> Thank you, >>>>>> Alexey >>>>>>> On 22 Feb 2020, at 15:00, security-dev-request at openjdk.java.net wrote: >>>>>>> >>>>>>> I will look into the issue. >>>>>>> >>>>>>> BTW, I closed JDK-8239788 as duplicate of JDK-8239798. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: >>>>>>>> Hi security-folk, >>>>>>>> >>>>>>>> At VMware while upgrading our application to OpenJDK11u, we have >>>>>>>> encountered what seems to be a serious behavior issue. >>>>>>>> The issue AFAICT seems to have stemmed from the work for TLS1.3 and >>>>>>>> JDK-8196584 . >>>>>>>> >>>>>>>> Overview: >>>>>>>> With OpenJDK11 the end-points are closed immediately with TLS alerts >>>>>>>> raised when an exception is received. >>>>>>>> This is not the case with JDK8 the socket is not closed allowing retries. >>>>>>>> >>>>>>>> I have filed: JDK-8239798 (with a reproducer), this issue was also >>>>>>>> reported ?to Azul and they have filed: JDK-8239788. >>>>>>>> >>>>>>>> Can you please evaluate this at the earliest, this is a serious show >>>>>>>> stopper for VMware. >>>>>>>> >>>>>>>> Thank >>>>>>>> Kumar Srinivasan >>>>>>>> VMware >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sean.mullan at oracle.com Thu Feb 27 19:05:55 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Feb 2020 11:05:55 -0800 Subject: RFR[jdk]: JDK-8239815: Update ECC legal file In-Reply-To: References: Message-ID: The bug should have a noreg-doc label. Looks fine otherwise. --Sean On 2/24/20 3:29 PM, Bradford Wetmore wrote: > Minor codereview to add a couple sentences about the high-level impact > of removing the ECC native library. > > https://bugs.openjdk.java.net/browse/JDK-8239815 > http://cr.openjdk.java.net/~wetmore/8239815/webrev.00/ > > More details to come in the Oracle Provider documentation. > > Plus a few markdown style cleanups. > > Brad From mbalao at redhat.com Thu Feb 27 19:32:18 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 27 Feb 2020 16:32:18 -0300 Subject: RFR 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB In-Reply-To: <7fe474f9-ece2-3f70-cdbd-94355e56dfb3@oracle.com> References: <16482275-856f-1411-34ab-034605541866@oracle.com> <7fe474f9-ece2-3f70-cdbd-94355e56dfb3@oracle.com> Message-ID: <8db50200-8938-6622-f03d-6f420552fa8b@redhat.com> Hi Sean and Valerie, Thanks for your feedback. I've written the "8240191: Release Note: Allow SunPKCS11 initialization with NSS when FIPS external modules are available in the Security Modules Database" release note [1]. Please feel free to edit or ask me to do so if you have any suggestion. Look forward to your final approval so I push. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8240191 On 2/13/20 6:07 PM, Valerie Peng wrote: > > I think it's fine to remove this check given the recent NSS changes as > Martin mentioned. > > Second Sean's release note suggestion as well. > > Thanks, > > Valerie > > On 2/10/2020 11:14 AM, Sean Mullan wrote: >> Looks good to me, although I would also like Valerie to review it as >> she has the most experience with the PKCS11 code. >> >> This issue should probably also have a release note. Have you ever >> written one? >> >> Thanks, >> Sean >> >> On 2/5/20 10:47 AM, Martin Balao wrote: >>> Hi, >>> >>> I'd like to propose a solution for 8238555 [1]. >>> >>> Webrev.00: >>> >>> ? * >>> http://cr.openjdk.java.net/~mbalao/webrevs/8238555/8238555.webrev.00/ >>> >>> Reproducing this issue requires manual configuration steps and there is >>> not a single way of doing so. The ultimate goal for a reproduction is to >>> initialize a SunPKCS11 provider with an NSSDB that has at least 1 >>> external module configured in FIPS mode, with at least 1 opened slot. >>> >>> The 8238555_manual_reproducer_v0 code [2] provides a standalone >>> SunPKCS11 initialization with an NSSDB that has a single internal FIPS >>> module configured. That's not enough though because the external module >>> is still missing in the NSSDB. There are two paths from this point: >>> >>> 1) Manually add an external module ("modutil" command) in FIPS mode to >>> the NSSDB >>> >>> 2) Run the code in the latest Fedora/CentOS/RHEL Linux release -I'm not >>> sure if other distributions work- where p11-kit-proxy PKCS#11 module is >>> automatically added to every NSSDB. If you go this way, configure FIPS >>> policy globally (fips-mode-setup --enable) and recompile the NSS library >>> to artificially expose a slot for p11-kit-proxy module [3] (use >>> LD_PRELOAD when running the reproducer code). If you don't want to >>> recompile the NSS library, manually add a module to p11-kit (such as >>> softHSM) so a slot is opened. >>> >>> In my own environment, I had the following output before the patch: >>> >>> Beginning test run ExternalFipsModules... >>> Cannot resolve artifact, please check if JIB jar is present in >>> classpath. >>> nssLibDir: /usr/lib64/ >>> Exception in thread "main" java.lang.RuntimeException: FIPS flag set for >>> non-internal module: p11-kit-proxy.so, p11-kit-proxy >>> ????at >>> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod$Module.(Secmod.java:418) >>> >>> ????at >>> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.nssGetModuleList(Native >>> Method) >>> ????at >>> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.getModules(Secmod.java:258) >>> >>> ????at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:219) >>> >>> ????at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:112) >>> >>> ????at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:109) >>> >>> ????at >>> java.base/java.security.AccessController.doPrivileged(AccessController.java:554) >>> >>> ????at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:109) >>> >>> ????at PKCS11Test.getSunPKCS11(PKCS11Test.java:160) >>> ????at PKCS11Test.testNSS(PKCS11Test.java:580) >>> ????at PKCS11Test.main(PKCS11Test.java:220) >>> ????at PKCS11Test.main(PKCS11Test.java:196) >>> ????at ExternalFipsModules.main(ExternalFipsModules.java:31) >>> >>> And after the patch: >>> >>> Beginning test run ExternalFipsModules... >>> Cannot resolve artifact, please check if JIB jar is present in >>> classpath. >>> nssLibDir: /usr/lib64/ >>> Running test with provider SunPKCS11-NSS-FIPS (security manager >>> disabled) ... >>> Provider: SunPKCS11-NSS-FIPS version 15 >>> TEST PASS - OK >>> Completed test with provider SunPKCS11-NSS-FIPS (2 ms). >>> >>> Thanks, >>> Martin.- >>> >>> --? >>> [1] - https://bugs.openjdk.java.net/browse/JDK-8238555 >>> [2] - >>> http://cr.openjdk.java.net/~mbalao/webrevs/8238555/8238555_manual_reproducer_v0.tar.gz >>> >>> [3] - >>> http://cr.openjdk.java.net/~mbalao/webrevs/8238555/emulate_p11-kit-proxy_with_slots.nss.patch >>> >>> > From xuelei.fan at oracle.com Thu Feb 27 21:35:49 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 27 Feb 2020 13:35:49 -0800 Subject: RFR JDK-8240193 : loadLibrary("osxsecurity") should not be removed Message-ID: Hi, Could I get the following update reviewed: http://cr.openjdk.java.net/~xuelei/8240193/webrev.00/ In the JDK-8239264 update, the 'osxsecurity' library loading line was removed by by accident. And thus cause link error if using this library. This update undo this removing, and take the line back. No new regression test, noreg-undo and noreg-trivial lables were added. Thanks, Xuelei From anthony.scarpino at oracle.com Thu Feb 27 22:50:52 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 27 Feb 2020 14:50:52 -0800 Subject: RFR JDK-8240193 : loadLibrary("osxsecurity") should not be removed In-Reply-To: References: Message-ID: Looks good Tony > On Feb 27, 2020, at 1:36 PM, Xuelei Fan wrote: > > ?Hi, > > Could I get the following update reviewed: > > http://cr.openjdk.java.net/~xuelei/8240193/webrev.00/ > > In the JDK-8239264 update, the 'osxsecurity' library loading line was removed by by accident. And thus cause link error if using this library. This update undo this removing, and take the line back. > > No new regression test, noreg-undo and noreg-trivial lables were added. > > Thanks, > Xuelei From valerie.peng at oracle.com Fri Feb 28 02:48:52 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 27 Feb 2020 18:48:52 -0800 Subject: RFR 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB In-Reply-To: <8db50200-8938-6622-f03d-6f420552fa8b@redhat.com> References: <16482275-856f-1411-34ab-034605541866@oracle.com> <7fe474f9-ece2-3f70-cdbd-94355e56dfb3@oracle.com> <8db50200-8938-6622-f03d-6f420552fa8b@redhat.com> Message-ID: <5ac36839-f7d1-ba5c-e515-2579d6dc7777@oracle.com> Hi Martin, I have looked over the release note subtask and made some minor changes on wordings and added RN-Change label. Sean may have additional comments to add though. Also, when you mark it as delivered, the tech writer will also make their edit. Just FYI. Thanks, Valerie On 2/27/2020 11:32 AM, Martin Balao wrote: > Hi Sean and Valerie, > > Thanks for your feedback. > > I've written the "8240191: Release Note: Allow SunPKCS11 initialization > with NSS when FIPS external modules are available in the Security > Modules Database" release note [1]. Please feel free to edit or ask me > to do so if you have any suggestion. > > Look forward to your final approval so I push. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8240191 > > > > On 2/13/20 6:07 PM, Valerie Peng wrote: >> I think it's fine to remove this check given the recent NSS changes as >> Martin mentioned. >> >> Second Sean's release note suggestion as well. >> >> Thanks, >> >> Valerie >> >> On 2/10/2020 11:14 AM, Sean Mullan wrote: >>> Looks good to me, although I would also like Valerie to review it as >>> she has the most experience with the PKCS11 code. >>> >>> This issue should probably also have a release note. Have you ever >>> written one? >>> >>> Thanks, >>> Sean >>> >>> On 2/5/20 10:47 AM, Martin Balao wrote: >>>> Hi, >>>> >>>> I'd like to propose a solution for 8238555 [1]. >>>> >>>> Webrev.00: >>>> >>>> ? * >>>> http://cr.openjdk.java.net/~mbalao/webrevs/8238555/8238555.webrev.00/ >>>> >>>> Reproducing this issue requires manual configuration steps and there is >>>> not a single way of doing so. The ultimate goal for a reproduction is to >>>> initialize a SunPKCS11 provider with an NSSDB that has at least 1 >>>> external module configured in FIPS mode, with at least 1 opened slot. >>>> >>>> The 8238555_manual_reproducer_v0 code [2] provides a standalone >>>> SunPKCS11 initialization with an NSSDB that has a single internal FIPS >>>> module configured. That's not enough though because the external module >>>> is still missing in the NSSDB. There are two paths from this point: >>>> >>>> 1) Manually add an external module ("modutil" command) in FIPS mode to >>>> the NSSDB >>>> >>>> 2) Run the code in the latest Fedora/CentOS/RHEL Linux release -I'm not >>>> sure if other distributions work- where p11-kit-proxy PKCS#11 module is >>>> automatically added to every NSSDB. If you go this way, configure FIPS >>>> policy globally (fips-mode-setup --enable) and recompile the NSS library >>>> to artificially expose a slot for p11-kit-proxy module [3] (use >>>> LD_PRELOAD when running the reproducer code). If you don't want to >>>> recompile the NSS library, manually add a module to p11-kit (such as >>>> softHSM) so a slot is opened. >>>> >>>> In my own environment, I had the following output before the patch: >>>> >>>> Beginning test run ExternalFipsModules... >>>> Cannot resolve artifact, please check if JIB jar is present in >>>> classpath. >>>> nssLibDir: /usr/lib64/ >>>> Exception in thread "main" java.lang.RuntimeException: FIPS flag set for >>>> non-internal module: p11-kit-proxy.so, p11-kit-proxy >>>> ????at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod$Module.(Secmod.java:418) >>>> >>>> ????at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.nssGetModuleList(Native >>>> Method) >>>> ????at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.getModules(Secmod.java:258) >>>> >>>> ????at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:219) >>>> >>>> ????at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:112) >>>> >>>> ????at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:109) >>>> >>>> ????at >>>> java.base/java.security.AccessController.doPrivileged(AccessController.java:554) >>>> >>>> ????at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:109) >>>> >>>> ????at PKCS11Test.getSunPKCS11(PKCS11Test.java:160) >>>> ????at PKCS11Test.testNSS(PKCS11Test.java:580) >>>> ????at PKCS11Test.main(PKCS11Test.java:220) >>>> ????at PKCS11Test.main(PKCS11Test.java:196) >>>> ????at ExternalFipsModules.main(ExternalFipsModules.java:31) >>>> >>>> And after the patch: >>>> >>>> Beginning test run ExternalFipsModules... >>>> Cannot resolve artifact, please check if JIB jar is present in >>>> classpath. >>>> nssLibDir: /usr/lib64/ >>>> Running test with provider SunPKCS11-NSS-FIPS (security manager >>>> disabled) ... >>>> Provider: SunPKCS11-NSS-FIPS version 15 >>>> TEST PASS - OK >>>> Completed test with provider SunPKCS11-NSS-FIPS (2 ms). >>>> >>>> Thanks, >>>> Martin.- >>>> >>>> -- >>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8238555 >>>> [2] - >>>> http://cr.openjdk.java.net/~mbalao/webrevs/8238555/8238555_manual_reproducer_v0.tar.gz >>>> >>>> [3] - >>>> http://cr.openjdk.java.net/~mbalao/webrevs/8238555/emulate_p11-kit-proxy_with_slots.nss.patch >>>> >>>> From mbalao at redhat.com Fri Feb 28 13:26:12 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 28 Feb 2020 10:26:12 -0300 Subject: RFR 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB In-Reply-To: <5ac36839-f7d1-ba5c-e515-2579d6dc7777@oracle.com> References: <16482275-856f-1411-34ab-034605541866@oracle.com> <7fe474f9-ece2-3f70-cdbd-94355e56dfb3@oracle.com> <8db50200-8938-6622-f03d-6f420552fa8b@redhat.com> <5ac36839-f7d1-ba5c-e515-2579d6dc7777@oracle.com> Message-ID: <381a0e30-9545-0a49-b722-d6f51f8403f4@redhat.com> Hi Valerie, Thanks for having a look at this. I've seen your changes. Can I proceed with the push? Thanks, Martin.- On 2/27/20 11:48 PM, Valerie Peng wrote: > > I have looked over the release note subtask and made some minor changes > on wordings and added RN-Change label. > > Sean may have additional comments to add though. Also, when you mark it > as delivered, the tech writer will also make their edit. Just FYI. > From mstjohns at comcast.net Fri Feb 28 20:05:23 2020 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 28 Feb 2020 15:05:23 -0500 Subject: RFR 8237218: Support NIST Curves verification in java implementation In-Reply-To: <3d566a78-ac9b-d14a-9ca5-d252d2288f2d@oracle.com> References: <328A5FFB-A9EC-479A-B009-7C2D26CB9EF3@oracle.com> <08122126-c14c-ff12-bcbe-556b52cccfa8@oracle.com> <8F9AA2DB-CBAC-4980-BDD0-69E0B80C4FD9@oracle.com> <3d566a78-ac9b-d14a-9ca5-d252d2288f2d@oracle.com> Message-ID: <8071bb62-dc0c-67f3-6f67-5d2a95f9f1f3@comcast.net> Sorry - running behind on this thread. In ECUtil.decodePoint(), Since this code is open, I'm wondering if it might be useful to add the checks specified in NIST SP800-186 Appendix D.1.? or SP800-56Ar1 5.6.2.3 E.g. > D.1.2 Montgomery Curves > D.1.2.1 Partial Public Key Validation > Inputs: > 1. Montgomery curve MA,B defined over the prime field GF(p) > > 2. Point Q=(u, v) 1712 > Output: ACCEPT or REJECT Q as an affine point on MA,B. > Process: > 1. If Q is the point at infinity ?, output REJECT. > 2. Verify that both u and v are integers in the interval [0, p?1]. > Output REJECT if? verification fails. > 3. Verify that (u, v) is a point on the MA,B by checking that (u, v) > satisfies the defining equation v2 = u (u2 + A u + 1) where > computations are carried out in GF(p). Output? REJECT if verification > fails. > 4. Otherwise output ACCEPT. > D.1.2.2 Full Public Key Validation > Inputs: > 1. Montgomery curve MA,B defined over the prime field GF(p) > 2. Point Q > Output: ACCEPT or REJECT Q as a point on MA,B of order n. > Process: > 1. Perform partial public key validation on Q using the procedure of > Appendix D.1.2.1.? Output REJECT if this procedure outputs REJECT. > 2. Verify that n Q = ?. Output REJECT if verification fails. > 3. Otherwise output ACCEPT. This mainly ensures that the X/Y provided is actually a point on the curve.?? The threat to receiving a bad public key is more on the ECDH side, but this appears to be the code that would need to be modified so... Later, Mike On 2/20/2020 11:03 PM, Anthony Scarpino wrote: > I'm ok with this update > > Tony > > On 2/19/20 5:35 AM, Weijun Wang wrote: >> New webrev at >> >> ?? http://cr.openjdk.java.net/~weijun/8237218/webrev.04/ >> >> Only test change. For each signature, modify it a little and check if >> verify fails. >> >> Thanks, >> Max >> >>> On Feb 18, 2020, at 2:09 AM, Anthony Scarpino >>> wrote: >>> >>> The change looks fine.? I'm trusting that the existing Known Answer >>> Tests are proving your verifySignedDigest() is correct. >>> >>> You may want to comment in the code that your test depends on these >>> method names.? I was going to suggest simplifying the all the >>> verifySigned*() methods until I saw the test was dependent on it. >>> >>> Tony >>> >>> >>> On 2/13/20 3:06 AM, Weijun Wang wrote: >>>> Webrev updated at >>>> ??? http://cr.openjdk.java.net/~weijun/8237218/webrev.03/ >>>> The test is modified. Instead of adding a hacked ECDSASignature I'm >>>> using JDI to detect if the Java impl or the native impl is used. >>>> Two method names in ECDSASignature are modified to ease method >>>> lookup in the test. >>>> Thanks, >>>> Max >>>>> On Feb 11, 2020, at 7:52 PM, Weijun Wang >>>>> wrote: >>>>> >>>>> Please take a review at >>>>> >>>>> ?? http://cr.openjdk.java.net/~weijun/8237218/webrev.02/ >>>>> >>>>> A test is added that uses a patched ECDSASignature.java that >>>>> exposes how the signature is verified. >>>>> >>>>> BTW, I also updated ECDSASignature.java a little to accept non >>>>> SunEC keys, so that I can do some interop testing. If you believe >>>>> this is unnecessary I can revert the change. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>> >> > From mstjohns at comcast.net Fri Feb 28 20:18:03 2020 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 28 Feb 2020 15:18:03 -0500 Subject: RFR 8237218: Support NIST Curves verification in java implementation In-Reply-To: <8071bb62-dc0c-67f3-6f67-5d2a95f9f1f3@comcast.net> References: <328A5FFB-A9EC-479A-B009-7C2D26CB9EF3@oracle.com> <08122126-c14c-ff12-bcbe-556b52cccfa8@oracle.com> <8F9AA2DB-CBAC-4980-BDD0-69E0B80C4FD9@oracle.com> <3d566a78-ac9b-d14a-9ca5-d252d2288f2d@oracle.com> <8071bb62-dc0c-67f3-6f67-5d2a95f9f1f3@comcast.net> Message-ID: On 2/28/2020 3:05 PM, Michael StJohns wrote: > Sorry - running behind on this thread. > > In ECUtil.decodePoint(), > > Since this code is open, I'm wondering if it might be useful to add > the checks specified in NIST SP800-186 Appendix D.1.? or SP800-56Ar1 > 5.6.2.3 E.g. > >> D.1.2 Montgomery Curves >> D.1.2.1 Partial Public Key Validation > >> Inputs: >> 1. Montgomery curve MA,B defined over the prime field GF(p) >> >> 2. Point Q=(u, v) 1712 >> Output: ACCEPT or REJECT Q as an affine point on MA,B. >> Process: >> 1. If Q is the point at infinity ?, output REJECT. >> 2. Verify that both u and v are integers in the interval [0, p?1]. >> Output REJECT if? verification fails. >> 3. Verify that (u, v) is a point on the MA,B by checking that (u, v) >> satisfies the defining equation v2 = u (u2 + A u + 1) where >> computations are carried out in GF(p). Output? REJECT if verification >> fails. >> 4. Otherwise output ACCEPT. > >> D.1.2.2 Full Public Key Validation >> Inputs: >> 1. Montgomery curve MA,B defined over the prime field GF(p) >> 2. Point Q >> Output: ACCEPT or REJECT Q as a point on MA,B of order n. >> Process: >> 1. Perform partial public key validation on Q using the procedure of >> Appendix D.1.2.1.? Output REJECT if this procedure outputs REJECT. >> 2. Verify that n Q = ?. Output REJECT if verification fails. >> 3. Otherwise output ACCEPT. > > This mainly ensures that the X/Y provided is actually a point on the > curve.?? The threat to receiving a bad public key is more on the ECDH > side, but this appears to be the code that would need to be modified > so... > > Later, Mike > Here's the function I use in my application code - the last check (needed for full verification) uses BouncyCastle as I didn't have access to the internal methods in the SunEC provider.? Would have to be refactored slightly to be used in ECUtil.decodePoint(). ? /** ?? *? This function performs the checks described in NIST SP800-56A, ?? *? section 5.6.2.5 over an ECPublicKey.? It throws a ?? *? GeneralSecurityException if the key does not validate ?? * ?? * @param k the key to validate ?? * ?? * @throws InvalidKeyException if the key is invalid ?? */ ? public static void checkECPublicKey (ECPublicKey k) ??? throws InvalidKeyException { ??? // Step 0 - not in the SP document, but we don't support F2M ??? // curves ??? if (!((k.getParams().getCurve().getField()) instanceof ECFieldFp)) { ????? throw new InvalidKeyException ("ECPublicKey is not on a Prime Curve - not supported"); ??? } ??? ECPoint point = k.getW(); ??? // Step 1: ??? if (point.equals(ECPoint.POINT_INFINITY)) { ????? throw new InvalidKeyException ("ECPublic key is point at Infinity"); ??? } ??? // Step 2: ??? EllipticCurve curve = k.getParams().getCurve(); ??? BigInteger p = ((ECFieldFp)curve.getField()).getP(); ??? BigInteger x = point.getAffineX(); ??? BigInteger y = point.getAffineY(); ??? if (x.compareTo(BigInteger.ZERO) <= 0 || x.compareTo(p) >= 0) ????? throw new InvalidKeyException ("ECPublicKey X out of Range"); ??? if (y.compareTo(BigInteger.ZERO) <= 0 || y.compareTo(p) >= 0) ????? throw new InvalidKeyException ("ECPublicKey Y out of Range"); ??? // Step 3: ??? BigInteger y2 = y.pow(2).mod(p); ??? BigInteger x3 = x.pow(3); ??? BigInteger ax = curve.getA().multiply(x); ??? BigInteger sum = x3.add(ax).add(curve.getB()).mod(p); ??? if (!y2.equals(sum)) ????? throw new InvalidKeyException ("ECPublicKey Point is not on Curve"); ??? // Step 4:? check nQ == INFINITY ??? BigInteger n = k.getParams().getOrder(); ??? org.bouncycastle.math.ec.ECPoint bcPoint = ????? //? EC5Util.convertPoint(k.getParams(), point, false); A/O 1.64 ????? EC5Util.convertPoint(k.getParams(), point); ??? org.bouncycastle.math.ec.ECPoint testPoint = ????? bcPoint.multiply(n); ??? if (!testPoint.isInfinity()) ????? throw new InvalidKeyException ("ECPublicKey invalid order"); ? } From valerie.peng at oracle.com Fri Feb 28 20:41:14 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 28 Feb 2020 12:41:14 -0800 Subject: RFR 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB In-Reply-To: <381a0e30-9545-0a49-b722-d6f51f8403f4@redhat.com> References: <16482275-856f-1411-34ab-034605541866@oracle.com> <7fe474f9-ece2-3f70-cdbd-94355e56dfb3@oracle.com> <8db50200-8938-6622-f03d-6f420552fa8b@redhat.com> <5ac36839-f7d1-ba5c-e515-2579d6dc7777@oracle.com> <381a0e30-9545-0a49-b722-d6f51f8403f4@redhat.com> Message-ID: Sure, you can push since release note wording does not affect the changes. Valerie On 2/28/2020 5:26 AM, Martin Balao wrote: > Hi Valerie, > > Thanks for having a look at this. I've seen your changes. > > Can I proceed with the push? > > Thanks, > Martin.- > > > On 2/27/20 11:48 PM, Valerie Peng wrote: >> I have looked over the release note subtask and made some minor changes >> on wordings and added RN-Change label. >> >> Sean may have additional comments to add though. Also, when you mark it >> as delivered, the tech writer will also make their edit. Just FYI. >> From xuelei.fan at oracle.com Sat Feb 29 00:24:16 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 28 Feb 2020 16:24:16 -0800 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> Message-ID: <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> > Webrev JDK11: http://cr.openjdk.java.net/~bae/8239788/webrev.v3/ > getSession() method is implemented identically to JDK8, so it's > behaviour is backward compatible to JDK8 I know, but I would like to see if there is really a compatibility impact if the getSession() is consistent with other IO operations. We could fix the problem later if there is a need. > I may try to catch the InterruptedIOException, rather than handle it > in the IOException catching block or the Exception catching block. try { ... } catch (Exception e) { if (e instanceof ... ) { ... } else (e instanceof ...) { ... } } vs try { } catch (AException e) { ... } catch (IOException e) { ... } catch (Exception e) { ... } the later is the common coding style SSLSocketInputRecord: 52 private byte[] inputBuffer = new byte[maxRecordSize]; Would you mind consider an improvement to use less memory? If you have webrev for JDK 15, I could help to run more testing for you. Thanks, Xuelei On 2/27/2020 9:05 AM, Alexey Bakhtin wrote: > Hello Xuelei, > > You are right, SSLSocketInputRecord.read() method could be interrupted > before all requested data is received. > > I have updated ?SSLSocketInputRecord class to use single buffer for > incoming data. Also I?ve updated read() method to take into account > every chunk of incoming data. It should prevent possible loss of data if > socket timed out. > > Webrev JDK11: http://cr.openjdk.java.net/~bae/8239788/webrev.v3/ > > Tested with sun/security/ssl and javax/net/ssl jtreg tests > > Thank you > Alexey > >> On 27 Feb 2020, at 01:04, Xuelei Fan > > wrote: >> >> > Webrev for JDK15 : http://cr.openjdk.java.net/~yan/8239788/webrev.2/ >> For the SSLSocketInputRecord.java update, is it possible that the >> read() implementation interrupted before reading the exact specified >> bytes of data? ?The received data may be lost if it is interrupted. >> >> BTW, it might not be effective to use three fields to store the data, >> temporary, header and inputBuffer. ?Is it possible to use just one >> buffer (temporary, for example) and one integer to remember the >> received data length? >> >> Thanks, >> Xuelei >> >> >> On 2/26/2020 4:22 AM, Alexey Bakhtin wrote: >>> Hello Xuelei, >>> Thank you for review. >>> getSession() method is implemented identically to JDK8, so it's >>> behaviour is backward compatible to JDK8 >>> I have updated review with some modifications: >>> 1) Enabled sun/security/ssl/SSLSocketImpl/ClientTimeout.java jtreg >>> test. This test emulates socket timeout during handshake and app data >>> transfer. >>> 2) I have added cache for incoming data received from socket >>> (sun.security.ssl.SSLSocketInputRecord class). Socket timeout could >>> happen while reading single handshake message by small chunks. It is >>> implemented similarly to JDK8 and allows to pass >>> sun/security/ssl/SSLSocketImpl/ClientTimeout test >>> 3) I have added SocketTimeoutException handling into >>> sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java jtreg >>> test. This test also verifies SocketExceptions during handshake. >>> Webrev for JDK11 : http://cr.openjdk.java.net/~yan/8239788/webrev.1/ >>> Webrev for JDK15 : http://cr.openjdk.java.net/~yan/8239788/webrev.2/ >>> Tested with sun/security/ssl and javax/net/ssl jtreg tests >>> Thank you >>> Alexey >>>> On 25 Feb 2020, at 19:42, Xuelei Fan >>> > wrote: >>>> >>>>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >>>> Maybe, the getSession() could throw InterruptedIOException as well. >>>> >>>> I may try to catch the InterruptedIOException, rather than handle it >>>> in the IOException catching block. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 2/24/2020 11:04 AM, Alexey Bakhtin wrote: >>>>> Hi Xuelei, >>>>> Thank you. It would be glad if you can review this fix. >>>>> The patch almost cleanly applied to JDK15. >>>>> Also, As Kumar mentioned, the patch does not include regression test. >>>>> I?m going to add regression test and patch for JDK15 tomorrow. >>>>> Thank you. >>>>> Alexey >>>>>> On 24 Feb 2020, at 21:41, Xuelei Fan >>>>> > wrote: >>>>>> >>>>>> Hi Alexey, >>>>>> >>>>>> Thanks for working on this issue. ?Do you plan to fix it for JDK >>>>>> 15, the current JDK reposiroty? >>>>>> >>>>>> I need more time for evaluate the fix. ?For example, I'm not sure >>>>>> if we could always throw InterruptedIOException to applications, >>>>>> even for getSession(). >>>>>> >>>>>> Regards, >>>>>> Xuelei >>>>>> >>>>>> On 2/24/2020 7:58 AM, Alexey Bakhtin wrote: >>>>>>> Hello, >>>>>>> I have been working on this issue for some time already. >>>>>>> The patch below adds ?java.net.SocketTimeoutException handling >>>>>>> during TLS handshake negotiation. This functionality seems to >>>>>>> have been missed during the TLSv1.3 implementation ( JDK-8196584 ) >>>>>>> Tested with JDK11 and higher. >>>>>>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8239788 >>>>>>> Thank you, >>>>>>> Alexey >>>>>>>> On 22 Feb 2020, at 15:00, security-dev-request at openjdk.java.net >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> I will look into the issue. >>>>>>>> >>>>>>>> BTW, I closed JDK-8239788 as duplicate of JDK-8239798. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: >>>>>>>>> Hi security-folk, >>>>>>>>> >>>>>>>>> At VMware while upgrading our application to OpenJDK11u, we have >>>>>>>>> encountered what seems to be a serious behavior issue. >>>>>>>>> The issue AFAICT seems to have stemmed from the work for TLS1.3 and >>>>>>>>> JDK-8196584 . >>>>>>>>> >>>>>>>>> Overview: >>>>>>>>> With OpenJDK11 the end-points are closed immediately with TLS >>>>>>>>> alerts >>>>>>>>> raised when an exception is received. >>>>>>>>> This is not the case with JDK8 the socket is not closed >>>>>>>>> allowing retries. >>>>>>>>> >>>>>>>>> I have filed: JDK-8239798 (with a reproducer), this issue was also >>>>>>>>> reported ?to Azul and they have filed: JDK-8239788. >>>>>>>>> >>>>>>>>> Can you please evaluate this at the earliest, this is a serious >>>>>>>>> show >>>>>>>>> stopper for VMware. >>>>>>>>> >>>>>>>>> Thank >>>>>>>>> Kumar Srinivasan >>>>>>>>> VMware >>>>>>>> > From weijun.wang at oracle.com Sat Feb 29 13:02:50 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 29 Feb 2020 21:02:50 +0800 Subject: RFR 8240261: Use make/templates/gpl-cp-header in FieldGen.java Message-ID: <7931F3D4-6382-46B1-AFF0-12F12AC38587@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8240261/webrev.00 Thanks, Max