On Wed, Jan 7, 2015 at 4:04 AM, Nikos Mavrogiannopoulos <nmav(a)redhat.com>
On Tue, 2015-01-06 at 12:16 -0500, Christopher wrote:
> Are there any guidelines for enforcing crypto policies in Java
> Primarily, I was thinking about those Java applications that use JSSE
> system properties or similar user-driven configuration to specify
> keystores. Are those affected by this crypto policy at all?
Not yet. I haven't started a process on that, as I'd like to have time
to spend on the successful deployment on openssl, gnutls and hopefully
nss. However, maybe we don't need to do everything in a serialized way.
If you are interested in that, may I suggest to fill feature request
with the relevant java packages shipped in fedora?
I've put a tracker of the crypto policies applicability at:
> Also, what about situations where SSL/TLS is off by default in the
> application, but is an available as an optional feature, if the user
> configures it? Since users are obliged to configure it, it seems
> there's not much for a packager to do in those situations, because
> that depends on the user's configuration, right?
I'm not sure I understand the question. Let's see wget.
----> no ssl
----> ssl with system wide policies
wget --secure-protocol=TLSv1 -----> application/user specific policy
That is the default policies should be used if the user simply asks for
SSL/TLS without being more specific.
I was more curious about services (vs. clients) which provide optional
SSL/TLS features (httpd, as a representative example case), and how this
policy would apply to the default configs for such services. My package,
accumulo, has such a feature, but a user has to edit configuration to turn
it on, specifying keystores, truststores, algorithms, etc. (analogous to
httpd). The default config ships with it turned off, because it's a lot of
overhead, and the primary use case (in a cloud) doesn't require secure
connections. I just want to make sure that if this policy affects me, I do
the right thing to comply. It doesn't seem like it affects me, as I