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
