The security of network communications is a high priority for the Fedora project, with strong TLS providing the first line of defense against traffic inspection. Two systems negotiating a TLS connection must agree on a common cipher to encrypt their communications, and as ciphers become deprecated, it is important to exclude them.
The ciphers that an administrator might consider adequately secure are determined by vulnerabilities published against specific ciphers. The acceptable cipher suite applies to all communications on the internet, and is not specific to any one system or daemon. To ease administration and increase adminsitrator confidence in the system’s security posture, Fedora has been configuring various software to use a system-global configuration so that TLS ciphers need only be updated in one place.
With Fedora 26, two more things will use the system-wide crypto policy,
OpenSSH clients will use system preferred key exchange algorithms, encryption ciphers, and message authentication code (MAC) algorithms. This is enabled by an
Include directive in
/etc/ssh/ssh_config to include directives in
/etc/ssh/ssh_config.d/*.conf, which pulls in
OpenJDK has been modified to read additional security properties from the generated crypto policies file at
This change may affect connections to legacy systems that do not support more strict crypto policies. While it is possible to switch the system profile from DEFAULT to LEGACY, or to set
security.useSystemPropertiesFile=false in a project’s
java.security file (refer to https://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html), it would be best to also update legacy applications to modern security standards.
The introduction of OpenSSL 1.1.0 in Fedora 26 brings many big improvements, new cryptographic algorithms, and API changes that allow for keeping the ABI stable in future upgrades. There is also now a compat-openssl10 package in Fedora that provides OpenSSL 1.0.2 for dependent applications that cannot move to 1.1.0 yet.
There is more information about OpenSSL 1.1.0 in the OpenSSL wiki.
Fedora 26 is not shipping the Coolkey PKCS#11 module in the NSS database by default. Instead, there will be the OpenSC PKCS#11 module, which supports more different Smart Cards. The Coolkey package will be removed in Fedora 27. If other applications were using Coolkey, they should be able to switch to OpenSC.
In case you still need Coolkey in the NSS DB, you can add it manually using
modutil -dbdir /etc/pki/nssdb -add "CoolKey PKCS #11 Module (manual)" -libfile libcoolkeypk11.so -force (the different name is used to prevent automatic removals when updating coolkey package).
Soon (during F26 cycle) there will be fully-featured 0.17.0 update to OpenSC with all the tested features and cards that should serve as a complete replacement of Coolkey.
SSSD has shipped with a very fast memory cache in the last couple of Fedora releases. However, using this cache conflicts with nscd’s caching and nscd has been disabled by default. That degrades performance, because every user or group lookup must open the local files.
From Fedora 26, a new SSSD "files" provider will resolve users from the local files. That way, the "sss" NSS module can be configured before the files module in nsswitch.conf and the system can leverage sss_nss caching for both local and remote users. As a result, user and group resolution in Fedora will be much faster.
Obsolete and unmaintainable code was removed from
The graphical interface (system-config-authentication) and the interactive text mode, which relied on old and unmaintained libraries (GTK+2 and Glade) have been removed from the distribution.
The command line tool, which has been deprecated previously, continues to be part of the distribution for legacy reasons. However, some deprecated and obsolete functionality such as support for
HESIODhas been removed in this release.
The removal effort is happening because current modern environments support automatic configuration of remote user identities using
SSSD and do not require manual configuration through an interactive interface such as system-config-authentication. Some of the existing authconfig command line functionality is being preserved due to it still retaining some usefulness in certain environments, and to support the
auth command in Kickstart. Removing parts of the code base that are no longer maintainable makes it easier to continue providing this functionality.