Re: Update mechanism for the upcoming trust store
Hello Sean, On 29/01/2018 04:30 μμ, Fotis Loukos wrote: > On 26/01/2018 11:31 μμ, Sean Mullan wrote: >> On 1/24/18 5:39 AM, Fotis Loukos wrote: >>>> 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. >> >> One thing we could potentially do initially is to provide a stable https >> URL where an updated blacklist could be downloaded, something like what >> Mozilla does for OneCRL [1]. This would be an initial step, not the >> whole solution of course, but it at least would allow someone to quickly >> update their JDK should a certificate need to be distrusted ASAP. >> >> Let me look into that a bit. >> >> I think implementing a dynamic solution is more challenging and would >> require more design/review, etc but feel free to provide more details on >> any additional thoughts or design sketches you might have. > > I find it pretty important to ensure that the file is also signed and > not just served over https. I was wondering if the community runs a > private CA, or has access to an HSM that can be used to generate and > store a private key that will sign these files. > Do you have any info on this? Is there a way to sign these files securely, or should we find a different method of packaging them? Regards, Fotis > Regards, > Fotis > >> >> --Sean >> >> [1] >> https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records >> >> >> > > -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: fot...@ssl.com w: https://www.ssl.com
Re: Update mechanism for the upcoming trust store
On 26/01/2018 11:31 μμ, Sean Mullan wrote: > On 1/24/18 5:39 AM, Fotis Loukos wrote: >>> 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. > > One thing we could potentially do initially is to provide a stable https > URL where an updated blacklist could be downloaded, something like what > Mozilla does for OneCRL [1]. This would be an initial step, not the > whole solution of course, but it at least would allow someone to quickly > update their JDK should a certificate need to be distrusted ASAP. > > Let me look into that a bit. > > I think implementing a dynamic solution is more challenging and would > require more design/review, etc but feel free to provide more details on > any additional thoughts or design sketches you might have. I find it pretty important to ensure that the file is also signed and not just served over https. I was wondering if the community runs a private CA, or has access to an HSM that can be used to generate and store a private key that will sign these files. Regards, Fotis > > --Sean > > [1] > https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records > > > -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: fot...@ssl.com w: https://www.ssl.com
Update mechanism for the upcoming trust store
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: sun.security.x509.DNSName leading dot in name constraints
Hello, On 06/09/2015 03:12 PM, Sean Mullan wrote: On 06/09/2015 07:21 AM, Sean Mullan wrote: -Bcc jdk9-dev This question is more appropriate for security-dev, so I am copying that list for further discussion. --Sean On 06/09/2015 02:21 AM, Vyronas Tsingaras wrote: Hi all, I work for the Hellenic Academic and Research Institutions Certification Authority (https://www.harica.gr), a Root Certification Authority included in the NSS, Microsoft and Apple certificate stores. Our RootCA certificate uses the name constraints extension with a small error, instead of just gr, org and edu in the permitted subtrees it has .gr, .edu and .org. As a result certificates issued under our CA fail to verify with Java. We had the same issue with OpenSSL and gnuTLS but fortunately they modified their implementation to accommodate for our situation. I kindly ask if this is something that could also be done with OpenJDK, and if so what would be the best way to implement that. Currently we have a patch against the 'constrains' method of 'DNSName' that just ignores the leading dot in name constraints. We don't make exceptions for cases like this, as it is not compliant with RFC 5280. However, are the name constraints only on the root certificate? When specified this way, they are optional (see RFC 5280 section 6.2). Our implementation does not process them by default (you must specify them as an optional parameter to the TrustAnchor class). Are the name constraints included in other certificates chaining back to the root? According to RFC 5280 DNS name restrictions are not domain names. For checking if a constraint is satisfied, you should add zero or more labels to the left-hand side of the constraint and then you generate the domain name. Thus, we believe that our implementation is compliant with RFC 5280. As you noticed, by default the name constraints at the trust anchor are not checked, however we wanted to know if it is possible to successfully validate certificates if they are enforced by the programmer at his application. Regards, Fotis Loukos, PhD HARICA Public Key Infrastructure --Sean Kind Regards, Vyronas Tsingaras, Aristotle University of Thessaloniki, IT Center
