Tls 1.2 support info
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.
Re: [PATCH] JDK-8190917 : SSL session resumption, through handshake, in SSLEngine is broken for any protocols lesser than TLSv1.2
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
Re: KDF API review, round 2
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
Re: KDF API review, round 2
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
Re: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields
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
RFR 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite
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
Re: KDF API review, round 2
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
