The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not merge the repository. Could not push the repository.
English Japanese
Security
System-wide Crypto Policy
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` and `Java`.
OpenSSH Crypto
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 `/etc/crypto-policies/back-ends/openssh.config`.
Java Crypto
OpenJDK has been modified to read additional security properties from the generated crypto policies file at `/etc/crypto-policies/back-ends/java.config`
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 link:++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.
OpenSSL 1.1.0
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 link:++https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes++[ OpenSSL wiki].
OpenSC Replaces Coolkey
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 [command]`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 fast cache for local users
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.