Re: contribute to the OpenJDK security group

[Tomas Gustavsson]

Sorry for jumping in :-)

Imho the P11 layer always needs attention. To work properly we're
relying on some patches, where parts was recently merged into OpenJDK.
We just started testing the Amazon CloudHSM, and that requires changes
to SunPKCS11 as well to work. Not always bad in SunPKCS11 as some P11
libraries out there do strange non-conforming stuff, but there's room
for more flexibility nevertheless.

Cheers,
Tomas

On 2018-01-17 20:09, Leo Grove wrote:
> Thanks Sean, I've filled out the OCA and sent it in. I'll take a gander
> around after reading up on the link you posted and see where we might be
> able to jump in and assist.
> 
> Leo
> 
> 
> On 1/17/2018 7:53 AM, Sean Mullan wrote:
>> Hi Leo,
>>
>> Thanks for the offer to help and contribute! I would suggest you start
>> by reading the OpenJDK contribution page (if you have not done so
>> already):
>>
>> http://openjdk.java.net/contribute/
>>
>> which has some tips and other helpful advice. You will also need to
>> sign an OCA (Oracle Contributor Agreement) before we can accept any
>> contributions.
>>
>> Thanks,
>> Sean
>>
>> On 1/16/18 9:03 PM, Leo Grove wrote:
>>> Hello Everyone,
>>>
>>> I'd like to introduce myself. I'm Leo Grove, founder of SSL.com and
>>> also Java Certified Programmer ('98). Although I'm not so much into
>>> coding these days, I'm always looking for ways to contribute to
>>> internet security and the public WebPKI. We do have some very sharp
>>> java developers that specialize in PKI and certs, so if there is
>>> something you need a hand with (or a pair of eyeballs on), please let
>>> me know, thanks.
>>
>>
> 

Re: Update mechanism for the upcoming trust store

[Fotis Loukos]

Hello Sean,

On 23/01/2018 09:12 μμ, Sean Mullan wrote:
> Hi Fotis,
> 
> This is an interesting issue and I agree it is important. From your post
> it seems that each implementation has come up with a different mechanism
> for solving this problem, which is unfortunate - it would be more ideal
> if we could converge on a standard mechanism for addressing it. There
> certainly seems that there is a need for that. Do you know if anything
> is being discussed along those lines?

There is RFC5914 which describes the Trust Anchor Format. It can be used
to create a trust store by populating a TrustAnchorList SEQUENCE. I am
not sure if there is some standard implementation in Java, but it
shouldn't be difficult to implement something like this.

In order to be able to verify the data, I think that the best practice
is to encapsulate and sign everything using the CMS/PKCS#7 format, as
described in RFC5652. The signing certificate could chain to a CA which
is built in the JDK.

Thus, you will only have to include a single certificate in the JDK
which will be used to verify the whole trust store. Of course, after
parsing it, it can be converted to some other format. I would suggest to
keep all the information in the TrustAnchorInfo structure for every CA
in order to be able to support other extensions in the future, such as
EV certificates.

> 
> You may not be aware, but the JDK does currently support a mechanism for
> blacklisting certificates. The lib/security/blacklisted.certs file
> contains a list of the fingerprints of certificates that are explicitly
> distrusted. If a root was compromised and added to this file it would no
> longer be trusted.

My biggest concern is what you describe below, the dynamic update.

> 
> However, currently there is no mechanism in OpenJDK to dynamically
> update that file. While I think there is merit in implementing something
> like that, many challenges would need to be addressed as part of that,
> for example, where and how does this file get updated, how is it
> verified, etc.

The verification step can be implemented as described above. I think
that the update step requires some design, but I don't think it is that
difficult. For example, a naive algorithm such as every Monday plus a
random number of days/hours/minutes in order to avoid heavy traffic
during the update period would be good for starters. As a first step to
try a new format, you could even fetch it once during installation and
provide a means for the user to update it manually.

Regards,
Fotis Loukos

> 
> Thanks,
> Sean
> 
> On 1/18/18 11:03 AM, Fotis Loukos wrote:
>> Hello everybody,
>> I am watching the effort of the community to create a new trust store
>> (JEP319). Based on the description, a trust store will be created which
>> will be shipped with every release.
>> I think that this is a really good step, however I believe that a
>> different approach should be used, namely create an API that will be
>> used to automatically populate the local trust store. If not a full API,
>> even downloading the cacerts file from a secure location would be better.
>> This will help in applying trust decisions in a more efficient way. Past
>> experience has shown us that there have been CAs which unfortunatelly
>> misissued certificates. One of the most famous examples is the Diginotar
>> case. Waiting for the next release of openjdk may leave a lot of people
>> vulnerable to such attacks at CAs. Most major trust store operators have
>> already implemented mechanisms to immediately take trust decisions,
>> until they are integrated in the next release. For example, Mozilla uses
>> OneCRL and Google uses CRLSet. Microsoft has taken a different approach
>> and publishes their whole trust store using the authroot.stl file and
>> specific distrusted certs using the disallowedcerts.stl file. The same
>> approach is being used by Adobe publishing the trust store at
>> http://trustlist.adobe.com/tl12.acrobatsecuritysettings and Cisco
>> publishing the different trust stores under
>> https://www.cisco.com/security/pki/trs/. These trust stores are
>> regularly fetched in order for the operators to be able to respond to CA
>> security incidents as soon as possible. As far as I know, Apple is going
>> to create an API for this.
>> Publishing the whole trust store will also help developers who create
>> validation programs that check against different trust stores. Many
>> sites exist such as the ssl labs tests, that need to have access to a
>> software's trust store, and making an automated mechanism to fetch it
>> would be really useful.
>>
>> Regards,
>> Fotis Loukos
>>


-- 
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fot...@ssl.com
w: https://www.ssl.com

Re: contribute to the OpenJDK security group

[Andrew Haley]

On 24/01/18 10:39, Tomas Gustavsson wrote:
> Imho the P11 layer always needs attention. To work properly we're
> relying on some patches, where parts was recently merged into OpenJDK.
> We just started testing the Amazon CloudHSM, and that requires changes
> to SunPKCS11 as well to work. Not always bad in SunPKCS11 as some P11
> libraries out there do strange non-conforming stuff, but there's room
> for more flexibility nevertheless.

Martin Balao has been heavily reworking this layer because it leaks
native memory.  I'll let him fill you in on the details.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

RFR 8177398: Exclude dot files ending with .conf from krb5.conf's includedir

[Weijun Wang]

Please take a review at

   http://cr.openjdk.java.net/~weijun/8177398/webrev.00/

Dotfiles will not be included in "includedir" of krb5.conf.

Thanks
Max

Re: RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed

[sha . jiang]

Hi Max, Xuelei,
Please review this updated patch: 
http://cr.openjdk.java.net/~jjiang/8186098/webrev.01/

Both of your suggestions are addressed.

Best regards,
John Jiang

On 24/01/2018 12:20, Weijun Wang wrote:



On Jan 24, 2018, at 11:28 AM, sha.ji...@oracle.com wrote:

Hi Max,

On 23/01/2018 17:49, Weijun Wang wrote:

Can you show us why the new code works?

The test assumes that nss3 lib contains a string likes:
$Header: NSS version.number, e.g. "$Header: NSS 3.16.2"
or
Version: NSS version.number, e.g. "Version: NSS 3.34.1"

But the current test expects that the version.number is followed by a space immediately. 
For example, "$Header: NSS 3.16.2 Basic". So, it tries to locate the next space 
index for parsing the version.
Unfortunately, that assumption is not true on some NSS builds. For example, 
"Version: NSS 3.34.1�
".

I see.

BTW, the byte-to-string conversion looks a little strange as the data is pure 
binary. Maybe you can use StandardCharsets.US_ASCII to be safe.

--Max


This fix just cares the chars, such as "." or "0-9", after "$Header: NSS " or "Version: NSS ". If a 
char, which is not in the specific char set ("." or "0-9"), is met, that means the version has been extracted.


  What does "s" looks like?

The followings are some snippets of nss3 lib from different NSS builds.
1. NSS 3.16.2 on macosx
Content-Length: %u

Re: RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed

[Weijun Wang]

The change looks fine.

Thanks
Max

> On Jan 25, 2018, at 1:52 PM, sha.ji...@oracle.com wrote:
> 
> Hi Max, Xuelei,
> Please review this updated patch: 
> http://cr.openjdk.java.net/~jjiang/8186098/webrev.01/
> Both of your suggestions are addressed.
> 
> Best regards,
> John Jiang
> 
> On 24/01/2018 12:20, Weijun Wang wrote:
>> 
>>> On Jan 24, 2018, at 11:28 AM, sha.ji...@oracle.com wrote:
>>> 
>>> Hi Max,
>>> 
>>> On 23/01/2018 17:49, Weijun Wang wrote:
 Can you show us why the new code works?
>>> The test assumes that nss3 lib contains a string likes:
>>> $Header: NSS version.number, e.g. "$Header: NSS 3.16.2"
>>> or
>>> Version: NSS version.number, e.g. "Version: NSS 3.34.1"
>>> 
>>> But the current test expects that the version.number is followed by a space 
>>> immediately. For example, "$Header: NSS 3.16.2 Basic". So, it tries to 
>>> locate the next space index for parsing the version.
>>> Unfortunately, that assumption is not true on some NSS builds. For example, 
>>> "Version: NSS 3.34.1�
".
>> I see.
>> 
>> BTW, the byte-to-string conversion looks a little strange as the data is 
>> pure binary. Maybe you can use StandardCharsets.US_ASCII to be safe.
>> 
>> --Max
>> 
>>> This fix just cares the chars, such as "." or "0-9", after "$Header: NSS " 
>>> or "Version: NSS ". If a char, which is not in the specific char set ("." 
>>> or "0-9"), is met, that means the version has been extracted.
>>> 
  What does "s" looks like?
>>> The followings are some snippets of nss3 lib from different NSS builds.
>>> 1. NSS 3.16.2 on macosx
>>> Content-Length: %u
>> 
>