Re: RFR 8177784 Use CounterMode intrinsic for AES/GCM

[Sean Mullan]

On 4/7/17 3:47 PM, Anthony Scarpino wrote:

On 04/07/2017 06:58 AM, Chris Hegarty wrote:

On 06/04/17 21:39, Anthony Scarpino wrote:


I'd like to get a review for this performance change to use the existing
CounterMode parallelized intrinsic instead of GCTR's own version. The
two classes were nearly identical except for the doFinal() method which
doesn't belong in CounterMode.java.

I could have been more aggressive with this change, but I'm looking to
get this into 9, so I stayed away from completely merging GCTR into
CounterMode in case of incompatibilities.  All tests security and
hotspot tests pass.

http://cr.openjdk.java.net/~ascarpino/8177784/webrev/


This change looks good to me. Trivially, the class-level comment in
GCTR should be updated ( it refers to removed fields ). Also,
CounterMode.counter could be protected ( rather than package-private ).

-Chris.


Thanks Chris,

I left CounterMode.counter as package-private because the package is
what becomes the SunJCE provider.  I don't believe there should be any
outside package classes accessing this code.


I agree it is better to keep it package-private since the field is not 
intended to be ever accessed outside the package, and keeping it 
package-private is in general a better practice for writing secure code. 
See also Guideline 4-1 of Java Secure Coding Guidelines: 
http://www.oracle.com/technetwork/java/seccodeguide-139067.html#4


--Sean

Re: RFR 8177784 Use CounterMode intrinsic for AES/GCM

[Sean Mullan]

On 4/6/17 4:39 PM, Anthony Scarpino wrote:


I'd like to get a review for this performance change to use the existing
CounterMode parallelized intrinsic instead of GCTR's own version. The
two classes were nearly identical except for the doFinal() method which
doesn't belong in CounterMode.java.

I could have been more aggressive with this change, but I'm looking to
get this into 9, so I stayed away from completely merging GCTR into
CounterMode in case of incompatibilities.


If there is some additional followon work or additional performance 
improvement that you think should be done, please file that as a 
separate issue.



All tests security and
hotspot tests pass.

http://cr.openjdk.java.net/~ascarpino/8177784/webrev/


GCTR.java:

I had one question about the clone on line 62 -- it did not seem 
necessary as the array was subsequently copied in the reset method and I 
don't think the iv is needed again. Also a nit on line 66, add @Override 
to getFeedback(). Also, not part of your change but the doFinal method 
does not need to be protected - package-private is fine/better.


Otherwise, it looks good to me.

--Sean

Re: RFR 8177784 Use CounterMode intrinsic for AES/GCM

[Paul Sandoz]

> On 7 Apr 2017, at 12:47, Anthony Scarpino  wrote:
> 
> On 04/07/2017 06:58 AM, Chris Hegarty wrote:
>> On 06/04/17 21:39, Anthony Scarpino wrote:
>>> 
>>> I'd like to get a review for this performance change to use the existing
>>> CounterMode parallelized intrinsic instead of GCTR's own version. The
>>> two classes were nearly identical except for the doFinal() method which
>>> doesn't belong in CounterMode.java.
>>> 
>>> I could have been more aggressive with this change, but I'm looking to
>>> get this into 9, so I stayed away from completely merging GCTR into
>>> CounterMode in case of incompatibilities.  All tests security and
>>> hotspot tests pass.
>>> 
>>> http://cr.openjdk.java.net/~ascarpino/8177784/webrev/
>> 
>> This change looks good to me. Trivially, the class-level comment in
>> GCTR should be updated ( it refers to removed fields ). Also,
>> CounterMode.counter could be protected ( rather than package-private ).
>> 
>> -Chris.
> 
> Thanks Chris,
> 
> I left CounterMode.counter as package-private because the package is what 
> becomes the SunJCE provider.  I don't believe there should be any outside 
> package classes accessing this code.
> 
> I updated the webrev at with the comment update:
>  http://cr.openjdk.java.net/~ascarpino/8177784/webrev.01/
> 

It’s the same pattern for “iv” with CounterMode and FeedbackCipher, although i 
prefer protected as well if never accessed by other classes in the same 
package, it makes it easier to reason about the code, since i know more about 
what can access it.

Suggestion, take it or leave it: personally i would prefer to see an additional 
constructor in CounterMode:

  GCTR(SymmetricCipher cipher, byte[] initialCounterBlk) {
super(cipher, checkBlockSize(initialCounterBlk));
   }

Where new CounterMode constructor performs the clone, assignmentm and reset, 
the static method checkBlockSize checks the array length is equal to 
AES_BLOCK_SIZE Thereby you have a cleaner separation of concerns.

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR[8u] JDK-8157035: Use stronger algorithms and keys for JSSE testing

[Seán Coffey]

Looks good to me Prasad. Thanks for fixing this.

Regards,
Sean.

On 10/04/17 07:02, Prasadrao Koppula wrote:


Hi,

Please review this patch for “JDK-8157035: Use stronger algorithms and 
keys for JSSE testing”


Issue:

https://bugs.openjdk.java.net/browse/JDK-8157035

Webrev:

http://cr.openjdk.java.net/~coffeys/webrev.8157035.jdk8u/ 



Changes:

sun/security/ssl/etc/truststore and truststore are having old certs 
with weaker algorithms. Due to this, in some of the tests, 
“jdk.certpath.disabledAlgorithms” property is hardcoded with empty 
string(“”).


It’s not direct backport. Following changes are made in addition to 
JDK9 changes.


-Removed hardcoded value for jdk.certpath.disabledAlgorithms property 
in bellow test files.


otest/javax/net/ssl/ciphersuites/DisabledAlgorithms.java

otest/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java

Thanks,

Prasad.K

RE: JGSS-API supporting SSPI on Windows

[Chan, Sunny]

So just to clarify my understanding, this situation is similar to how Swing and 
AWT related to each other - Traditional Delegation for GSS-API is that most 
processing is done in Java code, so it will need access to Session Key in order 
to decrypt the ticket directly and communicate with the Kerberos server. While 
Microsoft's Constrained delegation is like AWT where all the authentication 
operations are delegated to Windows and JGSS is merely a wrapper to those API?

Let's assume if we implement a Constrained Delegation client just for Windows 
and only turned on via a security property, would that be acceptable solution?

-Original Message-
From: Weijun Wang [mailto:weijun.w...@oracle.com] 
Sent: 10 April 2017 16:05
To: Chan, Sunny [Tech]; 'security-dev@openjdk.java.net'
Subject: Re: JGSS-API supporting SSPI on Windows

Hi Sunny

If I understand correctly, the major difference between SSPI and GSS-API is 
delegation. In GSS-API, the client initiates the delegation by forwarding a 
credential to the intermediate server so the latter can use this delegated 
credential to access a backend server on behalf of the client. In SSPI, the 
intermediate server itself asks the KDC (Active Directory Domain Server) 
whether it can impersonate a client to access the backend server. Microsoft 
calls it constrained delegation.

Java supports both traditional delegation and constrained delegation, but if we 
add SSPI as a JGSS-API provider, it can only support constrained delegation.

Implementing SSPI requires quite a lot of coding, including both Java and C 
codes. There will also be quite some testing work.

A partial solution is to only support Windows' native service ticket retrieval. 
This means we can bypass the TGT (where AllowTGTSessionKey is
needed) and acquire a service ticket directly. After this ticket is available, 
we still use the current Java codes to access the service. 
This solution also won't support traditional delegation.

There is no decision yet.

Any contribution is welcomed.

Thanks
Weijun

On 04/10/2017 12:46 PM, Chan, Sunny wrote:
> Hello,
>
> Windows has changed the default such that the session key is not 
> included in TGT, and for Windows SSO to work with Java implementation 
> out of the box it will required AllowTGTSessionKey options to be added 
> to the registry. However, this options has associated security risk as 
> it expose the session key to all apps, and it also means that right 
> now Kerberos SSO in Windows does not work out of the box
>
> Looking at the Java bug database, there has been suggestion that Java 
> could support SSPI as a JGSS-API provided which would allow Java to 
> work out of the box without the AllowTGTSessionKey options.
> (https://urldefense.proofpoint.com/v2/url?u=http-3A__bugs.java.com_bug
> database_view-5Fbug.do-3Fbug-5Fid-3D6722928=DgID-g=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZlX4=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3m5E=tVm1uVTgadiBY_OTgDIvULQDi4i4YBQTTE8cwwJhW9M=U0di20MO97JRZDulQs-1MtqrEE4yo9nygL-WvEBkZjM=
>  ). However, in the evaluation it says:
>
> Might support it, although I hope most of the functions of Windows 
> SSPI can also be supported by pure Java. Interop is important between 
> different platforms
>
> I would like to understand what is the "Interop" concern here? Have we 
> evaluated how much work need to do to support it (so that we can 
> consider contributing the implementation)?
>
> *Sunny Chan*
> Executive Director
> Technology
>
> *Goldman Sachs (Asia) L.L.C.*| 39th Floor | The Center | 99 Queens 
> Road Central | Hong Kong
>
> Email:  sunny.c...@gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633

Re: JGSS-API supporting SSPI on Windows

[Weijun Wang]

Hi Sunny

If I understand correctly, the major difference between SSPI and GSS-API 
is delegation. In GSS-API, the client initiates the delegation by 
forwarding a credential to the intermediate server so the latter can use 
this delegated credential to access a backend server on behalf of the 
client. In SSPI, the intermediate server itself asks the KDC (Active 
Directory Domain Server) whether it can impersonate a client to access 
the backend server. Microsoft calls it constrained delegation.


Java supports both traditional delegation and constrained delegation, 
but if we add SSPI as a JGSS-API provider, it can only support 
constrained delegation.


Implementing SSPI requires quite a lot of coding, including both Java 
and C codes. There will also be quite some testing work.


A partial solution is to only support Windows' native service ticket 
retrieval. This means we can bypass the TGT (where AllowTGTSessionKey is 
needed) and acquire a service ticket directly. After this ticket is 
available, we still use the current Java codes to access the service. 
This solution also won't support traditional delegation.


There is no decision yet.

Any contribution is welcomed.

Thanks
Weijun

On 04/10/2017 12:46 PM, Chan, Sunny wrote:

Hello,

Windows has changed the default such that the session key is not
included in TGT, and for Windows SSO to work with Java implementation
out of the box it will required AllowTGTSessionKey options to be added
to the registry. However, this options has associated security risk as
it expose the session key to all apps, and it also means that right now
Kerberos SSO in Windows does not work out of the box

Looking at the Java bug database, there has been suggestion that Java
could support SSPI as a JGSS-API provided which would allow Java to work
out of the box without the AllowTGTSessionKey options.
(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6722928). However,
in the evaluation it says:

Might support it, although I hope most of the functions of Windows SSPI
can also be supported by pure Java. Interop is important between
different platforms

I would like to understand what is the “Interop” concern here? Have we
evaluated how much work need to do to support it (so that we can
consider contributing the implementation)?

*Sunny Chan*
Executive Director
Technology

*Goldman Sachs (Asia) L.L.C.*| 39th Floor | The Center | 99 Queens Road
Central | Hong Kong

Email:  sunny.c...@gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633

RFR[8u] JDK-8157035: Use stronger algorithms and keys for JSSE testing

[Prasadrao Koppula]

Hi,

 

Please review this patch for "JDK-8157035: Use stronger algorithms and keys for 
JSSE testing"

 

Issue: 

https://bugs.openjdk.java.net/browse/JDK-8157035 

Webrev: 

HYPERLINK 
"http://cr.openjdk.java.net/%7Ecoffeys/webrev.8157035.jdk8u/"http://cr.openjdk.java.net/~coffeys/webrev.8157035.jdk8u/
 

 

Changes:



sun/security/ssl/etc/truststore and truststore are having old certs with weaker 
algorithms. Due to this, in some of the tests, 
"jdk.certpath.disabledAlgorithms" property is hardcoded with empty string("").

 

It's not direct backport. Following changes are made in addition to JDK9 
changes.

 

-  Removed hardcoded value for jdk.certpath.disabledAlgorithms property 
in bellow test files.

o   test/javax/net/ssl/ciphersuites/DisabledAlgorithms.java

o   test/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java

 

 

Thanks,

Prasad.K