Re: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k
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
Re: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k
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
Re: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k
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
RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k
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
Re: RFR 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB
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
Re: RFR[15] 8238677: java/net/httpclient/ssltest/CertificateTest.java should not specify TLS version
On 08/02/2020 07:46, sha.ji...@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
RE: RFR[jdk] 8237474: Default SSLEngine should create in server role
> -Original Message- > From: Daniel Fuchs > Sent: Friday, February 7, 2020 8:32 PM > To: Prasadrao Koppula ; Sean Coffey > ; security-dev@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 >
