From weijun.wang at oracle.com Wed Nov 1 02:33:38 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 1 Nov 2017 10:33:38 +0800 Subject: Tomcat, SPNEGO, Kerberos against two Active Directory services In-Reply-To: References: Message-ID: You can add info about multiple realms in a single krb5.conf. There is only one default_realm but if the principal name contains the realm part it will be recognized. BTW, this mail list is about developing the JDK instead of how to use it. --Max > On Nov 1, 2017, at 4:25 AM, Andreas R?sdal wrote: > > Hello! > > I would like some help with setting up Tomcat, SPNEGO and Kerberos against two Active Directory services. > > At the monent I have a Java webapp running on Tomcat, which uses SPNEGO and Kerberos to authenticate users (clients in Internet Explorer) against one (1) Active Directory user database. Currently, there is only one krb5.conf which is configured against one Active Directory. There is some custom Java code (Servlet filters) which extend the integrated Tomcat SPNEGO classes, and authenticate users against the Active Directory. > > However, I now need to authenticate users against two different Active Directory databases. Some users are found only in > one of the Active Directories, while others are found only in the other Active Directory, so I now need to authenticate against > both Active Directories. However, the Java configuration only seems to be able to connect to one Active Directory at a time. > I can't use forest trust between the two Actice Directories. > > I would appreciate any information about best-practices of authenticating users in two Active Directory databases. > > > Regards, > Andreas R. From weijun.wang at oracle.com Thu Nov 2 00:38:37 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 2 Nov 2017 08:38:37 +0800 Subject: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5 In-Reply-To: <598A4449-E91D-4B13-A4F0-B2313BE36A8B@oracle.com> References: <598A4449-E91D-4B13-A4F0-B2313BE36A8B@oracle.com> Message-ID: <226355E4-F0B1-45CB-95C5-E86E93BCC112@oracle.com> Ping again. > On Sep 18, 2017, at 5:15 PM, Weijun Wang wrote: > > Hi All > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8014628/webrev.00/ > > Most changes are just duplicating existing classes/methods/fields on AES-SHA1 etypes. One day we might do some refactoring to simplify this. > > Real changes: > > - AesSha2DkCrypto.java: > > 1. A new dr() method, explained in https://tools.ietf.org/html/rfc8009#section-3 > > 2. etype name used in stringToKey(), explained in https://tools.ietf.org/html/rfc8009#section-4 > > 3. A separate deriveKey() method. Not only it reduces duplicated codes, but it is also used in KerberosAesSha2.java the test. > > - Config.java: > > Previous AES-SHA1 etypes now have aliases aes128-sha1 and aes256-sha1. > > - EType.java: > > The default enctypes set now includes the new aes-sha2 etypes, but aes-sha1 etypes are more preferred. This is also what MIT krb5 is doing. > > - KerberosAesSha2.java > > Test vectors in https://tools.ietf.org/html/rfc8009#appendix-A. > > Thanks > Max > From valerie.peng at oracle.com Fri Nov 3 01:24:03 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 2 Nov 2017 18:24:03 -0700 Subject: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator Message-ID: <112aed8a-88ea-8e3e-b69a-27f32b7a287c@oracle.com> Sean, Could you help review this RFE below? It's mainly the javadoc update of java.security.interfaces.DSAKeyPairGenerator which replaces the 1024-bit default value with provider-specific one and removal of the earlier changes for working around this javadoc limitation. I reused the wordings from existing security classes. RFE: https://bugs.openjdk.java.net/browse/JDK-8182484 Webrev: http://cr.openjdk.java.net/~valeriep/8182484/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8190569 Thanks, Valerie From jamil.j.nimeh at oracle.com Fri Nov 3 20:59:34 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 3 Nov 2017 13:59:34 -0700 Subject: Draft design for Key Derivation API Message-ID: <71d0e6e2-b133-9dd9-4f85-6ce70c994016@oracle.com> Hello all, This is a review request for the draft of a new Key Derivation API. The goal of this API will be to provide a framework for KDF algorithms like HKDF, TLS-PRF, PBKDF2 and so forth to be publicly accessible. We also plan to provide an SPI that let 3rd parties create their own implementations of KDFs in their providers, rather than trying to force them into KeyGenerators, SecretKeyFactories and the like. Rather than stuff this email full of the specification text (since it is likely to get quite a few iterations of comments and comments-to-comments), I have placed the API both in simple text form and as a Javadoc at the following locations: spec: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/kdfspec.01.txt javadoc: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/javadoc.01/ They're both the same content, just use whichever is friendlier for your eyes. In addition, I have opened up the JEP as well: https://bugs.openjdk.java.net/browse/JDK-8189808 Thanks to those who have contributed to very early internal drafts of this so far, and thanks in advance to those who will be contributing comments going forward. --Jamil From mstjohns at comcast.net Tue Nov 7 01:25:08 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 6 Nov 2017 20:25:08 -0500 Subject: Draft design for Key Derivation API In-Reply-To: <71d0e6e2-b133-9dd9-4f85-6ce70c994016@oracle.com> References: <71d0e6e2-b133-9dd9-4f85-6ce70c994016@oracle.com> Message-ID: On 11/3/2017 4:59 PM, Jamil Nimeh wrote: > Hello all, > > This is a review request for the draft of a new Key Derivation API.? > The goal of this API will be to provide a framework for KDF algorithms > like HKDF, TLS-PRF, PBKDF2 and so forth to be publicly accessible.? We > also plan to provide an SPI that let 3rd parties create their own > implementations of KDFs in their providers, rather than trying to > force them into KeyGenerators, SecretKeyFactories and the like. > > Rather than stuff this email full of the specification text (since it > is likely to get quite a few iterations of comments and > comments-to-comments), I have placed the API both in simple text form > and as a Javadoc at the following locations: > > spec: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/kdfspec.01.txt > > javadoc: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/javadoc.01/ > > They're both the same content, just use whichever is friendlier for > your eyes. > > In addition, I have opened up the JEP as well: > > https://bugs.openjdk.java.net/browse/JDK-8189808 > > Thanks to those who have contributed to very early internal drafts of > this so far, and thanks in advance to those who will be contributing > comments going forward. > > --Jamil > > Most of the following suggestions (and please take them as such regardless of any directive language) represent things I've had to do manually that I'd really prefer to do in a real key derivation API.? A few are related to how to keep things securely stored in an HSM. Add a .reset() method to KeyDerivation.? Call this to clear the state of the KDF. Add an .initialize(List, SecretKey masterSecret) method.? Remove the argument to deriveKey and deriveKeys.? This plays with the stuff to follow, but basically, a KDF may need all of the per-key derivation input to calculate the total length of the output key stream as an internal input to the KDF before ever emitting a single key.?? Also - how exactly were you planning on keying the KDF?? I guess you could pass that in in the KeyDerivation.getInstance() call or as part of the algorithmParameter but.... probably makes more sense to keep the KDF instance key-free to allow for reuse. Rename DerivedKeyParameterSpec to DeriviationParameterSpec and provide an algorithm name for "IV" or "Cleartext".? See below for .deriveData() deriveKey() emits the next key in the sequence using the data stream to key conversion rules. deriveKeys() emits as many keys left in the stream to the next data derivation or the defined end of stream based on the input specs.? deriveKeys(int num) derives the next num keys. Add a .deriveData() with a return class of byte[].?? This gets a portion of the derived data stream in the clear. E.g. an IV. Add a .deriveObject() with a return class of Object.? The returned object may not be an instance of java.security.Key.? This takes the derived data stream and converts it into the object type specified by the derivation parameter.? In a hardware security module, this might be a reference to a secured set of data or even an confidential IV. All of the derive methods throw an InvalidParameterSpecException if the next derivation parameter doesn't match the calling method (e.g. trying to deriveData when the parameter spec says emit a key). In KeyDerivation, change the output class of the deriveKey to java.security.Key; similar for deriveKeys change the output to List.?? Basically, its possible to use the output of a KDF stream to derive private keys and this should be supported. It's occasionally helpful (but not very often) for two devices to share a key pair that they create through a key agreement process (e.g. two HSMs acting as backup to each other).? Alternately, consider adding a "public KeyPair deriveKeyPair()" method. Consider adding a marker interface? javax.crypto.MasterSecret (subclass of javax.crypto.SecretKey) and using that as class for the initialize call argument. I'm happy to provide an edited .java file with these proposed changes - but not until at least next Monday; I'm on travel. Mike From jamil.j.nimeh at oracle.com Wed Nov 8 01:17:06 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 7 Nov 2017 17:17:06 -0800 Subject: Draft design for Key Derivation API In-Reply-To: References: <71d0e6e2-b133-9dd9-4f85-6ce70c994016@oracle.com> Message-ID: <98017da2-ae47-31ce-8fd6-5e21295d41a7@oracle.com> Hi Mike, thank you for your comments and feedback. I have a few comments and questions inline: On 11/06/2017 05:25 PM, Michael StJohns wrote: > On 11/3/2017 4:59 PM, Jamil Nimeh wrote: >> Hello all, >> >> This is a review request for the draft of a new Key Derivation API. >> The goal of this API will be to provide a framework for KDF >> algorithms like HKDF, TLS-PRF, PBKDF2 and so forth to be publicly >> accessible. We also plan to provide an SPI that let 3rd parties >> create their own implementations of KDFs in their providers, rather >> than trying to force them into KeyGenerators, SecretKeyFactories and >> the like. >> >> Rather than stuff this email full of the specification text (since it >> is likely to get quite a few iterations of comments and >> comments-to-comments), I have placed the API both in simple text form >> and as a Javadoc at the following locations: >> >> spec: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/kdfspec.01.txt >> >> javadoc: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/javadoc.01/ >> >> They're both the same content, just use whichever is friendlier for >> your eyes. >> >> In addition, I have opened up the JEP as well: >> >> https://bugs.openjdk.java.net/browse/JDK-8189808 >> >> Thanks to those who have contributed to very early internal drafts of >> this so far, and thanks in advance to those who will be contributing >> comments going forward. >> >> --Jamil >> >> > Most of the following suggestions (and please take them as such > regardless of any directive language) represent things I've had to do > manually that I'd really prefer to do in a real key derivation API. A > few are related to how to keep things securely stored in an HSM. > > Add a .reset() method to KeyDerivation. Call this to clear the state > of the KDF. > > Add an .initialize(List, SecretKey > masterSecret) method. Remove the argument to deriveKey and > deriveKeys. This plays with the stuff to follow, but basically, a KDF > may need all of the per-key derivation input to calculate the total > length of the output key stream as an internal input to the KDF before > ever emitting a single key. Also - how exactly were you planning on > keying the KDF? I guess you could pass that in in the > KeyDerivation.getInstance() call or as part of the algorithmParameter > but.... probably makes more sense to keep the KDF instance key-free to > allow for reuse. Well, let's get the easy one out of the way. As you suspected I planned to pass the SecretKey in via AlgorithmParameterSpec. The three classes unfortunately didn't show that. Maybe on the next iteration I can put an HkdfParameterSpec in there just as a sample so folks can see that where the key comes in. The reason I went that way was because the goal was to provide all algorithm paramters at instantiation time, and the SecretKey was just another input. I don't know if just making the KDF key-free would be enough for reuse, at least not for all cases. Thinking about HKDF and TLS 1.3 for instance, the key is the same for a collection of keys (like the client and server app traffic master keys that come from the master secret, for instance) - what changes are the other inputs to HKDF. One issue that came up on an early internal rev of the API was that we didn't want to separate instantiation and initialization, so all the inputs to the KDF now come in at getInstance time through AlgorithmParameterSpecs, rather than doing getInstance/init/... like KeyAgreement does. I wonder if it would be OK to still have an init (and a reset as you wanted) method so we can provide new inputs top-to-bottom into the KDF object. All the getInstance forms would stay more or less the same, so there's no way to make a KDF object without it being in an initialized state. But when you need new inputs you don't have to make a new object. I like being able to reuse the object and reset it to its starting state. I don't know if the folks that brought up the instance/init issue would have a problem with that. I think we're still adhering to the spirit of what they wanted to see since getInstance still gives you a fully initialized object. That's a bit different than what you're talking about with your initialize method, I kinda birdwalked a bit. Let me ask a couple questions: When you proposed initialize(), were you envisioning that applications would always need to call it before derive*? Or did you really mean "may" and an implementation would have to go back and generate more material if they exhausted everything they knew about? Given your changes to deriveKey(s) it looked more like you intended to know the total length up-front, since there's no other way to say some arbitrary next key is of a specific length with no argument to deriveKey[s]. If you did want the total length of all keys/data/objects to be supplied before derivation, what if we were to supply that to the getInstance calls? A similar idea was put forth internally, but we decided to hold off on it and wait for some feedback from the field. So if we were to go this route then getInstance calls might look like this: public static KeyDerivation getInstance(String alg, AlgorithmParameterSpec params, List deriveParams); public static KeyDerivation getInstance(String alg, String provider, AlgorithmParameterSpec params, List deriveParams); public static KeyDerivation getInstance(String alg, Provider provider, AlgorithmParameterSpec params, List deriveParams); You end up with a ready-to-use KDF right from the get-go. If we're going that route though, *and* we try to make it reusable, then we have to specify both KDF parameters and derivation parameters in an initialize call. If reusability isn't all that important then we don't have reset and initialize and you just make a new KDF every time. I like the former approach better, myself - though I would like to know how others feel about it. > > Rename DerivedKeyParameterSpec to DeriviationParameterSpec and provide > an algorithm name for "IV" or "Cleartext". See below for .deriveData() I think we could do that. Those don't sound like names that would be a problem. But maybe we go with an even more generic name like "data" or "raw". Cleartext sounds too much like plaintext/ciphertext kind of lingo and IV is use specific. > > deriveKey() emits the next key in the sequence using the data stream > to key conversion rules. > > deriveKeys() emits as many keys left in the stream to the next data > derivation or the defined end of stream based on the input specs. > deriveKeys(int num) derives the next num keys. Minor clarification: "...emits as many keys left in the stream to the next data /*or Object*/ derivation" (I'm asking, not stating, just making sure I understand what you intended). > > Add a .deriveData() with a return class of byte[]. This gets a > portion of the derived data stream in the clear. E.g. an IV. > > Add a .deriveObject() with a return class of Object. The returned > object may not be an instance of java.security.Key. This takes the > derived data stream and converts it into the object type specified by > the derivation parameter. In a hardware security module, this might > be a reference to a secured set of data or even an confidential IV. Again, just want to make sure I understand fully: So in a case where I want a given output to be an Object, I would provide a DerivationParameterSpec with an alg of..."Object" (?), a byte length, and Object-specific parameters provided through the "params" argument to the DPS? > > All of the derive methods throw an InvalidParameterSpecException if > the next derivation parameter doesn't match the calling method (e.g. > trying to deriveData when the parameter spec says emit a key). Makes sense to me. Are you OK with IllegalStateException when you try to derive a key after all elements in List have been previously returned? > > In KeyDerivation, change the output class of the deriveKey to > java.security.Key; similar for deriveKeys change the output to > List. Basically, its possible to use the output of a KDF stream > to derive private keys and this should be supported. It's occasionally > helpful (but not very often) for two devices to share a key pair that > they create through a key agreement process (e.g. two HSMs acting as > backup to each other). Alternately, consider adding a "public KeyPair > deriveKeyPair()" method. Changing the output to Key makes sense. For the HSM to HSM use case you're mentioning, that seems better suited to the KeyAgreement API, wouldn't it? > > Consider adding a marker interface javax.crypto.MasterSecret > (subclass of javax.crypto.SecretKey) and using that as class for the > initialize call argument. Maybe OBE since I'm proposing to pass the secret through the AlgorithmParameterSpec. If not, I would recommend not subclassing it from SecretKey. The Secret won't always be a key. For an alg like PBKDF2 it would be a password. > > I'm happy to provide an edited .java file with these proposed changes > - but not until at least next Monday; I'm on travel. > > Mike Let me know your thoughts on this and maybe I can cook up another rev of the spec/javadoc. Thanks again for the feedback! --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Wed Nov 8 02:24:54 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 7 Nov 2017 18:24:54 -0800 Subject: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck Message-ID: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> Hello everybody! The class sun.security.ssl.SSLSessionContextImpl maintains caches for the sessions reuse. Access to the cache from threads is serialized. It was reported that under heavy load the time of waiting for the turn to access the synchronized methods outweighs the time of creating a new session. It is proposed to introduce a flag that will allow to avoid using the cache altogether. Would you please help review the proposed fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186628 WEBREV: http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/ -- With kind regards, Ivan Gerasimov From mstjohns at comcast.net Wed Nov 8 07:40:10 2017 From: mstjohns at comcast.net (Mike StJohns) Date: Tue, 7 Nov 2017 23:40:10 -0800 Subject: Draft design for Key Derivation API In-Reply-To: <98017da2-ae47-31ce-8fd6-5e21295d41a7@oracle.com> References: <71d0e6e2-b133-9dd9-4f85-6ce70c994016@oracle.com> <98017da2-ae47-31ce-8fd6-5e21295d41a7@oracle.com> Message-ID: <93DE716B-F476-4B05-889E-77A6DF4351E9@comcast.net> Hi - I on a plane tomorrow so it may be a few days before I can completely answer the email, but I wanted to hit this section. Think of KeyDerivation as something that has a pattern similar to Cipher or KeyAgreement or Signature. The instantiation phase sets up the mechanism of the crypto object, but allows you to use that object with many keys through an init/reset (implicit or explicit) cycle. That model works well with both software and hardware implementations. In literally no case can I see it making sense to irrevocably bind the key to the keyderivation object and every reason not to do it. Consider for a minute the server side of TLS. Wouldn?t it make sense to instantiate a single KeyDerivation object and throw different master keys at it as they are negotiated? Especially if the KeyDerivation object is an abstract for an HSM implementation. None of the other crypto main classes feed in the key during instantiation. I don?t think it?s a good idea to vary the pattern without a better reason than you?ve given. more later -Mike Sent from my iPad > On Nov 7, 2017, at 17:17, Jamil Nimeh wrote: > > One issue that came up on an early internal rev of the API was that we didn't want to separate instantiation and initialization, so all the inputs to the KDF now come in at getInstance time through AlgorithmParameterSpecs, rather than doing getInstance/init/... like KeyAgreement does. I wonder if it would be OK to still have an init (and a reset as you wanted) method so we can provide new inputs top-to-bottom into the KDF object. All the getInstance forms would stay more or less the same, so there's no way to make a KDF object without it being in an initialized state. But when you need new inputs you don't have to make a new object. I like being able to reuse the object and reset it to its starting state. I don't know if the folks that brought up the instance/init issue would have a problem with that. I think we're still adhering to the spirit of what they wanted to see since getInstance still gives you a fully initialized object. From ecki at zusammenkunft.net Wed Nov 8 07:42:30 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 8 Nov 2017 07:42:30 +0000 Subject: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck In-Reply-To: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> References: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> Message-ID: Hello, There is already a property to set the cache size, would it be enough to re-purpose a cache size of 0 to turn it off? Are there numbers to show when this is actually a problem? Is this only for 100% Cache misses? Maybe the cache itself needs some optimizations? (It is hard to imagine that a saved handshake does not compensate for hundreds of gets - especially if the current version still would generate a cache key) Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: security-dev on behalf of Ivan Gerasimov Sent: Wednesday, November 8, 2017 3:24:54 AM To: security-dev at openjdk.java.net Subject: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck Hello everybody! The class sun.security.ssl.SSLSessionContextImpl maintains caches for the sessions reuse. Access to the cache from threads is serialized. It was reported that under heavy load the time of waiting for the turn to access the synchronized methods outweighs the time of creating a new session. It is proposed to introduce a flag that will allow to avoid using the cache altogether. Would you please help review the proposed fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186628 WEBREV: http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/ -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Wed Nov 8 19:09:14 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 8 Nov 2017 11:09:14 -0800 Subject: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck In-Reply-To: References: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> Message-ID: Thank you Bernd for looking into this! On 11/7/17 11:42 PM, Bernd Eckenfels wrote: > Hello, > > There is already a property to set the cache size, would it be enough > to re-purpose a cache size of 0 to turn it off? > Currently, setting the cache size to 0 means that it is unbounded, so that the entries are removed from the cache only when they get expired. > Are there numbers to show when this is actually a problem? Is this > only for 100% Cache misses? We've seen dumps with lots of threads blocked waiting on the Cache.get()/put()/remove(). This is primarily due to the time spent in the cache cleaning routines (see sun.security.util.MemoryCache.emptyQueue()/expungeExpiredEntries()), which are executed inside the synchronization block. This time is linear on the size of cache, but limiting the cache size doesn't always help either, as the amount of cleanup work also increases with a bounded cache. Allowing to avoid to use the cache removed this bottleneck and under certain conditions the throughput increased from 35 to 120 sessions per second. Please note that the proposed option javax.net.ssl.needCacheSessions will be true by default, so the default behavior will not change. Only in specific situation, if it is proved that turning off the cache will improve performance, this option will be recommended to be set to false. > Maybe the cache itself needs some optimizations? Certainly, it would be very good to optimize the cache implementation! I've made a few attempts, but failed to achieve a significant improvement in different scenarios. The complication is due to the two requirements: maintaining fixed cache capacity and maintaining FIFO order when removing the entries. This makes it hard to use the concurrent data structures as is. Still, I'm totally for the cache optimization in JDK 10, if it is possible. However, if it is done, it would not be probably backported to the earlier releases. And I'm going to propose to backport the proposed fix with the option to turn off the cache, as it will be useful for some currently running applications. With kind regards, Ivan > (It is hard to imagine that a saved handshake does not compensate for > hundreds of gets - especially if the current version still would > generate a cache key) > > Gruss > Bernd > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *From:* security-dev on behalf > of Ivan Gerasimov > *Sent:* Wednesday, November 8, 2017 3:24:54 AM > *To:* security-dev at openjdk.java.net > *Subject:* [10] RFR : 8186628 : SSL session cache can cause a > scalability bottleneck > Hello everybody! > > The class sun.security.ssl.SSLSessionContextImpl maintains caches for > the sessions reuse. > Access to the cache from threads is serialized. > It was reported that under heavy load the time of waiting for the turn > to access the synchronized methods outweighs the time of creating a new > session. > > It is proposed to introduce a flag that will allow to avoid using the > cache altogether. > Would you please help review the proposed fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186628 > WEBREV: http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/ > > > -- > With kind regards, > Ivan Gerasimov > -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Wed Nov 8 20:18:07 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 8 Nov 2017 15:18:07 -0500 Subject: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck In-Reply-To: References: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> Message-ID: <31f22c54-0580-1e7f-1f8a-d122066b8629@Oracle.com> Hi Ivan, One idea to consider is an indirection that spreads the work over multiple Cache implementations. Similar to what ConcurrentHashMap does, doing an early fan out to multiple Caches based on the key. If it was keyed to the same key as the cache, it would be able to take advantage of re-using the contexts. Though I'm not sure how to size or re-size the index based on load or ... I would think that using a 'small' cache size would bound the expunge time and still allow some-reuse. $.02, Roger On 11/8/2017 2:09 PM, Ivan Gerasimov wrote: > > Thank you Bernd for looking into this! > > > On 11/7/17 11:42 PM, Bernd Eckenfels wrote: >> Hello, >> >> There is already a property to set the cache size, would it be enough >> to re-purpose a cache size of 0 to turn it off? >> > Currently, setting the cache size to 0 means that it is unbounded, so > that the entries are removed from the cache only when they get expired. > >> Are there numbers to show when this is actually a problem? Is this >> only for 100% Cache misses? > We've seen dumps with lots of threads blocked waiting on the > Cache.get()/put()/remove(). > This is primarily due to the time spent in the cache cleaning routines > (see > sun.security.util.MemoryCache.emptyQueue()/expungeExpiredEntries()), > which are executed inside the synchronization block. > This time is linear on the size of cache, but limiting the cache size > doesn't always help either, as the amount of cleanup work also > increases with a bounded cache. > > Allowing to avoid to use the cache removed this bottleneck and under > certain conditions the throughput increased from 35 to 120 sessions > per second. > > Please note that the proposed option javax.net.ssl.needCacheSessions > will be true by default, so the default behavior will not change. > Only in specific situation, if it is proved that turning off the cache > will improve performance, this option will be recommended to be set to > false. > >> Maybe the cache itself needs some optimizations? > Certainly, it would be very good to optimize the cache implementation! > I've made a few attempts, but failed to achieve a significant > improvement in different scenarios. > The complication is due to the two requirements: maintaining fixed > cache capacity and maintaining FIFO order when removing the entries.? > This makes it hard to use the concurrent data structures as is. > > Still, I'm totally for the cache optimization in JDK 10, if it is > possible. > However, if it is done, it would not be probably backported to the > earlier releases. > > And I'm going to propose to backport the proposed fix with the option > to turn off the cache, as it will be useful for some currently running > applications. > > With kind regards, > Ivan > >> (It is hard to imagine that a saved handshake does not compensate for >> hundreds of gets - especially if the current version still would >> generate a cache key) >> >> Gruss >> Bernd >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ------------------------------------------------------------------------ >> *From:* security-dev on >> behalf of Ivan Gerasimov >> *Sent:* Wednesday, November 8, 2017 3:24:54 AM >> *To:* security-dev at openjdk.java.net >> *Subject:* [10] RFR : 8186628 : SSL session cache can cause a >> scalability bottleneck >> Hello everybody! >> >> The class sun.security.ssl.SSLSessionContextImpl maintains caches for >> the sessions reuse. >> Access to the cache from threads is serialized. >> It was reported that under heavy load the time of waiting for the turn >> to access the synchronized methods outweighs the time of creating a new >> session. >> >> It is proposed to introduce a flag that will allow to avoid using the >> cache altogether. >> Would you please help review the proposed fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186628 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/ >> >> >> -- >> With kind regards, >> Ivan Gerasimov >> > > -- > With kind regards, > Ivan Gerasimov From valerie.peng at oracle.com Wed Nov 8 23:47:16 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 8 Nov 2017 15:47:16 -0800 Subject: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator In-Reply-To: <112aed8a-88ea-8e3e-b69a-27f32b7a287c@oracle.com> References: <112aed8a-88ea-8e3e-b69a-27f32b7a287c@oracle.com> Message-ID: Hi, Sean, I updated the webrev in place - now this change contains only javadoc update of DSAKeyPairGenerator interface. CSR has also been updated accordingly. Could you please take a look? Thanks, Valerie On 11/2/2017 6:24 PM, Valerie Peng wrote: > Sean, > > Could you help review this RFE below? It's mainly the javadoc update > of java.security.interfaces.DSAKeyPairGenerator which replaces the > 1024-bit default value with provider-specific one and removal of the > earlier changes for working around this javadoc limitation. I reused > the wordings from existing security classes. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8182484 > Webrev: http://cr.openjdk.java.net/~valeriep/8182484/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8190569 > > Thanks, > Valerie From mstjohns at comcast.net Wed Nov 8 23:50:45 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 8 Nov 2017 18:50:45 -0500 Subject: Draft design for Key Derivation API In-Reply-To: <98017da2-ae47-31ce-8fd6-5e21295d41a7@oracle.com> References: <71d0e6e2-b133-9dd9-4f85-6ce70c994016@oracle.com> <98017da2-ae47-31ce-8fd6-5e21295d41a7@oracle.com> Message-ID: On 11/7/2017 8:17 PM, Jamil Nimeh wrote: > > Hi Mike, thank you for your comments and feedback.? I have a few > comments and questions inline: > (I have a little bit more time before my flight than i thought so.... see inline). > > > On 11/06/2017 05:25 PM, Michael StJohns wrote: >> On 11/3/2017 4:59 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This is a review request for the draft of a new Key Derivation API.? >>> The goal of this API will be to provide a framework for KDF >>> algorithms like HKDF, TLS-PRF, PBKDF2 and so forth to be publicly >>> accessible.? We also plan to provide an SPI that let 3rd parties >>> create their own implementations of KDFs in their providers, rather >>> than trying to force them into KeyGenerators, SecretKeyFactories and >>> the like. >>> >>> Rather than stuff this email full of the specification text (since >>> it is likely to get quite a few iterations of comments and >>> comments-to-comments), I have placed the API both in simple text >>> form and as a Javadoc at the following locations: >>> >>> spec: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/kdfspec.01.txt >>> >>> javadoc: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/javadoc.01/ >>> >>> They're both the same content, just use whichever is friendlier for >>> your eyes. >>> >>> In addition, I have opened up the JEP as well: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8189808 >>> >>> Thanks to those who have contributed to very early internal drafts >>> of this so far, and thanks in advance to those who will be >>> contributing comments going forward. >>> >>> --Jamil >>> >>> >> Most of the following suggestions (and please take them as such >> regardless of any directive language) represent things I've had to do >> manually that I'd really prefer to do in a real key derivation API.? >> A few are related to how to keep things securely stored in an HSM. >> >> Add a .reset() method to KeyDerivation.? Call this to clear the state >> of the KDF. >> >> Add an .initialize(List, SecretKey >> masterSecret) method.? Remove the argument to deriveKey and >> deriveKeys.? This plays with the stuff to follow, but basically, a >> KDF may need all of the per-key derivation input to calculate the >> total length of the output key stream as an internal input to the KDF >> before ever emitting a single key.?? Also - how exactly were you >> planning on keying the KDF? I guess you could pass that in in the >> KeyDerivation.getInstance() call or as part of the algorithmParameter >> but.... probably makes more sense to keep the KDF instance key-free >> to allow for reuse. > Well, let's get the easy one out of the way.? As you suspected I > planned to pass the SecretKey in via AlgorithmParameterSpec.? The > three classes unfortunately didn't show that.? Maybe on the next > iteration I can put an HkdfParameterSpec in there just as a sample so > folks can see that where the key comes in.? The reason I went that way > was because the goal was to provide all algorithm paramters at > instantiation time, and the SecretKey was just another input.? I don't > know if just making the KDF key-free would be enough for reuse, at > least not for all cases.? Thinking about HKDF and TLS 1.3 for > instance, the key is the same for a collection of keys (like the > client and server app traffic master keys that come from the master > secret, for instance) - what changes are the other inputs to HKDF. Yup - but that's easily handled through the new initialization call - which again matches the way Cipher, Signature and KeyAgreement do things.?? Simplifying (??) the interface just to make one use case easier is probably not a great tradeoff. > > One issue that came up on an early internal rev of the API was that we > didn't want to separate instantiation and initialization, so all the > inputs to the KDF now come in at getInstance time through > AlgorithmParameterSpecs, rather than doing getInstance/init/... like > KeyAgreement does.? I wonder if it would be OK to still have an init > (and a reset as you wanted) method so we can provide new inputs > top-to-bottom into the KDF object.? All the getInstance forms would > stay more or less the same, so there's no way to make a KDF object > without it being in an initialized state.? But when you need new > inputs you don't have to make a new object.? I like being able to > reuse the object and reset it to its starting state.? I don't know if > the folks that brought up the instance/init issue would have a problem > with that.? I think we're still adhering to the spirit of what they > wanted to see since getInstance still gives you a fully initialized > object. As I noted in my other email, that's not the general form of a contract in the JCA. > > That's a bit different than what you're talking about with your > initialize method, I kinda birdwalked a bit.? Let me ask a couple > questions: When you proposed initialize(), were you envisioning that > applications would always need to call it before derive*? Yes, init would always need to be called before you begin derives. A KDF call would require an instantiation (where you pass the parameters of the mechanism - think about the SP800-108 chinese menu of stuff that needs to be specified), an initialization (to get the keys in place and to set up the queue of derivation material and calculate the total length L if needed by the KDF), and then one or more derive commands to convert the derived key stream bytes into the keys. You could merge the init and derive states for simple things, but each call has a specific set of things its trying to accomplish and its probably better to keep the init/derive stages separate. > ? Or did you really mean "may" and an implementation would have to go > back and generate more material if they exhausted everything they knew > about?? Given your changes to deriveKey(s) it looked more like you > intended to know the total length up-front, since there's no other way > to say some arbitrary next key is of a specific length with no > argument to deriveKey[s]. Take a look at SP800-108 - the counter mode KDF. There's a parameter L in there that mostly not optional.? It's there to ensure that if you twiddle with the length of the total output the entire underlying keystream changes.?? This turns out to be a critical security aspect of these things especially if you're doing any of this in an HSM. > > If you did want the total length of all keys/data/objects to be > supplied before derivation, what if we were to supply that to the > getInstance calls? It's better to let the underlying function do the calculation as the number of key stream bytes might not actually be what you think it is for the assignment to a key. > A similar idea was put forth internally, but we decided to hold off on > it and wait for some feedback from the field.? So if we were to go > this route then getInstance calls might look like this: > > public static KeyDerivation getInstance(String alg, > AlgorithmParameterSpec params, List > deriveParams); > public static KeyDerivation getInstance(String alg, String provider, > AlgorithmParameterSpec params, List > deriveParams); > public static KeyDerivation getInstance(String alg, Provider provider, > AlgorithmParameterSpec params, List > deriveParams); > > You end up with a ready-to-use KDF right from the get-go. Still not buying it.?? this removes one user line of code as a cost of loss of flexibility, a model that looks nothing like those for Cipher, KeyAgreement and Signature etc. > > If we're going that route though, *and* we try to make it reusable, > then we have to specify both KDF parameters and derivation parameters > in an initialize call.? If reusability isn't all that important then > we don't have reset and initialize and you just make a new KDF every > time.? I like the former approach better, myself - though I would like > to know how others feel about it. > >> >> Rename DerivedKeyParameterSpec to DeriviationParameterSpec and >> provide an algorithm name for "IV" or "Cleartext".? See below for >> .deriveData() > I think we could do that.? Those don't sound like names that would be > a problem.? But maybe we go with an even more generic name like "data" > or "raw".? Cleartext sounds too much like plaintext/ciphertext kind of > lingo and IV is use specific. Yup.? Names are easy. > >> >> deriveKey() emits the next key in the sequence using the data stream >> to key conversion rules. >> >> deriveKeys() emits as many keys left in the stream to the next data >> derivation or the defined end of stream based on the input specs.? >> deriveKeys(int num) derives the next num keys. > Minor clarification: "...emits as many keys left in the stream to the > next data /*or Object*/ derivation" (I'm asking, not stating, just > making sure I understand what you intended). derive keys will derive objects that are subclasses of java.crypto.Key.?? If the next object is specifying raw bytes or an object that is not a Key, then it stops.? So your language is correct.? Maybe cleaner to say "many keys left in the stream until the next non-Key derivation" >> >> Add a .deriveData() with a return class of byte[].?? This gets a >> portion of the derived data stream in the clear. E.g. an IV. >> >> Add a .deriveObject() with a return class of Object.? The returned >> object may not be an instance of java.security.Key. This takes the >> derived data stream and converts it into the object type specified by >> the derivation parameter.? In a hardware security module, this might >> be a reference to a secured set of data or even an confidential IV. > Again, just want to make sure I understand fully: So in a case where I > want a given output to be an Object, I would provide a > DerivationParameterSpec with an alg of..."Object" (?), a byte length, > and Object-specific parameters provided through the "params" argument > to the DPS? Working this through, but it should be a Class? being specified with a constructor of a byte array plus a length. >> >> All of the derive methods throw an InvalidParameterSpecException if >> the next derivation parameter doesn't match the calling method (e.g. >> trying to deriveData when the parameter spec says emit a key). > Makes sense to me.? Are you OK with IllegalStateException when you try > to derive a key after all elements in List > have been previously returned? Maybe - I was trying to figure out the nuances of returning a RuntimeException vs a normal exception in this case.? That's probably OK but I want to think about it and re-read the RuntimeException general contract stuff. >> >> In KeyDerivation, change the output class of the deriveKey to >> java.security.Key; similar for deriveKeys change the output to >> List.?? Basically, its possible to use the output of a KDF >> stream to derive private keys and this should be supported. It's >> occasionally helpful (but not very often) for two devices to share a >> key pair that they create through a key agreement process (e.g. two >> HSMs acting as backup to each other).? Alternately, consider adding a >> "public KeyPair deriveKeyPair()" method. > Changing the output to Key makes sense.? For the HSM to HSM use case > you're mentioning, that seems better suited to the KeyAgreement API, > wouldn't it? the way this works is: 1) HSM1 generates a key pair 2) HSM2 generates a key pair 3) HSM1 and 2 exchange the public keys from the key pair 4) HSM1 calculates ECDH (HSM1private, HSM2public) while HSM2 calculates ECDSA (HSM2private,HSM1Public) to get the same shared secret S. 5) HSM1 and HSM2 both using a well defined KDF instantiate that KDF and initialize it to emit a private key.? Basically, for an EC private key on P-256 the KDF emits 320 bytes which are converted into a big integer and then taken mod P of the curve to get the common private key p for the two boxes.? Depending on the mixin data for the KDF this could be one of a few different pairs or could be regenerated as needed if there were problems with storage.? Both sides can calculate the common public key P as P = pG where G is the basepoint of the curve. In other news I want to add an ability to generate a public key if all you have is a private key.? We fixed this for RSA in PKCS11 a few years ago and it would be nice to carry it forward here. >> >> Consider adding a marker interface? javax.crypto.MasterSecret >> (subclass of javax.crypto.SecretKey) and using that as class for the >> initialize call argument. > Maybe OBE since I'm proposing to pass the secret through the > AlgorithmParameterSpec.? If not, I would recommend not subclassing it > from SecretKey.? The Secret won't always be a key.? For an alg like > PBKDF2 it would be a password. Point taken.? The MasterSecret markers would be useful to indicate key material that can only be used with a kdf - there are some attacks that can be avoided if you can keep master secrets from being able to key the underlying PRF and vice versa.? E.g. if the master secret is an HMAC secret key, the output of HMAC is public data, but the output of the KDF with HMAC is private (key) data. Let me think about the password input case.? I think it actually is a SecretKey - and using the SecretKeySpec with PBKDF2 as the algorithm to get a SecretKey object could make sense. >> >> I'm happy to provide an edited .java file with these proposed changes >> - but not until at least next Monday; I'm on travel. >> >> Mike > Let me know your thoughts on this and maybe I can cook up another rev > of the spec/javadoc.? Thanks again for the feedback! > > --Jamil > > Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Nov 9 09:04:48 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 9 Nov 2017 17:04:48 +0800 Subject: [8u-dev] RFR 8190690: Impact on krb5 test cases in the 8u-CPU nightly Message-ID: Please review the fix at http://cr.openjdk.java.net/~weijun/8190690/webrev.00/ Before this fix, a static block in KDC.java set a customized name service provider. Some recent change (jdk8u161?) inside JDK might have added a name lookup before this provider is set and the provider is never loaded. This is a <=jdk8u issue. We switch to a different mechanism in jdk9. This fix just sets the provider right on the command line, for example: - * @run main/othervm Basic + * @run main/othervm -Dsun.net.spi.nameservice.provider.1=ns,mock Basic BasicProc.java and ReplayCacheTestProc.java launch child processes, the system property is also set on the child processes. Thanks Max From seandawson2015 at gmail.com Thu Nov 9 15:50:13 2017 From: seandawson2015 at gmail.com (Sean Dawson) Date: Thu, 9 Nov 2017 10:50:13 -0500 Subject: java.net.ConnectException: Received fatal alert: unexpected_message Message-ID: Hello, We have a server that makes a request to another one using (com.ning) AsyncHttpClient and we're having an issue getting TLS working. I've looked at quite a few Google results but they don't seem to apply; or the suggestions don't make a difference in our case. Java 1.8.0_131 Both servers on same machine, using same Java Source server is using async-http-client 1.9.18 Destination server is using Jetty 9.4.7.v20170914 Tried... Variations of combinations/permutations for https.protocols -Dcom.sun.net.ssl.enableECC=false -Djsse.enableSNIExtension=false Here's debug output (with a couple small portions manually removed, indicated with ellipses)... Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_DH_anon_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 trustStore is: c:\temp\selfsigned.jks trustStore type is : jks trustStore provider is : init truststore adding as trusted cert: Subject: CN=localhost, OU=Q, O=I, L=P, ST=M, C=U Issuer: CN=localhost, OU=Q, O=I, L=P, ST=M, C=U Algorithm: RSA; Serial number: 0x5a80280b Valid from Tue Nov 07 15:53:43 EST 2017 until Mon Feb 05 15:53:43 EST 2018 trigger seeding of SecureRandom done seeding SecureRandom Using SSLEngineImpl. ... trigger seeding of SecureRandom done seeding SecureRandom trustStore is: c:\temp\selfsigned.jks trustStore type is : jks trustStore provider is : init truststore adding as trusted cert: Subject: CN=localhost, OU=Q, O=I, L=P, ST=M, C=U Issuer: CN=localhost, OU=Q, O=I, L=P, ST=M, C=U Algorithm: RSA; Serial number: 0x5a80280b Valid from Tue Nov 07 15:53:43 EST 2017 until Mon Feb 05 15:53:43 EST 2018 keyStore is : keyStore type is : jks keyStore provider is : init keystore init keymanager of type SunX509 trigger seeding of SecureRandom done seeding SecureRandom Using SSLEngineImpl. Allow unsafe renegotiation: false Allow legacy hello messages: true Is initial handshake: true Is secure renegotiation: false Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1.1 %% No cached client session *** ClientHello, TLSv1.2 RandomCookie: GMT: 1510241429 bytes = { ... } Session ID: {} Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Compression Methods: { 0 } Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1} Extension ec_point_formats, formats: [uncompressed] Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA *** [write] MD5 and SHA1 hashes: len = 161 0000: 01 00 00 9D 03 03 5A 04 75 95 24 2F A6 B1 8C 45 ......Z.u.$/...E ... 0090: 01 05 03 05 01 04 03 04 01 04 02 02 03 02 01 02 ................ 00A0: 02 . New I/O worker #10, WRITE: TLSv1.2 Handshake, length = 161 [write] MD5 and SHA1 hashes: len = 140 0000: 01 03 03 00 63 00 00 00 20 00 C0 23 00 C0 27 00 ....c... ..#..'. ... 0080: 07 06 BB A0 AB 39 66 80 95 55 14 65 .....9f..U.e New I/O worker #10, WRITE: SSLv2 client hello message, length = 140 [Raw write]: length = 142 0000: 80 8C 01 03 03 00 63 00 00 00 20 00 C0 23 00 C0 ......c... ..#.. ... 0080: ED B2 07 06 BB A0 AB 39 66 80 95 55 14 65 .......9f..U.e [Raw read]: length = 5 0000: 15 03 03 00 02 ..... [Raw read]: length = 2 0000: 02 0A .. New I/O worker #10, READ: TLSv1.2 Alert, length = 2 New I/O worker #10, RECV TLSv1.2 ALERT: fatal, unexpected_message New I/O worker #10, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: unexpected_message New I/O worker #10, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: unexpected_message New I/O worker #10, called closeOutbound() New I/O worker #10, closeOutboundInternal() New I/O worker #10, SEND TLSv1.2 ALERT: warning, description = close_notify New I/O worker #10, WRITE: TLSv1.2 Alert, length = 2 New I/O worker #10, called closeInbound() New I/O worker #10, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack? [Raw write]: length = 7 0000: 15 03 03 00 02 01 00 ....... New I/O worker #10, called closeOutbound() New I/O worker #10, closeOutboundInternal() 09 Nov 2017 10:34:46.014 25 ERROR [ ] java.net.ConnectException: Received fatal alert: unexpected_message Thanks for any suggestions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Fri Nov 10 05:00:40 2017 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 10 Nov 2017 10:30:40 +0530 Subject: 8190917: SSL session resumption broken for protocols other than TLSv1.2 Message-ID: <430d94e2-8a1c-a7a9-eede-d33b146e8fdf@gmail.com> (Moved from jdk9-dev list[1] to here) I would like to contribute a patch, containing a potential fix and a test case, to the issue reported at https://bugs.openjdk.java.net/browse/JDK-8190917. This is going to be my first contribution to OpenJDK, so I would need some guidance/help in having this reviewed/merged, please. To give a quick overview of this specific bug - the issue relates to SSL session resumption which is no longer functional in Java 9 for SSL protocols other than TLSv1.2. The JIRA itself has more extensive details and a test case which reproduces the issue. So far, I have followed various documentation to setup and build OpenJDK locally. I have completed the following set of basic tasks: ??? - Checked out the mercurial repo for jdk (http://hg.openjdk.java.net/jdk/jdk) ??? - Built the JDK locally, following the instructions under doc/building.md ??? - Run some of the basic tests successfully I have also signed and submitted the Oracle Contributor Agreement in a mail a few hours back. Right now I have the patch with the potential fix ready and also have a (jtreg) testcase which reproduces the issue and verifies the bug fix. I would like to understand what my next steps should be. More specifically: ??? 1. How do I initiate a review of the proposed change? Should I start a new discussion, in this very mailing list, with the subject line having [PATCH], an attachment with the patch and the details about the change? Or should I be attaching the proposed change in this current discussion itself? ??? 2. The "How to contribute" guide states "Your patch must be built and tested on all relevant platforms before submission." I use Mac OS for development and that's the only system I have access to. Would I be required to test this change on other *nix and Windows OS? [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-November/006050.html [2] http://openjdk.java.net/contribute/ -Jaikiran From mbalao at redhat.com Fri Nov 10 14:38:36 2017 From: mbalao at redhat.com (Martin Balao) Date: Fri, 10 Nov 2017 11:38:36 -0300 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider Message-ID: Hi, I would like to propose a patch for JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider [1]. * http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_12_sunpkcs11/2017_11_09/8029661.webrev.01/ (browse online) * http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_12_sunpkcs11/2017_11_09/8029661.webrev.01.zip (download) The following algorithms have been implemented in SunPKCS11 provider (based on PKCS#11 v2.40 mechanisms): * SunTls12RsaPremasterSecret * SunTls12MasterSecret * SunTls12KeyMaterial * SunTls12Prf A minor API change is proposed to expose TLS ProtocolVersion constants (SSL30, TLS10, TLS11, etc.) from java.base to jdk.crypto.cryptoki module. This allows to remove hardcoded TLS int constants in SunPKCS11 classes (required when implementing "Tls"-like algorithms). A test case is included with the following: * TLS 1.2 communication using SunPKCS11 + NSS (in FIPS mode) * Algorithms test against SunJCE Regards, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8029661 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Nov 10 16:11:49 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 10 Nov 2017 08:11:49 -0800 Subject: 8190917: SSL session resumption broken for protocols other than TLSv1.2 In-Reply-To: <430d94e2-8a1c-a7a9-eede-d33b146e8fdf@gmail.com> References: <430d94e2-8a1c-a7a9-eede-d33b146e8fdf@gmail.com> Message-ID: <05fb0ca6-7b46-0b68-5d63-ecd953298019@oracle.com> On 11/9/2017 9:00 PM, Jaikiran Pai wrote: > (Moved from jdk9-dev list[1] to here) > > I would like to contribute a patch, containing a potential fix and a > test case, to the issue reported at > https://bugs.openjdk.java.net/browse/JDK-8190917. This is going to be my > first contribution to OpenJDK, so I would need some guidance/help in > having this reviewed/merged, please. > > To give a quick overview of this specific bug - the issue relates to SSL > session resumption which is no longer functional in Java 9 for SSL > protocols other than TLSv1.2. The JIRA itself has more extensive details > and a test case which reproduces the issue. > > So far, I have followed various documentation to setup and build OpenJDK > locally. I have completed the following set of basic tasks: > > ??? - Checked out the mercurial repo for jdk > (http://hg.openjdk.java.net/jdk/jdk) > ??? - Built the JDK locally, following the instructions under > doc/building.md > ??? - Run some of the basic tests successfully > > I have also signed and submitted the Oracle Contributor Agreement in a > mail a few hours back. > > Right now I have the patch with the potential fix ready and also have a > (jtreg) testcase which reproduces the issue and verifies the bug fix. I > would like to understand what my next steps should be. More specifically: > > ??? 1. How do I initiate a review of the proposed change? Should I > start a new discussion, in this very mailing list, with the subject line > having [PATCH], an attachment with the patch and the details about the > change? Or should I be attaching the proposed change in this current > discussion itself? > Per the "3. Submit a patch" section of the "How to contribute" page [2], I may start patch with a subject line of the form "[PATCH] 8190917: Java 9 regression : SSL session resumption, through handshake, in SSLEngine is broken for any protocols lesser than TLSv1.2". See more of "3. Submit a patch" section about what should be contained in the patch mail. > ??? 2. The "How to contribute" guide states "Your patch must be built > and tested on all relevant platforms before submission." I use Mac OS > for development and that's the only system I have access to. Would I be > required to test this change on other *nix and Windows OS? > I would not submit a patch without test on all relevant platforms. If you only have one platform, you may want to work with your sponsor or other contributors for the testing on the relevant platforms. Xuelei > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-November/006050.html > [2] http://openjdk.java.net/contribute/ > > -Jaikiran > From jai.forums2013 at gmail.com Sat Nov 11 03:38:55 2017 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 11 Nov 2017 09:08:55 +0530 Subject: 8190917: SSL session resumption broken for protocols other than TLSv1.2 In-Reply-To: <05fb0ca6-7b46-0b68-5d63-ecd953298019@oracle.com> References: <430d94e2-8a1c-a7a9-eede-d33b146e8fdf@gmail.com> <05fb0ca6-7b46-0b68-5d63-ecd953298019@oracle.com> Message-ID: <4eaaf089-e9d3-3f65-71ff-a0ee8250c70c@gmail.com> On 10/11/17 9:41 PM, Xuelei Fan wrote: > On 11/9/2017 9:00 PM, Jaikiran Pai wrote: > >> ???? 2. The "How to contribute" guide states "Your patch must be >> built and tested on all relevant platforms before submission." I use >> Mac OS for development and that's the only system I have access to. >> Would I be required to test this change on other *nix and Windows OS? >> > I would not submit a patch without test on all relevant platforms.? If > you only have one platform, you may want to work with your sponsor or > other contributors for the testing on the relevant platforms. > > Xuelei Anyone willing to sponsor this, please? -Jaikiran From jai.forums2013 at gmail.com Sat Nov 11 04:48:21 2017 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 11 Nov 2017 10:18:21 +0530 Subject: java.net.ConnectException: Received fatal alert: unexpected_message In-Reply-To: Message-ID: <16b5b168-23a2-161a-c093-e3f06f31ba9d@gmail.com> > Java 1.8.0_131 > Both servers on same machine, using same Java > Source server is using async-http-client 1.9.18 > Destination server is using Jetty 9.4.7.v20170914 .... > New I/O worker #10, WRITE: TLSv1.2 Handshake, length = 161 > [write] MD5 and SHA1 hashes:? len = 140 > 0000: 01 03 03 00 63 00 00 00?? 20 00 C0 23 00 C0 27 00 ....c... ..#..'. > ... > 0080: 07 06 BB A0 AB 39 66 80?? 95 55 14 65 .....9f..U.e > New I/O worker #10, WRITE: SSLv2 client hello message, length = 140 It looks like the async-http-client is sending a SSLv2 client hello message during the handshake and I'm guessing Jetty doesn't support (or maybe has disabled) SSLv2Hello handshake messages. What SSL protocols have you enabled on both these sides? If you haven't explicitly enabled any, then what do they default to in these libraries/servers? -Jaikiran From xuelei.fan at oracle.com Sat Nov 11 05:39:28 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 10 Nov 2017 21:39:28 -0800 Subject: 8190917: SSL session resumption broken for protocols other than TLSv1.2 In-Reply-To: <4eaaf089-e9d3-3f65-71ff-a0ee8250c70c@gmail.com> References: <430d94e2-8a1c-a7a9-eede-d33b146e8fdf@gmail.com> <05fb0ca6-7b46-0b68-5d63-ecd953298019@oracle.com> <4eaaf089-e9d3-3f65-71ff-a0ee8250c70c@gmail.com> Message-ID: On 11/10/2017 7:38 PM, Jaikiran Pai wrote: > > On 10/11/17 9:41 PM, Xuelei Fan wrote: >> On 11/9/2017 9:00 PM, Jaikiran Pai wrote: >> >>> ???? 2. The "How to contribute" guide states "Your patch must be >>> built and tested on all relevant platforms before submission." I use >>> Mac OS for development and that's the only system I have access to. >>> Would I be required to test this change on other *nix and Windows OS? >>> >> I would not submit a patch without test on all relevant platforms.? If >> you only have one platform, you may want to work with your sponsor or >> other contributors for the testing on the relevant platforms. >> >> Xuelei > Anyone willing to sponsor this, please? > After you get an accept note for the Oracle Contributor Agreement, please attach your patch in your mail to security-dev at openjdk. It's a open platform, someone may pick it up for the testing for you. Xuelei > -Jaikiran From jai.forums2013 at gmail.com Sat Nov 11 06:12:11 2017 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 11 Nov 2017 11:42:11 +0530 Subject: 8190917: SSL session resumption broken for protocols other than TLSv1.2 In-Reply-To: References: <430d94e2-8a1c-a7a9-eede-d33b146e8fdf@gmail.com> <05fb0ca6-7b46-0b68-5d63-ecd953298019@oracle.com> <4eaaf089-e9d3-3f65-71ff-a0ee8250c70c@gmail.com> Message-ID: Thank you Xuelei, will do. -Jaikiran On 11/11/17 11:09 AM, Xuelei Fan wrote: > > > On 11/10/2017 7:38 PM, Jaikiran Pai wrote: >> >> On 10/11/17 9:41 PM, Xuelei Fan wrote: >>> On 11/9/2017 9:00 PM, Jaikiran Pai wrote: >>> >>>> ???? 2. The "How to contribute" guide states "Your patch must be >>>> built and tested on all relevant platforms before submission." I >>>> use Mac OS for development and that's the only system I have access >>>> to. Would I be required to test this change on other *nix and >>>> Windows OS? >>>> >>> I would not submit a patch without test on all relevant platforms.? >>> If you only have one platform, you may want to work with your >>> sponsor or other contributors for the testing on the relevant >>> platforms. >>> >>> Xuelei >> Anyone willing to sponsor this, please? >> > After you get an accept note for the Oracle Contributor Agreement, > please attach your patch in your mail to security-dev at openjdk.? It's a > open platform, someone may pick it up for the testing for you. > > Xuelei > >> -Jaikiran From ivan.gerasimov at oracle.com Sat Nov 11 06:48:14 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 10 Nov 2017 22:48:14 -0800 Subject: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck In-Reply-To: <31f22c54-0580-1e7f-1f8a-d122066b8629@Oracle.com> References: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> <31f22c54-0580-1e7f-1f8a-d122066b8629@Oracle.com> Message-ID: <1c6582ea-87be-a1a8-63cc-28b3cb791d81@oracle.com> Thank you Roger for the suggestion! Indeed an interesting idea to consider for optimization! I guess, in inventory of how Cache is used needs to be made to see if the maximum size requirement may be weakened. At this point, however, I'd like to have a simple solution with a choice between MemoryCache and NullCache, which will allow to have a better performance in certain situations. Benchmarking with small cache size with accessing the cache from many threads showed that the cache was still a hot point and threads were spending lots of time blocked. With kind regards, Ivan On 11/8/17 12:18 PM, Roger Riggs wrote: > Hi Ivan, > > One idea to consider is an indirection that spreads the work over > multiple Cache implementations. > Similar to what ConcurrentHashMap does, doing an early fan out to > multiple Caches based on the key. > If it was keyed to the same key as the cache, it would be able to take > advantage of re-using the contexts. > Though I'm not sure how to size or re-size the index based on load or ... > > I would think that using a 'small' cache size would bound the expunge > time and still allow some-reuse. > > $.02, Roger > > > On 11/8/2017 2:09 PM, Ivan Gerasimov wrote: >> >> Thank you Bernd for looking into this! >> >> >> On 11/7/17 11:42 PM, Bernd Eckenfels wrote: >>> Hello, >>> >>> There is already a property to set the cache size, would it be >>> enough to re-purpose a cache size of 0 to turn it off? >>> >> Currently, setting the cache size to 0 means that it is unbounded, so >> that the entries are removed from the cache only when they get expired. >> >>> Are there numbers to show when this is actually a problem? Is this >>> only for 100% Cache misses? >> We've seen dumps with lots of threads blocked waiting on the >> Cache.get()/put()/remove(). >> This is primarily due to the time spent in the cache cleaning >> routines (see >> sun.security.util.MemoryCache.emptyQueue()/expungeExpiredEntries()), >> which are executed inside the synchronization block. >> This time is linear on the size of cache, but limiting the cache size >> doesn't always help either, as the amount of cleanup work also >> increases with a bounded cache. >> >> Allowing to avoid to use the cache removed this bottleneck and under >> certain conditions the throughput increased from 35 to 120 sessions >> per second. >> >> Please note that the proposed option javax.net.ssl.needCacheSessions >> will be true by default, so the default behavior will not change. >> Only in specific situation, if it is proved that turning off the >> cache will improve performance, this option will be recommended to be >> set to false. >> >>> Maybe the cache itself needs some optimizations? >> Certainly, it would be very good to optimize the cache implementation! >> I've made a few attempts, but failed to achieve a significant >> improvement in different scenarios. >> The complication is due to the two requirements: maintaining fixed >> cache capacity and maintaining FIFO order when removing the entries. >> This makes it hard to use the concurrent data structures as is. >> >> Still, I'm totally for the cache optimization in JDK 10, if it is >> possible. >> However, if it is done, it would not be probably backported to the >> earlier releases. >> >> And I'm going to propose to backport the proposed fix with the option >> to turn off the cache, as it will be useful for some currently >> running applications. >> >> With kind regards, >> Ivan >> >>> (It is hard to imagine that a saved handshake does not compensate >>> for hundreds of gets - especially if the current version still would >>> generate a cache key) >>> >>> Gruss >>> Bernd >>> >>> Gruss >>> Bernd >>> -- >>> http://bernd.eckenfels.net >>> ------------------------------------------------------------------------ >>> >>> *From:* security-dev on >>> behalf of Ivan Gerasimov >>> *Sent:* Wednesday, November 8, 2017 3:24:54 AM >>> *To:* security-dev at openjdk.java.net >>> *Subject:* [10] RFR : 8186628 : SSL session cache can cause a >>> scalability bottleneck >>> Hello everybody! >>> >>> The class sun.security.ssl.SSLSessionContextImpl maintains caches for >>> the sessions reuse. >>> Access to the cache from threads is serialized. >>> It was reported that under heavy load the time of waiting for the turn >>> to access the synchronized methods outweighs the time of creating a new >>> session. >>> >>> It is proposed to introduce a flag that will allow to avoid using the >>> cache altogether. >>> Would you please help review the proposed fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186628 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/ >>> >>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> >> >> -- >> With kind regards, >> Ivan Gerasimov > > -- With kind regards, Ivan Gerasimov From seandawson2015 at gmail.com Sun Nov 12 18:23:21 2017 From: seandawson2015 at gmail.com (Sean Dawson) Date: Sun, 12 Nov 2017 13:23:21 -0500 Subject: java.net.ConnectException: Received fatal alert: unexpected_message In-Reply-To: <16b5b168-23a2-161a-c093-e3f06f31ba9d@gmail.com> References: <16b5b168-23a2-161a-c093-e3f06f31ba9d@gmail.com> Message-ID: Thanks for the reply. This is one of the latest versions of Jetty so I would hope that it would support that. But I've also tried specifying various other http.protocols on both sides but it hasn't seemed to change the result. Any other flags or things I should try? On Fri, Nov 10, 2017 at 11:48 PM, Jaikiran Pai wrote: > > Java 1.8.0_131 > > Both servers on same machine, using same Java > > Source server is using async-http-client 1.9.18 > > Destination server is using Jetty 9.4.7.v20170914 > > .... > > > New I/O worker #10, WRITE: TLSv1.2 Handshake, length = 161 > > [write] MD5 and SHA1 hashes: len = 140 > > 0000: 01 03 03 00 63 00 00 00 20 00 C0 23 00 C0 27 00 ....c... ..#..'. > > ... > > 0080: 07 06 BB A0 AB 39 66 80 95 55 14 65 .....9f..U.e > > New I/O worker #10, WRITE: SSLv2 client hello message, length = 140 > > It looks like the async-http-client is sending a SSLv2 client hello > message during the handshake and I'm guessing Jetty doesn't support (or > maybe has disabled) SSLv2Hello handshake messages. What SSL protocols have > you enabled on both these sides? If you haven't explicitly enabled any, > then what do they default to in these libraries/servers? > > -Jaikiran > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Sun Nov 12 21:05:56 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 12 Nov 2017 22:05:56 +0100 Subject: AW: java.net.ConnectException: Received fatal alert:unexpected_message In-Reply-To: References: <16b5b168-23a2-161a-c093-e3f06f31ba9d@gmail.com> Message-ID: <5a08b7b4.3bb0df0a.47892.a68f@mx.google.com> The newer the Jetty Server is the more unlikely it Supports the old and unsafe SSL2 handshake. You should not enable the SSL2Hello pseudo protocol on Client side. JDK certainly does not by Default. Gruss Bernd -- http://bernd.eckenfels.net Von: Sean Dawson Gesendet: Sonntag, 12. November 2017 20:24 An: security-dev at openjdk.java.net Betreff: Re: java.net.ConnectException: Received fatal alert:unexpected_message Thanks for the reply. This is one of the latest versions of Jetty so I would hope that it would support that. But I've also tried specifying various other http.protocols on both sides but it hasn't seemed to change the result. Any other flags or things I should try? On Fri, Nov 10, 2017 at 11:48 PM, Jaikiran Pai wrote: > Java 1.8.0_131 > Both servers on same machine, using same Java > Source server is using async-http-client 1.9.18 > Destination server is using Jetty 9.4.7.v20170914 .... > New I/O worker #10, WRITE: TLSv1.2 Handshake, length = 161 > [write] MD5 and SHA1 hashes:? len = 140 > 0000: 01 03 03 00 63 00 00 00?? 20 00 C0 23 00 C0 27 00 ....c... ..#..'. > ... > 0080: 07 06 BB A0 AB 39 66 80?? 95 55 14 65 .....9f..U.e > New I/O worker #10, WRITE: SSLv2 client hello message, length = 140 It looks like the async-http-client is sending a SSLv2 client hello message during the handshake and I'm guessing Jetty doesn't support (or maybe has disabled) SSLv2Hello handshake messages. What SSL protocols have you enabled on both these sides? If you haven't explicitly enabled any, then what do they default to in these libraries/servers? -Jaikiran -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Mon Nov 13 09:14:49 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 13 Nov 2017 09:14:49 +0000 Subject: [8u-dev] RFR 8190690: Impact on krb5 test cases in the 8u-CPU nightly In-Reply-To: References: Message-ID: <2a51391b-67e1-6874-4e76-5220f722fe95@oracle.com> Looks like some test clients can have old configuration files which trigger early loading of InetAddress. Your edits look fine and hardens the testcase against such issues. regards, Sean. On 09/11/2017 09:04, Weijun Wang wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8190690/webrev.00/ > > Before this fix, a static block in KDC.java set a customized name service provider. Some recent change (jdk8u161?) inside JDK might have added a name lookup before this provider is set and the provider is never loaded. > > This is a <=jdk8u issue. We switch to a different mechanism in jdk9. > > This fix just sets the provider right on the command line, for example: > > - * @run main/othervm Basic > + * @run main/othervm -Dsun.net.spi.nameservice.provider.1=ns,mock Basic > > BasicProc.java and ReplayCacheTestProc.java launch child processes, the system property is also set on the child processes. > > Thanks > Max > From weijun.wang at oracle.com Mon Nov 13 16:07:01 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Nov 2017 00:07:01 +0800 Subject: How to escape "/" in a distinguished name in a LDAP URI? Message-ID: <06CD6E19-08CB-459C-B113-3F2D471849AC@oracle.com> If the dn is "CN=esca/ped", what does a LDAP URI containing it look like? How many levels of escaping do I need? Just percent? Or I need to add backslash first? Thanks Max From ecki at zusammenkunft.net Mon Nov 13 17:19:14 2017 From: ecki at zusammenkunft.net (Bernd) Date: Mon, 13 Nov 2017 18:19:14 +0100 Subject: java.security still talks about "limited" as default Message-ID: Hello, in the OpenJDK 9.0.1 java.security file is the crypto.policy=unlimited set. However the boilerplate text above still speaks of "limited" as a default: # Due to the import control restrictions of some countries, the default # JCE policy files allow for strong but "limited" cryptographic key # lengths to be used. If your country's cryptographic regulations allow, # the "unlimited" strength policy files can be used instead, which contain # no restrictions on cryptographic strengths. I guess this needs to be adjusted. BTW: does anybody know examples of where limited would be needed? Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.mckenna at oracle.com Mon Nov 13 17:49:13 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 13 Nov 2017 17:49:13 +0000 Subject: How to escape "/" in a distinguished name in a LDAP URI? In-Reply-To: <06CD6E19-08CB-459C-B113-3F2D471849AC@oracle.com> References: <06CD6E19-08CB-459C-B113-3F2D471849AC@oracle.com> Message-ID: <20171113174913.GA2954@vimes> I can never recall off the top of my head but I wrote a test that might be helpful: http://t4.ie.oracle.com/home/robm/files/webrev/8177806/webrev.02/raw_files/new/test/javax/naming/Name/LdapEscapeTest.java This didn't require pushing in the end but I should hang onto it as its a simple way of checking how we end up parsing ldap urls. -Rob On 14/11/17 00:07, Weijun Wang wrote: > If the dn is "CN=esca/ped", what does a LDAP URI containing it look like? > > How many levels of escaping do I need? Just percent? Or I need to add backslash first? > > Thanks > Max > From sean.mullan at oracle.com Mon Nov 13 17:49:28 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Nov 2017 12:49:28 -0500 Subject: RFR: 8175091: Mark the deprecated java.security.{Certificate,Identity,IdentityScope,Signer} APIs with forRemoval=true Message-ID: <0ced19cd-f00a-2d99-eef9-087983159866@oracle.com> Please review this JDK 10 change to mark the deprecated java.security.{Certificate,Identity,IdentityScope,Signer} APIs with forRemoval=true. These APIs will be removed from a subsequent version of Java SE. They have been deprecated since 1.2 and superseded by java.security.cert, java.security.KeyStore and related classes since 1.2. It is no longer necessary to retain these classes. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8175091/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8175091 --Sean From sean.mullan at oracle.com Mon Nov 13 18:51:46 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Nov 2017 13:51:46 -0500 Subject: RFR: 8175094: Mark the deprecated java.security.acl APIs with forRemoval=true Message-ID: Please review this JDK 10 change to mark the deprecated java.security.acl APIs with forRemoval=true. These APIs will be removed from a subsequent version of Java SE. They have been deprecated since JDK 9 and superseded by classes in java.security since 1.2. It is no longer necessary to retain these classes. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8175094/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8175094 --Sean From florian.bruckner at 3kraft.com Mon Nov 13 19:20:42 2017 From: florian.bruckner at 3kraft.com (Florian Bruckner (3kraft)) Date: Mon, 13 Nov 2017 20:20:42 +0100 Subject: JDK-8180819 No installed provider supports this key: sun.security.pkcs.PKCS8Key Message-ID: <63f00010-f1cc-9200-7eae-d1d7b425dd41@3kraft.com> Hi, have just stumbled upon a quite strange behavior in a SSL connection with a client certificate. It looks like something introduced between JDK 8u111 and JDK 8u121; JDK9 (all Oracle) and OpenJDK 8u151 are affected as well. There is already a ticket for this (JDK-8180819) but this has been closed due to no response from the original reporter. This is the exception (with 8u121): Exception in thread "main" com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: javax.net.ssl.SSLHandshakeException: Error signing certificate verify ??? at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:117) ??? at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:208) ??? at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:130) ??? at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:124) ??? at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:1121) ??? at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:1035) ??? at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:1004) ??? at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:862) ??? at com.sun.xml.internal.ws.client.Stub.process(Stub.java:448) ??? at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:178) ??? at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93) ??? at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:77) ??? at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:147) Caused by: javax.net.ssl.SSLHandshakeException: Error signing certificate verify ??? at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ??? at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949) ??? at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) ??? at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1113) ??? at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:348) ??? at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026) ??? at sun.security.ssl.Handshaker.process_record(Handshaker.java:961) ??? at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062) ??? at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) ??? at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403) ??? at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387) ??? at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) ??? at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) ??? at sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1316) ??? at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1291) ??? at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250) ??? at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:104) ??? ... 14 more Caused by: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs.PKCS8Key ??? at java.security.Signature$Delegate.chooseProvider(Signature.java:1135) ??? at java.security.Signature$Delegate.engineInitSign(Signature.java:1185) ??? at java.security.Signature.initSign(Signature.java:550) ??? at sun.security.ssl.HandshakeMessage$CertificateVerify.(HandshakeMessage.java:1587) ??? at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1110) ??? ... 27 more When using PKCS12 instead of JKS for the identity keystore, the trace is different (this trace is from a JDK 8u151): Exception in thread "main" com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) ??????? at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:117) ??????? at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:208) ??????? at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:130) ??????? at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:124) ??????? at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:1121) ??????? at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:1035) ??????? at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:1004) ??????? at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:862) ??????? at com.sun.xml.internal.ws.client.Stub.process(Stub.java:448) ??????? at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:178) ??????? at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93) ??????? at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:77) ??????? at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:147) Caused by: java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) ??????? at javax.net.ssl.DefaultSSLSocketFactory.throwException(SSLSocketFactory.java:248) ??????? at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:255) ??????? at sun.net.www.protocol.https.HttpsClient.createSocket(HttpsClient.java:405) ??????? at sun.net.NetworkClient.doConnect(NetworkClient.java:162) ??????? at sun.net.www.http.HttpClient.openServer(HttpClient.java:463) ??????? at sun.net.www.http.HttpClient.openServer(HttpClient.java:558) ??????? at sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:264) ??????? at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:367) ??????? at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191) ??????? at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1199) ??????? at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1050) ??????? at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177) ??????? at sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1334) ??????? at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1309) ??????? at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:259) ??????? at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:104) ??????? ... 14 more Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) ??????? at java.security.Provider$Service.newInstance(Provider.java:1617) ??????? at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) ??????? at sun.security.jca.GetInstance.getInstance(GetInstance.java:164) ??????? at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) ??????? at javax.net.ssl.SSLContext.getDefault(SSLContext.java:96) ??????? at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:122) ??????? at javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:332) ??????? at javax.net.ssl.HttpsURLConnection.(HttpsURLConnection.java:289) ??????? at sun.net.www.protocol.https.HttpsURLConnectionImpl.(HttpsURLConnectionImpl.java:94) ??????? at sun.net.www.protocol.https.Handler.openConnection(Handler.java:62) ??????? at java.net.URL.openConnection(URL.java:1028) ??????? at com.sun.xml.internal.ws.api.EndpointAddress.openConnection(EndpointAddress.java:217) ??????? at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.createHttpConnection(HttpClientTransport.java:242) ??????? at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:101) ??????? ... 14 more Caused by: java.security.UnrecoverableKeyException: Get Key failed: java.security.InvalidKeyException: Invalid RSA private key ??????? at sun.security.pkcs12.PKCS12KeyStore.engineGetKey(PKCS12KeyStore.java:435) ??????? at sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96) ??????? at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:70) ??????? at java.security.KeyStore.getKey(KeyStore.java:1023) ??????? at sun.security.ssl.SunX509KeyManagerImpl.(SunX509KeyManagerImpl.java:133) ??????? at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70) ??????? at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256) ??????? at sun.security.ssl.SSLContextImpl$DefaultManagersHolder.getKeyManagers(SSLContextImpl.java:873) ??????? at sun.security.ssl.SSLContextImpl$DefaultManagersHolder.(SSLContextImpl.java:758) ??????? at sun.security.ssl.SSLContextImpl$DefaultSSLContext.(SSLContextImpl.java:913) ??????? at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ??????? at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ??????? at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ??????? at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ??????? at java.security.Provider$Service.newInstance(Provider.java:1595) ??????? ... 27 more Caused by: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: Invalid RSA private key ??????? at sun.security.rsa.RSAKeyFactory.engineGeneratePrivate(RSAKeyFactory.java:217) ??????? at java.security.KeyFactory.generatePrivate(KeyFactory.java:372) ??????? at sun.security.pkcs12.PKCS12KeyStore.engineGetKey(PKCS12KeyStore.java:399) ??????? ... 41 more Caused by: java.security.InvalidKeyException: Invalid RSA private key ??????? at sun.security.rsa.RSAPrivateCrtKeyImpl.parseKeyBits(RSAPrivateCrtKeyImpl.java:214) ??????? at sun.security.pkcs.PKCS8Key.decode(PKCS8Key.java:343) ??????? at sun.security.pkcs.PKCS8Key.decode(PKCS8Key.java:357) ??????? at sun.security.rsa.RSAPrivateCrtKeyImpl.(RSAPrivateCrtKeyImpl.java:91) ??????? at sun.security.rsa.RSAPrivateCrtKeyImpl.newKey(RSAPrivateCrtKeyImpl.java:75) ??????? at sun.security.rsa.RSAKeyFactory.generatePrivate(RSAKeyFactory.java:316) ??????? at sun.security.rsa.RSAKeyFactory.engineGeneratePrivate(RSAKeyFactory.java:213) ??????? ... 43 more Caused by: java.io.IOException: DerInputStream.getLength(): Redundant length bytes found ??????? at sun.security.util.DerInputStream.getLength(DerInputStream.java:606) ??????? at sun.security.util.DerInputStream.getLength(DerInputStream.java:569) ??????? at sun.security.util.DerInputStream.getPositiveBigInteger(DerInputStream.java:220) ??????? at sun.security.rsa.RSAPrivateCrtKeyImpl.parseKeyBits(RSAPrivateCrtKeyImpl.java:205) ??????? ... 49 more The keystores as JKS and PKCS#12 have been verified to be working with Java 8u60, so they seem to be fine. Activating unlimited jurisdiction does not solve the problem. Restricting the client to TLSv1 or TLSv1.1 (via jdk.tls.client.protocols) has not changed behavior. While the client is under my control, the server isn't. There are no client properties for SSL set except truststore and keystore. I need to discuss with my client whether I can share -Djavax.net.debug=ssl, but before I do this: Is this list the right place to work on this and is someone willing to approach this issue? Regards, Florian From bradford.wetmore at oracle.com Mon Nov 13 20:13:15 2017 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 13 Nov 2017 12:13:15 -0800 Subject: java.security still talks about "limited" as default In-Reply-To: References: Message-ID: This was fixed in: https://bugs.openjdk.java.net/browse/JDK-8186093 Sadly, it was noticed too late in JDK 9/9.0.1 to fix for GA of those releases. Brad On 11/13/2017 9:19 AM, Bernd wrote: > Hello, > > in the OpenJDK 9.0.1 java.security file is the crypto.policy=unlimited set. > > However the boilerplate text above still speaks of "limited" as a default: > > # Due to the import control restrictions of some countries, the default > # JCE policy files allow for strong but "limited" cryptographic key > # lengths to be used.? If your country's cryptographic regulations allow, > # the "unlimited" strength policy files can be used instead, which contain > # no restrictions on cryptographic strengths. > > I guess this needs to be adjusted. > > BTW: does anybody know examples of where limited would be needed? > > Gruss > Bernd From weijun.wang at oracle.com Mon Nov 13 23:55:54 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Nov 2017 07:55:54 +0800 Subject: RFR: 8175091: Mark the deprecated java.security.{Certificate,Identity,IdentityScope,Signer} APIs with forRemoval=true In-Reply-To: <0ced19cd-f00a-2d99-eef9-087983159866@oracle.com> References: <0ced19cd-f00a-2d99-eef9-087983159866@oracle.com> Message-ID: <9D4184F7-FFF2-4ED7-8E16-3075B59D1974@oracle.com> Change looks fine. Thanks Max > On Nov 14, 2017, at 1:49 AM, Sean Mullan wrote: > > Please review this JDK 10 change to mark the deprecated java.security.{Certificate,Identity,IdentityScope,Signer} APIs with forRemoval=true. These APIs will be removed from a subsequent version of Java SE. They have been deprecated since 1.2 and superseded by java.security.cert, java.security.KeyStore and related classes since 1.2. It is no longer necessary to retain these classes. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8175091/webrev.00/ > issue: https://bugs.openjdk.java.net/browse/JDK-8175091 > > --Sean From weijun.wang at oracle.com Tue Nov 14 04:20:38 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Nov 2017 12:20:38 +0800 Subject: RFR 8191137: keytool fails to format resource strings for keys for some languages after JDK-8171319 Message-ID: keytool contains a printf("%d-bit %s key", 1024, "RSA") call but when it's translated into French the call becomes printf("Clave %s de %d bits", 1024, "RSA") and %s does not match 1024. The fix adds position parameters to printf resources strings when there are multiple arguments. The translations should follow. diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java --- a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java +++ b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java @@ -456,21 +456,21 @@ {"the.tsa.certificate", "The TSA certificate"}, {"the.input", "The input"}, {"reply", "Reply"}, - {"one.in.many", "%s #%d of %d"}, + {"one.in.many", "%1$s #%2$d of %3$d"}, {"alias.in.cacerts", "Issuer <%s> in cacerts"}, {"alias.in.keystore", "Issuer <%s>"}, {"with.weak", "%s (weak)"}, - {"key.bit", "%d-bit %s key"}, - {"key.bit.weak", "%d-bit %s key (weak)"}, + {"key.bit", "%1$d-bit %2$s key"}, + {"key.bit.weak", "%1$d-bit %2$s key (weak)"}, {"unknown.size.1", "unknown size %s key"}, {".PATTERN.printX509Cert.with.weak", "Owner: {0}\nIssuer: {1}\nSerial number: {2}\nValid from: {3} until: {4}\nCertificate fingerprints:\n\t SHA1: {5}\n\t SHA256: {6}\nSignature algorithm name: {7}\nSubject Public Key Algorithm: {8}\nVersion: {9}"}, {"PKCS.10.with.weak", "PKCS #10 Certificate Request (Version 1.0)\n" + - "Subject: %s\nFormat: %s\nPublic Key: %s\nSignature algorithm: %s\n"}, - {"verified.by.s.in.s.weak", "Verified by %s in %s with a %s"}, - {"whose.sigalg.risk", "%s uses the %s signature algorithm which is considered a security risk."}, - {"whose.key.risk", "%s uses a %s which is considered a security risk."}, + "Subject: %1$s\nFormat: %2$s\nPublic Key: %3$s\nSignature algorithm: %4$s\n"}, + {"verified.by.s.in.s.weak", "Verified by %1$s in %2$s with a %3$s"}, + {"whose.sigalg.risk", "%1$s uses the %2$s signature algorithm which is considered a security risk."}, + {"whose.key.risk", "%1$s uses a %2$s which is considered a security risk."}, {"jks.storetype.warning", "The %1$s keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using \"keytool -importkeystore -srckeystore %2$s -destkeystore %2$s -deststoretype pkcs12\"."}, {"migrate.keystore.warning", "Migrated \"%1$s\" to %4$s. The %2$s keystore is backed up as \"%3$s\"."}, {"backup.keystore.warning", "The original keystore \"%1$s\" is backed up as \"%3$s\"..."}, diff --git a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java --- a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java +++ b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java @@ -270,7 +270,7 @@ {"The.1.algorithm.specified.for.the.2.option.is.considered.a.security.risk.", "The %1$s algorithm specified for the %2$s option is considered a security risk."}, {"The.1.signing.key.has.a.keysize.of.2.which.is.considered.a.security.risk.", - "The %s signing key has a keysize of %d which is considered a security risk."}, + "The %1$s signing key has a keysize of %2$d which is considered a security risk."}, {"This.jar.contains.entries.whose.certificate.chain.is.invalid.reason.1", "This jar contains entries whose certificate chain is invalid. Reason: %s"}, {"This.jar.contains.entries.whose.tsa.certificate.chain.is.invalid.reason.1", After this there is neither /%.*%[^0-9]/ nor /%[^0-9].*%/ patterns. Thanks Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Tue Nov 14 06:16:25 2017 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 14 Nov 2017 14:16:25 +0800 Subject: RFR[10] 8186057: TLS interoperability testing between different Java versions In-Reply-To: References: <12833c7c-3b34-3d8a-77ee-9299e8cca88d@oracle.com> <05d9da98-205a-887d-ad88-c88b15832947@oracle.com> <7fcc23e3-dd4e-d127-0cc2-f4990fb5d665@oracle.com> <894241da-b4d7-46ce-2962-c3e6e9a2227b@oracle.com> Message-ID: <1e8d1acf-7f06-9e08-5a48-a65751586471@oracle.com> Hi Artem, Please find the new webrev [1]. This test has been refactored significantly. It supports more cipher suites, and case combinations among the TLS communication parameters. For more details, please look through README [2]. [1] http://cr.openjdk.java.net/~jjiang/8186057/webrev.04/ [2] http://cr.openjdk.java.net/~jjiang/8186057/webrev.04/test/jdk/javax/net/ssl/compatibility/README.html Best regards, John Jiang On 07/09/2017 18:47, sha.jiang at oracle.com wrote: > Hi Artem, > > On 07/09/2017 16:28, Artem Smotrakov wrote: >> In case of SNI, SSLParemeters.setServerNames() method (and others >> related to SNI) was introduced in 8. I don't think the code which use >> this method can be compiled with 6 and 7. > All of Java source are compiled by a JDK 10 build, which is specified > by jtreg option "-jdk". Other testing JDKs, including 6 and 7, just > use the .class files on runtime. > That's why the below line exists in Compatibility.java, > 32? * @compile -source 1.6 -target 1.6 Server.java Client.java > JdkUtils.java >> >> But if you want to test SNI with 8+, you need to call them. >> >> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLParameters.html#setServerNames-java.util.List- >> > If a feature, like ALPN and SNI, is not supported, such method would > not be called on runtime. > > Best regards, > John Jiang >> >> Artem >> >> On 09/07/2017 11:24 AM, sha.jiang at oracle.com wrote: >>> Hi Artem, >>> >>> On 07/09/2017 16:07, Artem Smotrakov wrote: >>>>> >>>>>> - Please use try-with-resources if possible (files, sockets, etc) >>>>> The test uses only JDK 6-supported language features, but >>>>> try-with-resources is introduced by JDK 7. >>>> Here we come to another issue. I believe that it would be good to >>>> use write clients for all JDK versions. If you use the same code >>>> for all Java versions, that means that you use only JDK 6 API. >>>> Let's consider the following: >>>> - we want to test 8 vs 9 >>>> - 8 and 9 may have some API (or just functionality) which is not >>>> supported by 6 (for example, ALPN, SNI) >>>> >>>> If you write code which is compatible with 6, then you can use API >>>> from newer versions, but we still may want to test it. >>> In fact, the current test has already covered ALPN, though only JDK >>> 9 and 10 support the associated methods, like >>> SSLParameters.getApplicationProtocols(). >>> ALPN-associated case combinations are ignored if a JDK doesn't >>> support this feature. Exactly, JdkUtils checks if a specific JDK >>> build contains method SSLParameters.getApplicationProtocols(). >>> I think the same approach could be applied for SNI in the future. >>> >>> Best regards, >>> John Jiang >>>> >>>> Artem >>>>> >>>>> Best regards, >>>>> John Jiang >>>>>> >>>>>> Artem >>>>>> >>>>>> On 09/07/2017 08:52 AM, sha.jiang at oracle.com wrote: >>>>>>> Hi, >>>>>>> Please review this test for checking the interop compatibility >>>>>>> on JSSE among different JDK releases (from 6 to 10). >>>>>>> It covers the cases, like handshake, data exchange, client >>>>>>> authentication and APLN, on all TLS versions (if possible). >>>>>>> And the selected TLS cipher suites are: >>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA >>>>>>> and TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA. >>>>>>> For more details, please look though the README. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8186057/webrev.00 >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8186057 >>>>>>> >>>>>>> Best regards, >>>>>>> John Jiang >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > > From sgehwolf at redhat.com Tue Nov 14 10:02:59 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 14 Nov 2017 11:02:59 +0100 Subject: RFR 8191137: keytool fails to format resource strings for keys for some languages after JDK-8171319 In-Reply-To: References: Message-ID: <1510653779.3978.1.camel@redhat.com> Hi, On Tue, 2017-11-14 at 12:20 +0800, Weijun Wang wrote: > keytool contains a printf("%d-bit %s key", 1024, "RSA") call but when it's translated into French the call becomes printf("Clave %s de %d bits", 1024, "RSA") and %s does not match 1024. > > The fix adds position parameters to printf resources strings when there are multiple arguments. The translations should follow. > > diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java > --- a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java > +++ b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java > @@ -456,21 +456,21 @@ > ?? ? ? ? {"the.tsa.certificate", "The TSA certificate"}, > ?? ? ? ? {"the.input", "The input"}, > ?? ? ? ? {"reply", "Reply"}, > -? ? ? ? {"one.in.many", "%s #%d of %d"}, > +? ? ? ? {"one.in.many", "%1$s #%2$d of %3$d"}, > ?? ? ? ? {"alias.in.cacerts", "Issuer <%s> in cacerts"}, > ?? ? ? ? {"alias.in.keystore", "Issuer <%s>"}, > ?? ? ? ? {"with.weak", "%s (weak)"}, > -? ? ? ? {"key.bit", "%d-bit %s key"}, > -? ? ? ? {"key.bit.weak", "%d-bit %s key (weak)"}, > +? ? ? ? {"key.bit", "%1$d-bit %2$s key"}, > +? ? ? ? {"key.bit.weak", "%1$d-bit %2$s key (weak)"}, > ?? ? ? ? {"unknown.size.1", "unknown size %s key"}, > ?? ? ? ? {".PATTERN.printX509Cert.with.weak", > ?? ? ? ? ? ? ? ? "Owner: {0}\nIssuer: {1}\nSerial number: {2}\nValid from: {3} until: {4}\nCertificate fingerprints:\n\t SHA1: {5}\n\t SHA256: {6}\nSignature algorithm name: {7}\nSubject Public Key Algorithm: {8}\nVersion: {9}"}, > ?? ? ? ? {"PKCS.10.with.weak", > ?? ? ? ? ? ? ? ? "PKCS #10 Certificate Request (Version 1.0)\n" + > -? ? ? ? ? ? ? ? ? ? ? ? "Subject: %s\nFormat: %s\nPublic Key: %s\nSignature algorithm: %s\n"}, > -? ? ? ? {"verified.by.s.in.s.weak", "Verified by %s in %s with a %s"}, > -? ? ? ? {"whose.sigalg.risk", "%s uses the %s signature algorithm which is considered a security risk."}, > -? ? ? ? {"whose.key.risk", "%s uses a %s which is considered a security risk."}, > +? ? ? ? ? ? ? ? ? ? ? ? "Subject: %1$s\nFormat: %2$s\nPublic Key: %3$s\nSignature algorithm: %4$s\n"}, > +? ? ? ? {"verified.by.s.in.s.weak", "Verified by %1$s in %2$s with a %3$s"}, > +? ? ? ? {"whose.sigalg.risk", "%1$s uses the %2$s signature algorithm which is considered a security risk."}, > +? ? ? ? {"whose.key.risk", "%1$s uses a %2$s which is considered a security risk."}, > ?? ? ? ? {"jks.storetype.warning", "The %1$s keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using \"keytool -importkeystore -srckeystore %2$s -destkeystore %2$s -deststoretype pkcs12\"."}, > ?? ? ? ? {"migrate.keystore.warning", "Migrated \"%1$s\" to %4$s. The %2$s keystore is backed up as \"%3$s\"."}, > ?? ? ? ? {"backup.keystore.warning", "The original keystore \"%1$s\" is backed up as \"%3$s\"..."}, > diff --git a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java > --- a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java > +++ b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java > @@ -270,7 +270,7 @@ > ?? ? ? ? {"The.1.algorithm.specified.for.the.2.option.is.considered.a.security.risk.", > ?? ? ? ? ? ? ? ? "The %1$s algorithm specified for the %2$s option is considered a security risk."}, > ?? ? ? ? {"The.1.signing.key.has.a.keysize.of.2.which.is.considered.a.security.risk.", > -? ? ? ? ? ? ? ? "The %s signing key has a keysize of %d which is considered a security risk."}, > +? ? ? ? ? ? ? ? "The %1$s signing key has a keysize of %2$d which is considered a security risk."}, > ?? ? ? ? {"This.jar.contains.entries.whose.certificate.chain.is.invalid.reason.1", > ? ? ? ? ? ? ? ? ? "This jar contains entries whose certificate chain is invalid. Reason: %s"}, > ?? ? ? ? {"This.jar.contains.entries.whose.tsa.certificate.chain.is.invalid.reason.1", > > After this there is neither?/%.*%[^0-9]/?nor?/%[^0-9].*%/?patterns. This looks fine, but I wonder if a regression test would be in order. E.g. test/sun/security/tools/keytool/WeakAlg.java with -Duser.language=fr or some such. Thanks, Severin From weijun.wang at oracle.com Tue Nov 14 10:47:31 2017 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 14 Nov 2017 18:47:31 +0800 Subject: RFR 8191137: keytool fails to format resource strings for keys for some languages after JDK-8171319 In-Reply-To: <1510653779.3978.1.camel@redhat.com> References: <1510653779.3978.1.camel@redhat.com> Message-ID: <14C79664-290F-4554-8957-3D8DDCA43695@oracle.com> > ? 2017?11?14??18:02?Severin Gehwolf ??? > > This looks fine, but I wonder if a regression test would be in order. > E.g. test/sun/security/tools/keytool/WeakAlg.java with > -Duser.language=fr or some such. But my change has not really fixed anything. It?s just a hint on how to correctly translate the strings. The test you suggested would still fail after this change. It might be useful when the French translation is updated. Thanks Max > > Thanks, > Severin From sgehwolf at redhat.com Tue Nov 14 11:40:45 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 14 Nov 2017 12:40:45 +0100 Subject: RFR 8191137: keytool fails to format resource strings for keys for some languages after JDK-8171319 In-Reply-To: <14C79664-290F-4554-8957-3D8DDCA43695@oracle.com> References: <1510653779.3978.1.camel@redhat.com> <14C79664-290F-4554-8957-3D8DDCA43695@oracle.com> Message-ID: <1510659645.3978.3.camel@redhat.com> On Tue, 2017-11-14 at 18:47 +0800, Wang Weijun wrote: > > ? 2017?11?14??18:02?Severin Gehwolf ??? > > > > This looks fine, but I wonder if a regression test would be in > > order. > > E.g. test/sun/security/tools/keytool/WeakAlg.java with > > -Duser.language=fr or some such. > > But my change has not really fixed anything. It?s just a hint on how > to correctly translate the strings. The test you suggested would > still fail after this change. It might be useful when the French > translation is updated.? Why can't this change update Resources_fr.java to include the correct position and then the test updated to also work in French? It's not really a localization change, but introduction of the correct position of the parameter. A follow-up bug could then move all other resources to a model similar to Resources_fr.java? Thanks, Severin From weijun.wang at oracle.com Tue Nov 14 12:21:37 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Nov 2017 20:21:37 +0800 Subject: RFR 8191137: keytool fails to format resource strings for keys for some languages after JDK-8171319 In-Reply-To: <1510659645.3978.3.camel@redhat.com> References: <1510653779.3978.1.camel@redhat.com> <14C79664-290F-4554-8957-3D8DDCA43695@oracle.com> <1510659645.3978.3.camel@redhat.com> Message-ID: <01D9891A-C7C6-48E2-B63B-162B909CFE29@oracle.com> > On Nov 14, 2017, at 7:40 PM, Severin Gehwolf wrote: > > On Tue, 2017-11-14 at 18:47 +0800, Wang Weijun wrote: >>> ? 2017?11?14??18:02?Severin Gehwolf ??? >>> >>> This looks fine, but I wonder if a regression test would be in >>> order. >>> E.g. test/sun/security/tools/keytool/WeakAlg.java with >>> -Duser.language=fr or some such. >> >> But my change has not really fixed anything. It?s just a hint on how >> to correctly translate the strings. The test you suggested would >> still fail after this change. It might be useful when the French >> translation is updated. > > Why can't this change update Resources_fr.java to include the correct > position and then the test updated to also work in French? It's not > really a localization change, but introduction of the correct position > of the parameter. I cannot be sure about the change, and there could be other places where similar change is needed. I'll leave it to the globalization team. This won't waste much time and they will be able to fix the problem in all releases at the same time. In fact, I initially assign this bug to globalization directly, but they suggested me to add position labels into the English resources first so they can follow. -- > A follow-up bug could then move all other resources to a model similar > to Resources_fr.java? > > Thanks, > Severin From sean.mullan at oracle.com Tue Nov 14 13:05:00 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Nov 2017 08:05:00 -0500 Subject: RFR 8191137: keytool fails to format resource strings for keys for some languages after JDK-8171319 In-Reply-To: References: Message-ID: Fix looks good. Do you also need to add a label or subtask to the bug so that the localization team knows that they still need to fix the resource files? --Sean On 11/13/17 11:20 PM, Weijun Wang wrote: > keytool contains a printf("%d-bit %s key", 1024, "RSA") call but when > it's translated into French the call becomes printf("Clave %s de %d > bits", 1024, "RSA") and %s does not match 1024. > > The fix adds position parameters to printf resources strings when there > are multiple arguments. The translations should follow. > > *diff --git > a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java > b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java* > *--- > a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java* > *+++ > b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java* > @@ -456,21 +456,21 @@ > ?? ? ? ? {"the.tsa.certificate", "The TSA certificate"}, > ?? ? ? ? {"the.input", "The input"}, > ?? ? ? ? {"reply", "Reply"}, > -? ? ? ? {"one.in.many", "%s #%d of %d"}, > +? ? ? ? {"one.in.many", "%1$s #%2$d of %3$d"}, > ?? ? ? ? {"alias.in.cacerts", "Issuer <%s> in cacerts"}, > ?? ? ? ? {"alias.in.keystore", "Issuer <%s>"}, > ?? ? ? ? {"with.weak", "%s (weak)"}, > -? ? ? ? {"key.bit", "%d-bit %s key"}, > -? ? ? ? {"key.bit.weak", "%d-bit %s key (weak)"}, > +? ? ? ? {"key.bit", "%1$d-bit %2$s key"}, > +? ? ? ? {"key.bit.weak", "%1$d-bit %2$s key (weak)"}, > ?? ? ? ? {"unknown.size.1", "unknown size %s key"}, > ?? ? ? ? {".PATTERN.printX509Cert.with.weak", > ?? ? ? ? ? ? ? ? "Owner: {0}\nIssuer: {1}\nSerial number: {2}\nValid > from: {3} until: {4}\nCertificate fingerprints:\n\t SHA1: {5}\n\t > SHA256: {6}\nSignature algorithm name: {7}\nSubject Public Key > Algorithm: {8}\nVersion: {9}"}, > ?? ? ? ? {"PKCS.10.with.weak", > ?? ? ? ? ? ? ? ? "PKCS #10 Certificate Request (Version 1.0)\n" + > -? ? ? ? ? ? ? ? ? ? ? ? "Subject: %s\nFormat: %s\nPublic Key: > %s\nSignature algorithm: %s\n"}, > -? ? ? ? {"verified.by.s.in.s.weak", "Verified by %s in %s with a %s"}, > -? ? ? ? {"whose.sigalg.risk", "%s uses the %s signature algorithm which > is considered a security risk."}, > -? ? ? ? {"whose.key.risk", "%s uses a %s which is considered a security > risk."}, > +? ? ? ? ? ? ? ? ? ? ? ? "Subject: %1$s\nFormat: %2$s\nPublic Key: > %3$s\nSignature algorithm: %4$s\n"}, > +? ? ? ? {"verified.by.s.in.s.weak", "Verified by %1$s in %2$s with a > %3$s"}, > +? ? ? ? {"whose.sigalg.risk", "%1$s uses the %2$s signature algorithm > which is considered a security risk."}, > +? ? ? ? {"whose.key.risk", "%1$s uses a %2$s which is considered a > security risk."}, > ?? ? ? ? {"jks.storetype.warning", "The %1$s keystore uses a > proprietary format. It is recommended to migrate to PKCS12 which is an > industry standard format using \"keytool -importkeystore -srckeystore > %2$s -destkeystore %2$s -deststoretype pkcs12\"."}, > ?? ? ? ? {"migrate.keystore.warning", "Migrated \"%1$s\" to %4$s. The > %2$s keystore is backed up as \"%3$s\"."}, > ?? ? ? ? {"backup.keystore.warning", "The original keystore \"%1$s\" is > backed up as \"%3$s\"..."}, > *diff --git > a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java > b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java* > *--- > a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java* > *+++ > b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java* > @@ -270,7 +270,7 @@ > > {"The.1.algorithm.specified.for.the.2.option.is.considered.a.security.risk.", > ?? ? ? ? ? ? ? ? "The %1$s algorithm specified for the %2$s option is > considered a security risk."}, > > {"The.1.signing.key.has.a.keysize.of.2.which.is.considered.a.security.risk.", > -? ? ? ? ? ? ? ? "The %s signing key has a keysize of %d which is > considered a security risk."}, > +? ? ? ? ? ? ? ? "The %1$s signing key has a keysize of %2$d which is > considered a security risk."}, > > {"This.jar.contains.entries.whose.certificate.chain.is.invalid.reason.1", > ? ? ? ? ? ? ? ? ? "This jar contains entries whose certificate chain is > invalid. Reason: %s"}, > > {"This.jar.contains.entries.whose.tsa.certificate.chain.is.invalid.reason.1", > > After this there is neither /%.*%[^0-9]/?nor /%[^0-9].*%/?patterns. > Thanks > Max From seandawson2015 at gmail.com Tue Nov 14 13:32:39 2017 From: seandawson2015 at gmail.com (Sean Dawson) Date: Tue, 14 Nov 2017 08:32:39 -0500 Subject: java.net.ConnectException: Received fatal alert:unexpected_message In-Reply-To: <5a08b7b4.3bb0df0a.47892.a68f@mx.google.com> References: <16b5b168-23a2-161a-c093-e3f06f31ba9d@gmail.com> <5a08b7b4.3bb0df0a.47892.a68f@mx.google.com> Message-ID: Thank you for the responses - turns out that even though I was using the latest version of AsyncHttpClient that I found in maven; there was another slightly different one that was more current - and seems to work. Old: https://mvnrepository.com/artifact/com.ning/async-http-client Newer: https://mvnrepository.com/artifact/org.asynchttpclient/async-http-client On Sun, Nov 12, 2017 at 4:05 PM, Bernd Eckenfels wrote: > The newer the Jetty Server is the more unlikely it Supports the old and > unsafe SSL2 handshake. You should not enable the SSL2Hello pseudo protocol > on Client side. JDK certainly does not by Default. > > > > Gruss > > Bernd > > -- > http://bernd.eckenfels.net > > > > *Von: *Sean Dawson > *Gesendet: *Sonntag, 12. November 2017 20:24 > *An: *security-dev at openjdk.java.net > *Betreff: *Re: java.net.ConnectException: Received fatal > alert:unexpected_message > > > > > > Thanks for the reply. This is one of the latest versions of Jetty so I > would hope that it would support that. But I've also tried specifying > various other http.protocols on both sides but it hasn't seemed to change > the result. Any other flags or things I should try? > > > > On Fri, Nov 10, 2017 at 11:48 PM, Jaikiran Pai > wrote: > > > Java 1.8.0_131 > > Both servers on same machine, using same Java > > Source server is using async-http-client 1.9.18 > > Destination server is using Jetty 9.4.7.v20170914 > > .... > > > New I/O worker #10, WRITE: TLSv1.2 Handshake, length = 161 > > [write] MD5 and SHA1 hashes: len = 140 > > 0000: 01 03 03 00 63 00 00 00 20 00 C0 23 00 C0 27 00 ....c... ..#..'. > > ... > > 0080: 07 06 BB A0 AB 39 66 80 95 55 14 65 .....9f..U.e > > New I/O worker #10, WRITE: SSLv2 client hello message, length = 140 > > It looks like the async-http-client is sending a SSLv2 client hello > message during the handshake and I'm guessing Jetty doesn't support (or > maybe has disabled) SSLv2Hello handshake messages. What SSL protocols have > you enabled on both these sides? If you haven't explicitly enabled any, > then what do they default to in these libraries/servers? > > -Jaikiran > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Tue Nov 14 15:34:49 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 14 Nov 2017 10:34:49 -0500 Subject: JDK-8180819 No installed provider supports this key: sun.security.pkcs.PKCS8Key In-Reply-To: <63f00010-f1cc-9200-7eae-d1d7b425dd41@3kraft.com> References: <63f00010-f1cc-9200-7eae-d1d7b425dd41@3kraft.com> Message-ID: On 11/13/2017 2:20 PM, Florian Bruckner (3kraft) wrote: > Hi, > > have just stumbled upon a quite strange behavior in a SSL connection > with a client certificate. Looks like your private key is BER encoded. I think this is supposed to be fine, but the code is being a bit too strict and rejecting it. There was a change around 8u121 that added some more DER enforcement. Can you try converting everything to DER to see if that clears up the problem? You can do this with openssl e.g.: openssl pkcs12 -in pkcs12-file -out key-and-cert -nodes -passin pass:abcXYZ openssl pkcs12 -in key-and-cert -export -out new-pkcs12-file -passout pass:abcXYZ The JKS exception doesn't really provide a lot of information. It would be helpful if you could import the DER-formatted PKCS#12 file back into JKS and let me know if that works. From sean.mullan at oracle.com Tue Nov 14 18:47:10 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Nov 2017 13:47:10 -0500 Subject: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator In-Reply-To: References: <112aed8a-88ea-8e3e-b69a-27f32b7a287c@oracle.com> Message-ID: On 11/8/17 6:47 PM, Valerie Peng wrote: > Hi, Sean, > > I updated the webrev in place - now this change contains only javadoc > update of DSAKeyPairGenerator interface. > CSR has also been updated accordingly. Could you please take a look? Sure. 35 * DSAKeyPairGenerator, each provider must supply (and document) a 36 * default initialization. I suggest saying "should" instead of "must" since we can't really require this to be documented, esp. for a 3rd-party provider. Also I would say "each provider that implements this interface ...". 52 * DSAKeyPairGenerator, then call one of the {@code initialize} methods Slight rewording suggestion: "DSAKeyPairGenerator and calling one of the {@code initialize} methods" 103 * thrown. It is guaranteed that there will always be 104 * default parameters for modulus lengths of 512, 1024, and 2048 bits. I guess "guaranteed" is referring to any impl of DSAKeyPairGenerator, but it is kind of hard to enforce that if you are using a 3rd-party provider. I think we should consider just removing this sentence entirely and leaving the requirements up to the implementation. It's also unusual that we would require 512-bits, and hard-coding that might make it hard to remove later on. Minimally, I think we should remove 512. --Sean > > Thanks, > Valerie > > On 11/2/2017 6:24 PM, Valerie Peng wrote: >> Sean, >> >> Could you help review this RFE below? It's mainly the javadoc update >> of java.security.interfaces.DSAKeyPairGenerator which replaces the >> 1024-bit default value with provider-specific one and removal of the >> earlier changes for working around this javadoc limitation. I reused >> the wordings from existing security classes. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8182484 >> Webrev: http://cr.openjdk.java.net/~valeriep/8182484/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8190569 >> >> Thanks, >> Valerie > From jamil.j.nimeh at oracle.com Wed Nov 15 16:43:48 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 15 Nov 2017 08:43:48 -0800 Subject: KDF API review, round 2 Message-ID: Hello all, Thanks to everyone who has given input so far. I've updated the KeyDerivation API with the comments I've received. The new specification is here: Text: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/kdfspec.02.txt Javadoc: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/javadoc.02/ In terms of high level changes: * Moved to a getInstance/init usage pattern similar to Mac, KeyAgreement, Cipher, etc. This allows KDF objects to be reused with different parameters by reinitializing. * Name change: DerivedKeyParameterSpec --> DerivationParameterSpec * Keys returned by derivation methods are now java.security.Key rather than SecretKey * Provided additional derivation methods to support non-key based output: deriveData, deriveObject * Added a new constructor to DerivationParameterSpec to support the Object return type. Thanks, --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Wed Nov 15 17:26:14 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 15 Nov 2017 09:26:14 -0800 Subject: KDF API review, round 2 In-Reply-To: References: Message-ID: Hello everyone, one other request. I would like to end this comment period by the end of next week (11/24) ideally. Thanks, --Jamil On 11/15/2017 08:43 AM, Jamil Nimeh wrote: > Hello all, > > Thanks to everyone who has given input so far. I've updated the > KeyDerivation API with the comments I've received. The new > specification is here: > > Text: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/kdfspec.02.txt > Javadoc: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/javadoc.02/ > > In terms of high level changes: > > * Moved to a getInstance/init usage pattern similar to Mac, > KeyAgreement, Cipher, etc. This allows KDF objects to be reused > with different parameters by reinitializing. > * Name change: DerivedKeyParameterSpec --> DerivationParameterSpec > * Keys returned by derivation methods are now java.security.Key > rather than SecretKey > * Provided additional derivation methods to support non-key based > output: deriveData, deriveObject > * Added a new constructor to DerivationParameterSpec to support the > Object return type. > > Thanks, > --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Thu Nov 16 05:47:57 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 16 Nov 2017 00:47:57 -0500 Subject: KDF API review, round 2 In-Reply-To: References: Message-ID: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> On 11/15/2017 11:43 AM, Jamil Nimeh wrote: > Hello all, > > Thanks to everyone who has given input so far.? I've updated the > KeyDerivation API with the comments I've received.? The new > specification is here: > > Text: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/kdfspec.02.txt > Javadoc: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/javadoc.02/ > > In terms of high level changes: > > * Moved to a getInstance/init usage pattern similar to Mac, > KeyAgreement, Cipher, etc.? This allows KDF objects to be reused > with different parameters by reinitializing. > * Name change: DerivedKeyParameterSpec --> DerivationParameterSpec > * Keys returned by derivation methods are now java.security.Key > rather than SecretKey > * Provided additional derivation methods to support non-key based > output: deriveData, deriveObject > * Added a new constructor to DerivationParameterSpec to support the > Object return type. > > Thanks, > --Jamil This is pretty close, but I think you need to add an AlgorithmParameters argument to each of the getInstance calls in KeyDerivation - or require each KDF to specify a default model - not all KDFs are fully specified in a given document. Alternately, you could use the .setParameter/.getParameter model of signature,? but it may be that underlying code will actually be creating a whole new instance.? (E.g. getInstance("NIST-SP800-108") vs getInstance("NIST-SP800-108-Counter") vs getInstance("NIST-SP800-108/Counter")) Here's the model I'm thinking about: SP800-108 is a parameterized set of Key derivation functions which goes something like: Pick either Counter or Feedback Pick the PRF (e.g. HMAC-SHA256, AES-128-CMAC, etc) Pick the size of the counter and endianness:? (e.g. Big endian Uint16) Pick the size and endianness of L Pick whether the counter precedes or follows the fixed data (for counter mode). Pick whether the counter is included and whether it precedes or follows the fixed data (for feedback mode) Taken together those instantiation parameters define a particular KDF model. Then for the .init() call, the kdfParams is where the Label and Context data go (what HKDF calls 'info').? For most KDFs this could just be a byte array. For HKDF the getInstance must specify an underlying hash function - by definition mode is feedback, the size of the counter is fixed, L is not included in the base calculation.? (TLS1.3 uses HKDF and makes L a mandatory part of the HKDF). I want to do a worked example from instantiation to use to make sure this covers the corner cases.? Give me a day....? I'm currently in Singapore. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Thu Nov 16 18:29:53 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 16 Nov 2017 13:29:53 -0500 Subject: Draft design for Key Derivation API In-Reply-To: References: <71d0e6e2-b133-9dd9-4f85-6ce70c994016@oracle.com> <98017da2-ae47-31ce-8fd6-5e21295d41a7@oracle.com> Message-ID: <6058eab6-dde1-24e3-30d2-a084380f1a17@oracle.com> On 11/8/2017 6:50 PM, Michael StJohns wrote: >>> On 11/3/2017 4:59 PM, Jamil Nimeh wrote: >>>> Add a .deriveData() with a return class of byte[].?? This gets a >>>> portion of the derived data stream in the clear. E.g. an IV. >>>> >>>> Add a .deriveObject() with a return class of Object.? The returned >>>> object may not be an instance of java.security.Key.? This takes the >>>> derived data stream and converts it into the object type specified >>>> by the derivation parameter.? In a hardware security module, this >>>> might be a reference to a secured set of data or even an >>>> confidential IV. >>> Again, just want to make sure I understand fully: So in a case where >>> I want a given output to be an Object, I would provide a >>> DerivationParameterSpec with an alg of..."Object" (?), a byte >>> length, and Object-specific parameters provided through the "params" >>> argument to the DPS? > > Working this through, but it should be a Class? being specified with a > constructor of a byte array plus a length. What is the motivation behind this constructor that takes a byte array? It seems like this constructor wouldn't actually help in a hardware implementation. Would it be better to leave the construction of this object to the implementation? From adam.petcher at oracle.com Thu Nov 16 19:15:02 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 16 Nov 2017 14:15:02 -0500 Subject: KDF API review, round 2 In-Reply-To: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> Message-ID: On 11/16/2017 12:47 AM, Michael StJohns wrote: > This is pretty close, but I think you need to add an > AlgorithmParameters argument to each of the getInstance calls in > KeyDerivation - or require each KDF to specify a default model - not > all KDFs are fully specified in a given document. > > Alternately, you could use the .setParameter/.getParameter model of > signature,? but it may be that underlying code will actually be > creating a whole new instance.? (E.g. getInstance("NIST-SP800-108") vs > getInstance("NIST-SP800-108-Counter") vs > getInstance("NIST-SP800-108/Counter")) > > > Here's the model I'm thinking about: > > SP800-108 is a parameterized set of Key derivation functions which > goes something like: > > Pick either Counter or Feedback > > Pick the PRF (e.g. HMAC-SHA256, AES-128-CMAC, etc) > Pick the size of the counter and endianness:? (e.g. Big endian > Uint16) > > Pick the size and endianness of L > > Pick whether the counter precedes or follows the fixed data > (for counter mode). > Pick whether the counter is included and whether it precedes > or follows the fixed data (for feedback mode) > > > Taken together those instantiation parameters define a particular KDF > model. > > Then for the .init() call, the kdfParams is where the Label and > Context data go (what HKDF calls 'info').? For most KDFs this could > just be a byte array. > > For HKDF the getInstance must specify an underlying hash function - by > definition mode is feedback, the size of the counter is fixed, L is > not included in the base calculation.? (TLS1.3 uses HKDF and makes L a > mandatory part of the HKDF). I don't like the idea of putting algorithm parameters in getInstance, because we don't have this pattern in JCA, and it doesn't seem like it is necessary here. In your example above, the first set of parameters are somehow different from the second set, but it is not clear how. So it seems like they could all be supplied to init. Alternatively, algorithm names could specify more concrete algorithms that include the mode/PRF/etc. Can you provide more information to explain why these existing patterns won't work in this case? -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri Nov 17 00:39:36 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 16 Nov 2017 16:39:36 -0800 Subject: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator In-Reply-To: References: <112aed8a-88ea-8e3e-b69a-27f32b7a287c@oracle.com> Message-ID: Thanks for the feedback. I have updated webrev to address your comments: http://cr.openjdk.java.net/~valeriep/8182484/webrev.01/ CSR has also been updated and proposed. Valerie On 11/14/2017 10:47 AM, Sean Mullan wrote: > On 11/8/17 6:47 PM, Valerie Peng wrote: >> Hi, Sean, >> >> I updated the webrev in place - now this change contains only javadoc >> update of DSAKeyPairGenerator interface. >> CSR has also been updated accordingly. Could you please take a look? > > Sure. > > ? 35? * DSAKeyPairGenerator, each provider must supply (and document) a > ? 36? * default initialization. > > I suggest saying "should" instead of "must" since we can't really > require this to be documented, esp. for a 3rd-party provider. Also I > would say "each provider that implements this interface ...". > > ? 52? * DSAKeyPairGenerator, then call one of the {@code initialize} > methods > > Slight rewording suggestion: "DSAKeyPairGenerator and calling one of > the {@code initialize} methods" > > ?103????? * thrown. It is guaranteed that there will always be > ?104????? * default parameters for modulus lengths of 512, 1024, and > 2048 bits. > > I guess "guaranteed" is referring to any impl of DSAKeyPairGenerator, > but it is kind of hard to enforce that if you are using a 3rd-party > provider. I think we should consider just removing this sentence > entirely and leaving the requirements up to the implementation. It's > also unusual that we would require 512-bits, and hard-coding that > might make it hard to remove later on. Minimally, I think we should > remove 512. > > --Sean > >> >> Thanks, >> Valerie >> >> On 11/2/2017 6:24 PM, Valerie Peng wrote: >>> Sean, >>> >>> Could you help review this RFE below? It's mainly the javadoc update >>> of java.security.interfaces.DSAKeyPairGenerator which replaces the >>> 1024-bit default value with provider-specific one and removal of the >>> earlier changes for working around this javadoc limitation. I reused >>> the wordings from existing security classes. >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8182484 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8182484/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190569 >>> >>> Thanks, >>> Valerie >> From mstjohns at comcast.net Fri Nov 17 15:04:05 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 17 Nov 2017 10:04:05 -0500 Subject: KDF API review, round 2 In-Reply-To: References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> Message-ID: On 11/16/2017 2:15 PM, Adam Petcher wrote: > > On 11/16/2017 12:47 AM, Michael StJohns wrote: > >> This is pretty close, but I think you need to add an >> AlgorithmParameters argument to each of the getInstance calls in >> KeyDerivation - or require each KDF to specify a default model - not >> all KDFs are fully specified in a given document. >> >> Alternately, you could use the .setParameter/.getParameter model of >> signature,? but it may be that underlying code will actually be >> creating a whole new instance.? (E.g. getInstance("NIST-SP800-108") >> vs getInstance("NIST-SP800-108-Counter") vs >> getInstance("NIST-SP800-108/Counter")) >> >> >> Here's the model I'm thinking about: >> >> SP800-108 is a parameterized set of Key derivation functions >> which goes something like: >> >> Pick either Counter or Feedback >> >> Pick the PRF (e.g. HMAC-SHA256, AES-128-CMAC, etc) >> Pick the size of the counter and endianness:? (e.g. Big >> endian Uint16) >> >> Pick the size and endianness of L >> >> Pick whether the counter precedes or follows the fixed data >> (for counter mode). >> Pick whether the counter is included and whether it precedes >> or follows the fixed data (for feedback mode) >> >> >> Taken together those instantiation parameters define a particular KDF >> model. >> >> Then for the .init() call, the kdfParams is where the Label and >> Context data go (what HKDF calls 'info').? For most KDFs this could >> just be a byte array. >> >> For HKDF the getInstance must specify an underlying hash function - >> by definition mode is feedback, the size of the counter is fixed, L >> is not included in the base calculation. (TLS1.3 uses HKDF and makes >> L a mandatory part of the HKDF). > > I don't like the idea of putting algorithm parameters in getInstance, > because we don't have this pattern in JCA, and it doesn't seem like it > is necessary here. Which is why I mentioned the Signature.setParameter() pattern as an alternative. > In your example above, the first set of parameters are somehow > different from the second set, but it is not clear how. The first set configures HOW the kdf operations, the second (.init()) gives the parameters needed for a specific set of invocations. > So it seems like they could all be supplied to init. Alternatively, > algorithm names could specify more concrete algorithms that include > the mode/PRF/etc. Can you provide more information to explain why > these existing patterns won't work in this case? What I need to do is provide a lifecycle diagram, but its hard to do in text.? But basically, the .getInstance() followed by .setParameters() builds a concrete engine while the .init() initializes that engine with a key and the derivation parameters. Think about a TLS 1.2 instance - the PRF is selected once, but the KDF may be used multiple times. I considered the mode/PRF/etc stuff but that works for things like Cipher and Signature because most of those have exactly the same pattern.? For the KDF pattern we;ve got fully specified KDFs (e.g. TLS 1.1 and before, IPSEC), almost fully specified KDFs (TLS 1.2 and HDKF needs a PRF) and then the SP800 style KDFs which are defined to be *very* flexible.? So translating that into a naming convention is going to be restrictive and may not cover all of the possible approaches.? I'd rather do it as an algorithmparameter instead. With a given KDF implementation having a default if nothing is specified during instantiation. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Fri Nov 17 15:10:10 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 17 Nov 2017 10:10:10 -0500 Subject: Draft design for Key Derivation API In-Reply-To: <6058eab6-dde1-24e3-30d2-a084380f1a17@oracle.com> References: <71d0e6e2-b133-9dd9-4f85-6ce70c994016@oracle.com> <98017da2-ae47-31ce-8fd6-5e21295d41a7@oracle.com> <6058eab6-dde1-24e3-30d2-a084380f1a17@oracle.com> Message-ID: <73a5acfb-04be-e969-76da-11b668773ff2@comcast.net> On 11/16/2017 1:29 PM, Adam Petcher wrote: > On 11/8/2017 6:50 PM, Michael StJohns wrote: > >>>> On 11/3/2017 4:59 PM, Jamil Nimeh wrote: >>>>> Add a .deriveData() with a return class of byte[].?? This gets a >>>>> portion of the derived data stream in the clear. E.g. an IV. >>>>> >>>>> Add a .deriveObject() with a return class of Object.? The returned >>>>> object may not be an instance of java.security.Key.? This takes >>>>> the derived data stream and converts it into the object type >>>>> specified by the derivation parameter.? In a hardware security >>>>> module, this might be a reference to a secured set of data or even >>>>> an confidential IV. >>>> Again, just want to make sure I understand fully: So in a case >>>> where I want a given output to be an Object, I would provide a >>>> DerivationParameterSpec with an alg of..."Object" (?), a byte >>>> length, and Object-specific parameters provided through the >>>> "params" argument to the DPS? >> >> Working this through, but it should be a Class? being specified with >> a constructor of a byte array plus a length. > > What is the motivation behind this constructor that takes a byte > array? It seems like this constructor wouldn't actually help in a > hardware implementation. Would it be better to leave the construction > of this object to the implementation? This is a reasonable point, but misses a few things.?? If you're calling the hardware implementation from software, you need to be able to pass data from the software domain to hardware domain.? If the KDF and the Object are both in hardware, then the provider implementation doesn't actually externalize the byte array from the KDF - it just returns the final pointer to the object. The hardware/software boundary has some unique challenges - mostly these are handled OK in the JCA.? For this particular model, you need to be able to move bits from software to hardware which is the point of the constructor as specified.? For hardware to hardware it happens under the hood.? For hardware to software it may be prohibited (e.g. you can't actually externalize the bits of the key stream), but if its permitted then you need a simple way of translating key stream bytes into an object. Mike From adam.petcher at oracle.com Fri Nov 17 15:48:16 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 17 Nov 2017 10:48:16 -0500 Subject: Draft design for Key Derivation API In-Reply-To: <73a5acfb-04be-e969-76da-11b668773ff2@comcast.net> References: <71d0e6e2-b133-9dd9-4f85-6ce70c994016@oracle.com> <98017da2-ae47-31ce-8fd6-5e21295d41a7@oracle.com> <6058eab6-dde1-24e3-30d2-a084380f1a17@oracle.com> <73a5acfb-04be-e969-76da-11b668773ff2@comcast.net> Message-ID: <268fd139-6405-db93-49a4-59e19c91b44d@oracle.com> On 11/17/2017 10:10 AM, Michael StJohns wrote: > On 11/16/2017 1:29 PM, Adam Petcher wrote: >> On 11/8/2017 6:50 PM, Michael StJohns wrote: >> >> What is the motivation behind this constructor that takes a byte >> array? It seems like this constructor wouldn't actually help in a >> hardware implementation. Would it be better to leave the construction >> of this object to the implementation? > > This is a reasonable point, but misses a few things.?? If you're > calling the hardware implementation from software, you need to be able > to pass data from the software domain to hardware domain.? If the KDF > and the Object are both in hardware, then the provider implementation > doesn't actually externalize the byte array from the KDF - it just > returns the final pointer to the object. > > The hardware/software boundary has some unique challenges - mostly > these are handled OK in the JCA.? For this particular model, you need > to be able to move bits from software to hardware which is the point > of the constructor as specified.? For hardware to hardware it happens > under the hood.? For hardware to software it may be prohibited (e.g. > you can't actually externalize the bits of the key stream), but if its > permitted then you need a simple way of translating key stream bytes > into an object. That behavior all sounds reasonable, I just have doubts that this belongs in the spec. Are you expecting KeyDerivation to contain the logic in your last paragraph? Something like this: class KeyDerivation{ ? Object deriveObject() { ??? try { ????? return spi.deriveObject(); ??? } catch (...) { ????? Class clazz = // get the class from the parameters ????? return clazz.newInstance(deriveData(), length); // shorthand for getting the right ctor and calling it ??? } ? } } I would expect something like that to happen in the KeyDerivationSpi implementation instead, in which case it could construct the object any way it wants. So the spec would not need to place any requirements on the class of objects returned by deriveObject. From adam.petcher at oracle.com Fri Nov 17 18:07:05 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 17 Nov 2017 13:07:05 -0500 Subject: KDF API review, round 2 In-Reply-To: References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> Message-ID: On 11/17/2017 10:04 AM, Michael StJohns wrote: > On 11/16/2017 2:15 PM, Adam Petcher wrote: >> So it seems like they could all be supplied to init. Alternatively, >> algorithm names could specify more concrete algorithms that include >> the mode/PRF/etc. Can you provide more information to explain why >> these existing patterns won't work in this case? > What I need to do is provide a lifecycle diagram, but its hard to do > in text.? But basically, the .getInstance() followed by > .setParameters() builds a concrete engine while the .init() > initializes that engine with a key and the derivation parameters. > Think about a TLS 1.2 instance - the PRF is selected once, but the KDF > may be used multiple times. This is the information I was missing. There are two sets of parameters, and the first set should be fixed, but the second set should be changed on each init. > > I considered the mode/PRF/etc stuff but that works for things like > Cipher and Signature because most of those have exactly the same > pattern.? For the KDF pattern we;ve got fully specified KDFs (e.g. TLS > 1.1 and before, IPSEC), almost fully specified KDFs (TLS 1.2 and HDKF > needs a PRF) and then the SP800 style KDFs which are defined to be > *very* flexible.? So translating that into a naming convention is > going to be restrictive and may not cover all of the possible > approaches.? I'd rather do it as an algorithmparameter instead.? With > a given KDF implementation having a default if nothing is specified > during instantiation. I agree that this is challenging because there is so much variety in KDFs. But I don't think that SP 800-108 is a good example of something that should be exposed as an algorithm in JCA, because it is too broad. SP 800-108 is more of a toolbox that can be used to construct KDFs. Particular specializations of SP 800-108 are widely used, and they will get names that can be used in getInstance. For example, HKDF-Expand is a particular specialization of SP 800-108. So I think the existing pattern of using algorithm names to specify concrete algorithms should work just as well in this API as it does in the rest of JCA. Of course, more flexibility in the API is a nice feature, but supporting this level of generality may be out of scope for this effort. > > Mike > > > > From mstjohns at comcast.net Sun Nov 19 20:15:40 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Sun, 19 Nov 2017 15:15:40 -0500 Subject: Draft design for Key Derivation API In-Reply-To: <268fd139-6405-db93-49a4-59e19c91b44d@oracle.com> References: <71d0e6e2-b133-9dd9-4f85-6ce70c994016@oracle.com> <98017da2-ae47-31ce-8fd6-5e21295d41a7@oracle.com> <6058eab6-dde1-24e3-30d2-a084380f1a17@oracle.com> <73a5acfb-04be-e969-76da-11b668773ff2@comcast.net> <268fd139-6405-db93-49a4-59e19c91b44d@oracle.com> Message-ID: <530fb6bd-c12c-dc60-4537-0605726ddc0b@comcast.net> Sorry - I've been on travel for the last few days... comments below. On 11/17/2017 10:48 AM, Adam Petcher wrote: > On 11/17/2017 10:10 AM, Michael StJohns wrote: > >> On 11/16/2017 1:29 PM, Adam Petcher wrote: >>> On 11/8/2017 6:50 PM, Michael StJohns wrote: >>> >>> What is the motivation behind this constructor that takes a byte >>> array? It seems like this constructor wouldn't actually help in a >>> hardware implementation. Would it be better to leave the >>> construction of this object to the implementation? >> >> This is a reasonable point, but misses a few things.?? If you're >> calling the hardware implementation from software, you need to be >> able to pass data from the software domain to hardware domain.? If >> the KDF and the Object are both in hardware, then the provider >> implementation doesn't actually externalize the byte array from the >> KDF - it just returns the final pointer to the object. >> >> The hardware/software boundary has some unique challenges - mostly >> these are handled OK in the JCA.? For this particular model, you need >> to be able to move bits from software to hardware which is the point >> of the constructor as specified. For hardware to hardware it happens >> under the hood.? For hardware to software it may be prohibited (e.g. >> you can't actually externalize the bits of the key stream), but if >> its permitted then you need a simple way of translating key stream >> bytes into an object. > > That behavior all sounds reasonable, I just have doubts that this > belongs in the spec. Are you expecting KeyDerivation to contain the > logic in your last paragraph? Something like this: > > class KeyDerivation{ > ? Object deriveObject() { > ??? try { > ????? return spi.deriveObject(); > ??? } catch (...) { > ????? Class clazz = // get the class from the parameters > ????? return clazz.newInstance(deriveData(), length); // shorthand for > getting the right ctor and calling it > ??? } > ? } > } > > I would expect something like that to happen in the KeyDerivationSpi > implementation instead, in which case it could construct the object > any way it wants. So the spec would not need to place any requirements > on the class of objects returned by deriveObject. > KDFs are somewhat problematic in that *_they may not necessarily be producing objects from their own provider_*. This unfortunately isn't obvious, but let me try and explain. A KDF is basically a keyed pseudo-random number generator.? From the input key (and mixin context and label stuff) it produces a stream of bits.?? Once that's done, the stream of bits is assigned to various output objects - secret keys, private keys, a byte array[] or a cryptographic object of some sort (cf TLS exporters for an example of this).? The current draft has an implicit assumption that the Key based objects will be formed from the current provider.? The byte array output is a providerless java.lang object.? The last type provides a model to allow for the production of objects not within the current provider.?? You *could* just punt on this and assume that you take the output of the deriveData() call and feed it to a factory of the other provider, but that means that the derivation production will necessarily be in the clear because the stream data will pass through the JVM. Here's where it gets even trickier: A given provider has a given security domain.? E.g. most software providers share the JVM memory domain.? HSM providers have a security domain representing pointers to objects within the HSM secure perimeter.? Mostly now, HSM providers do not share the same domains - but there are some cases where this might be possible and desirable (different providers leveraged on top the same HSM implementation, two SMs with a trusted path between them - TPMs and TEEPs for example).? I'd *really* like it if there is some way to keep? data from two different providers sharing the same or compatible security domains from having to pass their key stream data through the unsecure JVM memory domain. Maybe there's a different way to do this - perhaps by changing the DeriviationParameterSpec to include the output provider?? But then you still need a way of generating non-key secure cryptographic objects I think.... Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Sun Nov 19 20:45:38 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Sun, 19 Nov 2017 15:45:38 -0500 Subject: KDF API review, round 2 In-Reply-To: References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> Message-ID: On 11/17/2017 1:07 PM, Adam Petcher wrote: > On 11/17/2017 10:04 AM, Michael StJohns wrote: > >> On 11/16/2017 2:15 PM, Adam Petcher wrote: >>> So it seems like they could all be supplied to init. Alternatively, >>> algorithm names could specify more concrete algorithms that include >>> the mode/PRF/etc. Can you provide more information to explain why >>> these existing patterns won't work in this case? >> What I need to do is provide a lifecycle diagram, but its hard to do >> in text.? But basically, the .getInstance() followed by >> .setParameters() builds a concrete engine while the .init() >> initializes that engine with a key and the derivation parameters. >> Think about a TLS 1.2 instance - the PRF is selected once, but the >> KDF may be used multiple times. > > This is the information I was missing. There are two sets of > parameters, and the first set should be fixed, but the second set > should be changed on each init. > >> >> I considered the mode/PRF/etc stuff but that works for things like >> Cipher and Signature because most of those have exactly the same >> pattern.? For the KDF pattern we;ve got fully specified KDFs (e.g. >> TLS 1.1 and before, IPSEC), almost fully specified KDFs (TLS 1.2 and >> HDKF needs a PRF) and then the SP800 style KDFs which are defined to >> be *very* flexible.? So translating that into a naming convention is >> going to be restrictive and may not cover all of the possible >> approaches.? I'd rather do it as an algorithmparameter instead.? With >> a given KDF implementation having a default if nothing is specified >> during instantiation. > > I agree that this is challenging because there is so much variety in > KDFs. But I don't think that SP 800-108 is a good example of something > that should be exposed as an algorithm in JCA, because it is too > broad. SP 800-108 is more of a toolbox that can be used to construct > KDFs. Particular specializations of SP 800-108 are widely used, and > they will get names that can be used in getInstance. For example, > HKDF-Expand is a particular specialization of SP 800-108. > > So I think the existing pattern of using algorithm names to specify > concrete algorithms should work just as well in this API as it does in > the rest of JCA. Of course, more flexibility in the API is a nice > feature, but supporting this level of generality may be out of scope > for this effort. The more I think about it the more I think you're mostly right.? But let's split this slightly as almost every KDF allows for the specification of the PRF.? So /??? as the standard naming convention. Or TLS13/HMAC-SHA256 and HKDF/HMAC-SHA256 (which are different because of the mandatory inclusion of "L" in the derivation parameters and each component object for TLS13) Still - let's include the .setParameters() call as a failsafe as looking forward I can see the need for flexibility rearing its ugly head (e.g. adding PSS parameters to RSA signatures way late in the game.....) and it does match the pattern for Signature so its not a new concept. A given provider need not support the call, but its there if needed. Mike > > >> >> Mike >> >> >> >> > From jamil.j.nimeh at oracle.com Mon Nov 20 10:12:26 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 20 Nov 2017 02:12:26 -0800 Subject: KDF API review, round 2 In-Reply-To: References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> Message-ID: <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> On 11/19/2017 12:45 PM, Michael StJohns wrote: > On 11/17/2017 1:07 PM, Adam Petcher wrote: >> On 11/17/2017 10:04 AM, Michael StJohns wrote: >> >>> On 11/16/2017 2:15 PM, Adam Petcher wrote: >>>> So it seems like they could all be supplied to init. Alternatively, >>>> algorithm names could specify more concrete algorithms that include >>>> the mode/PRF/etc. Can you provide more information to explain why >>>> these existing patterns won't work in this case? >>> What I need to do is provide a lifecycle diagram, but its hard to do >>> in text.? But basically, the .getInstance() followed by >>> .setParameters() builds a concrete engine while the .init() >>> initializes that engine with a key and the derivation parameters. >>> Think about a TLS 1.2 instance - the PRF is selected once, but the >>> KDF may be used multiple times. >> >> This is the information I was missing. There are two sets of >> parameters, and the first set should be fixed, but the second set >> should be changed on each init. >> >>> >>> I considered the mode/PRF/etc stuff but that works for things like >>> Cipher and Signature because most of those have exactly the same >>> pattern.? For the KDF pattern we;ve got fully specified KDFs (e.g. >>> TLS 1.1 and before, IPSEC), almost fully specified KDFs (TLS 1.2 and >>> HDKF needs a PRF) and then the SP800 style KDFs which are defined to >>> be *very* flexible.? So translating that into a naming convention is >>> going to be restrictive and may not cover all of the possible >>> approaches. I'd rather do it as an algorithmparameter instead.? With >>> a given KDF implementation having a default if nothing is specified >>> during instantiation. >> >> I agree that this is challenging because there is so much variety in >> KDFs. But I don't think that SP 800-108 is a good example of >> something that should be exposed as an algorithm in JCA, because it >> is too broad. SP 800-108 is more of a toolbox that can be used to >> construct KDFs. Particular specializations of SP 800-108 are widely >> used, and they will get names that can be used in getInstance. For >> example, HKDF-Expand is a particular specialization of SP 800-108. > >> >> So I think the existing pattern of using algorithm names to specify >> concrete algorithms should work just as well in this API as it does >> in the rest of JCA. Of course, more flexibility in the API is a nice >> feature, but supporting this level of generality may be out of scope >> for this effort. > > > The more I think about it the more I think you're mostly right. But > let's split this slightly as almost every KDF allows for the > specification of the PRF.? So > > /??? as the standard naming convention. > > Or TLS13/HMAC-SHA256 and HKDF/HMAC-SHA256 (which are different because > of the mandatory inclusion of "L" in the derivation parameters and > each component object for TLS13) > > Still - let's include the .setParameters() call as a failsafe as > looking forward I can see the need for flexibility rearing its ugly > head (e.g. adding PSS parameters to RSA signatures way late in the > game.....) and it does match the pattern for Signature so its not a > new concept. A given provider need not support the call, but its there > if needed. Signature appears to have setParameter because the initSign and initVerify didn't have APS parameters in their method signatures. Since we're talking about providing APS objects through both getInstance() for those locked to the algorithm and init() for things like salts, info, etc. that can be changed on successive inits it seems like we're covered without the need for a setParameter method. One additional topic for discussion: Late in the week we talked about the current state of the API internally and one item to revisit is where the DerivationParameterSpec objects are passed.? It was brought up by a couple people that it would be better to provide the DPS objects pertaining to keys at the time they are called for through deriveKey() and deriveKeys() (and possibly deriveData). Originally we had them all grouped in a List in the init method. One reason for needing it up there was to know the total length of material to generate.? If we can provide the total length through the AlgorithmParameterSpec passed in via init() then things like: Key deriveKey(DerivationParameterSpec param); List deriveKeys(List params); become possible.? To my eyes at least it does make it more clear what DPS you're processing since they're provided at derive time, rather than the caller having to keep track in their heads where in the DPS list they might be with each successive deriveKey or deriveKeys calls.? And I think we could do away with deriveKeys(int), too. --Jamil From Alan.Bateman at oracle.com Mon Nov 20 13:18:03 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Nov 2017 13:18:03 +0000 Subject: Eliminating the security overhead when not running with a security manager Message-ID: <22225416-222d-afe9-3da4-f2465e7786f6@oracle.com> One of the long standing issues with the security manager support is that the overhead when there is no security manager is non-zero. Two specific examples are (i) the overhead of defineClass (assuming the defining loader is a SecureClassLoader) as it involves a callback to get the permissions for the protection domain and (ii) the overhead of AccessController.doPrivileged in order to execute an action on a privileged stack. The bigger question is of course whether it is interesting to run with a security manager in 2017. It's clearly still important for environments that download potentially malicious code to execute in a sandox but that isn't most applications these days. We have seen a few cases where applications set a security manager in order to enforce some policy, like preventing plugins calling System.exit but these are cases that would be better served with other solutions. I would like to explore changes to the API and implementation that would allow us to eliminate some of the overhead when not running with a security manager. Long term then it would be interesting to explore degrading and eventually dropping the security manager but that is beyond the scope of what I would like to discuss here. Sean Mullan and Jeff Nisewanger ran an interesting BOF at JavaOne 2017 on this topic and I believe are planning to do a survey at some point to understand the current usage of the security manager. For now I would like to explore what it would take to eliminate some of the overhead. A big challenge is the System.setSecurityManager API as allows a security manager to be set in a running VM. This means that classes loaded before a security manager is set may be involved in permission checks that happen after a security manager is set. Similarly, privileged actions may have started before the security manager is set. The complications around this go away if there was some way to know that a security manager can never be turned on in a running system. To get started, I've put a prototype of an initial proposal on the cr site [1]. The summary of the proposal is: 1. A "disallow security manager" mode that is opt-in to disallow setSecurityManager being used to set a security manager in a running VM. Opt-in means it has not impact on existing code. 2. Deprecates setSecurityManager to discourage further usage and allow for the possibility of making "disallow security manager" the default in the future. If that were to become the default then it would have no impact on deployments that set the security manager on the command line at startup. 3. When running in "disallow security manager" mode, AccessController.doPrivileged invokes actions directly and SecureClassLoader.defineClass skips the callback to get permissions for the protection domain. This part helps startup and runtime performance. It's important not to get hung up on the details in the webrev, the important thing is understand if the security folks on this mailing list are open to a run mode that prevents a security manager being set in a running system. -Alan. [1] http://cr.openjdk.java.net/~alanb/8191053/webrev/ From adam.petcher at oracle.com Mon Nov 20 15:32:38 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 20 Nov 2017 10:32:38 -0500 Subject: KDF API review, round 2 In-Reply-To: <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> Message-ID: <9672ed61-2568-48ab-44ac-477f7b39f6d4@oracle.com> On 11/20/2017 5:12 AM, Jamil Nimeh wrote: > > On 11/19/2017 12:45 PM, Michael StJohns wrote: >> On 11/17/2017 1:07 PM, Adam Petcher wrote: >>> >>> I agree that this is challenging because there is so much variety in >>> KDFs. But I don't think that SP 800-108 is a good example of >>> something that should be exposed as an algorithm in JCA, because it >>> is too broad. SP 800-108 is more of a toolbox that can be used to >>> construct KDFs. Particular specializations of SP 800-108 are widely >>> used, and they will get names that can be used in getInstance. For >>> example, HKDF-Expand is a particular specialization of SP 800-108. >>> So I think the existing pattern of using algorithm names to specify >>> concrete algorithms should work just as well in this API as it does >>> in the rest of JCA. Of course, more flexibility in the API is a nice >>> feature, but supporting this level of generality may be out of scope >>> for this effort. >> >> The more I think about it the more I think you're mostly right. But >> let's split this slightly as almost every KDF allows for the >> specification of the PRF.? So >> >> /??? as the standard naming convention. >> >> Or TLS13/HMAC-SHA256 and HKDF/HMAC-SHA256 (which are different >> because of the mandatory inclusion of "L" in the derivation >> parameters and each component object for TLS13) This approach seems fine to me. We would probably want to allow any algorithm name after the / (rather than limiting it to PRFs), because JCA doesn't have a notion of PRF, and because some KDFs take other kinds of functions (e.g. PBKDF1 uses a bare hash function). >> >> Still - let's include the .setParameters() call as a failsafe as >> looking forward I can see the need for flexibility rearing its ugly >> head (e.g. adding PSS parameters to RSA signatures way late in the >> game.....) and it does match the pattern for Signature so its not a >> new concept. A given provider need not support the call, but its >> there if needed. > Signature appears to have setParameter because the initSign and > initVerify didn't have APS parameters in their method signatures. > Since we're talking about providing APS objects through both > getInstance() for those locked to the algorithm and init() for things > like salts, info, etc. that can be changed on successive inits it > seems like we're covered without the need for a setParameter method. My argument is that providing APS in getInstance doesn't appear to be necessary. Of course, if you want to tackle this, that's fine with me.? But I think it complicates the API and I expect it will lead to other API/design problems that will need to be sorted out. I agree that setParameter() in Signature appears to be there to solve a different problem. This API doesn't have that problem because the init method takes an APS. > > One additional topic for discussion: Late in the week we talked about > the current state of the API internally and one item to revisit is > where the DerivationParameterSpec objects are passed. It was brought > up by a couple people that it would be better to provide the DPS > objects pertaining to keys at the time they are called for through > deriveKey() and deriveKeys() (and possibly deriveData). > > Originally we had them all grouped in a List in the init method. One > reason for needing it up there was to know the total length of > material to generate.? If we can provide the total length through the > AlgorithmParameterSpec passed in via init() then things like: > > Key deriveKey(DerivationParameterSpec param); > List deriveKeys(List params); > > become possible.? To my eyes at least it does make it more clear what > DPS you're processing since they're provided at derive time, rather > than the caller having to keep track in their heads where in the DPS > list they might be with each successive deriveKey or deriveKeys > calls.? And I think we could do away with deriveKeys(int), too. I like this change. It simplifies the API, and forcing the JCA client to be explicit and supply the output length in the APS is a good thing. From adam.petcher at oracle.com Mon Nov 20 16:09:50 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 20 Nov 2017 11:09:50 -0500 Subject: Draft design for Key Derivation API In-Reply-To: <530fb6bd-c12c-dc60-4537-0605726ddc0b@comcast.net> References: <71d0e6e2-b133-9dd9-4f85-6ce70c994016@oracle.com> <98017da2-ae47-31ce-8fd6-5e21295d41a7@oracle.com> <6058eab6-dde1-24e3-30d2-a084380f1a17@oracle.com> <73a5acfb-04be-e969-76da-11b668773ff2@comcast.net> <268fd139-6405-db93-49a4-59e19c91b44d@oracle.com> <530fb6bd-c12c-dc60-4537-0605726ddc0b@comcast.net> Message-ID: <6ce42706-8f83-5cc2-eff7-6774abd57f6e@oracle.com> On 11/19/2017 3:15 PM, Michael StJohns wrote: > >> That behavior all sounds reasonable, I just have doubts that this >> belongs in the spec. Are you expecting KeyDerivation to contain the >> logic in your last paragraph? Something like this: >> >> >> >> > KDFs are somewhat problematic in that *_they may not necessarily be > producing objects from their own provider_*. This unfortunately isn't > obvious, but let me try and explain. > > Your response didn't contain a direct answer to my question above. If I am interpreting your response correctly, then your answer is "Yes, and we may need some additional information in DerivationParameterSpec (or elsewhere) that controls this logic." Though I'm not sure I am interpreting this correctly, so please let me know. To be clear: I don't object to including the method that returns an Object produced by a KDF. I'm specifically asking about the requirement that this class of objects has a (byte[] int) constructor, and how that constructor is expected to be used. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.mckenna at oracle.com Mon Nov 20 16:16:55 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 20 Nov 2017 16:16:55 +0000 Subject: RFR - 8189646: sun/security/ssl/SSLSocketImpl/SSLSocketCloseHang.java failed with "java.net.SocketTimeoutException: Read timed out" Message-ID: <20171120161655.GA31859@vimes> Hi folks, This test appears to be timing out. The main culprit looks to be the fact that the 100ms sleep isn't enough for the server to respond (on a busy test machine) so that timeout has been bumped and some new logging has been added to make it obvious whats happening should the problem occur again. webrev: http://cr.openjdk.java.net/~robm/8189646/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8189646 Thanks, -Rob From mstjohns at comcast.net Mon Nov 20 16:17:43 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 20 Nov 2017 11:17:43 -0500 Subject: KDF API review, round 2 In-Reply-To: <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> Message-ID: <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> Apologies in advance for top posting and a need to be a little pedantic about KDFs.? I'll have some comments inline below as well. KDF's aren't well understood but people think they are.? The key stream generation part is pretty straightforward (keyed PRBG), but the interaction of how the key stream is generated and how the key stream is assigned to actual cryptographic objects is not.? Here's why: 1) KDF's are repeatable.? Given the exact same inputs (key, mixin data) they produce the same key stream. 2) Any change in the inputs changes ALL of the key stream. 3) Unless the overall length property is included, then changing the length of the key stream will not change the prefix (e.g. if the original call was for 10 bytes and a second call was for 20, the first 10 bytes of both calls will produce the exact same key stream data) 4) The general format of each round of key stream generation is something like PRF (master key, mixins), where mixins are the concatenation of at least a label and context and a value to differentiate each round (a counter or the previous rounds output for example).? Including L in the mixin prevents the property described in (3) above.? Including a length for each subcomponent as a mixin prevents the property described in (5) below. 5) Unless the length for each derived object is included in the mix in, then it is possible to move the assignment of key stream bytes between objects.? For example, both TLS (1.2 and before) and IPSEC use KDFs that generate non-secret IV material along with secret session key material.???? This is less important for software only KDFs as both the secret key material and the IV material are both in the JVM memory domain.? This is very important if you're trying to keep your secret key material secure in an HSM. Example:? a given TLS session may need 2 256 bit AES keys and 2 128 bit IVs.? That is a requirement for 96 bytes of key stream (if I've got my calculation correct).? We have the HSM produce this (see the PKCS11 calling sequence for example) and we get out the IVs.? An attacker who has access to the HSM (which may or may not be on the same machine as the TLS instantiation) can call the derivation function with new output parameters (but with the same master key and mixins)? which specifies only IV material and have the function output the same key stream bytes that were previously assigned to the secret key material in the IV output.? A very easy key extraction attack. This is why TLS1.3 only does single outputs per KDF call and makes the length of that output a mandatory mixin.? An HSM can also look at the labels and make a determination as to whether an object need be protected (key material) or in the clear (iv). Given (3) and (5) I believe that both L and l[i] (subcomponent length) may need to be provided for BEFORE any key material is produced which argues for input during initialization phase. On 11/20/2017 5:12 AM, Jamil Nimeh wrote: > > > On 11/19/2017 12:45 PM, Michael StJohns wrote: >> On 11/17/2017 1:07 PM, Adam Petcher wrote: >>> On 11/17/2017 10:04 AM, Michael StJohns wrote: >>> >>>> On 11/16/2017 2:15 PM, Adam Petcher wrote: >>>>> So it seems like they could all be supplied to init. >>>>> Alternatively, algorithm names could specify more concrete >>>>> algorithms that include the mode/PRF/etc. Can you provide more >>>>> information to explain why these existing patterns won't work in >>>>> this case? >>>> What I need to do is provide a lifecycle diagram, but its hard to >>>> do in text.? But basically, the .getInstance() followed by >>>> .setParameters() builds a concrete engine while the .init() >>>> initializes that engine with a key and the derivation parameters. >>>> Think about a TLS 1.2 instance - the PRF is selected once, but the >>>> KDF may be used multiple times. >>> >>> This is the information I was missing. There are two sets of >>> parameters, and the first set should be fixed, but the second set >>> should be changed on each init. >>> >>>> >>>> I considered the mode/PRF/etc stuff but that works for things like >>>> Cipher and Signature because most of those have exactly the same >>>> pattern.? For the KDF pattern we;ve got fully specified KDFs (e.g. >>>> TLS 1.1 and before, IPSEC), almost fully specified KDFs (TLS 1.2 >>>> and HDKF needs a PRF) and then the SP800 style KDFs which are >>>> defined to be *very* flexible.? So translating that into a naming >>>> convention is going to be restrictive and may not cover all of the >>>> possible approaches. I'd rather do it as an algorithmparameter >>>> instead.? With a given KDF implementation having a default if >>>> nothing is specified during instantiation. >>> >>> I agree that this is challenging because there is so much variety in >>> KDFs. But I don't think that SP 800-108 is a good example of >>> something that should be exposed as an algorithm in JCA, because it >>> is too broad. SP 800-108 is more of a toolbox that can be used to >>> construct KDFs. Particular specializations of SP 800-108 are widely >>> used, and they will get names that can be used in getInstance. For >>> example, HKDF-Expand is a particular specialization of SP 800-108. >> >>> >>> So I think the existing pattern of using algorithm names to specify >>> concrete algorithms should work just as well in this API as it does >>> in the rest of JCA. Of course, more flexibility in the API is a nice >>> feature, but supporting this level of generality may be out of scope >>> for this effort. >> >> >> The more I think about it the more I think you're mostly right. But >> let's split this slightly as almost every KDF allows for the >> specification of the PRF.? So >> >> /??? as the standard naming convention. >> >> Or TLS13/HMAC-SHA256 and HKDF/HMAC-SHA256 (which are different >> because of the mandatory inclusion of "L" in the derivation >> parameters and each component object for TLS13) >> >> Still - let's include the .setParameters() call as a failsafe as >> looking forward I can see the need for flexibility rearing its ugly >> head (e.g. adding PSS parameters to RSA signatures way late in the >> game.....) and it does match the pattern for Signature so its not a >> new concept. A given provider need not support the call, but its >> there if needed. > Signature appears to have setParameter because the initSign and > initVerify didn't have APS parameters in their method signatures. > Since we're talking about providing APS objects through both > getInstance() for those locked to the algorithm and init() for things > like salts, info, etc. that can be changed on successive inits it > seems like we're covered without the need for a setParameter method. You're missing the point that setParameter() provides information used in all future calls to the signature generation, while init() provides data specifically for a given key stream production.? In Signature() you call .setParameter() to set up the PSS parameters (or use the defaults).? Each subsequent call to initSign or initVerify uses those PSS parameters.? The? equivalent part of .init() in KeyDerivation is actually the calls to .update() in signature as they provide the specific information for the production of the output key stream.? In fact, setting up an HMAC signature instance and passing it the mixin data as part of a .update() is a way of producing the key stream round. So equivalences: KeyDerivation.getInstance(PRF) == Signature.getInstance(HMAC) KeyDerivation.setParameters() == Signature.setParameters() KeyDerivation.init(key, List) == concatenation of the results of multiple calls (each key stream round based on the needed output length) to [Signature.initSign(Key) followed by Signature.update(converttobytearray(List)) followed by? Signature.sign()] to produce the key stream KeyDerivation.deriveKey() ==? various calls to key or object factories with parts of the key stream (signature). (Hmm.. I think I forgot to get back to this comment - a KDF key should be tagged differently than an HMAC key even though the underlying functions are the same.? It shouldn't be possible to use an HMAC SecretKey (or an AES secret key) as a KDF master key and vice versa, basically because of the property that an HMAC output is by definition non-secret data while the key stream production is by definition - secret.? You want to make sure that its not trivial to do this). > > One additional topic for discussion: Late in the week we talked about > the current state of the API internally and one item to revisit is > where the DerivationParameterSpec objects are passed. It was brought > up by a couple people that it would be better to provide the DPS > objects pertaining to keys at the time they are called for through > deriveKey() and deriveKeys() (and possibly deriveData). > > Originally we had them all grouped in a List in the init method. One > reason for needing it up there was to know the total length of > material to generate.? If we can provide the total length through the > AlgorithmParameterSpec passed in via init() then things like: > > Key deriveKey(DerivationParameterSpec param); > List deriveKeys(List params); > > become possible.? To my eyes at least it does make it more clear what > DPS you're processing since they're provided at derive time, rather > than the caller having to keep track in their heads where in the DPS > list they might be with each successive deriveKey or deriveKeys > calls.? And I think we could do away with deriveKeys(int), too. See above - the key stream is logically produced in its entirety before any assignment of that stream is made to any cryptographic objects because the mixins (except for the round differentiator) are the same for each key stream production round.?? Simply passing in the total length may not give you the right result if the KDF requires a per component length (and it should to defeat (5) or it should only produce a single key). 95% of the time this will be a call to produce a single key.? 4% of the time it will be a call to produce multiple keys. Only 1% of the time will it need to intermix key, data and object productions. Anybody who is doing that is going to write a wrapper around this class to make sure they get the key and data production order correct for each call.? So I'm not all that bothered by keeping the complexity as a price for keeping flexibility. You could have a Key deriveKey(Key k, DerivationParameterSpec param) for some things like TLS1.3 (where you can only make a single call to derive key between inits) , but then you'd also need at least a byte[] deriveData (Key k, DerivationParameterSpec param) and an Object deriveObject(Key k, DerivationParameterSpec param). I think the most common pattern will be .init(Key k, DerivationParameterSpec param) followed by .deriveKey()? or .init(Key k, List params) followed by .deriveKeys() but the other intermixed patterns are just as valid. > > --Jamil > From sean.coffey at oracle.com Mon Nov 20 17:15:11 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 20 Nov 2017 17:15:11 +0000 Subject: RFR - 8189646: sun/security/ssl/SSLSocketImpl/SSLSocketCloseHang.java failed with "java.net.SocketTimeoutException: Read timed out" In-Reply-To: <20171120161655.GA31859@vimes> References: <20171120161655.GA31859@vimes> Message-ID: <36687bae-4b17-a115-bf33-7858b01e56ba@oracle.com> This should help harden the test. Looks fine to me. Regards, Sean. On 20/11/17 16:16, Rob McKenna wrote: > Hi folks, > > This test appears to be timing out. The main culprit looks to be the > fact that the 100ms sleep isn't enough for the server to respond (on a > busy test machine) so that timeout has been bumped and some new logging > has been added to make it obvious whats happening should the problem > occur again. > > webrev: http://cr.openjdk.java.net/~robm/8189646/webrev.01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8189646 > > Thanks, > > -Rob > From adam.petcher at oracle.com Mon Nov 20 17:37:45 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 20 Nov 2017 12:37:45 -0500 Subject: KDF API review, round 2 In-Reply-To: <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> Message-ID: On 11/20/2017 11:17 AM, Michael StJohns wrote: > >> >> One additional topic for discussion: Late in the week we talked about >> the current state of the API internally and one item to revisit is >> where the DerivationParameterSpec objects are passed. It was brought >> up by a couple people that it would be better to provide the DPS >> objects pertaining to keys at the time they are called for through >> deriveKey() and deriveKeys() (and possibly deriveData). >> >> Originally we had them all grouped in a List in the init method. One >> reason for needing it up there was to know the total length of >> material to generate.? If we can provide the total length through the >> AlgorithmParameterSpec passed in via init() then things like: >> >> Key deriveKey(DerivationParameterSpec param); >> List deriveKeys(List params); >> >> become possible.? To my eyes at least it does make it more clear what >> DPS you're processing since they're provided at derive time, rather >> than the caller having to keep track in their heads where in the DPS >> list they might be with each successive deriveKey or deriveKeys >> calls.? And I think we could do away with deriveKeys(int), too. > > See above - the key stream is logically produced in its entirety > before any assignment of that stream is made to any cryptographic > objects because the mixins (except for the round differentiator) are > the same for each key stream production round.?? Simply passing in the > total length may not give you the right result if the KDF requires a > per component length (and it should to defeat (5) or it should only > produce a single key). In general, if the KDF needs any information up front to produce the output bits, then that information can be supplied in init using the APS. In your example attack for (5), an implementation that prevents this attack would probably take a length and label (e.g. "key1", "key2", "iv1", "iv2") for each derived value. Then the HSM would need to enforce that any value derived with a "key*" label could not be extracted. If that entire sequence of lengths and labels needs to be known up front, then it can be supplied in the APS. In this organization, the only additional information that the DPS passed to deriveKey() needs to provide is the encryption algorithm name and parameters (though taking a length and checking it is probably a good idea). From jamil.j.nimeh at oracle.com Mon Nov 20 18:10:43 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 20 Nov 2017 10:10:43 -0800 Subject: KDF API review, round 2 In-Reply-To: <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> Message-ID: <561b3015-4ed0-4220-e0a0-3d8e81fba2e5@oracle.com> > You're missing the point that setParameter() provides information used > in all future calls to the signature generation, while init() provides > data specifically for a given key stream production.? In Signature() > you call .setParameter() to set up the PSS parameters (or use the > defaults).? Each subsequent call to initSign or initVerify uses those > PSS parameters.? The? equivalent part of .init() in KeyDerivation is > actually the calls to .update() in signature as they provide the > specific information for the production of the output key stream.? In > fact, setting up an HMAC signature instance and passing it the mixin > data as part of a .update() is a way of producing the key stream round. > > So equivalences: > > KeyDerivation.getInstance(PRF) == Signature.getInstance(HMAC) > KeyDerivation.setParameters() == Signature.setParameters() > KeyDerivation.init(key, List) == concatenation of the > results of multiple calls (each key stream round based on the needed > output length) to [Signature.initSign(Key) followed by > Signature.update(converttobytearray(List)) followed by? > Signature.sign()] to produce the key stream > KeyDerivation.deriveKey() ==? various calls to key or object factories > with parts of the key stream (signature). > Are you expecting that setParameters is called once per instantiation?? If so, then the parameters that would go into setParameter (an APS I assume) could just as easily go into the getInstance call.? It also removes the chance that someone would call it twice. If you're expecting someone to call setParameter more than once, then I would expect an init must follow.? So why not place it in a form of init that allows you to change that particular set of params?? Either way it seems like we could coalesce this method into one of the calls that sandwich it in your proposed model. From brian.goetz at oracle.com Mon Nov 20 18:21:15 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 20 Nov 2017 13:21:15 -0500 Subject: Fwd: [JCP]JSR-383(Java SE 18.3) Public review - JEP 116:Extended Validation SSL Certificates In-Reply-To: <1504356EFC539645A05071690EB7D549F2760D@cmbmb410a.exg.bpr.btm.co.jp> References: <1504356EFC539645A05071690EB7D549F2760D@cmbmb410a.exg.bpr.btm.co.jp> Message-ID: <55abc7e6-5f48-eb80-bd39-602c83c35e5d@oracle.com> This was received via the Java SE 10 umbrella JSR comments list; since it relates to JEP 116, I am forwarding it here. -------- Forwarded Message -------- Subject: [JCP]JSR-383(Java SE 18.3) Public review - JEP 116:Extended Validation SSL Certificates Date: Fri, 17 Nov 2017 10:33:41 +0000 From: kyosuke_yamagata at mufg.jp To: java-se-spec-comments at openjdk.java.net CC: youji_3_fujikura at mufg.jp, takahiro_ishifuku at mufg.jp, kazuhiro_2_itakura at mufg.jp, tomoyuki_3_iguchi at mufg.jp, kenya_2_saito at mufg.jp, hiromi_18_takahashi at mufg.jp JSR-383 developer all Hi, I?m Kyosuke Yamagata. I can't send E-mail by mail form(Expert Group Comments) because of the office network policy. So I send this mail to you. I work for Mitsubishi UFJ Information Technology. Our company is in charge of Mitsubishi UFJ financial group system development, operation and maintenance. And then , We are in charge of in-house Java framework. Our Java framework depends heavily on Java SE and Java EE technologies. I reviewed JEP 116: Extended Validation SSL Certificates in JSR-383(Java SE 18.3) Public review I think it's great. On the other hand, to make things even better, I would like to suggest the following: We can import Self-signed certificates as Root certificate. It used in SSL/TLS connections both Client-side and Server-side, and isn't necessarily EV SSL certificates. When the API takes these Non-EV SSL certificates, what kind of information does return? API user wants to take some information of the certificate without having to worry about what kind of certificate using, I think. For example, if I got some exceptions by using API, I MUST inject the judging code that this certificate is EV or Non-EV into my code. I want to support this usecase by this JEP(or other APIs). This content is the personal opinion by the contributor, not the official opinion of our company. Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Mon Nov 20 20:15:15 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 20 Nov 2017 21:15:15 +0100 Subject: Eliminating the security overhead when not running with a securitymanager In-Reply-To: <22225416-222d-afe9-3da4-f2465e7786f6@oracle.com> References: <22225416-222d-afe9-3da4-f2465e7786f6@oracle.com> Message-ID: <5a1337d3.c2afdf0a.b0f91.a895@mx.google.com> Hello Alan, not sure if it is good or bad to make the security manager even less Mainstream (especially after there was a Project to reduce the Impact of security Manager). However, not diving into this discussion here :) One thing which might be a problem: when doPrivileged does no longer execute the Code in a seperate stack this has implications to the runtime. The stacks will get deeper (and might even overflow (more often)). So maybe this ?no seperate stack? function should be opt-out (if implemented). Gruss Bernd -- http://bernd.eckenfels.net Von: Alan Bateman Gesendet: Montag, 20. November 2017 15:47 An: OpenJDK Dev list Betreff: Eliminating the security overhead when not running with a securitymanager One of the long standing issues with the security manager support is that the overhead when there is no security manager is non-zero. Two specific examples are (i) the overhead of defineClass (assuming the defining loader is a SecureClassLoader) as it involves a callback to get the permissions for the protection domain and (ii) the overhead of AccessController.doPrivileged in order to execute an action on a privileged stack. The bigger question is of course whether it is interesting to run with a security manager in 2017. It's clearly still important for environments that download potentially malicious code to execute in a sandox but that isn't most applications these days. We have seen a few cases where applications set a security manager in order to enforce some policy, like preventing plugins calling System.exit but these are cases that would be better served with other solutions. I would like to explore changes to the API and implementation that would allow us to eliminate some of the overhead when not running with a security manager. Long term then it would be interesting to explore degrading and eventually dropping the security manager but that is beyond the scope of what I would like to discuss here. Sean Mullan and Jeff Nisewanger ran an interesting BOF at JavaOne 2017 on this topic and I believe are planning to do a survey at some point to understand the current usage of the security manager. For now I would like to explore what it would take to eliminate some of the overhead. A big challenge is the System.setSecurityManager API as allows a security manager to be set in a running VM. This means that classes loaded before a security manager is set may be involved in permission checks that happen after a security manager is set. Similarly, privileged actions may have started before the security manager is set. The complications around this go away if there was some way to know that a security manager can never be turned on in a running system. To get started, I've put a prototype of an initial proposal on the cr site [1]. The summary of the proposal is: 1. A "disallow security manager" mode that is opt-in to disallow setSecurityManager being used to set a security manager in a running VM. Opt-in means it has not impact on existing code. 2. Deprecates setSecurityManager to discourage further usage and allow for the possibility of making "disallow security manager" the default in the future. If that were to become the default then it would have no impact on deployments that set the security manager on the command line at startup. 3. When running in "disallow security manager" mode, AccessController.doPrivileged invokes actions directly and SecureClassLoader.defineClass skips the callback to get permissions for the protection domain. This part helps startup and runtime performance. It's important not to get hung up on the details in the webrev, the important thing is understand if the security folks on this mailing list are open to a run mode that prevents a security manager being set in a running system. -Alan. [1] http://cr.openjdk.java.net/~alanb/8191053/webrev/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Mon Nov 20 20:34:41 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 20 Nov 2017 15:34:41 -0500 Subject: KDF API review, round 2 In-Reply-To: <561b3015-4ed0-4220-e0a0-3d8e81fba2e5@oracle.com> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <561b3015-4ed0-4220-e0a0-3d8e81fba2e5@oracle.com> Message-ID: On 11/20/2017 1:10 PM, Jamil Nimeh wrote: > >> You're missing the point that setParameter() provides information >> used in all future calls to the signature generation, while init() >> provides data specifically for a given key stream production.? In >> Signature() you call .setParameter() to set up the PSS parameters (or >> use the defaults).? Each subsequent call to initSign or initVerify >> uses those PSS parameters.? The? equivalent part of .init() in >> KeyDerivation is actually the calls to .update() in signature as they >> provide the specific information for the production of the output key >> stream.? In fact, setting up an HMAC signature instance and passing >> it the mixin data as part of a .update() is a way of producing the >> key stream round. >> >> So equivalences: >> >> KeyDerivation.getInstance(PRF) == Signature.getInstance(HMAC) >> KeyDerivation.setParameters() == Signature.setParameters() >> KeyDerivation.init(key, List) == concatenation of the >> results of multiple calls (each key stream round based on the needed >> output length) to [Signature.initSign(Key) followed by >> Signature.update(converttobytearray(List)) followed by? >> Signature.sign()] to produce the key stream >> KeyDerivation.deriveKey() ==? various calls to key or object >> factories with parts of the key stream (signature). >> > Are you expecting that setParameters is called once per > instantiation?? If so, then the parameters that would go into > setParameter (an APS I assume) could just as easily go into the > getInstance call.? It also removes the chance that someone would call > it twice. That was my original proposal.? .setParameter() was an alternative that matched the Signature pattern. > > If you're expecting someone to call setParameter more than once, then > I would expect an init must follow.? So why not place it in a form of > init that allows you to change that particular set of params?? Either > way it seems like we could coalesce this method into one of the calls > that sandwich it in your proposed model. > > I don't expect them to call it more than once.? The original (now deprecated) .setParameter (String, Object) method in Signature indicated it could be called only once and would throw an error if called again - I'm not sure why that wasn't brought forward to the Signature.setParameter(AlgorithmParameterSpec) method. In any event, I'd rather do the parameter setting in the getInstance call than as a separate .setParameters call if it can be done without exploding the interface. Hmm.. how does that map to the Spi?? Does the KeyDerivation.getInstance() code instantiate the object, call a setParameter() method on the SPI and then return the new object? Or what?? It may make more sense to just add the parameter related methods to both the KeyDerivationSpi and the KeyDerivation classes and leave the getInstance() method alone.... I'm sort of a don't care as long as I have a way of tweaking the KDF before run the first derivation. Mike From Alan.Bateman at oracle.com Mon Nov 20 21:02:54 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Nov 2017 21:02:54 +0000 Subject: Eliminating the security overhead when not running with a securitymanager In-Reply-To: <5a1337d3.c2afdf0a.b0f91.a895@mx.google.com> References: <22225416-222d-afe9-3da4-f2465e7786f6@oracle.com> <5a1337d3.c2afdf0a.b0f91.a895@mx.google.com> Message-ID: On 20/11/2017 20:15, Bernd Eckenfels wrote: > : > > One thing which might be a problem: when doPrivileged does no longer > execute the Code in a seperate stack this has implications to the > runtime. The stacks will get deeper (and might even overflow (more > often)). So maybe this ?no seperate stack? function should be opt-out > (if implemented). > > Are you assuming that the execution of the privileged action is done on a different thread stack? The effect of doPrivileged is to set the top of the privileged stack on the current thread stack, it gets restored when the action completes. So I think there isn't anything to be concerned about here. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Mon Nov 20 22:03:11 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 20 Nov 2017 23:03:11 +0100 Subject: Eliminating the security overhead when not running with asecuritymanager In-Reply-To: References: <22225416-222d-afe9-3da4-f2465e7786f6@oracle.com> <5a1337d3.c2afdf0a.b0f91.a895@mx.google.com> Message-ID: <5a13511f.e28edf0a.a85e7.e84c@mx.google.com> Yes Alan correct: I wrongly asumed ist a separate stack. So it is a non-issue. I tried it out and having a doPriv(lambda) block shortens the possible overall thread dept by about 200 calls (with my simple stack usage). BTW: the main thread does behave a bit less predictable: (run results at end of file) https://github.com/ecki/JavaSystemTest/blob/master/src/main/java/net/eckenfels/test/javasystemtest/StackDepth.java#L86 Greetings Bernd -- http://bernd.eckenfels.net Von: Alan Bateman Gesendet: Montag, 20. November 2017 22:02 An: Bernd Eckenfels; OpenJDK Dev list Betreff: Re: Eliminating the security overhead when not running with asecuritymanager On 20/11/2017 20:15, Bernd Eckenfels wrote: : ? One thing which might be a problem: when doPrivileged does no longer execute the Code in a seperate stack this has implications to the runtime. The stacks will get deeper (and might even overflow (more often)). So maybe this ?no seperate stack? function should be opt-out (if implemented). Are you assuming that the execution of the privileged action is done on a different thread stack? The effect of doPrivileged is to set the top of the privileged stack on the current thread stack, it gets restored when the action completes. So I think there isn't anything to be concerned about here. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Mon Nov 20 22:33:34 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 20 Nov 2017 14:33:34 -0800 Subject: KDF API review, round 2 In-Reply-To: References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <561b3015-4ed0-4220-e0a0-3d8e81fba2e5@oracle.com> Message-ID: On 11/20/2017 12:34 PM, Michael StJohns wrote: > On 11/20/2017 1:10 PM, Jamil Nimeh wrote: >> >>> You're missing the point that setParameter() provides information >>> used in all future calls to the signature generation, while init() >>> provides data specifically for a given key stream production.? In >>> Signature() you call .setParameter() to set up the PSS parameters >>> (or use the defaults).? Each subsequent call to initSign or >>> initVerify uses those PSS parameters.? The equivalent part of >>> .init() in KeyDerivation is actually the calls to .update() in >>> signature as they provide the specific information for the >>> production of the output key stream.? In fact, setting up an HMAC >>> signature instance and passing it the mixin data as part of a >>> .update() is a way of producing the key stream round. >>> >>> So equivalences: >>> >>> KeyDerivation.getInstance(PRF) == Signature.getInstance(HMAC) >>> KeyDerivation.setParameters() == Signature.setParameters() >>> KeyDerivation.init(key, List) == concatenation of the >>> results of multiple calls (each key stream round based on the needed >>> output length) to [Signature.initSign(Key) followed by >>> Signature.update(converttobytearray(List)) followed by? >>> Signature.sign()] to produce the key stream >>> KeyDerivation.deriveKey() ==? various calls to key or object >>> factories with parts of the key stream (signature). >>> >> Are you expecting that setParameters is called once per >> instantiation?? If so, then the parameters that would go into >> setParameter (an APS I assume) could just as easily go into the >> getInstance call.? It also removes the chance that someone would call >> it twice. > > That was my original proposal.? .setParameter() was an alternative > that matched the Signature pattern. Yes, I recall that.? Since it's a once-per instance call let me come up with a rev with it in the getInstance.? There's precedent for getInstance with APS, too.? It's just not any of the keyed forms, and the rationale for that was to combine instantiation and initialization (CertStore is an example).? It's not a great comparison to KDF for a myriad of reasons most of which you've talked about...but it at least shows that we have added params to getInstance calls in the past.? This seems like one place where we're not going to come up with an answer that pleases everyone. >> >> If you're expecting someone to call setParameter more than once, then >> I would expect an init must follow.? So why not place it in a form of >> init that allows you to change that particular set of params?? Either >> way it seems like we could coalesce this method into one of the calls >> that sandwich it in your proposed model. >> >> > > I don't expect them to call it more than once.? The original (now > deprecated) .setParameter (String, Object) method in Signature > indicated it could be called only once and would throw an error if > called again - I'm not sure why that wasn't brought forward to the > Signature.setParameter(AlgorithmParameterSpec) method. > > In any event, I'd rather do the parameter setting in the getInstance > call than as a separate .setParameters call if it can be done without > exploding the interface. > > Hmm.. how does that map to the Spi?? Does the > KeyDerivation.getInstance() code instantiate the object, call a > setParameter() method on the SPI and then return the new object? Or > what?? It may make more sense to just add the parameter related > methods to both the KeyDerivationSpi and the KeyDerivation classes and > leave the getInstance() method alone.... > > I'm sort of a don't care as long as I have a way of tweaking the KDF > before run the first derivation. > That's a good question, and one that I've been turning around in my head and don't (yet) have a great answer for, but we'll get there. So my original prototype was based off KeyAgreement.java and the order obtaining the spi depends on the form of getInstance.? If it's a simple string-based algorithm form, then the provider is actually selected during the init method.? In the other two forms where a provider is specified as either a String or a Provider, the spi is obtained through the Provider object and therefore no init-time selection is needed. We may need to have provider selection done a bit earlier since we're not only having to deal with the KDF itself, but a flavor of the KDF with the underlying PRF.? I need to find out a little bit of the history on why the provider selection happens during init for some of these APIs.? IIRC there was a reason to have delayed provider selection, but I don't have the history on that one. From david.lloyd at redhat.com Tue Nov 21 00:48:18 2017 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 20 Nov 2017 18:48:18 -0600 Subject: Eliminating the security overhead when not running with a security manager In-Reply-To: <22225416-222d-afe9-3da4-f2465e7786f6@oracle.com> References: <22225416-222d-afe9-3da4-f2465e7786f6@oracle.com> Message-ID: One thing that springs to mind. Some allowance would have to be made for domain combiners and JAAS Subject propagation: this mechanism also uses access control contexts, to its own great detriment. I would say that the JAAS domain combiner strategy should be dropped in favor of a simple thread local holding the Subject, regardless of what else is decided. I do personally believe that using a security manager as some kind of proof against untrusted Java code is a mistake. However I think one important use case of security managers is where the Java code being run actually _is_ trusted, but you want to avoid "weird machine" effects where server code could be exploited (by way of malformed requests or whatever) to perform actions that are unexpected but also technically allowed (for example, if your file management abstraction is only ever intended to modify "/app/user-storage/-" then you don't want it to be able to access "/app-server/secret-passwords", and if that happens, you maybe want to start yelling a lot). In this case it's an extra layer of protection. I don't see this use case going away or being invalidated in any way; an application server request _is_ code, in a way, that must be interpreted and "executed" after a fashion in order to do something useful for the user. In terms of approach: back when the discussion around StackWalker design was still going on, it seemed to me that the performance costs of the security manager could be mostly shifted to the security manager itself (thus solving the problem in a different way), if it would walk the stack to do access checking directly, like this: ? An "acc" field on Thread is used to hold the inherited access control context ? AccessController.doPrivileged(task) becomes empty other than to clear the acc field and delegate to the called block (and restore the acc field after) ? AccessController.doPrivileged(task, acc) becomes empty other than to set the acc field to the given ACC argument and delegate to the called block (and restore the acc field after) ? AccessController.checkPermission() iterates the call stack until it hits one-frame-lower-than-doPrivileged or the bottom of the stack, checking access along the way for each protection domain (with some simple duplicate elimination as it walks), and once it hits the end, it calls checkPermission on the inherited acc field in Thread (if any). ? Creating a new thread still captures the caller acc but then copies it into the new thread's inherited acc field ? Construction/compilation of the ACC could possibly be moved to userspace, which will reduce any memory overhead of having it baked in to the native JVM code when it's not actually used ? The doPrivileged(action, acc, perms) case could be handled with another Thread field which could be checked before or after the primary check (in this case all the doPrivileged methods would have to stash and set this field as well, and restore it after) ? A "shared secret" is added to let AccessController access the two Thread cache field(s) This way the cost of doPrivileged is greatly minimized (two Thread field reads and writes before the block, and two Thread field writes after the block, assuming the aforementioned second field for array permissions) without affecting security manager functionality should it happen to be enabled in software. Also it's easy to improve the security manager debug output, such that you could get a report on _all_ classes or modules or codeSources or whatever which would do not grant a given permission (instead of just the first one), which is greatly useful in reducing iterations in the design and debug stages. When the security manager is actually enabled, only testing would reveal the comparative performance of a stack walker based approach versus the current native ACC optimization code (maybe C2 can work some magic here). There's probably some kind of disgusting weirdness around method handles and reflection things on the call stack that would have to be examined as well. Finally, it will (as always) be a challenge to craft a Stream-consuming Function that doesn't allocate scads of objects when actually iterating the thread stack. Maybe we could allow an Iterator-based StackWalker method. Maybe I'll keep dreaming. Anyway I never got a chance to prototype this, but it might be a fun option worth exploring. I found the idea of moving this stuff all to user space to be very appealing (due in no small part to the idea that it could potentially be examined and analyzed by a much larger audience, being Java code). It also hints at the possibility of a fully "user space" replacement of the security manager concept (much of the remaining cost lives in the structure of AccessControlContext, which is based on an array of ProtectionDomain objects; this is definitely non-ideal and could possibly be hidden behind a smarter abstraction). I really firmly believe that domain combiners should be ultimately eliminated regardless of whatever else happens as they add a lot of complexity in an area where you really don't want complexity, and I think we've already seen specific negative effects of this that have needed fixing in various ways (recently even). On Mon, Nov 20, 2017 at 7:18 AM, Alan Bateman wrote: > > One of the long standing issues with the security manager support is that > the overhead when there is no security manager is non-zero. Two specific > examples are (i) the overhead of defineClass (assuming the defining loader > is a SecureClassLoader) as it involves a callback to get the permissions for > the protection domain and (ii) the overhead of AccessController.doPrivileged > in order to execute an action on a privileged stack. > > The bigger question is of course whether it is interesting to run with a > security manager in 2017. It's clearly still important for environments that > download potentially malicious code to execute in a sandox but that isn't > most applications these days. We have seen a few cases where applications > set a security manager in order to enforce some policy, like preventing > plugins calling System.exit but these are cases that would be better served > with other solutions. > > I would like to explore changes to the API and implementation that would > allow us to eliminate some of the overhead when not running with a security > manager. Long term then it would be interesting to explore degrading and > eventually dropping the security manager but that is beyond the scope of > what I would like to discuss here. Sean Mullan and Jeff Nisewanger ran an > interesting BOF at JavaOne 2017 on this topic and I believe are planning to > do a survey at some point to understand the current usage of the security > manager. > > For now I would like to explore what it would take to eliminate some of the > overhead. A big challenge is the System.setSecurityManager API as allows a > security manager to be set in a running VM. This means that classes loaded > before a security manager is set may be involved in permission checks that > happen after a security manager is set. Similarly, privileged actions may > have started before the security manager is set. The complications around > this go away if there was some way to know that a security manager can never > be turned on in a running system. > > To get started, I've put a prototype of an initial proposal on the cr site > [1]. The summary of the proposal is: > > 1. A "disallow security manager" mode that is opt-in to disallow > setSecurityManager being used to set a security manager in a running VM. > Opt-in means it has not impact on existing code. > > 2. Deprecates setSecurityManager to discourage further usage and allow for > the possibility of making "disallow security manager" the default in the > future. If that were to become the default then it would have no impact on > deployments that set the security manager on the command line at startup. > > 3. When running in "disallow security manager" mode, > AccessController.doPrivileged invokes actions directly and > SecureClassLoader.defineClass skips the callback to get permissions for the > protection domain. This part helps startup and runtime performance. > > It's important not to get hung up on the details in the webrev, the > important thing is understand if the security folks on this mailing list are > open to a run mode that prevents a security manager being set in a running > system. > > -Alan. > > [1] http://cr.openjdk.java.net/~alanb/8191053/webrev/ -- - DML From ivan.gerasimov at oracle.com Tue Nov 21 01:36:47 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 20 Nov 2017 17:36:47 -0800 Subject: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck In-Reply-To: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> References: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> Message-ID: <2ee4aea9-a23b-a4e3-8d29-59ab31c18ddd@oracle.com> Gentle ping. If people agree on the approach, I'll go ahead and file a CCC request for the new recognized system property. With kind regards, Ivan On 11/7/17 6:24 PM, Ivan Gerasimov wrote: > Hello everybody! > > The class sun.security.ssl.SSLSessionContextImpl maintains caches for > the sessions reuse. > Access to the cache from threads is serialized. > It was reported that under heavy load the time of waiting for the turn > to access the synchronized methods outweighs the time of creating a > new session. > > It is proposed to introduce a flag that will allow to avoid using the > cache altogether. > Would you please help review the proposed fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186628 > WEBREV: http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/ > -- With kind regards, Ivan Gerasimov From xuelei.fan at oracle.com Tue Nov 21 04:50:43 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 20 Nov 2017 20:50:43 -0800 Subject: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck In-Reply-To: <2ee4aea9-a23b-a4e3-8d29-59ab31c18ddd@oracle.com> References: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> <2ee4aea9-a23b-a4e3-8d29-59ab31c18ddd@oracle.com> Message-ID: <31e3cca3-ac33-54de-2beb-c600b59cea1d@oracle.com> Hi Ivan, I understand the desire of performance improvement. But I don't think avoiding the use of cache is the price we want to pay for. Besides, avoiding using of session cache is not something improving the performance in general, it is typically something impacting the performance, a lot sometimes. Xuelei On 11/20/2017 5:36 PM, Ivan Gerasimov wrote: > Gentle ping. > > If people agree on the approach, I'll go ahead and file a CCC request > for the new recognized system property. > > With kind regards, > > Ivan > > > On 11/7/17 6:24 PM, Ivan Gerasimov wrote: >> Hello everybody! >> >> The class sun.security.ssl.SSLSessionContextImpl maintains caches for >> the sessions reuse. >> Access to the cache from threads is serialized. >> It was reported that under heavy load the time of waiting for the turn >> to access the synchronized methods outweighs the time of creating a >> new session. >> >> It is proposed to introduce a flag that will allow to avoid using the >> cache altogether. >> Would you please help review the proposed fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186628 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/ >> > From Alan.Bateman at oracle.com Tue Nov 21 11:41:30 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Nov 2017 11:41:30 +0000 Subject: Eliminating the security overhead when not running with a security manager In-Reply-To: References: <22225416-222d-afe9-3da4-f2465e7786f6@oracle.com> Message-ID: On 21/11/2017 00:48, David Lloyd wrote: > One thing that springs to mind. Some allowance would have to be made > for domain combiners and JAAS Subject propagation: this mechanism also > uses access control contexts, to its own great detriment. Are you thinking about usages where there is no security manager but AccessController.checkPermission is still used to check permissions? > : > > Anyway I never got a chance to prototype this, but it might be a fun > option worth exploring. I found the idea of moving this stuff all to > user space to be very appealing (due in no small part to the idea that > it could potentially be examined and analyzed by a much larger > audience, being Java code). It also hints at the possibility of a > fully "user space" replacement of the security manager concept (much > of the remaining cost lives in the structure of AccessControlContext, > which is based on an array of ProtectionDomain objects; this is > definitely non-ideal and could possibly be hidden behind a smarter > abstraction). In terms of performance the main interest here is the "no security manager" case. If you have prototypes that moving the stack walking and help the security manager case then I expect the folks here will be interested. -Alan From david.lloyd at redhat.com Tue Nov 21 13:14:26 2017 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 21 Nov 2017 07:14:26 -0600 Subject: Eliminating the security overhead when not running with a security manager In-Reply-To: References: <22225416-222d-afe9-3da4-f2465e7786f6@oracle.com> Message-ID: On Tue, Nov 21, 2017 at 5:41 AM, Alan Bateman wrote: > On 21/11/2017 00:48, David Lloyd wrote: >> >> One thing that springs to mind. Some allowance would have to be made >> for domain combiners and JAAS Subject propagation: this mechanism also >> uses access control contexts, to its own great detriment. > > Are you thinking about usages where there is no security manager but > AccessController.checkPermission is still used to check permissions? Not specifically; I'm thinking more of the general problem of Subject association. Calling Subject#doAs*() has a heavy cost, as does Subject#getSubject(). I believe that most container vendors who use JAAS for authentication therefore provide an alternative association API using thread-locals. > In terms of performance the main interest here is the "no security manager" > case. If you have prototypes that moving the stack walking and help the > security manager case then I expect the folks here will be interested. I think that the main benefit of this suggested approach is in fact that it should reduce the cost of the "no security manager" case. Maybe if I get some time over the upcoming holidays I'll give it a spin and see how it goes. -- - DML From ivan.gerasimov at oracle.com Tue Nov 21 13:16:47 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 21 Nov 2017 05:16:47 -0800 Subject: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck In-Reply-To: <31e3cca3-ac33-54de-2beb-c600b59cea1d@oracle.com> References: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> <2ee4aea9-a23b-a4e3-8d29-59ab31c18ddd@oracle.com> <31e3cca3-ac33-54de-2beb-c600b59cea1d@oracle.com> Message-ID: Thanks Xuelei for the comment! On 11/20/17 8:50 PM, Xuelei Fan wrote: > Hi Ivan, > > I understand the desire of performance improvement. But I don't think > avoiding the use of cache is the price we want to pay for. Besides, > avoiding using of session cache is not something improving the > performance in general, it is typically something impacting the > performance, a lot sometimes. > The proposal is not meant to be a general solution. Clearly, turning the session cache off will increase the average time of session creation. However, if the cache becomes the reason of a bottleneck due to high contention, then turning it off helps by just shortening the waiting time for each thread. The option is set to true by default, i.e. the cache is used. Only if the application is used in such a way that high contention for the cache is exposed, then the setting the option to false may help to improve performance. With kind regards, Ivan > Xuelei > > On 11/20/2017 5:36 PM, Ivan Gerasimov wrote: >> Gentle ping. >> >> If people agree on the approach, I'll go ahead and file a CCC request >> for the new recognized system property. >> >> With kind regards, >> >> Ivan >> >> >> On 11/7/17 6:24 PM, Ivan Gerasimov wrote: >>> Hello everybody! >>> >>> The class sun.security.ssl.SSLSessionContextImpl maintains caches >>> for the sessions reuse. >>> Access to the cache from threads is serialized. >>> It was reported that under heavy load the time of waiting for the >>> turn to access the synchronized methods outweighs the time of >>> creating a new session. >>> >>> It is proposed to introduce a flag that will allow to avoid using >>> the cache altogether. >>> Would you please help review the proposed fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186628 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/ >>> >> > -- With kind regards, Ivan Gerasimov From sean.mullan at oracle.com Tue Nov 21 17:28:34 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 21 Nov 2017 12:28:34 -0500 Subject: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator In-Reply-To: References: <112aed8a-88ea-8e3e-b69a-27f32b7a287c@oracle.com> Message-ID: One more small comment: 51 *
  • Check if the returned key pair generator is an instance of the 52 * DSAKeyPairGenerator interface before casting the result to a I would just say "... instance of DSAKeyPairGenerator before ..." --Sean On 11/16/17 7:39 PM, Valerie Peng wrote: > > Thanks for the feedback. > > I have updated webrev to address your comments: > http://cr.openjdk.java.net/~valeriep/8182484/webrev.01/ > CSR has also been updated and proposed. > Valerie > > On 11/14/2017 10:47 AM, Sean Mullan wrote: >> On 11/8/17 6:47 PM, Valerie Peng wrote: >>> Hi, Sean, >>> >>> I updated the webrev in place - now this change contains only javadoc >>> update of DSAKeyPairGenerator interface. >>> CSR has also been updated accordingly. Could you please take a look? >> >> Sure. >> >> ? 35? * DSAKeyPairGenerator, each provider must supply (and document) a >> ? 36? * default initialization. >> >> I suggest saying "should" instead of "must" since we can't really >> require this to be documented, esp. for a 3rd-party provider. Also I >> would say "each provider that implements this interface ...". >> >> ? 52? * DSAKeyPairGenerator, then call one of the {@code initialize} >> methods >> >> Slight rewording suggestion: "DSAKeyPairGenerator and calling one of >> the {@code initialize} methods" >> >> ?103????? * thrown. It is guaranteed that there will always be >> ?104????? * default parameters for modulus lengths of 512, 1024, and >> 2048 bits. >> >> I guess "guaranteed" is referring to any impl of DSAKeyPairGenerator, >> but it is kind of hard to enforce that if you are using a 3rd-party >> provider. I think we should consider just removing this sentence >> entirely and leaving the requirements up to the implementation. It's >> also unusual that we would require 512-bits, and hard-coding that >> might make it hard to remove later on. Minimally, I think we should >> remove 512. >> >> --Sean >> >>> >>> Thanks, >>> Valerie >>> >>> On 11/2/2017 6:24 PM, Valerie Peng wrote: >>>> Sean, >>>> >>>> Could you help review this RFE below? It's mainly the javadoc update >>>> of java.security.interfaces.DSAKeyPairGenerator which replaces the >>>> 1024-bit default value with provider-specific one and removal of the >>>> earlier changes for working around this javadoc limitation. I reused >>>> the wordings from existing security classes. >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8182484 >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8182484/webrev.00/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190569 >>>> >>>> Thanks, >>>> Valerie >>> > From ivan.gerasimov at oracle.com Wed Nov 22 01:47:23 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 21 Nov 2017 17:47:23 -0800 Subject: [10] RFR 8068024 : Null pointer dereference in jdk/src/macosx/native/apple/security/KeystoreImpl.m Message-ID: <94f611ea-1d12-af56-8511-e9c78ca9ee4b@oracle.com> Hello! Here's a simple fix to correctly handle the malloc call returning NULL. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068024 WEBREV: http://cr.openjdk.java.net/~igerasim/8068024/00/webrev/ Would you please help review? -- With kind regards, Ivan Gerasimov From valerie.peng at oracle.com Wed Nov 22 02:04:26 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 21 Nov 2017 18:04:26 -0800 Subject: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator In-Reply-To: References: <112aed8a-88ea-8e3e-b69a-27f32b7a287c@oracle.com> Message-ID: Sure, webrev updated? and CSR moved to finalized state. http://cr.openjdk.java.net/~valeriep/8182484/webrev.02/ Thanks, Valerie On 11/21/2017 9:28 AM, Sean Mullan wrote: > One more small comment: > > ? 51? *
  • Check if the returned key pair generator is an instance of > the > ? 52? * DSAKeyPairGenerator interface before casting the result to a > > I would just say "... instance of DSAKeyPairGenerator before ..." > > --Sean > > On 11/16/17 7:39 PM, Valerie Peng wrote: >> >> Thanks for the feedback. >> >> I have updated webrev to address your comments: >> http://cr.openjdk.java.net/~valeriep/8182484/webrev.01/ >> CSR has also been updated and proposed. >> Valerie >> >> On 11/14/2017 10:47 AM, Sean Mullan wrote: >>> On 11/8/17 6:47 PM, Valerie Peng wrote: >>>> Hi, Sean, >>>> >>>> I updated the webrev in place - now this change contains only >>>> javadoc update of DSAKeyPairGenerator interface. >>>> CSR has also been updated accordingly. Could you please take a look? >>> >>> Sure. >>> >>> ? 35? * DSAKeyPairGenerator, each provider must supply (and document) a >>> ? 36? * default initialization. >>> >>> I suggest saying "should" instead of "must" since we can't really >>> require this to be documented, esp. for a 3rd-party provider. Also I >>> would say "each provider that implements this interface ...". >>> >>> ? 52? * DSAKeyPairGenerator, then call one of the {@code initialize} >>> methods >>> >>> Slight rewording suggestion: "DSAKeyPairGenerator and calling one of >>> the {@code initialize} methods" >>> >>> ?103????? * thrown. It is guaranteed that there will always be >>> ?104????? * default parameters for modulus lengths of 512, 1024, and >>> 2048 bits. >>> >>> I guess "guaranteed" is referring to any impl of >>> DSAKeyPairGenerator, but it is kind of hard to enforce that if you >>> are using a 3rd-party provider. I think we should consider just >>> removing this sentence entirely and leaving the requirements up to >>> the implementation. It's also unusual that we would require >>> 512-bits, and hard-coding that might make it hard to remove later >>> on. Minimally, I think we should remove 512. >>> >>> --Sean >>> >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 11/2/2017 6:24 PM, Valerie Peng wrote: >>>>> Sean, >>>>> >>>>> Could you help review this RFE below? It's mainly the javadoc >>>>> update of java.security.interfaces.DSAKeyPairGenerator which >>>>> replaces the 1024-bit default value with provider-specific one and >>>>> removal of the earlier changes for working around this javadoc >>>>> limitation. I reused the wordings from existing security classes. >>>>> >>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8182484 >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8182484/webrev.00/ >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190569 >>>>> >>>>> Thanks, >>>>> Valerie >>>> >> From valerie.peng at oracle.com Wed Nov 22 02:12:38 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 21 Nov 2017 18:12:38 -0800 Subject: [11] RFR JDK-8146293: Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2 Message-ID: <9c2b9a8d-9996-db12-791a-25d14b5bb0c9@oracle.com> Anyone who can help reviewing this enhancement? RFE: https://bugs.openjdk.java.net/browse/JDK-8146293 Webrev: http://cr.openjdk.java.net/~valeriep/8146293/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8190180 Quick summary on the changes: 1) Enhanced SunRsaSign provider with the following algorithms: ????????Signature.SHA512/224withRSA (1.2.840.113549.1.1.14) ????????Signature.SHA512/256withRSA (1.2.840.113549.1.1.15) ????????Signature.RSA-PSS (1.2.840.113549.1.1.10) ????????Signature.SHA1withRSAandMGF1 ????????Signature.SHA224withRSAandMGF1 ????????Signature.SHA256withRSAandMGF1 ????????Signature.SHA384withRSAandMGF1 ????????Signature.SHA512withRSAandMGF1 ????????Signature.SHA512/224withRSAandMGF1 ????????Signature.SHA512/256withRSAandMGF1 ????????AlgorithmParameters.RSA-PSS 2) Update the public RSA-related parameter spec classes to v2.2 3) Enhance the OAEP parameter SunJCE provider with SHA-512/224 and SHA-512/224 support (new in v2.2) Thanks, Valerie From weijun.wang at oracle.com Wed Nov 22 06:32:27 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Nov 2017 14:32:27 +0800 Subject: [10] RFR 8068024 : Null pointer dereference in jdk/src/macosx/native/apple/security/KeystoreImpl.m In-Reply-To: <94f611ea-1d12-af56-8511-e9c78ca9ee4b@oracle.com> References: <94f611ea-1d12-af56-8511-e9c78ca9ee4b@oracle.com> Message-ID: <850011AC-69A6-449C-8EA7-A88DF5D60F0C@oracle.com> This looks fine to me. Thanks Max > On Nov 22, 2017, at 9:47 AM, Ivan Gerasimov wrote: > > Hello! > > Here's a simple fix to correctly handle the malloc call returning NULL. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068024 > WEBREV: http://cr.openjdk.java.net/~igerasim/8068024/00/webrev/ > > Would you please help review? > > -- > With kind regards, > Ivan Gerasimov > From peter.levart at gmail.com Wed Nov 22 09:45:28 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 22 Nov 2017 10:45:28 +0100 Subject: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck In-Reply-To: References: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> <2ee4aea9-a23b-a4e3-8d29-59ab31c18ddd@oracle.com> <31e3cca3-ac33-54de-2beb-c600b59cea1d@oracle.com> Message-ID: <8e1d8cc9-2d14-0a0c-5438-3e5eb600060a@gmail.com> Hi Ivan, Here's my attempt to increase multithreaded scalability of Cache: http://cr.openjdk.java.net/~plevart/jdk10-dev/8186628_ssl_session_cache_scalability/webrev.01/ Haven't tested this yet, but I thought that since you already have relevant performance tests, you might want to try this, so I decided to release it as is. Rough sketch of changes: - replaced LinkedHashMap with ConcurrentHashMap - CacheEntry(s) are additionaly linked into a double-linked list. DL-list management is the only synchronization point (similar to Cleaner API) and the rule is: 1st new entry is linked into DL-list, then it is put into map - published. The same with removing: 1st an entry is unlinked from DL-list, then if successfull, removed from map and invalidated. - changed the way expiry is handled so that the whole list is never needed to be scanned. The code speaks for itself. Let me know if you find it usefull and/or it solves the scalability bottleneck. Regards, Peter On 11/21/17 14:16, Ivan Gerasimov wrote: > Thanks Xuelei for the comment! > > > On 11/20/17 8:50 PM, Xuelei Fan wrote: >> Hi Ivan, >> >> I understand the desire of performance improvement.? But I don't >> think avoiding the use of cache is the price we want to pay for. >> Besides, avoiding using of session cache is not something improving >> the performance in general, it is typically something impacting the >> performance,? a lot sometimes. >> > The proposal is not meant to be a general solution. > Clearly, turning the session cache off will increase the average time > of session creation. > However, if the cache becomes the reason of a bottleneck due to high > contention, then turning it off helps by just shortening the waiting > time for each thread. > > The option is set to true by default, i.e. the cache is used. > Only if the application is used in such a way that high contention for > the cache is exposed, then the setting the option to false may help to > improve performance. > > With kind regards, > Ivan > >> Xuelei >> >> On 11/20/2017 5:36 PM, Ivan Gerasimov wrote: >>> Gentle ping. >>> >>> If people agree on the approach, I'll go ahead and file a CCC >>> request for the new recognized system property. >>> >>> With kind regards, >>> >>> Ivan >>> >>> >>> On 11/7/17 6:24 PM, Ivan Gerasimov wrote: >>>> Hello everybody! >>>> >>>> The class sun.security.ssl.SSLSessionContextImpl maintains caches >>>> for the sessions reuse. >>>> Access to the cache from threads is serialized. >>>> It was reported that under heavy load the time of waiting for the >>>> turn to access the synchronized methods outweighs the time of >>>> creating a new session. >>>> >>>> It is proposed to introduce a flag that will allow to avoid using >>>> the cache altogether. >>>> Would you please help review the proposed fix? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186628 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/ >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Nov 22 13:23:05 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 Nov 2017 08:23:05 -0500 Subject: New JEP Draft: "Open-Source the Root Certificates" Message-ID: Please review a new JEP Draft titled "Open-Source the Root Certificates". The JDK source code currently contains an empty cacerts keystore, which prevents security components such as TLS from working out-of-the-box on OpenJDK builds. The goal of this JEP is to provide a default set of root certificates in the JDK, in order to reduce the differences between the OpenJDK and Oracle JDK builds. http://cr.openjdk.java.net/~mullan/jeps/8191486.html Thanks, Sean From Alan.Bateman at oracle.com Wed Nov 22 13:39:55 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Nov 2017 13:39:55 +0000 Subject: New JEP Draft: "Open-Source the Root Certificates" In-Reply-To: References: Message-ID: <11f7bea5-febe-0033-ef64-f51cf53fbd4c@oracle.com> On 22/11/2017 13:23, Sean Mullan wrote: > Please review a new JEP Draft titled "Open-Source the Root > Certificates". The JDK source code currently contains an empty cacerts > keystore, which prevents security components such as TLS from working > out-of-the-box on OpenJDK builds. > > The goal of this JEP is to provide a default set of root certificates > in the JDK, in order to reduce the differences between the OpenJDK and > Oracle JDK builds. > > http://cr.openjdk.java.net/~mullan/jeps/8191486.html It can be served up as a JEP draft too: ?? http://openjdk.java.net/jeps/8191486 -Alan From dalibor.topic at oracle.com Wed Nov 22 14:17:28 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 22 Nov 2017 15:17:28 +0100 Subject: New JEP Draft: "Open-Source the Root Certificates" In-Reply-To: References: Message-ID: <3fb560fd-4437-8ed6-b868-e09784912eb7@oracle.com> Thanks, Sean - this is a great step forward! On 22.11.2017 14:23, Sean Mullan wrote: > Please review a new JEP Draft titled "Open-Source the Root > Certificates". The JDK source code currently contains an empty cacerts > keystore, which prevents security components such as TLS from working > out-of-the-box on OpenJDK builds. > > The goal of this JEP is to provide a default set of root certificates in > the JDK, in order to reduce the differences between the OpenJDK and > Oracle JDK builds. > > http://cr.openjdk.java.net/~mullan/jeps/8191486.html > > Thanks, > Sean -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From sean.mullan at oracle.com Wed Nov 22 14:37:07 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 Nov 2017 09:37:07 -0500 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields Message-ID: Please review this change to remove the pre-JDK 1.2 SecurityManager methods that have been deprecated since JDK 1.2 and marked for removal in JDK 9. These methods are fragile, error-prone and have been obsolete since the SecurityManager was revamped in JDK 1.2. The methods to be removed are: getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader. In addition, the deprecated and error-prone checkMemberAccess method (which was deprecated in JDK 8 and marked for removal in JDK 9) has been changed to throw SecurityException if the caller has not been granted AllPermission. This makes the method less likely it will be used incorrectly while still allowing some more time before it is removed. http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ Thanks, Sean From Alan.Bateman at oracle.com Wed Nov 22 14:59:28 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Nov 2017 14:59:28 +0000 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: References: Message-ID: <0bd1f8ea-0d96-ce98-a587-818742f191d1@oracle.com> On 22/11/2017 14:37, Sean Mullan wrote: > Please review this change to remove the pre-JDK 1.2 SecurityManager > methods that have been deprecated since JDK 1.2 and marked for removal > in JDK 9. These methods are fragile, error-prone and have been > obsolete since the SecurityManager was revamped in JDK 1.2. The > methods to be removed are: getInCheck, classDepth, classLoaderDepth, > currentClassLoader, currentLoadedClass, inClass, and inClassLoader. > > In addition, the deprecated and error-prone checkMemberAccess method > (which was deprecated in JDK 8 and marked for removal in JDK 9) has > been changed to throw SecurityException if the caller has not been > granted AllPermission. This makes the method less likely it will be > used incorrectly while still allowing some more time before it is > removed. > > http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ This mostly looks good. Does the stack walker created in AppletSecurity need to be done in a privileged block? If this is just the mouldy appletviewer tool then ignore my comment. A minor comment is that the is legacy and we've been using {@code ...} for recent changes. We changed some of these methods to use {@code ...} when we degraded them in JDK 9. Also NoAWT probably isn't the right place to test checkMemberAccess. If the test is renamed and the description changed then it would be okay. -Alan From sean.mullan at oracle.com Wed Nov 22 15:49:16 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 Nov 2017 10:49:16 -0500 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: <0bd1f8ea-0d96-ce98-a587-818742f191d1@oracle.com> References: <0bd1f8ea-0d96-ce98-a587-818742f191d1@oracle.com> Message-ID: On 11/22/17 9:59 AM, Alan Bateman wrote: >> http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ > This mostly looks good. > > Does the stack walker created in AppletSecurity need to be done in a > privileged block? If this is just the mouldy appletviewer tool then > ignore my comment. Hmm. Where do you see it being called inside doPrivileged? > A minor comment is that the is legacy and we've been using {@code > ...} for recent changes. We changed some of these methods to use {@code > ...} when we degraded them in JDK 9. I guess you are referring to the checkMemberAccess method. Sure I can change it to use {@code}. > Also NoAWT probably isn't the right > place to test checkMemberAccess. If the test is renamed and the > description changed then it would be okay. Sure, the test already had everything I need so it was easier to leverage it rather than just duplicating. I had changed the description already. I will just rename it to something more generic, like DepMethodsRequireAllPerm. --Sean From Alan.Bateman at oracle.com Wed Nov 22 15:59:25 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Nov 2017 15:59:25 +0000 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: References: <0bd1f8ea-0d96-ce98-a587-818742f191d1@oracle.com> Message-ID: On 22/11/2017 15:49, Sean Mullan wrote: > > Hmm. Where do you see it being called inside doPrivileged? StackWalker.getInstance does a permission check when you want class refs. > : > > Sure, the test already had everything I need so it was easier to > leverage it rather than just duplicating. I had changed the > description already. I will just rename it to something more generic, > like DepMethodsRequireAllPerm. > I think I added the NoAWT test for the checkXXX methods that used to check AWTPermission, hence the name. Renaming it would be good. -Alan From artem.smotrakov at oracle.com Wed Nov 22 18:19:28 2017 From: artem.smotrakov at oracle.com (Artem) Date: Wed, 22 Nov 2017 21:19:28 +0300 Subject: RFR[10] 8186057: TLS interoperability testing between different Java versions In-Reply-To: <1e8d1acf-7f06-9e08-5a48-a65751586471@oracle.com> References: <12833c7c-3b34-3d8a-77ee-9299e8cca88d@oracle.com> <05d9da98-205a-887d-ad88-c88b15832947@oracle.com> <7fcc23e3-dd4e-d127-0cc2-f4990fb5d665@oracle.com> <894241da-b4d7-46ce-2962-c3e6e9a2227b@oracle.com> <1e8d1acf-7f06-9e08-5a48-a65751586471@oracle.com> Message-ID: <927b4361-5147-a385-7db6-05f68ee09ed2@oracle.com> Hi John, Could you please upload the report to http://cr.openjdk.java.net/~jjiang/8186057 ? One question about Compatibility.caseStatus(). What's the case when you expect a timeout and no client output? Should it always result to a test case failure? Otherwise, looks fine to me. A couple of minor comments which you may want to address: 1. Cert.getCert(): it would be nice to add a comment which explains what's returned in the array. It might be good to add an "else" block and throw an exception there. 2. Client.java, lines 83-84: it's not necessary to print a stack trace if you put the original exception to runtime exception. The same with ProcessUtils. 3. JdkInfo: the fields of this class should be final since you don't modify them then. If compilation fails because of complex logic in constructor, then it may be a sign that the logic should be simplified. Or, you can put the logic to a static factory method. 4. "sequence" field of JdkRelease looks redundant. A enum already defines the order. The same with Protocol. 5. On 11/14/2017 09:16 AM, sha.jiang at oracle.com wrote: > Hi Artem, > Please find the new webrev [1]. > This test has been refactored significantly. It supports more cipher > suites, and case combinations among the TLS communication parameters. > For more details, please look through README [2]. > > [1] http://cr.openjdk.java.net/~jjiang/8186057/webrev.04/ > [2] > http://cr.openjdk.java.net/~jjiang/8186057/webrev.04/test/jdk/javax/net/ssl/compatibility/README.html > > Best regards, > John Jiang > > On 07/09/2017 18:47, sha.jiang at oracle.com wrote: >> Hi Artem, >> >> On 07/09/2017 16:28, Artem Smotrakov wrote: >>> In case of SNI, SSLParemeters.setServerNames() method (and others >>> related to SNI) was introduced in 8. I don't think the code which >>> use this method can be compiled with 6 and 7. >> All of Java source are compiled by a JDK 10 build, which is specified >> by jtreg option "-jdk". Other testing JDKs, including 6 and 7, just >> use the .class files on runtime. >> That's why the below line exists in Compatibility.java, >> 32? * @compile -source 1.6 -target 1.6 Server.java Client.java >> JdkUtils.java >>> >>> But if you want to test SNI with 8+, you need to call them. >>> >>> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLParameters.html#setServerNames-java.util.List- >>> >> If a feature, like ALPN and SNI, is not supported, such method would >> not be called on runtime. >> >> Best regards, >> John Jiang >>> >>> Artem >>> >>> On 09/07/2017 11:24 AM, sha.jiang at oracle.com wrote: >>>> Hi Artem, >>>> >>>> On 07/09/2017 16:07, Artem Smotrakov wrote: >>>>>> >>>>>>> - Please use try-with-resources if possible (files, sockets, etc) >>>>>> The test uses only JDK 6-supported language features, but >>>>>> try-with-resources is introduced by JDK 7. >>>>> Here we come to another issue. I believe that it would be good to >>>>> use write clients for all JDK versions. If you use the same code >>>>> for all Java versions, that means that you use only JDK 6 API. >>>>> Let's consider the following: >>>>> - we want to test 8 vs 9 >>>>> - 8 and 9 may have some API (or just functionality) which is not >>>>> supported by 6 (for example, ALPN, SNI) >>>>> >>>>> If you write code which is compatible with 6, then you can use API >>>>> from newer versions, but we still may want to test it. >>>> In fact, the current test has already covered ALPN, though only JDK >>>> 9 and 10 support the associated methods, like >>>> SSLParameters.getApplicationProtocols(). >>>> ALPN-associated case combinations are ignored if a JDK doesn't >>>> support this feature. Exactly, JdkUtils checks if a specific JDK >>>> build contains method SSLParameters.getApplicationProtocols(). >>>> I think the same approach could be applied for SNI in the future. >>>> >>>> Best regards, >>>> John Jiang >>>>> >>>>> Artem >>>>>> >>>>>> Best regards, >>>>>> John Jiang >>>>>>> >>>>>>> Artem >>>>>>> >>>>>>> On 09/07/2017 08:52 AM, sha.jiang at oracle.com wrote: >>>>>>>> Hi, >>>>>>>> Please review this test for checking the interop compatibility >>>>>>>> on JSSE among different JDK releases (from 6 to 10). >>>>>>>> It covers the cases, like handshake, data exchange, client >>>>>>>> authentication and APLN, on all TLS versions (if possible). >>>>>>>> And the selected TLS cipher suites are: >>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA >>>>>>>> and TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA. >>>>>>>> For more details, please look though the README. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8186057/webrev.00 >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8186057 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> John Jiang >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > From ivan.gerasimov at oracle.com Thu Nov 23 00:16:44 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 22 Nov 2017 16:16:44 -0800 Subject: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck In-Reply-To: <8e1d8cc9-2d14-0a0c-5438-3e5eb600060a@gmail.com> References: <7870bfc1-5f83-fb28-fd69-53e582a90c37@oracle.com> <2ee4aea9-a23b-a4e3-8d29-59ab31c18ddd@oracle.com> <31e3cca3-ac33-54de-2beb-c600b59cea1d@oracle.com> <8e1d8cc9-2d14-0a0c-5438-3e5eb600060a@gmail.com> Message-ID: Hi Peter! Thank you very much for looking into this! On 11/22/17 1:45 AM, Peter Levart wrote: > Hi Ivan, > > Here's my attempt to increase multithreaded scalability of Cache: > > http://cr.openjdk.java.net/~plevart/jdk10-dev/8186628_ssl_session_cache_scalability/webrev.01/ > > Haven't tested this yet, but I thought that since you already have > relevant performance tests, you might want to try this, so I decided > to release it as is. I plugged your implementation into the benchmark I had [*] and got these numbers for the throughput: Original MemoryCache: 4,116,537 puts/second Your variant: 2,942,561 puts/second So, in the tested scenario performance downgraded by 28%. Still, I think it's important to try to improve performance of the MemoryCache and, if possible, remove the points of contention. > > Rough sketch of changes: > - replaced LinkedHashMap with ConcurrentHashMap > - CacheEntry(s) are additionaly linked into a double-linked list. > DL-list management is the only synchronization point (similar to > Cleaner API) and the rule is: 1st new entry is linked into DL-list, > then it is put into map - published. The same with removing: 1st an > entry is unlinked from DL-list, then if successfull, removed from map > and invalidated. > - changed the way expiry is handled so that the whole list is never > needed to be scanned. > > The code speaks for itself. > Your implementation is somewhat similar to what I had tried before coming up with proposal of the option to turn the cache off. I used ConcurrentHashMap + ConcurrentLinkedQueue to maintain the FIFO order, still the performance was a few percent less then the one of the original implementation. That's really why I decided to split the issue: - first, provide an option to turn the cache off (that should be easily backported and can provide immediate relief to the customers that experience the scalability bottleneck; - second, continue work on the cache implementation improvements. > Let me know if you find it usefull and/or it solves the scalability > bottleneck. > Yes, I think it's very useful! However, as I wrote above, I think that the issue needs be split into two parts: an option to turn the caching off (which can be easily backported) and improving the cache implementation (which can even relax the requirements, as the FIFO order or absolutely hard upper bound of the cache size). With kind regards, Ivan > Regards, Peter > > On 11/21/17 14:16, Ivan Gerasimov wrote: >> Thanks Xuelei for the comment! >> >> >> On 11/20/17 8:50 PM, Xuelei Fan wrote: >>> Hi Ivan, >>> >>> I understand the desire of performance improvement. But I don't >>> think avoiding the use of cache is the price we want to pay for. >>> Besides, avoiding using of session cache is not something improving >>> the performance in general, it is typically something impacting the >>> performance, a lot sometimes. >>> >> The proposal is not meant to be a general solution. >> Clearly, turning the session cache off will increase the average time >> of session creation. >> However, if the cache becomes the reason of a bottleneck due to high >> contention, then turning it off helps by just shortening the waiting >> time for each thread. >> >> The option is set to true by default, i.e. the cache is used. >> Only if the application is used in such a way that high contention >> for the cache is exposed, then the setting the option to false may >> help to improve performance. >> >> With kind regards, >> Ivan >> >>> Xuelei >>> >>> On 11/20/2017 5:36 PM, Ivan Gerasimov wrote: >>>> Gentle ping. >>>> >>>> If people agree on the approach, I'll go ahead and file a CCC >>>> request for the new recognized system property. >>>> >>>> With kind regards, >>>> >>>> Ivan >>>> >>>> >>>> On 11/7/17 6:24 PM, Ivan Gerasimov wrote: >>>>> Hello everybody! >>>>> >>>>> The class sun.security.ssl.SSLSessionContextImpl maintains caches >>>>> for the sessions reuse. >>>>> Access to the cache from threads is serialized. >>>>> It was reported that under heavy load the time of waiting for the >>>>> turn to access the synchronized methods outweighs the time of >>>>> creating a new session. >>>>> >>>>> It is proposed to introduce a flag that will allow to avoid using >>>>> the cache altogether. >>>>> Would you please help review the proposed fix? >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186628 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/ >>>>> >>>> >>> >> > -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Thu Nov 23 02:38:43 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 22 Nov 2017 18:38:43 -0800 Subject: [10] RFR 8068024 : Null pointer dereference in jdk/src/macosx/native/apple/security/KeystoreImpl.m In-Reply-To: <850011AC-69A6-449C-8EA7-A88DF5D60F0C@oracle.com> References: <94f611ea-1d12-af56-8511-e9c78ca9ee4b@oracle.com> <850011AC-69A6-449C-8EA7-A88DF5D60F0C@oracle.com> Message-ID: <5cbdb3ac-7c46-adf2-d944-e0920858ad37@oracle.com> Thank you for review! Pushed. With kind regards, Ivan On 11/21/17 10:32 PM, Weijun Wang wrote: > This looks fine to me. > > Thanks > Max > >> On Nov 22, 2017, at 9:47 AM, Ivan Gerasimov wrote: >> >> Hello! >> >> Here's a simple fix to correctly handle the malloc call returning NULL. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068024 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8068024/00/webrev/ >> >> Would you please help review? >> >> -- >> With kind regards, >> Ivan Gerasimov >> > -- With kind regards, Ivan Gerasimov From sha.jiang at oracle.com Thu Nov 23 13:54:01 2017 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 23 Nov 2017 21:54:01 +0800 Subject: RFR[10] 8186057: TLS interoperability testing between different Java versions In-Reply-To: <927b4361-5147-a385-7db6-05f68ee09ed2@oracle.com> References: <12833c7c-3b34-3d8a-77ee-9299e8cca88d@oracle.com> <05d9da98-205a-887d-ad88-c88b15832947@oracle.com> <7fcc23e3-dd4e-d127-0cc2-f4990fb5d665@oracle.com> <894241da-b4d7-46ce-2962-c3e6e9a2227b@oracle.com> <1e8d1acf-7f06-9e08-5a48-a65751586471@oracle.com> <927b4361-5147-a385-7db6-05f68ee09ed2@oracle.com> Message-ID: <66551e18-e4f8-7209-e325-81b28cb16d21@oracle.com> Hi Artem, Please find the updated webrev at: http://cr.openjdk.java.net/~jjiang/8186057/webrev.05/ And see my comments inline. On 23/11/2017 02:19, Artem wrote: > Hi John, > > Could you please upload the report to > http://cr.openjdk.java.net/~jjiang/8186057 ? http://cr.openjdk.java.net/~jjiang/8186057/webrev.05/report/report.html > > One question about Compatibility.caseStatus(). What's the case when > you expect a timeout and no client output? Should it always result to > a test case failure? I'm not sure understanding your question. Did you mean server or client timeout? I think client should output something. > > Otherwise, looks fine to me. > > A couple of minor comments which you may want to address: > > 1. Cert.getCert(): it would be nice to add a comment which explains > what's returned in the array. Some comments are added for method Cert.getCerts(). > It might be good to add an "else" block and throw an exception there. DSA certificates are selected by default. If these certificates are unexpected, I think some cases should fail, finally the test should fail. > > 2. Client.java, lines 83-84: it's not necessary to print a stack trace > if you put the original exception to runtime exception. The same with > ProcessUtils. Fixed. > > 3. JdkInfo: the fields of this class should be final since you don't > modify them then. If compilation fails because of complex logic in > constructor, then it may be a sign that the logic should be > simplified. Or, you can put the logic to a static factory method. That if-else clause is removed and such fields are final now. > > 4. "sequence" field of JdkRelease looks redundant. A enum already > defines the order. The same with Protocol. It looks the ordinal of enum constants is not recommended [1]. [1] https://docs.oracle.com/javase/9/docs/api/java/lang/Enum.html#ordinal-- Best regards, John Jiang > > 5. > > On 11/14/2017 09:16 AM, sha.jiang at oracle.com wrote: >> Hi Artem, >> Please find the new webrev [1]. >> This test has been refactored significantly. It supports more cipher >> suites, and case combinations among the TLS communication parameters. >> For more details, please look through README [2]. >> >> [1] http://cr.openjdk.java.net/~jjiang/8186057/webrev.04/ >> [2] >> http://cr.openjdk.java.net/~jjiang/8186057/webrev.04/test/jdk/javax/net/ssl/compatibility/README.html >> >> Best regards, >> John Jiang >> >> On 07/09/2017 18:47, sha.jiang at oracle.com wrote: >>> Hi Artem, >>> >>> On 07/09/2017 16:28, Artem Smotrakov wrote: >>>> In case of SNI, SSLParemeters.setServerNames() method (and others >>>> related to SNI) was introduced in 8. I don't think the code which >>>> use this method can be compiled with 6 and 7. >>> All of Java source are compiled by a JDK 10 build, which is >>> specified by jtreg option "-jdk". Other testing JDKs, including 6 >>> and 7, just use the .class files on runtime. >>> That's why the below line exists in Compatibility.java, >>> 32? * @compile -source 1.6 -target 1.6 Server.java Client.java >>> JdkUtils.java >>>> >>>> But if you want to test SNI with 8+, you need to call them. >>>> >>>> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLParameters.html#setServerNames-java.util.List- >>>> >>> If a feature, like ALPN and SNI, is not supported, such method would >>> not be called on runtime. >>> >>> Best regards, >>> John Jiang >>>> >>>> Artem >>>> >>>> On 09/07/2017 11:24 AM, sha.jiang at oracle.com wrote: >>>>> Hi Artem, >>>>> >>>>> On 07/09/2017 16:07, Artem Smotrakov wrote: >>>>>>> >>>>>>>> - Please use try-with-resources if possible (files, sockets, etc) >>>>>>> The test uses only JDK 6-supported language features, but >>>>>>> try-with-resources is introduced by JDK 7. >>>>>> Here we come to another issue. I believe that it would be good to >>>>>> use write clients for all JDK versions. If you use the same code >>>>>> for all Java versions, that means that you use only JDK 6 API. >>>>>> Let's consider the following: >>>>>> - we want to test 8 vs 9 >>>>>> - 8 and 9 may have some API (or just functionality) which is not >>>>>> supported by 6 (for example, ALPN, SNI) >>>>>> >>>>>> If you write code which is compatible with 6, then you can use >>>>>> API from newer versions, but we still may want to test it. >>>>> In fact, the current test has already covered ALPN, though only >>>>> JDK 9 and 10 support the associated methods, like >>>>> SSLParameters.getApplicationProtocols(). >>>>> ALPN-associated case combinations are ignored if a JDK doesn't >>>>> support this feature. Exactly, JdkUtils checks if a specific JDK >>>>> build contains method SSLParameters.getApplicationProtocols(). >>>>> I think the same approach could be applied for SNI in the future. >>>>> >>>>> Best regards, >>>>> John Jiang >>>>>> >>>>>> Artem >>>>>>> >>>>>>> Best regards, >>>>>>> John Jiang >>>>>>>> >>>>>>>> Artem >>>>>>>> >>>>>>>> On 09/07/2017 08:52 AM, sha.jiang at oracle.com wrote: >>>>>>>>> Hi, >>>>>>>>> Please review this test for checking the interop compatibility >>>>>>>>> on JSSE among different JDK releases (from 6 to 10). >>>>>>>>> It covers the cases, like handshake, data exchange, client >>>>>>>>> authentication and APLN, on all TLS versions (if possible). >>>>>>>>> And the selected TLS cipher suites are: >>>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA >>>>>>>>> and TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA. >>>>>>>>> For more details, please look though the README. >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8186057/webrev.00 >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8186057 >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> John Jiang >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> > > From artem.smotrakov at oracle.com Thu Nov 23 17:06:30 2017 From: artem.smotrakov at oracle.com (Artem) Date: Thu, 23 Nov 2017 20:06:30 +0300 Subject: RFR[10] 8186057: TLS interoperability testing between different Java versions In-Reply-To: <66551e18-e4f8-7209-e325-81b28cb16d21@oracle.com> References: <12833c7c-3b34-3d8a-77ee-9299e8cca88d@oracle.com> <05d9da98-205a-887d-ad88-c88b15832947@oracle.com> <7fcc23e3-dd4e-d127-0cc2-f4990fb5d665@oracle.com> <894241da-b4d7-46ce-2962-c3e6e9a2227b@oracle.com> <1e8d1acf-7f06-9e08-5a48-a65751586471@oracle.com> <927b4361-5147-a385-7db6-05f68ee09ed2@oracle.com> <66551e18-e4f8-7209-e325-81b28cb16d21@oracle.com> Message-ID: <54542382-5c9f-eb51-12b5-8e02e7c5e643@oracle.com> Hi John, A couple of more (probably minor) comments. Addressing them might simplify the code and make it more readable. Although, one might argue with it. So, feel free to ignore them. The only thing which I would like to clarify is the questing about timeouts below. I see you use multi-lined boolean expressions and ternary operators (especially when they are long). It might make the code shorter, but I believe in most cases it doesn't make it more readable. If you really want to make the code shorter (I don't think it should be the goal), you can also consider dropping "else" blocks if you just return values. I would also avoid implicit converting an integer to a string by concatenation of the integer with an empty string. You can use String.valueOf() instead. Please also see inline. On 11/23/2017 04:54 PM, sha.jiang at oracle.com wrote: >> Hi John, >> >> Could you please upload the report to >> http://cr.openjdk.java.net/~jjiang/8186057 ? > http://cr.openjdk.java.net/~jjiang/8186057/webrev.05/report/report.html Thank you. It might be better to add some space between columns. >> >> One question about Compatibility.caseStatus(). What's the case when >> you expect a timeout and no client output? Should it always result to >> a test case failure? > I'm not sure understanding your question. Did you mean server or > client timeout? > I think client should output something. My questing is - should timeout be always considered as a failure? Why don't you just check if server or client result is FAIL? if (clientStatus == FAIL || serverStatus == FAIL) { ??? return FAIL; } return PASS; > >> >> Otherwise, looks fine to me. >> >> A couple of minor comments which you may want to address: >> >> 4. "sequence" field of JdkRelease looks redundant. A enum already >> defines the order. The same with Protocol. > It looks the ordinal of enum constants is not recommended [1]. > > [1] > https://docs.oracle.com/javase/9/docs/api/java/lang/Enum.html#ordinal-- I don't see that it says that using "ordinal" is not recommended. I think "sequence" just duplicates of? "ordinal". Artem > > Best regards, > John Jiang > >> >> 5. >> >> On 11/14/2017 09:16 AM, sha.jiang at oracle.com wrote: >>> Hi Artem, >>> Please find the new webrev [1]. >>> This test has been refactored significantly. It supports more cipher >>> suites, and case combinations among the TLS communication parameters. >>> For more details, please look through README [2]. >>> >>> [1] http://cr.openjdk.java.net/~jjiang/8186057/webrev.04/ >>> [2] >>> http://cr.openjdk.java.net/~jjiang/8186057/webrev.04/test/jdk/javax/net/ssl/compatibility/README.html >>> >>> Best regards, >>> John Jiang >>> >>> On 07/09/2017 18:47, sha.jiang at oracle.com wrote: >>>> Hi Artem, >>>> >>>> On 07/09/2017 16:28, Artem Smotrakov wrote: >>>>> In case of SNI, SSLParemeters.setServerNames() method (and others >>>>> related to SNI) was introduced in 8. I don't think the code which >>>>> use this method can be compiled with 6 and 7. >>>> All of Java source are compiled by a JDK 10 build, which is >>>> specified by jtreg option "-jdk". Other testing JDKs, including 6 >>>> and 7, just use the .class files on runtime. >>>> That's why the below line exists in Compatibility.java, >>>> 32? * @compile -source 1.6 -target 1.6 Server.java Client.java >>>> JdkUtils.java >>>>> >>>>> But if you want to test SNI with 8+, you need to call them. >>>>> >>>>> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLParameters.html#setServerNames-java.util.List- >>>>> >>>> If a feature, like ALPN and SNI, is not supported, such method >>>> would not be called on runtime. >>>> >>>> Best regards, >>>> John Jiang >>>>> >>>>> Artem >>>>> >>>>> On 09/07/2017 11:24 AM, sha.jiang at oracle.com wrote: >>>>>> Hi Artem, >>>>>> >>>>>> On 07/09/2017 16:07, Artem Smotrakov wrote: >>>>>>>> >>>>>>>>> - Please use try-with-resources if possible (files, sockets, etc) >>>>>>>> The test uses only JDK 6-supported language features, but >>>>>>>> try-with-resources is introduced by JDK 7. >>>>>>> Here we come to another issue. I believe that it would be good >>>>>>> to use write clients for all JDK versions. If you use the same >>>>>>> code for all Java versions, that means that you use only JDK 6 >>>>>>> API. Let's consider the following: >>>>>>> - we want to test 8 vs 9 >>>>>>> - 8 and 9 may have some API (or just functionality) which is not >>>>>>> supported by 6 (for example, ALPN, SNI) >>>>>>> >>>>>>> If you write code which is compatible with 6, then you can use >>>>>>> API from newer versions, but we still may want to test it. >>>>>> In fact, the current test has already covered ALPN, though only >>>>>> JDK 9 and 10 support the associated methods, like >>>>>> SSLParameters.getApplicationProtocols(). >>>>>> ALPN-associated case combinations are ignored if a JDK doesn't >>>>>> support this feature. Exactly, JdkUtils checks if a specific JDK >>>>>> build contains method SSLParameters.getApplicationProtocols(). >>>>>> I think the same approach could be applied for SNI in the future. >>>>>> >>>>>> Best regards, >>>>>> John Jiang >>>>>>> >>>>>>> Artem >>>>>>>> >>>>>>>> Best regards, >>>>>>>> John Jiang >>>>>>>>> >>>>>>>>> Artem >>>>>>>>> >>>>>>>>> On 09/07/2017 08:52 AM, sha.jiang at oracle.com wrote: >>>>>>>>>> Hi, >>>>>>>>>> Please review this test for checking the interop >>>>>>>>>> compatibility on JSSE among different JDK releases (from 6 to >>>>>>>>>> 10). >>>>>>>>>> It covers the cases, like handshake, data exchange, client >>>>>>>>>> authentication and APLN, on all TLS versions (if possible). >>>>>>>>>> And the selected TLS cipher suites are: >>>>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA, >>>>>>>>>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA and >>>>>>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA. >>>>>>>>>> For more details, please look though the README. >>>>>>>>>> >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8186057/webrev.00 >>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8186057 >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> John Jiang >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > From jason at tedor.me Thu Nov 23 19:21:03 2017 From: jason at tedor.me (Jason Tedor) Date: Thu, 23 Nov 2017 19:21:03 +0000 Subject: Dropping the security manager (was Re: Eliminating the security overhead when not running with a security manager) Message-ID: > Long term then it would be interesting to explore degrading and eventually dropping the security manager but that is beyond the scope of what I would like to discuss here. That is a bold topic to immediately declare out of scope. I am looking for somewhere to reply, so I am forking this thread to a new subject to share my thoughts. I am an engineer on the Elasticsearch team at Elastic. Elasticsearch is a popular server application implemented in Java that runs on the JVM. We run with the security manager enabled, and there is no option to disable it. We have two major motivations for using the security manger: - as a server application, to reduce the scope of any exploits in the JDK, our code, or our third-party dependencies (e.g., prevent directory traversals, prevent RCE, etc.) - we provide a plugin framework (e.g., to add scripting languages) and use the security manager to sandbox untrusted code For additional background, please see the mail thread "SecurityManager environments" on jigsaw-dev[1]. >The bigger question is of course whether it is interesting to run with a security manager in 2017. Of course it is. Java is often used to code servers[no citation needed]. The question should be: what can be done to make using the security manager easier for servers[2]? When looking at the major exploits in the Java ecosystem in the last few years (e.g., the commons collections CVE[3] that led to RCE in e.g., JBoss (among others), the Apache Struts CVE[4] that played a role in the Equifax breach), every time my mind turns to: this would not be as large a problem if the server was using the security manager. The JDK needs to be a platform that enables developing secure server applications. Seeing this question raised without any explicit or implicit mention of this need is surprising. > We have seen a few cases where applications set a security manager in order to enforce some policy, like preventing plugins calling System.exit but these are cases that would be better served with other solutions. We do this[5][6], although we had to wrap the security manager in our own implementation[7] because we still need to be able to exit on our own[8][9]. However: an API to serve this use-case solely is not enough to meet our current needs from the security manager. > A big challenge is the System.setSecurityManager API as allows a security manager to be set in a running VM. We use the System#setSecurityManager API[10][11]. I do not think our use-case is unreasonable: there are privileges that are required upfront, and then we drop them. I am okay with the run mode that you propose (as long as System#setSecurityManager in this run mode is not a no-op but a hard exception), I am not okay with dropping this API entirely (so do not deprecate the System#setSecurityManager API). [1]: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012044.html [2]: https://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf [3]: https://www.cvedetails.com/cve/CVE-2015-6420/ [4]: https://www.cvedetails.com/cve/CVE-2017-5638/ [5]: https://github.com/elastic/securesm/blob/v1.2/src/main/java/org/elasticsearch/SecureSM.java#L75-L83 [6]: https://github.com/elastic/elasticsearch/blob/93a988c557fb4c4a052964d3192a5feb045039ae/core/src/main/java/org/elasticsearch/bootstrap/Security.java#L121-L123 [7]: https://github.com/elastic/securesm [8]: https://github.com/elastic/elasticsearch/blob/v6.0.0/core/src/main/java/org/elasticsearch/bootstrap/ElasticsearchUncaughtExceptionHandler.java [9]: https://github.com/elastic/elasticsearch/blob/v6.0.0/core/src/main/java/org/elasticsearch/cli/Command.java#L150 [10]: https://github.com/elastic/elasticsearch/blob/v6.0.0/core/src/main/java/org/elasticsearch/bootstrap/Elasticsearch.java#L75-L82 [11]: https://github.com/elastic/elasticsearch/blob/v6.0.0/core/src/main/java/org/elasticsearch/bootstrap/Security.java#L122-L123 On Mon, Nov 20, 2017 at 9:48 AM Alan Bateman wrote: > > One of the long standing issues with the security manager support is > that the overhead when there is no security manager is non-zero. Two > specific examples are (i) the overhead of defineClass (assuming the > defining loader is a SecureClassLoader) as it involves a callback to get > the permissions for the protection domain and (ii) the overhead of > AccessController.doPrivileged in order to execute an action on a > privileged stack. > > The bigger question is of course whether it is interesting to run with a > security manager in 2017. It's clearly still important for environments > that download potentially malicious code to execute in a sandox but that > isn't most applications these days. We have seen a few cases where > applications set a security manager in order to enforce some policy, > like preventing plugins calling System.exit but these are cases that > would be better served with other solutions. > > I would like to explore changes to the API and implementation that would > allow us to eliminate some of the overhead when not running with a > security manager. Long term then it would be interesting to explore > degrading and eventually dropping the security manager but that is > beyond the scope of what I would like to discuss here. Sean Mullan and > Jeff Nisewanger ran an interesting BOF at JavaOne 2017 on this topic and > I believe are planning to do a survey at some point to understand the > current usage of the security manager. > > For now I would like to explore what it would take to eliminate some of > the overhead. A big challenge is the System.setSecurityManager API as > allows a security manager to be set in a running VM. This means that > classes loaded before a security manager is set may be involved in > permission checks that happen after a security manager is set. > Similarly, privileged actions may have started before the security > manager is set. The complications around this go away if there was some > way to know that a security manager can never be turned on in a running > system. > > To get started, I've put a prototype of an initial proposal on the cr > site [1]. The summary of the proposal is: > > 1. A "disallow security manager" mode that is opt-in to disallow > setSecurityManager being used to set a security manager in a running VM. > Opt-in means it has not impact on existing code. > > 2. Deprecates setSecurityManager to discourage further usage and allow > for the possibility of making "disallow security manager" the default in > the future. If that were to become the default then it would have no > impact on deployments that set the security manager on the command line > at startup. > > 3. When running in "disallow security manager" mode, > AccessController.doPrivileged invokes actions directly and > SecureClassLoader.defineClass skips the callback to get permissions for > the protection domain. This part helps startup and runtime performance. > > It's important not to get hung up on the details in the webrev, the > important thing is understand if the security folks on this mailing list > are open to a run mode that prevents a security manager being set in a > running system. > > -Alan. > > [1] http://cr.openjdk.java.net/~alanb/8191053/webrev/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Nov 23 19:50:23 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Nov 2017 19:50:23 +0000 Subject: Dropping the security manager (was Re: Eliminating the security overhead when not running with a security manager) In-Reply-To: References: Message-ID: <93dfb848-c9d6-4176-59c8-b417f33d24ad@oracle.com> On 23/11/2017 19:21, Jason Tedor wrote: > > Long term then it would be interesting to explore degrading and > eventually dropping the security manager but that is beyond the scope > of what I would like to discuss here. > > That is a bold topic to immediately declare out of scope. I am looking > for somewhere to reply, so I am forking this thread to a new subject > to share my thoughts. Starting a new thread is fine as it's beyond the scope of the topic that I was looking to discuss. As I mentioned, Sean and Jeff are planning a survey and that would be a good time to bring up use-cases and suggestions. > The JDK needs to be a platform that enables developing secure server > applications. Seeing this question raised without any explicit or > implicit mention of this need is surprising. Sorry, that's a bit unfair as there has been massive effort put into the platform to support the development of secure applications. Security is much more than the security manager. -Alan From jai.forums2013 at gmail.com Fri Nov 24 05:22:29 2017 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 24 Nov 2017 10:52:29 +0530 Subject: [PATCH] JDK-8190917 : SSL session resumption, through handshake, in SSLEngine is broken for any protocols lesser than TLSv1.2 Message-ID: <427ca55d-e619-21e5-d803-4e829007da43@gmail.com> As noted in [1], there's a regression in Java 9, where SSL session resumption no longer works for SSL protocols other than TLSv1.2. The code which is responsible for session resumption resides in the ServerHandshaker[2], in the clientHello method. This method, in its logic to decide whether or not to resume a (previously) cached session, checks if the client hello message has a session id associated. If it does, it then fetches a session from the cache. If it does find a previously cached session for that id, it then goes ahead to check if the SSL protocol associated with the cached session matches with the protocol version that's "applicable/selected" of the incoming client hello message. However, a relatively recent change[3] has, IMO, unintentionally caused the protocol version check logic to fail for protocols other than TLSv1.2. The protocol version check looks like: // cannot resume session with different if (oldVersion != protocolVersion) { resumingSession = false; } The `protocolVersion` variable in this case happens to be a _default initialized value_ (TLSv1.2) instead of the one that's "selected" based on the incoming client hello message. As a result the `protocolVersion` value is always TLSv1.2 and thus for any other protocols, this comparison fails, even when the client hello message uses the right session id and the right protocol that matches the previous session. The attached patch, includes a potential fix to this issue. The change makes sure that the protocol selection, based on the client hello message, is done before this session resumption check and also makes sure it uses that "selected" protocol in the version comparison check instead of the class member `protocolVersion` (which gets set when the server hello message is finally being sent). The attached patch also contains a (jtreg) test case which reproduces this bug and verifies this fix. The test case tests the session resumption against TLSv1, TLSv1.1 and TLSv1.2. The test code itself is a minor modification of the SSL demo that's available here [4]. This is my first OpenJDK patch and my OCA got approved a few days back. Could someone please help with the review of this patch? P.S: I noticed that the JIRA got assigned a few days back. I am not sure if that means the fix is already being worked upon by someone else from the team. If that's the case, then let me know and I'll let it be handled by them. [1] https://bugs.openjdk.java.net/browse/JDK-8190917 [2] http://hg.openjdk.java.net/jdk/jdk/file/b7ae1437111b/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/42268eb6e04e [4] https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sslengine/SSLEngineSimpleDemo.java -Jaikiran -------------- next part -------------- # HG changeset patch # User Jaikiran Pai # Date 1511499148 -19800 # Fri Nov 24 10:22:28 2017 +0530 # Node ID b7531135b7382e8368d6135d2bd1f97f25edadba # Parent b7ae1437111b32abbcaeb01c10c52aa376761f83 JDK-8190917 Make sure SSL session resumption works (not just for TLSv1.2) diff --git a/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java b/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java --- a/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java +++ b/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java @@ -568,6 +568,18 @@ } // Otherwise, applicationProtocol will be set by the callback. session = null; // forget about the current session + clientRequestedVersion = mesg.protocolVersion; + + // select a proper protocol version. + final ProtocolVersion selectedVersion = + selectProtocolVersion(clientRequestedVersion); + if (selectedVersion == null || + selectedVersion.v == ProtocolVersion.SSL20Hello.v) { + fatalSE(Alerts.alert_handshake_failure, + "Client requested protocol " + clientRequestedVersion + + " not enabled or not supported"); + } + // // Here we go down either of two paths: (a) the fast one, where // the client's asked to rejoin an existing session, and the server @@ -592,7 +604,7 @@ if (resumingSession) { ProtocolVersion oldVersion = previous.getProtocolVersion(); // cannot resume session with different version - if (oldVersion != protocolVersion) { + if (oldVersion != selectedVersion) { resumingSession = false; } } @@ -709,18 +721,6 @@ */ ServerHello m1 = new ServerHello(); - clientRequestedVersion = mesg.protocolVersion; - - // select a proper protocol version. - ProtocolVersion selectedVersion = - selectProtocolVersion(clientRequestedVersion); - if (selectedVersion == null || - selectedVersion.v == ProtocolVersion.SSL20Hello.v) { - fatalSE(Alerts.alert_handshake_failure, - "Client requested protocol " + clientRequestedVersion + - " not enabled or not supported"); - } - handshakeHash.protocolDetermined(selectedVersion); setVersion(selectedVersion); diff --git a/test/jdk/sun/security/ssl/SessionResumption/SSLSessionResumption.java b/test/jdk/sun/security/ssl/SessionResumption/SSLSessionResumption.java new file mode 100644 --- /dev/null +++ b/test/jdk/sun/security/ssl/SessionResumption/SSLSessionResumption.java @@ -0,0 +1,371 @@ +/* + * Copyright (c) 2015, 2017, 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import javax.net.ssl.KeyManagerFactory; +import javax.net.ssl.SSLContext; +import javax.net.ssl.SSLEngine; +import javax.net.ssl.SSLEngineResult; +import javax.net.ssl.SSLEngineResult.HandshakeStatus; +import javax.net.ssl.SSLSession; +import javax.net.ssl.TrustManagerFactory; +import java.io.FileInputStream; +import java.nio.ByteBuffer; +import java.security.KeyStore; +import java.util.Arrays; +import java.util.HashSet; +import java.util.Set; + +/* + * @test + * @bug 8190917 + * @summary Verify that SSL session resumption works for all SSL protocols + * @run main SSLSessionResumption + */ +public class SSLSessionResumption { + + private static final boolean debug = false; + private static String pathToStores = "../../../../javax/net/ssl/etc"; + private static String keyStoreFile = "keystore"; + private static String trustStoreFile = "truststore"; + private static String passwd = "passphrase"; + + private static String keyFilename = + System.getProperty("test.src", "./") + "/" + pathToStores + + "/" + keyStoreFile; + private static String trustFilename = + System.getProperty("test.src", "./") + "/" + pathToStores + + "/" + trustStoreFile; + + + private final String sslProtocol; + private final SSLContext sslc; + + private SSLEngine clientEngine; // client Engine + private ByteBuffer clientOut; // write side of clientEngine + private ByteBuffer clientIn; // read side of clientEngine + + private SSLEngine serverEngine; // server Engine + private ByteBuffer serverOut; // write side of serverEngine + private ByteBuffer serverIn; // read side of serverEngine + + private ByteBuffer cTOs; // client->server + private ByteBuffer sTOc; // server->client + + + private byte[] previousSessionId; // session id of a previous established SSL session + + + private SSLSessionResumption(final String sslProtocol) throws Exception { + this.sslProtocol = sslProtocol; + + final KeyStore ks = KeyStore.getInstance("JKS"); + final KeyStore ts = KeyStore.getInstance("JKS"); + final char[] passphrase = passwd.toCharArray(); + + ks.load(new FileInputStream(keyFilename), passphrase); + ts.load(new FileInputStream(trustFilename), passphrase); + + final KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509"); + kmf.init(ks, passphrase); + + final TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509"); + tmf.init(ts); + + final SSLContext sslCtx = SSLContext.getInstance(this.sslProtocol); + sslCtx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null); + + this.sslc = sslCtx; + } + + public static void main(final String[] args) throws Exception { + // for each of these protocols we run the session resumption test + // individually + final String[] protocols = new String[]{"TLSv1", "TLSv1.1", "TLSv1.2"}; + final Set failedProtocols = new HashSet(); + for (final String protocol : protocols) { + final SSLSessionResumption test = new SSLSessionResumption(protocol); + // verify that the session resumption works + if (!test.verifySessionResumption()) { + failedProtocols.add(protocol); + } + } + if (!failedProtocols.isEmpty()) { + throw new Exception("SSL session resumption failed for protocols " + failedProtocols); + } + } + + /** + * Uses {@link SSLEngine} in the context of a {@link SSLContext} to do some SSL backed + * communication and verifies that the communication reuses a session + * + * @return Returns true if the SSL session was reused. False otherwise + * @throws Exception + */ + private boolean verifySessionResumption() throws Exception { + try { + for (int i = 0; i < 2; i++) { + log("Starting SSL communication " + (i + 1) + " using protocol " + this.sslProtocol); + this.doSSLCommunication(); + } + } catch (SessionIdMisMatchException e) { + return false; + } + return true; + } + + + private void doSSLCommunication() throws Exception { + boolean dataDone = false; + + createSSLEngines(); + createBuffers(); + + SSLEngineResult clientResult; // results from client's last operation + SSLEngineResult serverResult; // results from server's last operation + + /* + * Examining the SSLEngineResults could be much more involved, + * and may alter the overall flow of the application. + * + * For example, if we received a BUFFER_OVERFLOW when trying + * to write to the output pipe, we could reallocate a larger + * pipe, but instead we wait for the peer to drain it. + */ + while (!isEngineClosed(clientEngine) || + !isEngineClosed(serverEngine)) { + + log("================"); + + clientResult = clientEngine.wrap(clientOut, cTOs); + if (clientResult.getHandshakeStatus() == HandshakeStatus.FINISHED) { + assertSessionId(this.previousSessionId, clientEngine); + this.previousSessionId = clientEngine.getSession().getId(); + } + log("client wrap: ", clientResult); + runDelegatedTasks(clientResult, clientEngine); + + serverResult = serverEngine.wrap(serverOut, sTOc); + log("server wrap: ", serverResult); + runDelegatedTasks(serverResult, serverEngine); + + cTOs.flip(); + sTOc.flip(); + + log("----"); + + clientResult = clientEngine.unwrap(sTOc, clientIn); + if (clientResult.getHandshakeStatus() == HandshakeStatus.FINISHED) { + assertSessionId(this.previousSessionId, clientEngine); + this.previousSessionId = clientEngine.getSession().getId(); + } + log("client unwrap: ", clientResult); + runDelegatedTasks(clientResult, clientEngine); + + serverResult = serverEngine.unwrap(cTOs, serverIn); + log("server unwrap: ", serverResult); + runDelegatedTasks(serverResult, serverEngine); + + cTOs.compact(); + sTOc.compact(); + + /* + * After we've transfered all application data between the client + * and server, we close the clientEngine's outbound stream. + * This generates a close_notify handshake message, which the + * server engine receives and responds by closing itself. + * + * In normal operation, each SSLEngine should call + * closeOutbound(). To protect against truncation attacks, + * SSLEngine.closeInbound() should be called whenever it has + * determined that no more input data will ever be + * available (say a closed input stream). + */ + if (!dataDone && (clientOut.limit() == serverIn.position()) && + (serverOut.limit() == clientIn.position())) { + + /* + * A sanity check to ensure we got what was sent. + */ + checkTransfer(serverOut, clientIn); + checkTransfer(clientOut, serverIn); + + log("\tClosing clientEngine's *OUTBOUND*..."); + clientEngine.closeOutbound(); + // serverEngine.closeOutbound(); + dataDone = true; + } + } + } + + /* + * Using the SSLContext created during object creation, + * create/configure the SSLEngines we'll use for this demo. + */ + private void createSSLEngines() throws Exception { + /* + * Configure the serverEngine to act as a server in the SSL/TLS + * handshake. + */ + serverEngine = sslc.createSSLEngine(); + serverEngine.setUseClientMode(false); + serverEngine.setNeedClientAuth(false); + + /* + * Similar to above, but using client mode instead. + */ + clientEngine = sslc.createSSLEngine("client", 80); + clientEngine.setUseClientMode(true); + } + + /* + * Create and size the buffers appropriately. + */ + private void createBuffers() { + + /* + * We'll assume the buffer sizes are the same + * between client and server. + */ + SSLSession session = clientEngine.getSession(); + int appBufferMax = session.getApplicationBufferSize(); + int netBufferMax = session.getPacketBufferSize(); + + /* + * We'll make the input buffers a bit bigger than the max needed + * size, so that unwrap()s following a successful data transfer + * won't generate BUFFER_OVERFLOWS. + * + * We'll use a mix of direct and indirect ByteBuffers for + * tutorial purposes only. In reality, only use direct + * ByteBuffers when they give a clear performance enhancement. + */ + clientIn = ByteBuffer.allocate(appBufferMax + 50); + serverIn = ByteBuffer.allocate(appBufferMax + 50); + + cTOs = ByteBuffer.allocateDirect(netBufferMax); + sTOc = ByteBuffer.allocateDirect(netBufferMax); + + clientOut = ByteBuffer.wrap("JDK-8190917 : Hi Server, I'm Client".getBytes()); + serverOut = ByteBuffer.wrap("JDK-8190917 : Hello Client, I'm Server".getBytes()); + } + + /* + * If the result indicates that we have outstanding tasks to do, + * go ahead and run them in this thread. + */ + private static void runDelegatedTasks(final SSLEngineResult result, + final SSLEngine engine) throws Exception { + + if (result.getHandshakeStatus() == HandshakeStatus.NEED_TASK) { + Runnable runnable; + while ((runnable = engine.getDelegatedTask()) != null) { + log("\trunning delegated task..."); + runnable.run(); + } + final HandshakeStatus hsStatus = engine.getHandshakeStatus(); + if (hsStatus == HandshakeStatus.NEED_TASK) { + throw new Exception( + "handshake shouldn't need additional tasks"); + } + log("\tnew HandshakeStatus: " + hsStatus); + } + } + + private static boolean isEngineClosed(SSLEngine engine) { + return (engine.isOutboundDone() && engine.isInboundDone()); + } + + /* + * Simple check to make sure everything came across as expected. + */ + private static void checkTransfer(ByteBuffer a, ByteBuffer b) + throws Exception { + a.flip(); + b.flip(); + + if (!a.equals(b)) { + throw new Exception("Data didn't transfer cleanly"); + } else { + log("\tData transferred cleanly"); + } + + a.position(a.limit()); + b.position(b.limit()); + a.limit(a.capacity()); + b.limit(b.capacity()); + } + + private static void assertSessionId(final byte[] expected, final SSLEngine engine) throws SessionIdMisMatchException { + if (expected == null) { + // we haven't yet created a session previously, so there isn't any + // session to be expected to resume + return; + } + final byte[] sessionId = engine.getSession().getId(); + // compare and verify if they are same + if (!java.util.Arrays.equals(expected, sessionId)) { + throw new SessionIdMisMatchException(expected, sessionId); + } + } + + private static boolean resultOnce = true; + + private static void log(final String str, final SSLEngineResult result) { + if (!debug) { + return; + } + if (resultOnce) { + resultOnce = false; + log("The format of the SSLEngineResult is: \n" + + "\t\"getStatus() / getHandshakeStatus()\" +\n" + + "\t\"bytesConsumed() / bytesProduced()\"\n"); + } + final HandshakeStatus hsStatus = result.getHandshakeStatus(); + log(str + + result.getStatus() + "/" + hsStatus + ", " + + result.bytesConsumed() + "/" + result.bytesProduced() + + " bytes"); + if (hsStatus == HandshakeStatus.FINISHED) { + log("\t...ready for application data"); + } + } + + private static void log(final String message) { + if (debug) { + System.out.println(message); + } + } + + private static final class SessionIdMisMatchException extends Exception { + + private final byte[] expected; + private final byte[] actual; + + private SessionIdMisMatchException(final byte[] expected, final byte[] actual) { + super("SSL session id mismatch - expected " + Arrays.toString(expected) + " actual " + Arrays.toString(actual)); + this.expected = expected; + this.actual = actual; + } + } + +} \ No newline at end of file From sha.jiang at oracle.com Fri Nov 24 05:57:53 2017 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 24 Nov 2017 13:57:53 +0800 Subject: RFR[10] 8186057: TLS interoperability testing between different Java versions In-Reply-To: <54542382-5c9f-eb51-12b5-8e02e7c5e643@oracle.com> References: <12833c7c-3b34-3d8a-77ee-9299e8cca88d@oracle.com> <05d9da98-205a-887d-ad88-c88b15832947@oracle.com> <7fcc23e3-dd4e-d127-0cc2-f4990fb5d665@oracle.com> <894241da-b4d7-46ce-2962-c3e6e9a2227b@oracle.com> <1e8d1acf-7f06-9e08-5a48-a65751586471@oracle.com> <927b4361-5147-a385-7db6-05f68ee09ed2@oracle.com> <66551e18-e4f8-7209-e325-81b28cb16d21@oracle.com> <54542382-5c9f-eb51-12b5-8e02e7c5e643@oracle.com> Message-ID: <237b0b1d-cd71-f674-4ac3-ef625c2f917f@oracle.com> Hi Artem, The test is updated again: http://cr.openjdk.java.net/~jjiang/8186057/webrev.06/ The report table is decorated. And please see more comments inline. On 24/11/2017 01:06, Artem wrote: > Hi John, > > A couple of more (probably minor) comments. Addressing them might > simplify the code and make it more readable. Although, one might argue > with it. So, feel free to ignore them. The only thing which I would > like to clarify is the questing about timeouts below. > > I see you use multi-lined boolean expressions and ternary operators > (especially when they are long). It might make the code shorter, but I > believe in most cases it doesn't make it more readable. If not using ternary operator (conditional operator), it has to use if-else block. That would not be better. Especially, I don't use complex expressions with conditional operator. And the coding indent should comply with our convention. > > If you really want to make the code shorter (I don't think it should > be the goal), you can also consider dropping "else" blocks if you just > return values. String (String arg) { ??? if (args.equals("foo")) { ??????? return 'F'; ??? } else if (args.equals("bar")) { ??????? return "B"; ??? } else { ??????? return ""; ??? } } Do you mean change the above codes to the below style? String (String arg) { ??? if (args.equals("foo")) { ??????? return 'F'; ??? } else if (args.equals("bar")) { ??????? return "B"; ??? } ??? return ""; } Frankly, I'm not sure which one is better. > > I would also avoid implicit converting an integer to a string by > concatenation of the integer with an empty string. You can use > String.valueOf() instead. If that, do you suggest to change the following codes (in Compatibility.java) to use String.valueOf() for boolean values? ?101???????????????? props.put(Utils.PROP_SUPPORTS_SNI_ON_SERVER, ?102???????????????????????? serverJdk.supportsSNI + ""); ?103???????????????? props.put(Utils.PROP_SUPPORTS_ALPN_ON_SERVER, ?104???????????????????????? serverJdk.supportsALPN + ""); Here, serverJdk.supportsSNI and serverJdk.supportsALPN are boolean values. ?128???????????????????? props.put(Utils.PROP_PORT, port + ""); Here, port is an integer, but many existing JDK codes just use [port + ""] instead of [String.valueOf(port)]. > > Please also see inline. > > > On 11/23/2017 04:54 PM, sha.jiang at oracle.com wrote: >>> Hi John, >>> >>> Could you please upload the report to >>> http://cr.openjdk.java.net/~jjiang/8186057 ? >> http://cr.openjdk.java.net/~jjiang/8186057/webrev.05/report/report.html > Thank you. It might be better to add some space between columns. I add a style for the table and make it more friendly. http://cr.openjdk.java.net/~jjiang/8186057/webrev.06/report/report.html >>> >>> One question about Compatibility.caseStatus(). What's the case when >>> you expect a timeout and no client output? Should it always result >>> to a test case failure? >> I'm not sure understanding your question. Did you mean server or >> client timeout? >> I think client should output something. > My questing is - should timeout be always considered as a failure? Why > don't you just check if server or client result is FAIL? > > if (clientStatus == FAIL || serverStatus == FAIL) { > ??? return FAIL; > } > > return PASS; Some cases are negative cases, their status should be EXPECTED_FAIL. A server or client timeout would lead to the case to fail, if the failure is not expected. If a server starts normally, but client doesn't start due to a negative case, the server should get timeout. But this failure is expected. If a server starts normally, and client get a unexpected timeout, this failure would make the case to fail. >> >>> >>> Otherwise, looks fine to me. >>> >>> A couple of minor comments which you may want to address: >>> >>> 4. "sequence" field of JdkRelease looks redundant. A enum already >>> defines the order. The same with Protocol. >> It looks the ordinal of enum constants is not recommended [1]. >> >> [1] >> https://docs.oracle.com/javase/9/docs/api/java/lang/Enum.html#ordinal-- > I don't see that it says that using "ordinal" is not recommended. I > think "sequence" just duplicates of? "ordinal". The following words are copied from the description of method Enum.ordinal(): "Most programmers will have no use for this method. It is designed for use by sophisticated enum-based data structures, such as EnumSet and EnumMap." In addition, Effective Java (2nd) Item #33 also advise us not using ordinal index. Best regards, John Jiang From artem.smotrakov at oracle.com Fri Nov 24 09:56:52 2017 From: artem.smotrakov at oracle.com (Artem) Date: Fri, 24 Nov 2017 12:56:52 +0300 Subject: RFR[10] 8186057: TLS interoperability testing between different Java versions In-Reply-To: <237b0b1d-cd71-f674-4ac3-ef625c2f917f@oracle.com> References: <12833c7c-3b34-3d8a-77ee-9299e8cca88d@oracle.com> <05d9da98-205a-887d-ad88-c88b15832947@oracle.com> <7fcc23e3-dd4e-d127-0cc2-f4990fb5d665@oracle.com> <894241da-b4d7-46ce-2962-c3e6e9a2227b@oracle.com> <1e8d1acf-7f06-9e08-5a48-a65751586471@oracle.com> <927b4361-5147-a385-7db6-05f68ee09ed2@oracle.com> <66551e18-e4f8-7209-e325-81b28cb16d21@oracle.com> <54542382-5c9f-eb51-12b5-8e02e7c5e643@oracle.com> <237b0b1d-cd71-f674-4ac3-ef625c2f917f@oracle.com> Message-ID: <3a47f0b7-811e-0e1b-7207-30b1e312af95@oracle.com> Hi John, Let me skip most of cosmetic/style comments. I think you got my points, I'll let you decide if you want to address them or not. Or, you may want to ask for other's opinions. Let's focus on the question about timeout below. On 11/24/2017 08:57 AM, sha.jiang at oracle.com wrote: >>>> Could you please upload the report to >>>> http://cr.openjdk.java.net/~jjiang/8186057 ? >>> http://cr.openjdk.java.net/~jjiang/8186057/webrev.05/report/report.html >> Thank you. It might be better to add some space between columns. > I add a style for the table and make it more friendly. > http://cr.openjdk.java.net/~jjiang/8186057/webrev.06/report/report.html The report looks much better now, thank you. > >>>> >>>> One question about Compatibility.caseStatus(). What's the case when >>>> you expect a timeout and no client output? Should it always result >>>> to a test case failure? >>> I'm not sure understanding your question. Did you mean server or >>> client timeout? >>> I think client should output something. >> My questing is - should timeout be always considered as a failure? >> Why don't you just check if server or client result is FAIL? >> >> if (clientStatus == FAIL || serverStatus == FAIL) { >> ??? return FAIL; >> } >> >> return PASS; > Some cases are negative cases, their status should be EXPECTED_FAIL. That's fine, I got that. > A server or client timeout would lead to the case to fail, if the > failure is not expected. > If a server starts normally, but client doesn't start due to a > negative case, the server should get timeout. But this failure is > expected. > If a server starts normally, and client get a unexpected timeout, this > failure would make the case to fail. This logic looks unnecessary complex to me. The more complex it is, the more likely we get a bug there. I think TIMEOUT status is not necessary here. If a failure is expected on one side, the other side should fail as well (no matter if it's a timeout or an exception). If I were you, I would simplify this method like this if (client == EXPECTED_FAIL && server == EXPECTED_FAIL) { ??? return EXPECTED_FAIL; } if (client == PASS && server == PASS) { ??? return PASS; } return FAIL; If I am not missing something, the pseudo-code above looks better and simpler. > >>> >>>> >>>> Otherwise, looks fine to me. >>>> >>>> A couple of minor comments which you may want to address: >>>> >>>> 4. "sequence" field of JdkRelease looks redundant. A enum already >>>> defines the order. The same with Protocol. >>> It looks the ordinal of enum constants is not recommended [1]. >>> >>> [1] >>> https://docs.oracle.com/javase/9/docs/api/java/lang/Enum.html#ordinal-- >> I don't see that it says that using "ordinal" is not recommended. I >> think "sequence" just duplicates of? "ordinal". > The following words are copied from the description of method > Enum.ordinal(): > "Most programmers will have no use for this method. It is designed for > use by sophisticated enum-based data structures, such as EnumSet and > EnumMap." I don't think it says that "ordinal" is not recommended to use :) > > In addition, Effective Java (2nd) Item #33 also advise us not using > ordinal index. I respect and appreciate Mr. Bloch's book, but my point is that "ordinal" and "sequence" have exact the same meaning, so "sequence" just duplicates it, and as a result, it looks redundant :) http://hg.openjdk.java.net/jdk10/master/file/be620a591379/src/java.base/share/classes/java/lang/Enum.java#l91 ... ??? private final int ordinal; ... ??? public final int ordinal() { ??????? return ordinal; ??? } ... Artem > > Best regards, > John Jiang From jamil.j.nimeh at oracle.com Mon Nov 27 06:03:47 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sun, 26 Nov 2017 22:03:47 -0800 Subject: KDF API review, round 2 In-Reply-To: <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> Message-ID: <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> > >> >> One additional topic for discussion: Late in the week we talked about >> the current state of the API internally and one item to revisit is >> where the DerivationParameterSpec objects are passed. It was brought >> up by a couple people that it would be better to provide the DPS >> objects pertaining to keys at the time they are called for through >> deriveKey() and deriveKeys() (and possibly deriveData). >> >> Originally we had them all grouped in a List in the init method. One >> reason for needing it up there was to know the total length of >> material to generate.? If we can provide the total length through the >> AlgorithmParameterSpec passed in via init() then things like: >> >> Key deriveKey(DerivationParameterSpec param); >> List deriveKeys(List params); >> >> become possible.? To my eyes at least it does make it more clear what >> DPS you're processing since they're provided at derive time, rather >> than the caller having to keep track in their heads where in the DPS >> list they might be with each successive deriveKey or deriveKeys >> calls.? And I think we could do away with deriveKeys(int), too. > > See above - the key stream is logically produced in its entirety > before any assignment of that stream is made to any cryptographic > objects because the mixins (except for the round differentiator) are > the same for each key stream production round.?? Simply passing in the > total length may not give you the right result if the KDF requires a > per component length (and it should to defeat (5) or it should only > produce a single key). From looking at 800-108, I don't see any place where the KDF needs a per-component length.? It looks like it takes L (total length) as an input and that is applied to each round of the PRF.? HKDF takes L up-front as an input too, though it doesn't use it as an input to the HMAC function itself.? For TLS 1.3 that component length becomes part of the context info (HkdfLabel) through the HKDF-Expand-Label function...and it's only doing one key for a given label which is also part of that context specific info, necessitating an init() call.? Seems like the length can go into the APS provided via init (for those KDFs that need it at least) and you shouldn't need a DPS list up-front. As far as your (5) scenario goes, I can see how you can twiddle the lengths to get the keystream output with zero-length keys and large IV buffers.? But that scenario really glosses over what should be a big hurdle and a major access control issue that stands outside the KDF API: That the attacker shouldn't have access to the input keying material in the first place.? Protect the input keying material properly and their attack cannot be done. I would rather see the DPS provided in the deriveKey.? It couples what you want out with the call that makes the object and it makes a lot more sense to keep those two together than try to remember where in the submitted list of DPS objects you are. > > 95% of the time this will be a call to produce a single key.? 4% of > the time it will be a call to produce multiple keys. Only 1% of the > time will it need to intermix key, data and object productions. > Anybody who is doing that is going to write a wrapper around this > class to make sure they get the key and data production order correct > for each call.? So I'm not all that bothered by keeping the complexity > as a price for keeping flexibility. > > You could have a Key deriveKey(Key k, DerivationParameterSpec param) > for some things like TLS1.3 (where you can only make a single call to > derive key between inits) , but then you'd also need at least a byte[] > deriveData (Key k, DerivationParameterSpec param) and an Object > deriveObject(Key k, DerivationParameterSpec param). I don't think those are necessary.? If you're just doing HKDF-Expand (for the HKDF-Expand-Label TLS 1.3 key derivation) then you can provide the input key, label and max length and any other context info that goes into that HkdfLabel structure...all of that would go into init().? Then provide the key alg and desired length via the DPS at deriveKey time.? Any subsequent keys in the TLS 1.3 key schedule would need a new init call anyway since the labels change and possibly the output length. Over the next day or so I'm going to have to make some final decisions on this API as there are internal projects that are waiting on this API to proceed.? I'm already past the cut-off date I set, but I recognize these discussions are important to have and I appreciate the input you and others have provided. --Jamil From mstjohns at comcast.net Mon Nov 27 18:09:39 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 27 Nov 2017 13:09:39 -0500 Subject: KDF API review, round 2 In-Reply-To: <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> Message-ID: On 11/27/2017 1:03 AM, Jamil Nimeh wrote: > >> >>> >>> One additional topic for discussion: Late in the week we talked >>> about the current state of the API internally and one item to >>> revisit is where the DerivationParameterSpec objects are passed. It >>> was brought up by a couple people that it would be better to provide >>> the DPS objects pertaining to keys at the time they are called for >>> through deriveKey() and deriveKeys() (and possibly deriveData). >>> >>> Originally we had them all grouped in a List in the init method. One >>> reason for needing it up there was to know the total length of >>> material to generate.? If we can provide the total length through >>> the AlgorithmParameterSpec passed in via init() then things like: >>> >>> Key deriveKey(DerivationParameterSpec param); >>> List deriveKeys(List params); >>> >>> become possible.? To my eyes at least it does make it more clear >>> what DPS you're processing since they're provided at derive time, >>> rather than the caller having to keep track in their heads where in >>> the DPS list they might be with each successive deriveKey or >>> deriveKeys calls.? And I think we could do away with >>> deriveKeys(int), too. >> >> See above - the key stream is logically produced in its entirety >> before any assignment of that stream is made to any cryptographic >> objects because the mixins (except for the round differentiator) are >> the same for each key stream production round.?? Simply passing in >> the total length may not give you the right result if the KDF >> requires a per component length (and it should to defeat (5) or it >> should only produce a single key). > From looking at 800-108, I don't see any place where the KDF needs a > per-component length.? It looks like it takes L (total length) as an > input and that is applied to each round of the PRF.? HKDF takes L > up-front as an input too, though it doesn't use it as an input to the > HMAC function itself.? For TLS 1.3 that component length becomes part > of the context info (HkdfLabel) through the HKDF-Expand-Label > function...and it's only doing one key for a given label which is also > part of that context specific info, necessitating an init() call.? > Seems like the length can go into the APS provided via init (for those > KDFs that need it at least) and you shouldn't need a DPS list up-front. > HKDF and SP800-108 only deal with the creation of the key stream and ignore the issues with assigning the key stream to cryptographic objects.? In the TLS version of HDKF, the L value is mandatory and only a single object is assigned per init/call to the KDF.?? An HSM can look at the HKDF label information and set the appropriate policies for the assigned cryptographic object (because if any of the label data changes, the entire key stream changes).? That's not the case for the raw HKDF nor for any KDF that allows for multiple objects to be extracted out of a single key stream.? Hence the per-component length values. Ideally, there should be a complete object spec for each object to be generated that is part of the mixins (label and context) for any KDF.?? That allows an HSM to rely upon the object spec when setting policy controls for each generated object - and incidentally allows for a KDF to generate both public and non-public data in a secure way. So as long as you allow for the specification of all of the production objects as part of the .init() I'm good.?? A given KDF might not require this - but I can't see any way of fixing the current KDFs to work in HSMs without something like this. > As far as your (5) scenario goes, I can see how you can twiddle the > lengths to get the keystream output with zero-length keys and large IV > buffers.? But that scenario really glosses over what should be a big > hurdle and a major access control issue that stands outside the KDF > API: That the attacker shouldn't have access to the input keying > material in the first place.? Protect the input keying material > properly and their attack cannot be done. Let me give you an example.?? I'm running an embedded HSM - to protect TLS keys and to do all of the crypto.? An attacker compromises the TLS server and now has access to the HSM.? No problem - I'm going to notice if the attacker starts extraditing large amounts of data from the server (e.g. copies of the TLS in the clear but possibly reencrypted data stream) so this isn't a threat or is it?? Smart attacker does an extraction attack on the TLS 1.2 and before KDF and turns all of the key stream material into IV material and exports it from the HSM.? The attacker now has the much smaller key material so he can send a few messages with those keys and allow for the passive external interception of the traffic and decryption thereof without the risk of detection of all that traffic being sent.? Alternately, I can place the key material in a picture via steganography and publish it as part of the server data. The idea is to protect extraction of the key material from an HSM _*even from authorized users of that key material*_. ?KDFs don't currently do this well.? Adding the overall length and per component length stuff as well as a per component spec to the data used to derive the key stream means that 1) changes to any of those change the entire key stream, 2) the per component spec data may be used by the security module policy engine to enforce restrictions and 3) because of (1) and (2) calling the KDF a second time gets me exactly the same objects rather than just the same key stream.? The last isn't very important in a software based security domain, but turns out to have real implications for policy enforcing security modules. This gets worse when you realize that the KDF key is under it all either a HASH HMAC or CMAC key and all of those algorithms produce public data.?? Ideally you need a way of preventing a KDF key from calling the raw HASH/HMAC/CMAC functions directly (and vice versa). > > I would rather see the DPS provided in the deriveKey.? It couples what > you want out with the call that makes the object and it makes a lot > more sense to keep those two together than try to remember where in > the submitted list of DPS objects you are. >> >> 95% of the time this will be a call to produce a single key.? 4% of >> the time it will be a call to produce multiple keys. Only 1% of the >> time will it need to intermix key, data and object productions. >> Anybody who is doing that is going to write a wrapper around this >> class to make sure they get the key and data production order correct >> for each call.? So I'm not all that bothered by keeping the >> complexity as a price for keeping flexibility. >> >> You could have a Key deriveKey(Key k, DerivationParameterSpec param) >> for some things like TLS1.3 (where you can only make a single call to >> derive key between inits) , but then you'd also need at least a >> byte[] deriveData (Key k, DerivationParameterSpec param) and an >> Object deriveObject(Key k, DerivationParameterSpec param). > I don't think those are necessary.? If you're just doing HKDF-Expand > (for the HKDF-Expand-Label TLS 1.3 key derivation) then you can > provide the input key, label and max length and any other context info > that goes into that HkdfLabel structure...all of that would go into > init().? Then provide the key alg and desired length via the DPS at > deriveKey time.? Any subsequent keys in the TLS 1.3 key schedule would > need a new init call anyway since the labels change and possibly the > output length. > > Over the next day or so I'm going to have to make some final decisions > on this API as there are internal projects that are waiting on this > API to proceed.? I'm already past the cut-off date I set, but I > recognize these discussions are important to have and I appreciate the > input you and others have provided. > > --Jamil > Reading this last I think I've lost the context.?? Here's where I think we are: 1) Get instance gets the default configuration of a given KDF (and that default will be attached to the instance name defintion) 2) .setParameter() may be used to update the KDF configuration - once. 3) .init() takes at least the key, it may optionally take a set of derivation parameters.?? The derivation parameters provided in .init() are intended for use in forming the label and context mixins for the KDF.?? They may provide - for example - the total length of the key stream, the objects to be derived, the length of the objects, protection parameters for each of the objects etc. 4) A kdf generate a free-running or fixed length key stream depending on the derivation parameters (e.g. if "L" is not a mixin to the KDF then it is free-running and may produce as much key stream as desired or if the production object specifications are not part of the derivation mixins). Doing (4) is mostly not a good idea, but someone might want to do this.?? In that case it may make the most sense to just allow them to do deriveData(int length) calls as the only function (a keyed PRNG basically). Re the last version of your api - if you add the .setParameter() .getParameter() calls to both KeyDerivation and KeyDerivationSpi I think I'm happy with this part of the API.? I'm wondering if we should talk about KeyAgreement though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Mon Nov 27 19:16:30 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 27 Nov 2017 11:16:30 -0800 Subject: KDF API review, round 2 In-Reply-To: References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> Message-ID: On 11/27/2017 10:09 AM, Michael StJohns wrote: > On 11/27/2017 1:03 AM, Jamil Nimeh wrote: >> >>> >>>> >>>> One additional topic for discussion: Late in the week we talked >>>> about the current state of the API internally and one item to >>>> revisit is where the DerivationParameterSpec objects are passed. It >>>> was brought up by a couple people that it would be better to >>>> provide the DPS objects pertaining to keys at the time they are >>>> called for through deriveKey() and deriveKeys() (and possibly >>>> deriveData). >>>> >>>> Originally we had them all grouped in a List in the init method. >>>> One reason for needing it up there was to know the total length of >>>> material to generate.? If we can provide the total length through >>>> the AlgorithmParameterSpec passed in via init() then things like: >>>> >>>> Key deriveKey(DerivationParameterSpec param); >>>> List deriveKeys(List params); >>>> >>>> become possible.? To my eyes at least it does make it more clear >>>> what DPS you're processing since they're provided at derive time, >>>> rather than the caller having to keep track in their heads where in >>>> the DPS list they might be with each successive deriveKey or >>>> deriveKeys calls.? And I think we could do away with >>>> deriveKeys(int), too. >>> >>> See above - the key stream is logically produced in its entirety >>> before any assignment of that stream is made to any cryptographic >>> objects because the mixins (except for the round differentiator) are >>> the same for each key stream production round.?? Simply passing in >>> the total length may not give you the right result if the KDF >>> requires a per component length (and it should to defeat (5) or it >>> should only produce a single key). >> From looking at 800-108, I don't see any place where the KDF needs a >> per-component length.? It looks like it takes L (total length) as an >> input and that is applied to each round of the PRF.? HKDF takes L >> up-front as an input too, though it doesn't use it as an input to the >> HMAC function itself.? For TLS 1.3 that component length becomes part >> of the context info (HkdfLabel) through the HKDF-Expand-Label >> function...and it's only doing one key for a given label which is >> also part of that context specific info, necessitating an init() >> call.? Seems like the length can go into the APS provided via init >> (for those KDFs that need it at least) and you shouldn't need a DPS >> list up-front. >> > > HKDF and SP800-108 only deal with the creation of the key stream and > ignore the issues with assigning the key stream to cryptographic > objects.? In the TLS version of HDKF, the L value is mandatory and > only a single object is assigned per init/call to the KDF.?? An HSM > can look at the HKDF label information and set the appropriate > policies for the assigned cryptographic object (because if any of the > label data changes, the entire key stream changes).? That's not the > case for the raw HKDF nor for any KDF that allows for multiple objects > to be extracted out of a single key stream.? Hence the per-component > length values. > > Ideally, there should be a complete object spec for each object to be > generated that is part of the mixins (label and context) for any > KDF.?? That allows an HSM to rely upon the object spec when setting > policy controls for each generated object - and incidentally allows > for a KDF to generate both public and non-public data in a secure way. > > So as long as you allow for the specification of all of the production > objects as part of the .init() I'm good.?? A given KDF might not > require this - but I can't see any way of fixing the current KDFs to > work in HSMs without something like this. > >> As far as your (5) scenario goes, I can see how you can twiddle the >> lengths to get the keystream output with zero-length keys and large >> IV buffers.? But that scenario really glosses over what should be a >> big hurdle and a major access control issue that stands outside the >> KDF API: That the attacker shouldn't have access to the input keying >> material in the first place.? Protect the input keying material >> properly and their attack cannot be done. > > Let me give you an example.?? I'm running an embedded HSM - to protect > TLS keys and to do all of the crypto.? An attacker compromises the TLS > server and now has access to the HSM.? No problem - I'm going to > notice if the attacker starts extraditing large amounts of data from > the server (e.g. copies of the TLS in the clear but possibly > reencrypted data stream) so this isn't a threat or is it?? Smart > attacker does an extraction attack on the TLS 1.2 and before KDF and > turns all of the key stream material into IV material and exports it > from the HSM.? The attacker now has the much smaller key material so > he can send a few messages with those keys and allow for the passive > external interception of the traffic and decryption thereof without > the risk of detection of all that traffic being sent.? Alternately, I > can place the key material in a picture via steganography and publish > it as part of the server data. > > The idea is to protect extraction of the key material from an HSM > _*even from authorized users of that key material*_. > > ?KDFs don't currently do this well.? Adding the overall length and per > component length stuff as well as a per component spec to the data > used to derive the key stream means that 1) changes to any of those > change the entire key stream, 2) the per component spec data may be > used by the security module policy engine to enforce restrictions and > 3) because of (1) and (2) calling the KDF a second time gets me > exactly the same objects rather than just the same key stream.? The > last isn't very important in a software based security domain, but > turns out to have real implications for policy enforcing security modules. > > This gets worse when you realize that the KDF key is under it all > either a HASH HMAC or CMAC key and all of those algorithms produce > public data.?? Ideally you need a way of preventing a KDF key from > calling the raw HASH/HMAC/CMAC functions directly (and vice versa). > >> >> I would rather see the DPS provided in the deriveKey.? It couples >> what you want out with the call that makes the object and it makes a >> lot more sense to keep those two together than try to remember where >> in the submitted list of DPS objects you are. >>> >>> 95% of the time this will be a call to produce a single key. 4% of >>> the time it will be a call to produce multiple keys. Only 1% of the >>> time will it need to intermix key, data and object productions. >>> Anybody who is doing that is going to write a wrapper around this >>> class to make sure they get the key and data production order >>> correct for each call.? So I'm not all that bothered by keeping the >>> complexity as a price for keeping flexibility. >>> >>> You could have a Key deriveKey(Key k, DerivationParameterSpec param) >>> for some things like TLS1.3 (where you can only make a single call >>> to derive key between inits) , but then you'd also need at least a >>> byte[] deriveData (Key k, DerivationParameterSpec param) and an >>> Object deriveObject(Key k, DerivationParameterSpec param). >> I don't think those are necessary.? If you're just doing HKDF-Expand >> (for the HKDF-Expand-Label TLS 1.3 key derivation) then you can >> provide the input key, label and max length and any other context >> info that goes into that HkdfLabel structure...all of that would go >> into init().? Then provide the key alg and desired length via the DPS >> at deriveKey time.? Any subsequent keys in the TLS 1.3 key schedule >> would need a new init call anyway since the labels change and >> possibly the output length. >> >> Over the next day or so I'm going to have to make some final >> decisions on this API as there are internal projects that are waiting >> on this API to proceed.? I'm already past the cut-off date I set, but >> I recognize these discussions are important to have and I appreciate >> the input you and others have provided. >> >> --Jamil >> > > Reading this last I think I've lost the context.?? Here's where I > think we are: > > 1) Get instance gets the default configuration of a given KDF (and > that default will be attached to the instance name defintion) > 2) .setParameter() may be used to update the KDF configuration - once. I thought that we had ditched setParameter in favor of putting these parameters in getInstance.? IIRC we were headed toward an algorithm naming convention of /, plus APS in the getInstance (which may be null (and might be for most KDFs that we start with: HKDF and possibly TLS-PRF). For those I could see naming conventions: HKDF would need a PRF specifier, so HKDF/HmacSHA256, HKDF/HmacSHA384.? Basically for that PRF field I want to see values that line up with Mac algorthms in the standard names document. TLS-PRF would probably allow a default "TLS-PRF" would be TLS-PRF used in 1.1 and earlier.? "TLS-PRF/SHA256" would be P_SHA256 from RFC 5246.? Or we could make it also follow the Mac standard name, so "TLS-PRF/HmacSHA256".? I'm fine with that too.? Basically each implementation > 3) .init() takes at least the key, it may optionally take a set of > derivation parameters.?? The derivation parameters provided in .init() > are intended for use in forming the label and context mixins for the > KDF.?? They may provide - for example - the total length of the key > stream, the objects to be derived, the length of the objects, > protection parameters for each of the objects etc. Okay.? I think you've made a pretty strong case for the DerivationParameterSpec objects up-front. > 4) A kdf generate a free-running or fixed length key stream depending > on the derivation parameters (e.g. if "L" is not a mixin to the KDF > then it is free-running and may produce as much key stream as desired > or if the production object specifications are not part of the > derivation mixins). > > Doing (4) is mostly not a good idea, but someone might want to do > this.?? In that case it may make the most sense to just allow them to > do deriveData(int length) calls as the only function (a keyed PRNG > basically). There's a couple ways we could do this: byte[] deriveData(int length); int deriveData(byte[] buf, int offset, int length); I don't think we'll add these for this release of the KDF API.? It's easier to add these types of calls later if we need to than it is to have these extra forms for a KDF use-case that is "mostly not a good idea". > > Re the last version of your api - if you add the .setParameter() > .getParameter() calls to both KeyDerivation and KeyDerivationSpi I > think I'm happy with this part of the API.? I'm wondering if we should > talk about KeyAgreement though See above with respect to set/getParameter.? But hopefully you'll be happy with the API after this next round.? I have one other change I will be making.? I'm removing deriveObject.? I'm uncomfortable right now with the idea of the API executing an arbitrary class' constructor.? This is something I'm definitely willing to examine in the future once the most pressing tasks both with this API, and projects that are immediately depending on it are take care of.? It is easier to add calls to the API than it is to remove/modify/deprecate them if there's a problem.? I will file an RFE so that we can track this enhancement. Modifications to the KeyAgreement API are beyond the scope of this JEP.? We can certainly discuss ideas you have, but this KDF JEP isn't going to be dependent on those discussions. --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Mon Nov 27 19:29:01 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 27 Nov 2017 11:29:01 -0800 Subject: KDF API review, round 2 In-Reply-To: References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> Message-ID: <5c43864f-0482-74b3-8f45-d4a4a1b310be@oracle.com> On 11/27/2017 11:16 AM, Jamil Nimeh wrote: > I thought that we had ditched setParameter in favor of putting these > parameters in getInstance.? IIRC we were headed toward an algorithm > naming convention of /, plus APS in the getInstance (which may > be null (and might be for most KDFs that we start with: HKDF and > possibly TLS-PRF). > > For those I could see naming conventions: > HKDF would need a PRF specifier, so HKDF/HmacSHA256, HKDF/HmacSHA384. > Basically for that PRF field I want to see values that line up with Mac > algorthms in the standard names document. > TLS-PRF would probably allow a default "TLS-PRF" would be TLS-PRF used > in 1.1 and earlier.? "TLS-PRF/SHA256" would be P_SHA256 from RFC 5246. > Or we could make it also follow the Mac standard name, so > "TLS-PRF/HmacSHA256".? I'm fine with that too.? Basically each > implementation When the naming convention first came up, I never got around to replying. I think it would be better to specify the KDF and PRF as separate parameters. I don't think it's worth creating an naming convention given what we have/are experiencing with Cipher transformations, it's simpler to spell out each one separately. Tony From mstjohns at comcast.net Mon Nov 27 19:46:40 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 27 Nov 2017 14:46:40 -0500 Subject: KDF API review, round 2 In-Reply-To: References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> Message-ID: <10ef9287-a475-d6aa-030d-2819c9d3b0a5@comcast.net> On 11/27/2017 2:16 PM, Jamil Nimeh wrote: > See above with respect to set/getParameter.? But hopefully you'll be > happy with the API after this next round.? I have one other change I > will be making.? I'm removing deriveObject.? I'm uncomfortable right > now with the idea of the API executing an arbitrary class' > constructor.? This is something I'm definitely willing to examine in > the future once the most pressing tasks both with this API, and > projects that are immediately depending on it are take care of. It is > easier to add calls to the API than it is to remove/modify/deprecate > them if there's a problem.? I will file an RFE so that we can track > this enhancement. > > Modifications to the KeyAgreement API are beyond the scope of this > JEP.? We can certainly discuss ideas you have, but this KDF JEP isn't > going to be dependent on those discussions. Fair enough. The deriveObject stuff is a problem because it doesn't fit well in the JCA.? Mostly we've got KeyGenerator/KeyPairGenerator/KeyFactory that produce objects of a particular provider.? KeyDerivation is weird in that one provider will be producing the derived key stream and potentially others might need to provide key or cryptographic objects from that stream.?? I can see the point in delaying this to a later rev though it might make something like [KDF is Bouncycastle, keys are PKCS11] a bit difficult to work around. Last one - Can I get you to buy into a MasterKey/MasterKeySpec? that is not a sub class of SecretKey but has the same characteristics (and probably the same definitions) as those classes (and is what gets used in the .init() argument)?? This goes back to trying to prevent a SecretKey from being used both with a KDF and the underlying PRF of the KDF.? I know this is a don't care for software based providers but would be useful for security module based ones. I'm really hoping to improve cryptographic type and use safety along the way. Thanks - Mike From jamil.j.nimeh at oracle.com Mon Nov 27 22:23:51 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 27 Nov 2017 14:23:51 -0800 Subject: KDF API review, round 2 In-Reply-To: <10ef9287-a475-d6aa-030d-2819c9d3b0a5@comcast.net> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> <10ef9287-a475-d6aa-030d-2819c9d3b0a5@comcast.net> Message-ID: <3545e92b-5f70-84ca-cac9-a73749c26ef9@oracle.com> On 11/27/2017 11:46 AM, Michael StJohns wrote: > On 11/27/2017 2:16 PM, Jamil Nimeh wrote: >> See above with respect to set/getParameter.? But hopefully you'll be >> happy with the API after this next round.? I have one other change I >> will be making.? I'm removing deriveObject.? I'm uncomfortable right >> now with the idea of the API executing an arbitrary class' >> constructor.? This is something I'm definitely willing to examine in >> the future once the most pressing tasks both with this API, and >> projects that are immediately depending on it are take care of. It is >> easier to add calls to the API than it is to remove/modify/deprecate >> them if there's a problem.? I will file an RFE so that we can track >> this enhancement. >> >> Modifications to the KeyAgreement API are beyond the scope of this >> JEP.? We can certainly discuss ideas you have, but this KDF JEP isn't >> going to be dependent on those discussions. > > > Fair enough. > > The deriveObject stuff is a problem because it doesn't fit well in the > JCA.? Mostly we've got KeyGenerator/KeyPairGenerator/KeyFactory that > produce objects of a particular provider.? KeyDerivation is weird in > that one provider will be producing the derived key stream and > potentially others might need to provide key or cryptographic objects > from that stream.?? I can see the point in delaying this to a later > rev though it might make something like [KDF is Bouncycastle, keys are > PKCS11] a bit difficult to work around. > > Last one - > > Can I get you to buy into a MasterKey/MasterKeySpec? that is not a sub > class of SecretKey but has the same characteristics (and probably the > same definitions) as those classes (and is what gets used in the > .init() argument)?? This goes back to trying to prevent a SecretKey > from being used both with a KDF and the underlying PRF of the KDF.? I > know this is a don't care for software based providers but would be > useful for security module based ones. > > I'm really hoping to improve cryptographic type and use safety along > the way. I'm not quite getting what you mean here.? From looking at KDFs described in 800-108, it looks like the key input to the KDF is K_I , and K_I ends up being the seed for each round of the PRF. If that isn't what you're referring to can you explain what you're looking for in more detail? --Jamil _ -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Nov 28 00:12:08 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 28 Nov 2017 08:12:08 +0800 Subject: KDF API review, round 2 In-Reply-To: <3545e92b-5f70-84ca-cac9-a73749c26ef9@oracle.com> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> <10ef9287-a475-d6aa-030d-2819c9d3b0a5@comcast.net> <3545e92b-5f70-84ca-cac9-a73749c26ef9@oracle.com> Message-ID: <3E81312A-0EBF-4235-82FC-468FEC4606A5@oracle.com> Very very new to this discussion. If what I say below does not make sense, please ignore it. I'm still finding it uncomfortable to provide _n_ DPSes in initialize() and let user to call deriveKey() _n_ times later. (Or, is this still the preferred way?) If providing all DPSes up-front helps an HSM to emit all keys in a single operation (this is how I understand the reason), do you expect user calling deriveKeys() to get all of them or calling deriveKey() again and again? If the former, we can still put DPS into deriveKey (i.e. deriveKey(DPS) and deriveKeys(DPS[])) and restrict that deriveKey(s) can only be called once with each initialize() so they are not "abused". If user uses this a PRNG, they can always call deriveData() indefinitely. Thanks Max > On Nov 28, 2017, at 6:23 AM, Jamil Nimeh wrote: > > > > On 11/27/2017 11:46 AM, Michael StJohns wrote: >> On 11/27/2017 2:16 PM, Jamil Nimeh wrote: >>> See above with respect to set/getParameter. But hopefully you'll be happy with the API after this next round. I have one other change I will be making. I'm removing deriveObject. I'm uncomfortable right now with the idea of the API executing an arbitrary class' constructor. This is something I'm definitely willing to examine in the future once the most pressing tasks both with this API, and projects that are immediately depending on it are take care of. It is easier to add calls to the API than it is to remove/modify/deprecate them if there's a problem. I will file an RFE so that we can track this enhancement. >>> >>> Modifications to the KeyAgreement API are beyond the scope of this JEP. We can certainly discuss ideas you have, but this KDF JEP isn't going to be dependent on those discussions. >> >> >> Fair enough. >> >> The deriveObject stuff is a problem because it doesn't fit well in the JCA. Mostly we've got KeyGenerator/KeyPairGenerator/KeyFactory that produce objects of a particular provider. KeyDerivation is weird in that one provider will be producing the derived key stream and potentially others might need to provide key or cryptographic objects from that stream. I can see the point in delaying this to a later rev though it might make something like [KDF is Bouncycastle, keys are PKCS11] a bit difficult to work around. >> >> Last one - >> >> Can I get you to buy into a MasterKey/MasterKeySpec that is not a sub class of SecretKey but has the same characteristics (and probably the same definitions) as those classes (and is what gets used in the .init() argument)? This goes back to trying to prevent a SecretKey from being used both with a KDF and the underlying PRF of the KDF. I know this is a don't care for software based providers but would be useful for security module based ones. >> >> I'm really hoping to improve cryptographic type and use safety along the way. > > I'm not quite getting what you mean here. From looking at KDFs described in 800-108, it looks like the key input to the KDF is KI, and KI ends up being the seed for each round of the PRF. If that isn't what you're referring to can you explain what you're looking for in more detail? > > --Jamil From sha.jiang at oracle.com Tue Nov 28 02:35:27 2017 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 28 Nov 2017 10:35:27 +0800 Subject: RFR[10] 8186057: TLS interoperability testing between different Java versions In-Reply-To: <3a47f0b7-811e-0e1b-7207-30b1e312af95@oracle.com> References: <12833c7c-3b34-3d8a-77ee-9299e8cca88d@oracle.com> <05d9da98-205a-887d-ad88-c88b15832947@oracle.com> <7fcc23e3-dd4e-d127-0cc2-f4990fb5d665@oracle.com> <894241da-b4d7-46ce-2962-c3e6e9a2227b@oracle.com> <1e8d1acf-7f06-9e08-5a48-a65751586471@oracle.com> <927b4361-5147-a385-7db6-05f68ee09ed2@oracle.com> <66551e18-e4f8-7209-e325-81b28cb16d21@oracle.com> <54542382-5c9f-eb51-12b5-8e02e7c5e643@oracle.com> <237b0b1d-cd71-f674-4ac3-ef625c2f917f@oracle.com> <3a47f0b7-811e-0e1b-7207-30b1e312af95@oracle.com> Message-ID: <8e682254-28de-0464-f723-a50e332be325@oracle.com> Hi Artem, Please review the new webrev at: http://cr.openjdk.java.net/~jjiang/8186057/webrev.07/ Please see my comments below. >>>>> >>>>> One question about Compatibility.caseStatus(). What's the case >>>>> when you expect a timeout and no client output? Should it always >>>>> result to a test case failure? >>>> I'm not sure understanding your question. Did you mean server or >>>> client timeout? >>>> I think client should output something. >>> My questing is - should timeout be always considered as a failure? >>> Why don't you just check if server or client result is FAIL? >>> >>> if (clientStatus == FAIL || serverStatus == FAIL) { >>> ??? return FAIL; >>> } >>> >>> return PASS; >> Some cases are negative cases, their status should be EXPECTED_FAIL. > That's fine, I got that. >> A server or client timeout would lead to the case to fail, if the >> failure is not expected. >> If a server starts normally, but client doesn't start due to a >> negative case, the server should get timeout. But this failure is >> expected. >> If a server starts normally, and client get a unexpected timeout, >> this failure would make the case to fail. > This logic looks unnecessary complex to me. The more complex it is, > the more likely we get a bug there. I think TIMEOUT status is not > necessary here. If a failure is expected on one side, the other side > should fail as well (no matter if it's a timeout or an exception). > > If I were you, I would simplify this method like this > > if (client == EXPECTED_FAIL && server == EXPECTED_FAIL) { > ??? return EXPECTED_FAIL; > } > > if (client == PASS && server == PASS) { > ??? return PASS; > } > > return FAIL; > > If I am not missing something, the pseudo-code above looks better and > simpler. 1. This test designs 5 status: SUCCESS, UNEXPECTED_SUCCESS, FAIL, EXPECTED_FAIL and TIMEOUT The main purpose is making the test report more clear. A case fails that may be due to: Unexpected failure; No failure, but it is expected to get some failure; Timeout, although it is also not expected, this failure may have nothing to do with SSL/TLS exceptions, like SSLHandshakeException. The test just wants to distinguish these different situations. I assume users generally just look through the report table, but not the detail logs. 2. This test really treats TIMEOUT as failure. Server and/or client timout, it should result in the case gets FAIL or EXPECTED_FAIL. 3. Your above code snippet doesn't cover all possible result status. For example, client == PASS && server == PASS, but this case may be expected to get some failure. The status should be UNEXPECTED_SUCCESS in my design. Again, some more status are used to make the report table could give more information before investigating details. 4. The updated webrev havs merged two if-clauses to simplify the method Compatibility.caseStatus() a bit. Best regards, John Jiang From artem.smotrakov at oracle.com Tue Nov 28 03:41:59 2017 From: artem.smotrakov at oracle.com (Artem) Date: Tue, 28 Nov 2017 06:41:59 +0300 Subject: RFR[10] 8186057: TLS interoperability testing between different Java versions In-Reply-To: <8e682254-28de-0464-f723-a50e332be325@oracle.com> References: <12833c7c-3b34-3d8a-77ee-9299e8cca88d@oracle.com> <05d9da98-205a-887d-ad88-c88b15832947@oracle.com> <7fcc23e3-dd4e-d127-0cc2-f4990fb5d665@oracle.com> <894241da-b4d7-46ce-2962-c3e6e9a2227b@oracle.com> <1e8d1acf-7f06-9e08-5a48-a65751586471@oracle.com> <927b4361-5147-a385-7db6-05f68ee09ed2@oracle.com> <66551e18-e4f8-7209-e325-81b28cb16d21@oracle.com> <54542382-5c9f-eb51-12b5-8e02e7c5e643@oracle.com> <237b0b1d-cd71-f674-4ac3-ef625c2f917f@oracle.com> <3a47f0b7-811e-0e1b-7207-30b1e312af95@oracle.com> <8e682254-28de-0464-f723-a50e332be325@oracle.com> Message-ID: <7ca2ebb3-dcda-316d-08a7-357bb1a23d54@oracle.com> Hi John, Please see inline. On 11/28/2017 05:35 AM, sha.jiang at oracle.com wrote: > Hi Artem, > Please review the new webrev at: > http://cr.openjdk.java.net/~jjiang/8186057/webrev.07/ > Please see my comments below. > >>>>>> >>>>>> One question about Compatibility.caseStatus(). What's the case >>>>>> when you expect a timeout and no client output? Should it always >>>>>> result to a test case failure? >>>>> I'm not sure understanding your question. Did you mean server or >>>>> client timeout? >>>>> I think client should output something. >>>> My questing is - should timeout be always considered as a failure? >>>> Why don't you just check if server or client result is FAIL? >>>> >>>> if (clientStatus == FAIL || serverStatus == FAIL) { >>>> ??? return FAIL; >>>> } >>>> >>>> return PASS; >>> Some cases are negative cases, their status should be EXPECTED_FAIL. >> That's fine, I got that. >>> A server or client timeout would lead to the case to fail, if the >>> failure is not expected. >>> If a server starts normally, but client doesn't start due to a >>> negative case, the server should get timeout. But this failure is >>> expected. >>> If a server starts normally, and client get a unexpected timeout, >>> this failure would make the case to fail. >> This logic looks unnecessary complex to me. The more complex it is, >> the more likely we get a bug there. I think TIMEOUT status is not >> necessary here. If a failure is expected on one side, the other side >> should fail as well (no matter if it's a timeout or an exception). >> >> If I were you, I would simplify this method like this >> >> if (client == EXPECTED_FAIL && server == EXPECTED_FAIL) { >> ??? return EXPECTED_FAIL; >> } >> >> if (client == PASS && server == PASS) { >> ??? return PASS; >> } >> >> return FAIL; >> >> If I am not missing something, the pseudo-code above looks better and >> simpler. > 1. This test designs 5 status: > SUCCESS, UNEXPECTED_SUCCESS, FAIL, EXPECTED_FAIL and TIMEOUT > The main purpose is making the test report more clear. > A case fails that may be due to: > Unexpected failure; > No failure, but it is expected to get some failure; > Timeout, although it is also not expected, this failure may have > nothing to do with SSL/TLS exceptions, like SSLHandshakeException. > The test just wants to distinguish these different situations. I > assume users generally just look through the report table, but not the > detail logs. > I am not sure it's useful to distinguish this situations, but it makes the logic more complex. > 2. This test really treats TIMEOUT as failure. Server and/or client > timout, it should result in the case gets FAIL or EXPECTED_FAIL. > > 3. Your above code snippet doesn't cover all possible result status. > For example, client == PASS && server == PASS, but this case may be > expected to get some failure. The status should be UNEXPECTED_SUCCESS > in my design. My code might not cover all cases because it's just an example. If there are more statuses, then it's going to be more complex. I am suggesting to get rid of unnecessary statuses to make it simpler. > > Again, some more status are used to make the report table could give > more information before investigating details. I don't think it's going to be useful at least to me. Instead, it might be better to print an exception message in a separate columns for both client and server. > > 4. The updated webrev havs merged two if-clauses to simplify the > method Compatibility.caseStatus() a bit. That's fine. I'll let you decide if you want to simplify it or not. By the way, I just noticed that JdkUtils.supportECKey() method and other return strings "true" and "false" instead of boolean values. This looks a bit unusual and unnecessary. Utils.java, line 146: it would be better to close the stream. Artem > > Best regards, > John Jiang From jamil.j.nimeh at oracle.com Tue Nov 28 06:04:33 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 27 Nov 2017 22:04:33 -0800 Subject: KDF API review, round 2 In-Reply-To: References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> Message-ID: <1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com> Hi Mike, I know I said you made arguments in favor of specifying the keys up front in init, but I'm still really uncomfortable with this.? It's been bothering me all day.? Comments below: On 11/27/2017 10:09 AM, Michael StJohns wrote: > On 11/27/2017 1:03 AM, Jamil Nimeh wrote: >> >>> >>>> >>>> One additional topic for discussion: Late in the week we talked >>>> about the current state of the API internally and one item to >>>> revisit is where the DerivationParameterSpec objects are passed. It >>>> was brought up by a couple people that it would be better to >>>> provide the DPS objects pertaining to keys at the time they are >>>> called for through deriveKey() and deriveKeys() (and possibly >>>> deriveData). >>>> >>>> Originally we had them all grouped in a List in the init method. >>>> One reason for needing it up there was to know the total length of >>>> material to generate.? If we can provide the total length through >>>> the AlgorithmParameterSpec passed in via init() then things like: >>>> >>>> Key deriveKey(DerivationParameterSpec param); >>>> List deriveKeys(List params); >>>> >>>> become possible.? To my eyes at least it does make it more clear >>>> what DPS you're processing since they're provided at derive time, >>>> rather than the caller having to keep track in their heads where in >>>> the DPS list they might be with each successive deriveKey or >>>> deriveKeys calls.? And I think we could do away with >>>> deriveKeys(int), too. >>> >>> See above - the key stream is logically produced in its entirety >>> before any assignment of that stream is made to any cryptographic >>> objects because the mixins (except for the round differentiator) are >>> the same for each key stream production round.?? Simply passing in >>> the total length may not give you the right result if the KDF >>> requires a per component length (and it should to defeat (5) or it >>> should only produce a single key). >> From looking at 800-108, I don't see any place where the KDF needs a >> per-component length.? It looks like it takes L (total length) as an >> input and that is applied to each round of the PRF.? HKDF takes L >> up-front as an input too, though it doesn't use it as an input to the >> HMAC function itself.? For TLS 1.3 that component length becomes part >> of the context info (HkdfLabel) through the HKDF-Expand-Label >> function...and it's only doing one key for a given label which is >> also part of that context specific info, necessitating an init() >> call.? Seems like the length can go into the APS provided via init >> (for those KDFs that need it at least) and you shouldn't need a DPS >> list up-front. >> > > HKDF and SP800-108 only deal with the creation of the key stream and > ignore the issues with assigning the key stream to cryptographic > objects.? In the TLS version of HDKF, the L value is mandatory and > only a single object is assigned per init/call to the KDF.?? An HSM > can look at the HKDF label information and set the appropriate > policies for the assigned cryptographic object (because if any of the > label data changes, the entire key stream changes).? That's not the > case for the raw HKDF nor for any KDF that allows for multiple objects > to be extracted out of a single key stream.? Hence the per-component > length values. So enforce a no-zero-length key policy in your provider code.? You probably can't affect the internals of the HSM, but you should be able to prevent it in the provider code.? I can't get away from the feeling that this could be dealt with in other ways besides specifying all this up-front. > > > Ideally, there should be a complete object spec for each object to be > generated that is part of the mixins (label and context) for any > KDF.?? That allows an HSM to rely upon the object spec when setting > policy controls for each generated object - and incidentally allows > for a KDF to generate both public and non-public data in a secure way. Between different generations of keystreams do you expect to have different sets of policy controls?? The KDF API has no way for you to set those things so I would assume those would be pretty static, or at least controlled outside the KDF API.? If so, why is the KDF API concerning itself with how some HSM sets its policy on objects it makes? > > So as long as you allow for the specification of all of the production > objects as part of the .init() I'm good.?? A given KDF might not > require this - but I can't see any way of fixing the current KDFs to > work in HSMs without something like this. > >> As far as your (5) scenario goes, I can see how you can twiddle the >> lengths to get the keystream output with zero-length keys and large >> IV buffers.? But that scenario really glosses over what should be a >> big hurdle and a major access control issue that stands outside the >> KDF API: That the attacker shouldn't have access to the input keying >> material in the first place.? Protect the input keying material >> properly and their attack cannot be done. > > Let me give you an example.?? I'm running an embedded HSM - to protect > TLS keys and to do all of the crypto.? An attacker compromises the TLS > server and now has access to the HSM.? No problem - I'm going to > notice if the attacker starts extraditing large amounts of data from > the server (e.g. copies of the TLS in the clear but possibly > reencrypted data stream) so this isn't a threat or is it?? Smart > attacker does an extraction attack on the TLS 1.2 and before KDF and > turns all of the key stream material into IV material and exports it > from the HSM.? The attacker now has the much smaller key material so > he can send a few messages with those keys and allow for the passive > external interception of the traffic and decryption thereof without > the risk of detection of all that traffic being sent.? Alternately, I > can place the key material in a picture via steganography and publish > it as part of the server data. "If the attacker compromises a TLS server" is the part that gets me...we're using external software bugs/security holes as a justification to make the KDF API in ways that I think are less clear to the consumer, to cover one class of providers (HSMs). > > The idea is to protect extraction of the key material from an HSM > _*even from authorized users of that key material*_. That may well be a goal for the HSM, to be solved by the HSM or the provider that front-ends it.? I do not see that as something to be solved by the KDF API. > > ?KDFs don't currently do this well.? Adding the overall length and per > component length stuff as well as a per component spec to the data > used to derive the key stream means that 1) changes to any of those > change the entire key stream, 2) the per component spec data may be > used by the security module policy engine to enforce restrictions and > 3) because of (1) and (2) calling the KDF a second time gets me > exactly the same objects rather than just the same key stream.? The > last isn't very important in a software based security domain, but > turns out to have real implications for policy enforcing security modules. But there aren't KDFs that take individual component lengths as inputs, so alterations to individual key component lengths don't change the keystream (unless someone decides to write a KDF that does, but none that I've seen do).? With the way the KDF API is taking shape, there's no enforcement that you get the same objects - none of that is locked to the instance.? It can change between inits.? If you reinitialize with the same key and KDF parameters, whether you specify all objects up front or one at a time in derive calls you can still ask for a different set of output objects.? And changing lengths on various objects won't matter because HKDF, Counter-mode KDF, Feedback-mode KDF...none of those care a whit about individual component lengths.? All they care about is the total length of the keystream (and HKDF only cares about that to make sure it's not more than 255 * Hmac length). > > This gets worse when you realize that the KDF key is under it all > either a HASH HMAC or CMAC key and all of those algorithms produce > public data.?? Ideally you need a way of preventing a KDF key from > calling the raw HASH/HMAC/CMAC functions directly (and vice versa). I don't see how we'd prevent this in software.? If I've got a key as input to a KDF (a SecretKey) there's no way to prevent it being used by anything else that takes a SecretKey.? If you need to prevent that in hardware then that seems like a concern for your provider or the HSM itself. > >> >> I would rather see the DPS provided in the deriveKey.? It couples >> what you want out with the call that makes the object and it makes a >> lot more sense to keep those two together than try to remember where >> in the submitted list of DPS objects you are. >>> >>> 95% of the time this will be a call to produce a single key. 4% of >>> the time it will be a call to produce multiple keys. Only 1% of the >>> time will it need to intermix key, data and object productions. >>> Anybody who is doing that is going to write a wrapper around this >>> class to make sure they get the key and data production order >>> correct for each call.? So I'm not all that bothered by keeping the >>> complexity as a price for keeping flexibility. >>> >>> You could have a Key deriveKey(Key k, DerivationParameterSpec param) >>> for some things like TLS1.3 (where you can only make a single call >>> to derive key between inits) , but then you'd also need at least a >>> byte[] deriveData (Key k, DerivationParameterSpec param) and an >>> Object deriveObject(Key k, DerivationParameterSpec param). >> I don't think those are necessary.? If you're just doing HKDF-Expand >> (for the HKDF-Expand-Label TLS 1.3 key derivation) then you can >> provide the input key, label and max length and any other context >> info that goes into that HkdfLabel structure...all of that would go >> into init().? Then provide the key alg and desired length via the DPS >> at deriveKey time.? Any subsequent keys in the TLS 1.3 key schedule >> would need a new init call anyway since the labels change and >> possibly the output length. >> >> Over the next day or so I'm going to have to make some final >> decisions on this API as there are internal projects that are waiting >> on this API to proceed.? I'm already past the cut-off date I set, but >> I recognize these discussions are important to have and I appreciate >> the input you and others have provided. >> >> --Jamil >> > > Reading this last I think I've lost the context.?? Here's where I > think we are: > > 1) Get instance gets the default configuration of a given KDF (and > that default will be attached to the instance name defintion) > 2) .setParameter() may be used to update the KDF configuration - once. > 3) .init() takes at least the key, it may optionally take a set of > derivation parameters.?? The derivation parameters provided in .init() > are intended for use in forming the label and context mixins for the > KDF.?? They may provide - for example - the total length of the key > stream, the objects to be derived, the length of the objects, > protection parameters for each of the objects etc. > 4) A kdf generate a free-running or fixed length key stream depending > on the derivation parameters (e.g. if "L" is not a mixin to the KDF > then it is free-running and may produce as much key stream as desired > or if the production object specifications are not part of the > derivation mixins). > > Doing (4) is mostly not a good idea, but someone might want to do > this.?? In that case it may make the most sense to just allow them to > do deriveData(int length) calls as the only function (a keyed PRNG > basically). > > Re the last version of your api - if you add the .setParameter() > .getParameter() calls to both KeyDerivation and KeyDerivationSpi I > think I'm happy with this part of the API.? I'm wondering if we should > talk about KeyAgreement though. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Tue Nov 28 07:36:56 2017 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 28 Nov 2017 15:36:56 +0800 Subject: RFR[10] 8186057: TLS interoperability testing between different Java versions In-Reply-To: <7ca2ebb3-dcda-316d-08a7-357bb1a23d54@oracle.com> References: <12833c7c-3b34-3d8a-77ee-9299e8cca88d@oracle.com> <05d9da98-205a-887d-ad88-c88b15832947@oracle.com> <7fcc23e3-dd4e-d127-0cc2-f4990fb5d665@oracle.com> <894241da-b4d7-46ce-2962-c3e6e9a2227b@oracle.com> <1e8d1acf-7f06-9e08-5a48-a65751586471@oracle.com> <927b4361-5147-a385-7db6-05f68ee09ed2@oracle.com> <66551e18-e4f8-7209-e325-81b28cb16d21@oracle.com> <54542382-5c9f-eb51-12b5-8e02e7c5e643@oracle.com> <237b0b1d-cd71-f674-4ac3-ef625c2f917f@oracle.com> <3a47f0b7-811e-0e1b-7207-30b1e312af95@oracle.com> <8e682254-28de-0464-f723-a50e332be325@oracle.com> <7ca2ebb3-dcda-316d-08a7-357bb1a23d54@oracle.com> Message-ID: <739dc70e-99fa-77df-41e1-907287f3f7e0@oracle.com> Hi Artem, Could you please take a look this update: http://cr.openjdk.java.net/~jjiang/8186057/webrev.08/ > By the way, I just noticed that JdkUtils.supportECKey() method and > other return strings "true" and "false" instead of boolean values. > This looks a bit unusual and unnecessary. The returned values from method supportECKey(), supportsSNI and supportsALPN are consumed by method attr(), which only accepts String value. The values are outputted to stdout. Especially these supportXXX() methods are not used by other classes. So, I thought they could simply return String instead of boolean. But now I change them to return boolean values, and accordingly modify method attr() to accept any type. > Utils.java, line 146: it would be better to close the stream. Fixed. Best regards, John Jiang From mstjohns at comcast.net Tue Nov 28 17:34:52 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 28 Nov 2017 12:34:52 -0500 Subject: KDF API review, round 2 In-Reply-To: <1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> <1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com> Message-ID: On 11/28/2017 1:04 AM, Jamil Nimeh wrote: > Hi Mike, I know I said you made arguments in favor of specifying the > keys up front in init, but I'm still really uncomfortable with this.? > It's been bothering me all day.? Comments below: Before I get to those: 1) Do you know of any protocol using a KDF where the key production information is not known before you'd need to call the .init()? 2) If you do, couldn't you simply provide an empty or null list of key derivation spec's to .init()? 3) If you're doing a multiobject production from a single call to .init() do you expect in all cases to NOT include the production data as mixins? My problem is that I have use cases where ALL of my key production information is used as mixins to the key stream.? Now I could provide a List as part of the KDF init algorithm parameter spec (kdfParams), but that means that I have to provide a different APS for each different key schedule (consider TLS1.3s various calls). If you take out the List out of the .init() I'll end up having to do that and probably having to accept null values for the deriveKey calls. More in line. > > On 11/27/2017 10:09 AM, Michael StJohns wrote: >> On 11/27/2017 1:03 AM, Jamil Nimeh wrote: >>> >> >> HKDF and SP800-108 only deal with the creation of the key stream and >> ignore the issues with assigning the key stream to cryptographic >> objects.? In the TLS version of HDKF, the L value is mandatory and >> only a single object is assigned per init/call to the KDF.?? An HSM >> can look at the HKDF label information and set the appropriate >> policies for the assigned cryptographic object (because if any of the >> label data changes, the entire key stream changes).? That's not the >> case for the raw HKDF nor for any KDF that allows for multiple >> objects to be extracted out of a single key stream.? Hence the >> per-component length values. > So enforce a no-zero-length key policy in your provider code.? You > probably can't affect the internals of the HSM, but you should be able > to prevent it in the provider code.? I can't get away from the feeling > that this could be dealt with in other ways besides specifying all > this up-front. The best way to understand this is to look at the PKCS11 TLS1.2 and before KDF stuff.? The key production schedule was for an encryption key, an integrity key and two IVs, all from the same key stream.? It turns out that NOTHING the HSM could do could prevent the extraction of key material because changing the boundaries between each object did not change the key stream.? In the TLS case (and IPSec for that matter), it's a simple matter to move confidential key material into non-confidential IVs.? However, even if you limit the production to only confidential items, you still have a problem in that using the same key material for different algorithms (e.g. using part of an AES key as a single DES key) can lead to vulnerabilities. TLS 1.3 fixed this problem by only doing single key productions for each call to the KDF (and by adding the length of the production to the mixins).? Because of this, an HSM can look at the mixin data and "do the right thing" with respect to policy.? If TLS1.3 had kept the multiple object production model, they would have included the per-object lengths in the KDF mixin data. The HSM can do the right thing because the bits it can depend upon (in the TLS 1.3 case the label and the length) are included in the mixin and not simply as part of the added on key creation stuff. Without this, there is nothing an HSM can do for enforcement because changing these inputs wouldn't change the key stream. >> >> >> Ideally, there should be a complete object spec for each object to be >> generated that is part of the mixins (label and context) for any >> KDF.?? That allows an HSM to rely upon the object spec when setting >> policy controls for each generated object - and incidentally allows >> for a KDF to generate both public and non-public data in a secure way. > Between different generations of keystreams do you expect to have > different sets of policy controls?? The KDF API has no way for you to > set those things so I would assume those would be pretty static, or at > least controlled outside the KDF API.? If so, why is the KDF API > concerning itself with how some HSM sets its policy on objects it makes? If I call a KDF with the same key but with different key productions, I *want* the key stream to be different.? If I call it with the same key but with same key productions, I *want* it to be the same.?? Say I call the KDF to produce two objects -? an AES key of length 16 bytes and a HMAC-SHA256 key of also length 16 bytes. If I then call the same kdf with the same key to produce two AES keys of length 16 bytes (same overall length of the key stream, but different objects), I would *really* like it if the second object did not have the same key bytes as the HMAC-SHA256 key of the first call.?? The only way I can ensure this is to provide mixins that cause the entire key stream to change if anything changes in the key production data. If the mixins include policy hints (key type, key length, label, etc) then the HSM can rely upon those and set policy accordingly for the objects. >> >> So as long as you allow for the specification of all of the >> production objects as part of the .init() I'm good.?? A given KDF >> might not require this - but I can't see any way of fixing the >> current KDFs to work in HSMs without something like this. >> >>> As far as your (5) scenario goes, I can see how you can twiddle the >>> lengths to get the keystream output with zero-length keys and large >>> IV buffers.? But that scenario really glosses over what should be a >>> big hurdle and a major access control issue that stands outside the >>> KDF API: That the attacker shouldn't have access to the input keying >>> material in the first place. Protect the input keying material >>> properly and their attack cannot be done. >> >> Let me give you an example.?? I'm running an embedded HSM - to >> protect TLS keys and to do all of the crypto.? An attacker >> compromises the TLS server and now has access to the HSM.? No problem >> - I'm going to notice if the attacker starts extraditing large >> amounts of data from the server (e.g. copies of the TLS in the clear >> but possibly reencrypted data stream) so this isn't a threat or is >> it?? Smart attacker does an extraction attack on the TLS 1.2 and >> before KDF and turns all of the key stream material into IV material >> and exports it from the HSM.? The attacker now has the much smaller >> key material so he can send a few messages with those keys and allow >> for the passive external interception of the traffic and decryption >> thereof without the risk of detection of all that traffic being >> sent.? Alternately, I can place the key material in a picture via >> steganography and publish it as part of the server data. > "If the attacker compromises a TLS server" is the part that gets > me...we're using external software bugs/security holes as a > justification to make the KDF API in ways that I think are less clear > to the consumer, to cover one class of providers (HSMs). This isn't a bug in the HSM - its a bug in thinking about how KDFs work/should work.??? There are three parts to a KDF - extraction of entropy from the master secret, expansion of that entropy into a key stream and finally, assignment of that key stream to cryptographic objects.? HKDF and SP800-108 talk about the first two, but don't consider the implications of the third.?? Because of this, neither TLS1.2 nor IPSec provide a KDF with secure key production. >> >> The idea is to protect extraction of the key material from an HSM >> _*even from authorized users of that key material*_. > That may well be a goal for the HSM, to be solved by the HSM or the > provider that front-ends it.? I do not see that as something to be > solved by the KDF API. It has to be solved by the KDF API because the only way this works is if the mixin data for all the productions is included prior to producing the first object. >> >> ?KDFs don't currently do this well.? Adding the overall length and >> per component length stuff as well as a per component spec to the >> data used to derive the key stream means that 1) changes to any of >> those change the entire key stream, 2) the per component spec data >> may be used by the security module policy engine to enforce >> restrictions and 3) because of (1) and (2) calling the KDF a second >> time gets me exactly the same objects rather than just the same key >> stream.? The last isn't very important in a software based security >> domain, but turns out to have real implications for policy enforcing >> security modules. > But there aren't KDFs that take individual component lengths as > inputs, so alterations to individual key component lengths don't > change the keystream (unless someone decides to write a KDF that does, > but none that I've seen do).? With the way the KDF API is taking > shape, there's no enforcement that you get the same objects - none of > that is locked to the instance.? It can change between inits.? If you > reinitialize with the same key and KDF parameters, whether you specify > all objects up front or one at a time in derive calls you can still > ask for a different set of output objects.? And changing lengths on > various objects won't matter because HKDF, Counter-mode KDF, > Feedback-mode KDF...none of those care a whit about individual > component lengths.? All they care about is the total length of the > keystream (and HKDF only cares about that to make sure it's not more > than 255 * Hmac length). Yes but. TLS1.3 will be NOT be an HKDF KDF instantiation, it will be a TLS1.3 KDF instantiation (which uses the HDKF function internally) that will limit production to a single object per init and with a known set of labels and using L as a mixin.? Because that's how TLS13 dealt with the problem. AND - there are KDFs that take individual components lengths as inputs - in at least two proprietary protocols that I know of. Mostly though, with the trend to AEAD algorithms most of the protocols are tending to move to a single production per init. (since they don't need both an integrity and confidentiality key nor an IV per se) >> >> This gets worse when you realize that the KDF key is under it all >> either a HASH HMAC or CMAC key and all of those algorithms produce >> public data.?? Ideally you need a way of preventing a KDF key from >> calling the raw HASH/HMAC/CMAC functions directly (and vice versa). > I don't see how we'd prevent this in software.? If I've got a key as > input to a KDF (a SecretKey) there's no way to prevent it being used > by anything else that takes a SecretKey.? If you need to prevent that > in hardware then that seems like a concern for your provider or the > HSM itself. If I tag a key as MasterSecret (where MasterSecret is not a subinterface of SecretKey, but is of Key) and use MasterSecret instead of Key in .init()..... The HSM (and the JVM) would both identify functions that can be used with that key and keep others away. This is what I was talking about with cryptographic type safety in my last email - the idea that the Key objects be as strongly typed as possible to prevent them from being used inappropriately or in ways that mathematically bypass security.?? Take a KDF with a PRF of CMAC-AES-128.? The KDF is meant to produce secret data (a key stream for the production of keys), but a CMAC-AES-128 is meant to produce public data (an integrity tag over a set of data).? Given that KDF algorithm is simply a wrapper to the PRF to allow for the production of multiple blocks of data, then its trivial - if you have access to *use* the KDF key - to use it with the CMAC function to extract the key stream. In the HSM I can *somewhat* combat this by (in PKCS11) attributing the key, but how do get those attributes on the key in the first place if I'm using a Java front end? In software this isn't a big thing as the confidential key material and the public CMAC integrity tag are both in the same software domain.? But over the years we've tried to do the right thing (see javax.security.auth.Destroyable for example) by thinking about security past the limitations of what we can get in software. For KDFs I'd add a? jaxa.crypto.MasterSecret interface extending Key,Destroyable (and pretty much a clone of SecretKey) a javax.crypto.spec.MasterSecretSpec implementing KeySpec and MasterSecret (and a clone of SecretKeySpec) to tag these secret keys as for use only with a KDF. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Nov 28 19:41:42 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 28 Nov 2017 11:41:42 -0800 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: References: Message-ID: <97def149-d3dc-bbe9-939c-5f2d7ffd8eba@oracle.com> On 11/22/17 6:37 AM, Sean Mullan wrote: > Please review this change to remove the pre-JDK 1.2 SecurityManager > methods that have been deprecated since JDK 1.2 and marked for removal > in JDK 9. These methods are fragile, error-prone and have been > obsolete since the SecurityManager was revamped in JDK 1.2. The > methods to be removed are: getInCheck, classDepth, classLoaderDepth, > currentClassLoader, currentLoadedClass, inClass, and inClassLoader. > > In addition, the deprecated and error-prone checkMemberAccess method > (which was deprecated in JDK 8 and marked for removal in JDK 9) has > been changed to throw SecurityException if the caller has not been > granted AllPermission. This makes the method less likely it will be > used incorrectly while still allowing some more time before it is > removed. > > http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ > src/java.desktop/share/classes/sun/applet/AppletSecurity.java ?111???? private static final StackWalker walker = ?112???????? StackWalker.getInstance(RETAIN_CLASS_REFERENCE); This call will do a stack-based permission check.? So it needs to be wrapped with doPrivileged. Otherwise, looks fine. Just to mention this:? AppletSecurity does not really need the currentClassLoader method. AppletSecurity::currentAppletClassLoader could be reimplemented to use StackWalker to walk the stack once (replacing the call to currentClassLoader and getClassContext) to find AppletClassLoader. OTOH it does not worth making more change since applets are going away. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Wed Nov 29 13:38:07 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 29 Nov 2017 05:38:07 -0800 Subject: KDF API review, round 2 In-Reply-To: References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> <1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com> Message-ID: <575cf18a-879e-d0d1-b85b-8f84246a8f4f@oracle.com> On 11/28/2017 9:34 AM, Michael StJohns wrote: > On 11/28/2017 1:04 AM, Jamil Nimeh wrote: >> Hi Mike, I know I said you made arguments in favor of specifying the >> keys up front in init, but I'm still really uncomfortable with this.? >> It's been bothering me all day.? Comments below: > > Before I get to those: > > 1) Do you know of any protocol using a KDF where the key production > information is not known before you'd need to call the .init()? I honestly don't.? I think it's safe to say you probably don't need a KDF instance until you know at least the first object you want out of it.? But for the protocols I know of all the objects are known once a cipher suite or proposal is agreed upon. > 2) If you do, couldn't you simply provide an empty or null list of key > derivation spec's to .init()? You could, but that would end up necessitating two models of operation.? One where we give a? list up front of all objects and call derive actions with no parameters, and a second model where you specify nothing and then provide object specs one-by-one.? Each one has pros and cons, but trying to support both models I think would make the API even more confusing. > 3) If you're doing a multiobject production from a single call to > .init() do you expect in all cases to NOT include the production data > as mixins? In all cases?? I can't honestly say that.? For the protocols I know of, the individual object attributes (like length) are not mixins. But you later go on to say that you know of a couple protocols where they do.? If we have real-world scenarios where individual object lengths or other attributes really affect the keystream then I guess we need to take that into account. > > My problem is that I have use cases where ALL of my key production > information is used as mixins to the key stream.? Now I could provide > a List as part of the KDF init algorithm > parameter spec (kdfParams), but that means that I have to provide a > different APS for each different key schedule (consider TLS1.3s > various calls). If you take out the List out > of the .init() I'll end up having to do that and probably having to > accept null values for the deriveKey calls. > > More in line. > > >> >> On 11/27/2017 10:09 AM, Michael StJohns wrote: >>> On 11/27/2017 1:03 AM, Jamil Nimeh wrote: >>>> >>> >>> HKDF and SP800-108 only deal with the creation of the key stream and >>> ignore the issues with assigning the key stream to cryptographic >>> objects.? In the TLS version of HDKF, the L value is mandatory and >>> only a single object is assigned per init/call to the KDF.?? An HSM >>> can look at the HKDF label information and set the appropriate >>> policies for the assigned cryptographic object (because if any of >>> the label data changes, the entire key stream changes).? That's not >>> the case for the raw HKDF nor for any KDF that allows for multiple >>> objects to be extracted out of a single key stream.? Hence the >>> per-component length values. >> So enforce a no-zero-length key policy in your provider code. You >> probably can't affect the internals of the HSM, but you should be >> able to prevent it in the provider code.? I can't get away from the >> feeling that this could be dealt with in other ways besides >> specifying all this up-front. > > The best way to understand this is to look at the PKCS11 TLS1.2 and > before KDF stuff.? The key production schedule was for an encryption > key, an integrity key and two IVs, all from the same key stream.? It > turns out that NOTHING the HSM could do could prevent the extraction > of key material because changing the boundaries between each object > did not change the key stream.? In the TLS case (and IPSec for that > matter), it's a simple matter to move confidential key material into > non-confidential IVs. However, even if you limit the production to > only confidential items, you still have a problem in that using the > same key material for different algorithms (e.g. using part of an AES > key as a single DES key) can lead to vulnerabilities. > > TLS 1.3 fixed this problem by only doing single key productions for > each call to the KDF (and by adding the length of the production to > the mixins).? Because of this, an HSM can look at the mixin data and > "do the right thing" with respect to policy. If TLS1.3 had kept the > multiple object production model, they would have included the > per-object lengths in the KDF mixin data. > > The HSM can do the right thing because the bits it can depend upon (in > the TLS 1.3 case the label and the length) are included in the mixin > and not simply as part of the added on key creation stuff. Without > this, there is nothing an HSM can do for enforcement because changing > these inputs wouldn't change the key stream. > > >>> >>> >>> Ideally, there should be a complete object spec for each object to >>> be generated that is part of the mixins (label and context) for any >>> KDF.?? That allows an HSM to rely upon the object spec when setting >>> policy controls for each generated object - and incidentally allows >>> for a KDF to generate both public and non-public data in a secure way. >> Between different generations of keystreams do you expect to have >> different sets of policy controls?? The KDF API has no way for you to >> set those things so I would assume those would be pretty static, or >> at least controlled outside the KDF API.? If so, why is the KDF API >> concerning itself with how some HSM sets its policy on objects it makes? > > If I call a KDF with the same key but with different key productions, > I *want* the key stream to be different.? If I call it with the same > key but with same key productions, I *want* it to be the same.?? Say I > call the KDF to produce two objects -? an AES key of length 16 bytes > and a HMAC-SHA256 key of also length 16 bytes.? If I then call the > same kdf with the same key to produce two AES keys of length 16 bytes > (same overall length of the key stream, but different objects), I > would *really* like it if the second object did not have the same key > bytes as the HMAC-SHA256 key of the first call.?? The only way I can > ensure this is to provide mixins that cause the entire key stream to > change if anything changes in the key production data. With the KDFs I know of I don't see how you're going to pull that off.? If you call HKDF with the same key, same salt, same info, you're going to create the same keystream, no matter how you choose to segment it or what kinds of objects you wish to assign them to. I guess in your implementation of a KDF you can choose to go through the DPS objects and mix their attributes in. I had been working on the model that kdfParams provides the mixins (salt, context info, iteration count, whatever the KDF needs to make a keystream).? That was based on how the KDFs I know of function. Even TLS 1.3 keys can be done via HDKF in this manner by just adding those label and length properties to the context info field.? But if you want your implementation to draw it from the DPS, I guess you could do that.? It just seems like two providers providing the same algorithm would come to different answers. > > If the mixins include policy hints (key type, key length, label, etc) > then the HSM can rely upon those and set policy accordingly for the > objects. I think I alluded to that up above with TLS 1.3 key derivation using HKDF.? The kdfParams APS for an HKDF-Expand operation would provide context specific info in the form of an HkdfLabel.? You'd have the key-specific info you're talking about already as part of the mixin.? You don't need to get it from the DPS directly. > >>> >>> So as long as you allow for the specification of all of the >>> production objects as part of the .init() I'm good.?? A given KDF >>> might not require this - but I can't see any way of fixing the >>> current KDFs to work in HSMs without something like this. >>> >>>> As far as your (5) scenario goes, I can see how you can twiddle the >>>> lengths to get the keystream output with zero-length keys and large >>>> IV buffers.? But that scenario really glosses over what should be a >>>> big hurdle and a major access control issue that stands outside the >>>> KDF API: That the attacker shouldn't have access to the input >>>> keying material in the first place.? Protect the input keying >>>> material properly and their attack cannot be done. >>> >>> Let me give you an example.?? I'm running an embedded HSM - to >>> protect TLS keys and to do all of the crypto.? An attacker >>> compromises the TLS server and now has access to the HSM.? No >>> problem - I'm going to notice if the attacker starts extraditing >>> large amounts of data from the server (e.g. copies of the TLS in the >>> clear but possibly reencrypted data stream) so this isn't a threat >>> or is it?? Smart attacker does an extraction attack on the TLS 1.2 >>> and before KDF and turns all of the key stream material into IV >>> material and exports it from the HSM.? The attacker now has the much >>> smaller key material so he can send a few messages with those keys >>> and allow for the passive external interception of the traffic and >>> decryption thereof without the risk of detection of all that traffic >>> being sent.? Alternately, I can place the key material in a picture >>> via steganography and publish it as part of the server data. >> "If the attacker compromises a TLS server" is the part that gets >> me...we're using external software bugs/security holes as a >> justification to make the KDF API in ways that I think are less clear >> to the consumer, to cover one class of providers (HSMs). > > This isn't a bug in the HSM - its a bug in thinking about how KDFs > work/should work.??? There are three parts to a KDF - extraction of > entropy from the master secret, expansion of that entropy into a key > stream and finally, assignment of that key stream to cryptographic > objects.? HKDF and SP800-108 talk about the first two, but don't > consider the implications of the third.?? Because of this, neither > TLS1.2 nor IPSec provide a KDF with secure key production. When I referred to "bug" I wasn't talking about the HSM, I was referring to the server that could be compromised, but no matter. I'm not sure there's any KDF API out there that talks about the third class.? Seems like they're all concerned with providing the first two.? I had envisioned our KDF API providing equivalent functionality. > > >>> >>> The idea is to protect extraction of the key material from an HSM >>> _*even from authorized users of that key material*_. >> That may well be a goal for the HSM, to be solved by the HSM or the >> provider that front-ends it.? I do not see that as something to be >> solved by the KDF API. > > It has to be solved by the KDF API because the only way this works is > if the mixin data for all the productions is included prior to > producing the first object. > >>> >>> ?KDFs don't currently do this well.? Adding the overall length and >>> per component length stuff as well as a per component spec to the >>> data used to derive the key stream means that 1) changes to any of >>> those change the entire key stream, 2) the per component spec data >>> may be used by the security module policy engine to enforce >>> restrictions and 3) because of (1) and (2) calling the KDF a second >>> time gets me exactly the same objects rather than just the same key >>> stream.? The last isn't very important in a software based security >>> domain, but turns out to have real implications for policy enforcing >>> security modules. >> But there aren't KDFs that take individual component lengths as >> inputs, so alterations to individual key component lengths don't >> change the keystream (unless someone decides to write a KDF that >> does, but none that I've seen do).? With the way the KDF API is >> taking shape, there's no enforcement that you get the same objects - >> none of that is locked to the instance.? It can change between >> inits.? If you reinitialize with the same key and KDF parameters, >> whether you specify all objects up front or one at a time in derive >> calls you can still ask for a different set of output objects.? And >> changing lengths on various objects won't matter because HKDF, >> Counter-mode KDF, Feedback-mode KDF...none of those care a whit about >> individual component lengths.? All they care about is the total >> length of the keystream (and HKDF only cares about that to make sure >> it's not more than 255 * Hmac length). > Yes but. > > TLS1.3 will be NOT be an HKDF KDF instantiation, it will be a TLS1.3 > KDF instantiation (which uses the HDKF function internally) that will > limit production to a single object per init and with a known set of > labels and using L as a mixin.? Because that's how TLS13 dealt with > the problem. > > AND - there are KDFs that take individual components lengths as inputs > - in at least two proprietary protocols that I know of. Mostly though, > with the trend to AEAD algorithms most of the protocols are tending to > move to a single production per init. (since they don't need both an > integrity and confidentiality key nor an IV per se) > > >>> >>> This gets worse when you realize that the KDF key is under it all >>> either a HASH HMAC or CMAC key and all of those algorithms produce >>> public data.?? Ideally you need a way of preventing a KDF key from >>> calling the raw HASH/HMAC/CMAC functions directly (and vice versa). >> I don't see how we'd prevent this in software.? If I've got a key as >> input to a KDF (a SecretKey) there's no way to prevent it being used >> by anything else that takes a SecretKey.? If you need to prevent that >> in hardware then that seems like a concern for your provider or the >> HSM itself. > > If I tag a key as MasterSecret (where MasterSecret is not a > subinterface of SecretKey, but is of Key) and use MasterSecret instead > of Key in .init()..... > > The HSM (and the JVM) would both identify functions that can be used > with that key and keep others away. > > This is what I was talking about with cryptographic type safety in my > last email - the idea that the Key objects be as strongly typed as > possible to prevent them from being used inappropriately or in ways > that mathematically bypass security.?? Take a KDF with a PRF of > CMAC-AES-128.? The KDF is meant to produce secret data (a key stream > for the production of keys), but a CMAC-AES-128 is meant to produce > public data (an integrity tag over a set of data).? Given that KDF > algorithm is simply a wrapper to the PRF to allow for the production > of multiple blocks of data, then its trivial - if you have access to > *use* the KDF key - to use it with the CMAC function to extract the > key stream. > > In the HSM I can *somewhat* combat this by (in PKCS11) attributing the > key, but how do get those attributes on the key in the first place if > I'm using a Java front end? > > In software this isn't a big thing as the confidential key material > and the public CMAC integrity tag are both in the same software > domain.? But over the years we've tried to do the right thing (see > javax.security.auth.Destroyable for example) by thinking about > security past the limitations of what we can get in software. > > For KDFs I'd add a? jaxa.crypto.MasterSecret interface extending > Key,Destroyable (and pretty much a clone of SecretKey) a > javax.crypto.spec.MasterSecretSpec implementing KeySpec and > MasterSecret (and a clone of SecretKeySpec) to tag these secret keys > as for use only with a KDF. > > Mike > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Wed Nov 29 14:11:07 2017 From: mbalao at redhat.com (Martin Balao) Date: Wed, 29 Nov 2017 11:11:07 -0300 Subject: RFR 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite Message-ID: Hi, I'd like to propose a fix for JDK-8165996 - PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite [1]. Webrev01: * http://cr.openjdk.java.net/~akasko/mbalao/8165996.webrev.01/ (browse online) * http://cr.openjdk.java.net/~akasko/mbalao/8165996.webrev.01.zip (download) Kind regards, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8165996 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Nov 29 15:03:58 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 Nov 2017 10:03:58 -0500 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: <97def149-d3dc-bbe9-939c-5f2d7ffd8eba@oracle.com> References: <97def149-d3dc-bbe9-939c-5f2d7ffd8eba@oracle.com> Message-ID: <0964267f-757c-86d5-f927-298a8f842aa4@oracle.com> On 11/28/17 2:41 PM, mandy chung wrote: > > > On 11/22/17 6:37 AM, Sean Mullan wrote: >> Please review this change to remove the pre-JDK 1.2 SecurityManager >> methods that have been deprecated since JDK 1.2 and marked for removal >> in JDK 9. These methods are fragile, error-prone and have been >> obsolete since the SecurityManager was revamped in JDK 1.2. The >> methods to be removed are: getInCheck, classDepth, classLoaderDepth, >> currentClassLoader, currentLoadedClass, inClass, and inClassLoader. >> >> In addition, the deprecated and error-prone checkMemberAccess method >> (which was deprecated in JDK 8 and marked for removal in JDK 9) has >> been changed to throw SecurityException if the caller has not been >> granted AllPermission. This makes the method less likely it will be >> used incorrectly while still allowing some more time before it is >> removed. >> >> http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ >> > > src/java.desktop/share/classes/sun/applet/AppletSecurity.java > ?111???? private static final StackWalker walker = > ?112???????? StackWalker.getInstance(RETAIN_CLASS_REFERENCE); > > This call will do a stack-based permission check.? So it needs to be > wrapped with doPrivileged. Yes, Alan had the same comment. I have wrapped it in doPrivileged. > Otherwise, looks fine. > > Just to mention this:? AppletSecurity does not really need the > currentClassLoader method. AppletSecurity::currentAppletClassLoader > could be reimplemented to use StackWalker to walk the stack once > (replacing the call to currentClassLoader and getClassContext) to find > AppletClassLoader. OTOH it does not worth making more change since > applets are going away. Ok. Good point though. --Sean From mstjohns at comcast.net Wed Nov 29 17:06:23 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 29 Nov 2017 12:06:23 -0500 Subject: KDF API review, round 2 In-Reply-To: <575cf18a-879e-d0d1-b85b-8f84246a8f4f@oracle.com> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> <1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com> <575cf18a-879e-d0d1-b85b-8f84246a8f4f@oracle.com> Message-ID: Hi Jamil et al - I think I finally understand the disconnect here - let me try and work through an explanation from another direction. The TLS 1.3 KDF is NOT HKDF-Expand, it is HKDF-Expand-Label. HKDF-Expand has a calling sequence of HKDF-Expand (Secret, Label, Length).?? That results in underlying calls to T(n) = PRF (Secret, T(n-1) || label || n) for each block of key stream (RFC 5869 - page 3). Two key things to understand here are:? that the Length value in HKDF-Expand is not passed in as a mixin, only as a value to determine how much key stream to produce; that the "label" parameter is just opaque data (remember this please - its important later). HKDF-Expand-Label (Secret, Label, HashValue, Length)? is defined as HKDF-Expand (Secret, hkdfLabel, Length) where hkdfLabel is a structured value (NON-Opaque) consisting of the Length, Label (from the top level call) and Hash Value (also from the top level call) (TLS 1.3 section 7.1 Key Schedule). The hkdfLabel ultimately is the "label" part of the call to the PRF. A module creating a key from HKDF-Expand-Label knows that it MUST cut off the key stream after Length bytes (and if a new length value is provided, you get a whole different key stream).? It can read the hkdfLabel? from the call and know this production is for a key or an iv and set protections appropriately.?HKDF-Expand-Label also knows that it will only produce a single object from each call.? In HDKF-Expand, the Label value is opaque.? It may contain the Length value, it may contain key tagging information, it may contain your dog's name, but since it's not structured in any way, an implementer of the HKDF-Expand calling convention can't do anything useful with that data in figuring out the assignment of the key stream to a key object. I think what we have is a failure of language.? HKDF (and for that matter SP800-108) should be called key stream producers - not key derivation functions.? Mainly because they don't properly consider the assignment of the key stream bytes to the keys and how that interacts with the key stream production. I need a way of making sure that 1) the key assignment/production specifications can be included in the mixins, and 2) a way of letting the module/provider be able to rely upon those specifications (e.g. by changing the key stream if the specifications change).? That means that the KeyDerivation calling convention needs to let me provide all of this data before the first call to derive a key. This would have been more obvious had TLS1.3 kept the same multiple production per KDF call as was in previous versions - the HkdfLabel argument would have been an array of hkdfLabel structures.? They opted to clean it up slightly and limit it to a single production per KDF call. Mike From mstjohns at comcast.net Wed Nov 29 17:43:09 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 29 Nov 2017 12:43:09 -0500 Subject: KDF API review, round 2 In-Reply-To: <575cf18a-879e-d0d1-b85b-8f84246a8f4f@oracle.com> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> <7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com> <1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com> <575cf18a-879e-d0d1-b85b-8f84246a8f4f@oracle.com> Message-ID: <2e4ccc07-3780-c974-1fe6-30a784709333@comcast.net> On 11/29/2017 8:38 AM, Jamil Nimeh wrote: > > > On 11/28/2017 9:34 AM, Michael StJohns wrote: >> On 11/28/2017 1:04 AM, Jamil Nimeh wrote: >>> Hi Mike, I know I said you made arguments in favor of specifying the >>> keys up front in init, but I'm still really uncomfortable with >>> this.? It's been bothering me all day. Comments below: >> >> Before I get to those: >> >> 1) Do you know of any protocol using a KDF where the key production >> information is not known before you'd need to call the .init()? > I honestly don't.? I think it's safe to say you probably don't need a > KDF instance until you know at least the first object you want out of > it.? But for the protocols I know of all the objects are known once a > cipher suite or proposal is agreed upon. >> 2) If you do, couldn't you simply provide an empty or null list of >> key derivation spec's to .init()? > You could, but that would end up necessitating two models of > operation.? One where we give a? list up front of all objects and call > derive actions with no parameters, and a second model where you > specify nothing and then provide object specs one-by-one. Each one has > pros and cons, but trying to support both models I think would make > the API even more confusing. I'm tempted to say that this case (where you don't know what the productions will be before the init) doesn't exist.?? This degenerate case is simply a keyed PRNG and could probably be handled by deriveBytes(int length). If you really want to produce keys from a keyed PRNG where the key objects are not a mixin then support both deriveKey() and deriveKey(params), but have the second throw a RuntimeException if you call it with a KDF initialized with a set of production params. >> 3) If you're doing a multiobject production from a single call to >> .init() do you expect in all cases to NOT include the production data >> as mixins? > In all cases?? I can't honestly say that.? For the protocols I know > of, the individual object attributes (like length) are not mixins.? > But you later go on to say that you know of a couple protocols where > they do.? If we have real-world scenarios where individual object > lengths or other attributes really affect the keystream then I guess > we need to take that into account. >> >> My problem is that I have use cases where ALL of my key production >> information is used as mixins to the key stream.? Now I could provide >> a List as part of the KDF init algorithm >> parameter spec (kdfParams), but that means that I have to provide a >> different APS for each different key schedule (consider TLS1.3s >> various calls). If you take out the List out >> of the .init() I'll end up having to do that and probably having to >> accept null values for the deriveKey calls. >> >> More in line. >> >> >>> >>> On 11/27/2017 10:09 AM, Michael StJohns wrote: >>>> On 11/27/2017 1:03 AM, Jamil Nimeh wrote: >>>>> >>>> >>>> HKDF and SP800-108 only deal with the creation of the key stream >>>> and ignore the issues with assigning the key stream to >>>> cryptographic objects.? In the TLS version of HDKF, the L value is >>>> mandatory and only a single object is assigned per init/call to the >>>> KDF.?? An HSM can look at the HKDF label information and set the >>>> appropriate policies for the assigned cryptographic object (because >>>> if any of the label data changes, the entire key stream changes).? >>>> That's not the case for the raw HKDF nor for any KDF that allows >>>> for multiple objects to be extracted out of a single key stream.? >>>> Hence the per-component length values. >>> So enforce a no-zero-length key policy in your provider code. You >>> probably can't affect the internals of the HSM, but you should be >>> able to prevent it in the provider code.? I can't get away from the >>> feeling that this could be dealt with in other ways besides >>> specifying all this up-front. >> >> The best way to understand this is to look at the PKCS11 TLS1.2 and >> before KDF stuff.? The key production schedule was for an encryption >> key, an integrity key and two IVs, all from the same key stream.? It >> turns out that NOTHING the HSM could do could prevent the extraction >> of key material because changing the boundaries between each object >> did not change the key stream. In the TLS case (and IPSec for that >> matter), it's a simple matter to move confidential key material into >> non-confidential IVs.? However, even if you limit the production to >> only confidential items, you still have a problem in that using the >> same key material for different algorithms (e.g. using part of an AES >> key as a single DES key) can lead to vulnerabilities. >> >> TLS 1.3 fixed this problem by only doing single key productions for >> each call to the KDF (and by adding the length of the production to >> the mixins).? Because of this, an HSM can look at the mixin data and >> "do the right thing" with respect to policy. If TLS1.3 had kept the >> multiple object production model, they would have included the >> per-object lengths in the KDF mixin data. >> >> The HSM can do the right thing because the bits it can depend upon >> (in the TLS 1.3 case the label and the length) are included in the >> mixin and not simply as part of the added on key creation stuff.? >> Without this, there is nothing an HSM can do for enforcement because >> changing these inputs wouldn't change the key stream. >> >> >>>> >>>> >>>> Ideally, there should be a complete object spec for each object to >>>> be generated that is part of the mixins (label and context) for any >>>> KDF.?? That allows an HSM to rely upon the object spec when setting >>>> policy controls for each generated object - and incidentally allows >>>> for a KDF to generate both public and non-public data in a secure way. >>> Between different generations of keystreams do you expect to have >>> different sets of policy controls?? The KDF API has no way for you >>> to set those things so I would assume those would be pretty static, >>> or at least controlled outside the KDF API. If so, why is the KDF >>> API concerning itself with how some HSM sets its policy on objects >>> it makes? >> >> If I call a KDF with the same key but with different key productions, >> I *want* the key stream to be different.? If I call it with the same >> key but with same key productions, I *want* it to be the same.?? Say >> I call the KDF to produce two objects - an AES key of length 16 bytes >> and a HMAC-SHA256 key of also length 16 bytes.? If I then call the >> same kdf with the same key to produce two AES keys of length 16 bytes >> (same overall length of the key stream, but different objects), I >> would *really* like it if the second object did not have the same key >> bytes as the HMAC-SHA256 key of the first call.?? The only way I can >> ensure this is to provide mixins that cause the entire key stream to >> change if anything changes in the key production data. > With the KDFs I know of I don't see how you're going to pull that > off.? If you call HKDF with the same key, same salt, same info, you're > going to create the same keystream, no matter how you choose to > segment it or what kinds of objects you wish to assign them to.? I > guess in your implementation of a KDF you can choose to go through the > DPS objects and mix their attributes in. > > I had been working on the model that kdfParams provides the mixins > (salt, context info, iteration count, whatever the KDF needs to make a > keystream).? That was based on how the KDFs I know of function.? Even > TLS 1.3 keys can be done via HDKF in this manner by just adding those > label and length properties to the context info field.? But if you > want your implementation to draw it from the DPS, I guess you could do > that.? It just seems like two providers providing the same algorithm > would come to different answers. See my other email.? This only works if the context field is formatted in a way that the KDF can parse it.? If the context field is opaque - none of this works. Let me give you an example case: SP800-108 counter based KDF with L of 32 bits (equal to 32 or 0x20) and counter of 32 bits.? Label is [BE EF CA FE].? Context is [01 03 10 00 00 10]. I'm producing a? AES Key? and an IV. ? Does the calling sequence give the provider any information about how many keys and IVs are being produced or how much key stream to assign to each? How about - Same underlying KDF, but the context is {{key (01), aes (03), 16 bytes}, {iv (0), generic (0), 16 bytes} which the provider reads and translates into [01 03 10 00 00 10] and calculates L from the sums of the lengths.? The same key stream is produced in both of these cases, but in the second case the key production has enforceable policy because the calling sequence provides non-opaque information. > >> >> If the mixins include policy hints (key type, key length, label, etc) >> then the HSM can rely upon those and set policy accordingly for the >> objects. > I think I alluded to that up above with TLS 1.3 key derivation using > HKDF.? The kdfParams APS for an HKDF-Expand operation would provide > context specific info in the form of an HkdfLabel.? You'd have the > key-specific info you're talking about already as part of the mixin.? > You don't need to get it from the DPS directly. >> >>>> >>>> So as long as you allow for the specification of all of the >>>> production objects as part of the .init() I'm good.?? A given KDF >>>> might not require this - but I can't see any way of fixing the >>>> current KDFs to work in HSMs without something like this. >>>> >>>>> As far as your (5) scenario goes, I can see how you can twiddle >>>>> the lengths to get the keystream output with zero-length keys and >>>>> large IV buffers.? But that scenario really glosses over what >>>>> should be a big hurdle and a major access control issue that >>>>> stands outside the KDF API: That the attacker shouldn't have >>>>> access to the input keying material in the first place.? Protect >>>>> the input keying material properly and their attack cannot be done. >>>> >>>> Let me give you an example.?? I'm running an embedded HSM - to >>>> protect TLS keys and to do all of the crypto.? An attacker >>>> compromises the TLS server and now has access to the HSM.? No >>>> problem - I'm going to notice if the attacker starts extraditing >>>> large amounts of data from the server (e.g. copies of the TLS in >>>> the clear but possibly reencrypted data stream) so this isn't a >>>> threat or is it? Smart attacker does an extraction attack on the >>>> TLS 1.2 and before KDF and turns all of the key stream material >>>> into IV material and exports it from the HSM.? The attacker now has >>>> the much smaller key material so he can send a few messages with >>>> those keys and allow for the passive external interception of the >>>> traffic and decryption thereof without the risk of detection of all >>>> that traffic being sent. Alternately, I can place the key material >>>> in a picture via steganography and publish it as part of the server >>>> data. >>> "If the attacker compromises a TLS server" is the part that gets >>> me...we're using external software bugs/security holes as a >>> justification to make the KDF API in ways that I think are less >>> clear to the consumer, to cover one class of providers (HSMs). >> >> This isn't a bug in the HSM - its a bug in thinking about how KDFs >> work/should work.??? There are three parts to a KDF - extraction of >> entropy from the master secret, expansion of that entropy into a key >> stream and finally, assignment of that key stream to cryptographic >> objects.? HKDF and SP800-108 talk about the first two, but don't >> consider the implications of the third.?? Because of this, neither >> TLS1.2 nor IPSec provide a KDF with secure key production. > When I referred to "bug" I wasn't talking about the HSM, I was > referring to the server that could be compromised, but no matter. I'm > not sure there's any KDF API out there that talks about the third > class.? Seems like they're all concerned with providing the first > two.? I had envisioned our KDF API providing equivalent functionality. HKDF-Expand-Label (the TLS1.3 KDF) actually does mostly the right thing.? The length and type (e.g. "iv" "key" "traffic upd" etc) are part of the mixins for each key assignment.? A policy aware provider can enforce appropriateness on the assignment of that key stream to an appropriate object.? It's not as clean (or as general) as I would like, but it's a vast improvement on TLS1.2 and before. I hope to get IPSec KDFs fixed at some point as well. Later, Mike From jai.forums2013 at gmail.com Thu Nov 30 02:04:36 2017 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 30 Nov 2017 07:34:36 +0530 Subject: [PATCH] JDK-8190917 : SSL session resumption, through handshake, in SSLEngine is broken for any protocols lesser than TLSv1.2 In-Reply-To: <427ca55d-e619-21e5-d803-4e829007da43@gmail.com> References: <427ca55d-e619-21e5-d803-4e829007da43@gmail.com> Message-ID: Anyone willing to sponsor/review the patch please? -Jaikiran On 24/11/17 10:52 AM, Jaikiran Pai wrote: > As noted in [1], there's a regression in Java 9, where SSL session > resumption no longer works for SSL protocols other than TLSv1.2. The > code which is responsible for session resumption resides in the > ServerHandshaker[2], in the clientHello method. This method, in its > logic to decide whether or not to resume a (previously) cached > session, checks if the client hello message has a session id > associated. If it does, it then fetches a session from the cache. If > it does find a previously cached session for that id, it then goes > ahead to check if the SSL protocol associated with the cached session > matches with the protocol version that's "applicable/selected" of the > incoming client hello message. However, a relatively recent change[3] > has, IMO, unintentionally caused the protocol version check logic to > fail for protocols other than TLSv1.2. The protocol version check > looks like: > > > // cannot resume session with different > > if (oldVersion != protocolVersion) { > resumingSession = false; > } > > The `protocolVersion` variable in this case happens to be a _default > initialized value_ (TLSv1.2) instead of the one that's "selected" > based on the incoming client hello message. As a result the > `protocolVersion` value is always TLSv1.2 and thus for any other > protocols, this comparison fails, even when the client hello message > uses the right session id and the right protocol that matches the > previous session. > > The attached patch, includes a potential fix to this issue. The change > makes sure that the protocol selection, based on the client hello > message, is done before this session resumption check and also makes > sure it uses that "selected" protocol in the version comparison check > instead of the class member `protocolVersion` (which gets set when the > server hello message is finally being sent). > > The attached patch also contains a (jtreg) test case which reproduces > this bug and verifies this fix. The test case tests the session > resumption against TLSv1, TLSv1.1 and TLSv1.2. The test code itself is > a minor modification of the SSL demo that's available here [4]. > > This is my first OpenJDK patch and my OCA got approved a few days > back. Could someone please help with the review of this patch? > > P.S: I noticed that the JIRA got assigned a few days back. I am not > sure if that means the fix is already being worked upon by someone > else from the team. If that's the case, then let me know and I'll let > it be handled by them. > > [1] https://bugs.openjdk.java.net/browse/JDK-8190917 > > [2] > http://hg.openjdk.java.net/jdk/jdk/file/b7ae1437111b/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java > > [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/42268eb6e04e > > [4] > https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sslengine/SSLEngineSimpleDemo.java > > -Jaikiran > > > From rgamarra at gmail.com Thu Nov 30 02:13:51 2017 From: rgamarra at gmail.com (rgamarra) Date: Wed, 29 Nov 2017 23:13:51 -0300 Subject: Tls 1.2 support info Message-ID: Hi there. I'd like to ask about TLS 1.2 support in open jdk 1.6 and 1.7. Starting in which version/update is the protocol supported? Is it the client-side default in any version / update? Any reference / link that can be provided will be most helpful. Regaring Oracle's version, I have found: jdk 6 update that incorportates tls 1.2 http://www.oracle.com/ technetwork/java/javase/overview-156328.html#R160_121 tls 1.2 default starting jdk 8 https://blogs.oracle.com/ java-platform-group/jdk-8-will-use-tls-12-as-default ?Thanks in advance. Best regards. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dalibor.topic at oracle.com Thu Nov 30 14:43:29 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 30 Nov 2017 15:43:29 +0100 Subject: Tls 1.2 support info In-Reply-To: References: Message-ID: <065cd319-8114-ae43-e972-7e8877bf59b3@oracle.com> On 30.11.2017 03:13, rgamarra wrote: > Hi there. > > I'd like to ask about TLS 1.2 support in open jdk 1.6 and 1.7. > OpenJDK 6 and OpenJDK 7 are currently maintained by different groups of maintainers. As such, I would suggest asking on the individual Project's mailing lists, i.e. jdk6-dev and jdk7u-dev. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From xuelei.fan at oracle.com Thu Nov 30 16:42:21 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 30 Nov 2017 08:42:21 -0800 Subject: KDF API review, round 2 In-Reply-To: <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> References: <1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net> <0211ccd4-d1b5-2ad6-3bdb-667155a81568@oracle.com> <059777b2-b402-c0e8-2534-f596ef7a00e4@comcast.net> Message-ID: <7a8a8d3a-e07d-3e36-2cbb-a2e4987a70bb@oracle.com> My apologies to break in the middle of the thread. The following attacking scenarios is a good concern to me for the API design. On 11/20/2017 8:17 AM, Michael StJohns wrote: > Example:? a given TLS session may need 2 256 bit AES keys and 2 128 bit > IVs.? That is a requirement for 96 bytes of key stream (if I've got my > calculation correct).? We have the HSM produce this (see the PKCS11 > calling sequence for example) and we get out the IVs.? An attacker who > has access to the HSM (which may or may not be on the same machine as > the TLS instantiation) can call the derivation function with new output > parameters (but with the same master key and mixins)? which specifies > only IV material and have the function output the same key stream bytes > that were previously assigned to the secret key material in the IV > output.? A very easy key extraction attack. I would like to avoid this problem if possible. But let me start from what we can do for the API design. Per my understanding, the input parameters of a KDF function may include: I-1. KDF algorithm I-2. KDF parameters I-3. derived key algorithm I-4. derived key parameters For a service provider framework, we use a service provided by the underlying provider as: P-1. search for the service (get the KDF function Java object) P-2. configure the service (configure the KDF function) P-3. use the service (derive the key) Among P-1 to P-3, where is the appropriate place to have the input parameters of a KDF function? In the current JDK framework, one cannot search for a service for the specific parameters except the service name. We may be able to twist a little bit, but I don't think there is too much we can do actually if we don't want to touch the provider framework too much. So, the first set of APIs comes out to me: KeyDerivation KeyDerivation.getInstance( String kdfAlgorithm, // I-1 Provider kdfProvider) and its variants. For P-2, configure the service, we can name the API as init(), serParameters() or configure(), or others. If we configure all of the following input parameters here: I-2. KDF parameters I-3. derived key algorithm I-4. derived key parameters the APIs may looks like: void configure(KDF-Params, Key-Algorithm, Key-Params) // P-2 Key deriveKey(); // P-3 From an application developer view of point, I'm uncomfortable to put a very hard limit of the P-3 possibilities in P-2 stage. No parameters for the deriveKey() method make me nervous because I don't actually know what the key is actually is for the developers and code reviewers. I would like to keep it simple that, in configuration period, configure the KDF function only, but not configure the derived key in general. OK, the 2nd set of APIs comes out to me (you can use init/setPara as the method name). void configure(KDF-Params) // I-2. and its variants if needed. If you agree with the above two stages, there is not much flexible for the 3rd stage (P-3). The 3rd set of APIs may looks like: Key deriveKey(Key-Algorithm, Key-Params) // I-3, I-4 and it variants if needed. Back to the Michael's attacking scenarios above. It's a really good argue. The point does not only apply to hardware implementation, it applies to software implementation too. IVs can be public, while secret key need to be secret. If there is a mixin, the weakness may be able to used by delicately designed attacking scenarios. I would like to use the existing methods above, but customize the KDF-Params instead. In the KDF-Params spec, we can specify the insensitive sections of the keying materials so that they can be used for IV and other purpose other than keys, if needed. The derived key is extractable only when the key materials is from the insensitive sections. Xuelei From rgamarra at gmail.com Thu Nov 30 16:53:50 2017 From: rgamarra at gmail.com (rgamarra) Date: Thu, 30 Nov 2017 13:53:50 -0300 Subject: Tls 1.2 support info In-Reply-To: <9ebd4743-4084-c6ef-8714-696878519d6c@suche.org> References: <065cd319-8114-ae43-e972-7e8877bf59b3@oracle.com> <9ebd4743-4084-c6ef-8714-696878519d6c@suche.org> Message-ID: Thank you for your response Thomas. I'm connecting to a backend that will start to require tls 1.2. Indeed, my question is general regarding tls 1.2 overall support. >From your answer I understand that: - there's no update to open jdk 1.6 that supports tls 1.2. - open jdk 1.7 supports tls 1.2 since its initial release. It's not clear to me from your answer whether tls 1.2 is the default option for any open jdk 1.7 version/update. In case it's not the default option, any advice on how to enable it will be most helpful. Thanks. On Nov 30, 2017 12:47 PM, "Thomas Lu?nig" wrote: Hi, maybe you could tell more what you need to know about TLS 1.2 support? Do you wan't an general overview of features (Stappling, SC, ...) or are you are you interested in the available cipher suites. If you are so general the simple answer is that TLS 1.2 is supported as client and server on open jdk 1.7 at least. Gru? Thomas On 11/30/2017 3:43 PM, dalibor topic wrote: > On 30.11.2017 03:13, rgamarra wrote: > >> Hi there. >> >> I'd like to ask about TLS 1.2 support in open jdk 1.6 and 1.7. >> >> OpenJDK 6 and OpenJDK 7 are currently maintained by different > groups of maintainers. As such, I would suggest asking on the individual > Project's mailing lists, i.e. jdk6-dev and jdk7u-dev. > > cheers, > dalibor topic > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Thu Nov 30 22:02:15 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Nov 2017 14:02:15 -0800 (PST) Subject: JEP 319: Root Certificates Message-ID: <20171130220215.2AC5F10B905@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/319 - Mark From lussnig at suche.org Thu Nov 30 15:46:40 2017 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Thu, 30 Nov 2017 16:46:40 +0100 Subject: Tls 1.2 support info In-Reply-To: <065cd319-8114-ae43-e972-7e8877bf59b3@oracle.com> References: <065cd319-8114-ae43-e972-7e8877bf59b3@oracle.com> Message-ID: <9ebd4743-4084-c6ef-8714-696878519d6c@suche.org> Hi, maybe you could tell more what you need to know about TLS 1.2 support? Do you wan't an general overview of features (Stappling, SC, ...) or are you are you interested in the available cipher suites. If you are so general the simple answer is that TLS 1.2 is supported as client and server on open jdk 1.7 at least. Gru? Thomas On 11/30/2017 3:43 PM, dalibor topic wrote: > On 30.11.2017 03:13, rgamarra wrote: >> Hi there. >> >> I'd like to ask about TLS 1.2 support in open jdk 1.6 and 1.7. >> > OpenJDK 6 and OpenJDK 7 are currently maintained by different > groups of maintainers. As such, I would suggest asking on the individual > Project's mailing lists, i.e. jdk6-dev and jdk7u-dev. > > cheers, > dalibor topic >