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
Re: Update mechanism for the upcoming trust store
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. --Sean [1] https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records
Re: Update mechanism for the upcoming trust store
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? 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. 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. 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
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
