Bug 1249083 - java SSL/TLS implementation: should follow the policies of system-wide crypto policy
java SSL/TLS implementation: should follow the policies of system-wide crypto...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: java-1.8.0-openjdk (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Andrew John Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks: fedora-crypto-policies 1335909 1340845
  Show dependency treegraph
 
Reported: 2015-07-31 09:12 EDT by Nikos Mavrogiannopoulos
Modified: 2017-11-14 02:11 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-15 08:03:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Icedtea Bugzilla 3183 None None None 2016-09-29 05:11 EDT

  None (edit)
Description Nikos Mavrogiannopoulos 2015-07-31 09:12:30 EDT
As it is now Java's configuration for SSL is set using properties in jre/lib/security/java.security and the administrator is responsible for doing any changes to it.

It would be simpler for Java to follow the system-wide crypto policy [0] by default and unless the administrator changes the configuration the policies will be kept up to date and will be consistent with the policies followed in other parts of the system.

The simplest approach for that would be for Java to be able to include a file in its default configuration files, and thus include a file which has been auto-generated.

That would also simplify an administrators job by not requiring to review configuration settings as recommended by: https://bettercrypto.org/static/applied-crypto-hardening.pdf

[This is a proposal for collaboration, please let me know whether that can be done in our current setup of Java and how, and if not, the steps that are required to achieve that goal]

[0]. http://fedoraproject.org/wiki/Changes/CryptoPolicy
Comment 1 Andrew John Hughes 2015-07-31 09:38:29 EDT
Can you provide an example of the configuration file you would want included?
Has the system described in [0] being employed anywhere other than Fedora?

I think this would require fairly significant changes to security configuration in OpenJDK, which would need to go upstream first. It does seem like a worthwhile goal though.
Comment 2 Nikos Mavrogiannopoulos 2015-07-31 10:45:18 EDT
From what I see in the java config file most likely we need to only modify the following options:
* jdk.tls.disabledAlgorithms=...
* jdk.certpath.disabledAlgorithms=...

The way it is done currently, is to auto-generate a file based on some criteria selected for the Fedora release [0]. The generation of that file is done when, "update-crypto-policies" is run. Typically the generated file is either "included" by the master config file.

Is the inclusion part that you mean that may need significant changes upstream? Other than that, if that approach is followed, I don't believe we need upstream changes.

[0]. https://github.com/nmav/fedora-crypto-policies
Comment 3 Andrew John Hughes 2015-07-31 11:03:25 EDT
Yes. For something as important as cryptography support, I don't want Fedora carrying some local hack that overrides the defaults.

AIUI, OpenJDK will need to look at this auto-generated file and use its settings if they are not overridden in java.security.

The difficulty is that java.security will have settings for these values, and there's no way to tell if they are from the default file supplied with OpenJDK or provided by the user i.e. you're effectively providing a third source of configuration for OpenJDK, in addition to the default OpenJDK settings and whatever the user sets.
Comment 6 Andrew John Hughes 2015-07-31 19:06:09 EDT
Nikos, could you please supply an example configuration file that would be made available by this feature, together with information on where it would be located? Thanks.
Comment 7 Nikos Mavrogiannopoulos 2015-08-02 09:19:31 EDT
I believe there is some misunderstanding. Let me rephrase. The requirement we have for system-wide crypto policies is to be able to modify the two options quoted above.

The question is can this be done without any code changes (e.g., by auto-generating the jdk's configuration file from a template), or by using an 'include' directive to include the auto-generated part?

Let's first explore this path before going to any changes in the code (which I agree they should not be Fedora specific). What is the blocker for the path above?
Comment 8 Andrew John Hughes 2015-08-26 10:54:44 EDT
Adding some form of inclusion would require code changes, which is why I headed down that track.

Users also modify this file so auto-generation of it directly seems problematic.

I really need examples of what you plan to generate from your tool. Also, is this available on anything other than Fedora?
Comment 21 Nikos Mavrogiannopoulos 2015-10-05 04:07:20 EDT
I've just updated crypto-policies in rawhide to generate /etc/crypto-policies/back-ends/java.config

I've tested all 3 generated configurations manually and the advertized ciphers are the expected ones. Please update this bug on any updates.
Comment 24 Jan Kurik 2016-02-24 08:30:24 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 27 Nikos Mavrogiannopoulos 2016-04-19 05:23:08 EDT
I've added a basic check for java policies, which can also be used to verify (manually) the ciphersuites expected on each level. Andrew any comments welcome. As it is now I use the presence of the SCSV ciphersuite as an indicator that the file was properly parsed, since I couldn't figure a better way.

https://github.com/nmav/fedora-crypto-policies/commit/88f0adc75e995ea9ef22ba2b0afc888fb2171154
Comment 28 Nikos Mavrogiannopoulos 2016-05-19 09:57:31 EDT
Added Fedora 25 change request.
https://fedoraproject.org/wiki/Changes/JavaCryptoPolicies
Comment 29 Andrew John Hughes 2016-11-03 00:16:25 EDT
Here's the patch:

http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/1c4d5cb2096a

Jiri, please add this to the Fedora RPMs.
Comment 30 jiri vanek 2016-11-03 03:45:12 EDT
(In reply to Andrew John Hughes from comment #29)
> Here's the patch:
> 
> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/1c4d5cb2096a
> 
> Jiri, please add this to the Fedora RPMs.

Thank you!
Work in progress.
Comment 31 Andrew John Hughes 2016-11-11 01:50:38 EST
Any ETA on this?
Comment 32 jiri vanek 2016-11-11 04:54:22 EST
its already built.
Comment 36 Michael Catanzaro 2016-11-22 05:15:32 EST
(In reply to jiri vanek from comment #32)
> its already built.

For the record, this is now stable for:

F24: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7da42d8561
F25: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ae6ca5f109
Comment 43 Nikos Mavrogiannopoulos 2017-03-03 06:40:37 EST
Check tests/java/CipherList in:
https://gitlab.com/nmav/fedora-crypto-policies

You should see a different ciphersuite list when you change system policy.

E.g.:
$ update-crypto-policies --set FUTURE
$ java CipherList

should give you a different (more strict) set than the following:
$ update-crypto-policies --set DEFAULT
$ java CipherList
Comment 44 jiri vanek 2017-03-30 06:24:52 EDT
(In reply to Nikos Mavrogiannopoulos from comment #43)
> Check tests/java/CipherList in:
> https://gitlab.com/nmav/fedora-crypto-policies
> 
> You should see a different ciphersuite list when you change system policy.
> 
> E.g.:
> $ update-crypto-policies --set FUTURE
> $ java CipherList
> 
> should give you a different (more strict) set than the following:
> $ update-crypto-policies --set DEFAULT
> $ java CipherList

Another good case is to install icedtea-web (javaws (and/or browser java plugin) and try various https resources. You may find cases which works only in one of the global/java state.
Comment 45 Nikos Mavrogiannopoulos 2017-05-23 10:00:55 EDT
Jiri is that already in F26? Shouldn't the bug be in closed state?
Comment 46 jiri vanek 2017-06-15 08:03:41 EDT
(In reply to Nikos Mavrogiannopoulos from comment #45)
> Jiri is that already in F26? Shouldn't the bug be in closed state?

We tested it and it seems ok. Is the tie to close now? If so, Although assigned To Andrew, I will close.
Comment 47 Nikos Mavrogiannopoulos 2017-06-15 08:16:50 EDT
Thank you.
Comment 48 jiri vanek 2017-11-13 05:30:08 EST
(In reply to Nikos Mavrogiannopoulos from comment #43)
> Check tests/java/CipherList in:
> https://gitlab.com/nmav/fedora-crypto-policies
> 
> You should see a different ciphersuite list when you change system policy.
> 
> E.g.:
> $ update-crypto-policies --set FUTURE
> $ java CipherList
> 
> should give you a different (more strict) set than the following:
> $ update-crypto-policies --set DEFAULT
> $ java CipherList

Hi Nikos, do you have that cypher list somewhere around?  It lookslike it is no longer on your gitlab...
Comment 50 Nikos Mavrogiannopoulos 2017-11-14 02:11:12 EST
The new repo is at:
https://gitlab.com/redhat-sectech/fedora-crypto-policies

Note You need to log in before you can comment on or make changes to this bug.