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
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.
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
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.
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.
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?
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?
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.
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
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
Added Fedora 25 change request. https://fedoraproject.org/wiki/Changes/JavaCryptoPolicies
Here's the patch: http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/1c4d5cb2096a Jiri, please add this to the Fedora RPMs.
(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.
Any ETA on this?
its already built.
(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
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
(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.
Jiri is that already in F26? Shouldn't the bug be in closed state?
(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.
Thank you.
(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...
UNless it it ... https://github.com/nmav/fedora-crypto-policies/blob/master/tests/java/CipherList.java
The new repo is at: https://gitlab.com/redhat-sectech/fedora-crypto-policies