1CRYPTO-POLICIES(7) CRYPTO-POLICIES(7)
2
6 crypto-policies - system-wide crypto policies overview
7
9 The security of cryptographic components of the operating system does
10 not remain constant over time. Algorithms, such as cryptographic
11 hashing and encryption, typically have a lifetime, after which they are
12 considered either too risky to use or plain insecure. That means, we
13 need to phase out such algorithms from the default settings or
14 completely disable them if they could cause an irreparable problem.
15 While in the past the algorithms were not disabled in a consistent way
17 and different applications applied different policies, the system-wide
18 crypto-policies followed by the crypto core components allow
19 consistently deprecating and disabling algorithms system-wide.
20 Several preconfigured policies (DEFAULT, LEGACY, FUTURE, and FIPS) and
22 subpolicies are included in the crypto-policies(7) package. System
23 administrators or third-party vendors can define custom policies and
24 subpolicies.
25 The recommended way to modify the effective configuration is to apply a
27 custom subpolicy on top of a predefined policy. This allows
28 configuration to evolve with future updates of the predefined policies
29 keeping desired modification in place. Modifying effective
30 configuration by defining a fully custom policy prevents the
31 configuration from evolving with future updates of the predefined
32 policies. The syntax to define custom policies and subpolicies is
33 described in the CRYPTO POLICY DEFINITION FORMAT section below.
34 For rationale, see RFC 7457 for a list of attacks taking advantage of
36 legacy crypto algorithms.
37
39 Crypto-policies apply to the configuration of the core cryptographic
40 subsystems, covering TLS, IKE, IPSec, DNSSec, and Kerberos protocols;
41 i.e., the supported secure communications protocols on the base
42 operating system.
43 Once an application runs in the operating system, it follows the
45 default or selected policy and refuses to fall back to algorithms and
46 protocols not within the policy, unless the user has explicitly
47 requested the application to do so. That is, the policy applies to the
48 default behavior of applications when running with the system-provided
49 configuration but the user can override it on an application-specific
50 basis.
51 The policies currently provide settings for these applications and
53 libraries:
54 • BIND DNS name server daemon (scopes: BIND, DNSSec)
56 • GnuTLS TLS library (scopes: GnuTLS, SSL, TLS)
58 • OpenJDK runtime environment (scopes: java-tls, SSL, TLS)
60 • Kerberos 5 library (scopes: krb5, Kerberos)
62 • Libreswan IPsec and IKE protocol implementation (scopes: libreswan,
64 IPSec, IKE)
65 • NSS TLS library (scopes: NSS, SSL, TLS)
67 • OpenSSH SSH2 protocol implementation (scopes: OpenSSH, SSH)
69 • OpenSSL TLS library (scopes: OpenSSL, SSL, TLS)
71 • libssh SSH2 protocol implementation (scopes: libssh, SSH)
73 • sequoia PGP implementation, for usage outside of rpm-sequoia
75 (scopes: sequoia)
76 • rpm-sequoia RPM Sequoia PGP backend (scopes: rpm, rpm-sequoia)
78 Applications using the above libraries and tools are covered by the
80 cryptographic policies unless they are explicitly configured otherwise.
81
83 LEGACY
84 This policy ensures maximum compatibility with legacy systems; it
85 is less secure and it includes support for TLS 1.0, TLS 1.1, and
86 SSH2 protocols or later. The algorithms DSA and 3DES are allowed,
87 while RSA and Diffie-Hellman parameters are accepted if larger than
88 1024 bits. This policy provides at least 64-bit security.
89 • MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305
91 etc.)
92 • Curves: all prime >= 255 bits (including Bernstein curves)
94 • Signature algorithms: with SHA1 hash or better (DSA allowed)
96 • TLS Ciphers: all available >= 112-bit key, >= 128-bit block
98 (including 3DES, excluding RC4)
99 • Non-TLS Ciphers: same as TLS ciphers with added Camellia
101 • Key exchange: ECDHE, RSA, DHE
103 • DH params size: >= 1024
105 • RSA keys size: >= 1024
107 • DSA params size: >= 1024
109 • TLS protocols: TLS >= 1.0, DTLS >= 1.0
111 DEFAULT
113 The DEFAULT policy is a reasonable default policy for today’s
114 standards. It allows the TLS 1.2, and TLS 1.3 protocols, as well as
115 IKEv2 and SSH2. The Diffie-Hellman parameters are accepted if they
116 are at least 2048 bits long. This policy provides at least 112-bit
117 security with the exception of allowing SHA-1 signatures in DNSSec
118 where they are still prevalent.
119 • MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305
121 etc.)
122 • Curves: all prime >= 255 bits (including Bernstein curves)
124 • Signature algorithms: with SHA-224 hash or better (no DSA)
126 • TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20,
128 including AES-CBC)
129 • non-TLS Ciphers: as TLS Ciphers with added Camellia
131 • key exchange: ECDHE, RSA, DHE (no DHE-DSS)
133 • DH params size: >= 2048
135 • RSA keys size: >= 2048
137 • TLS protocols: TLS >= 1.2, DTLS >= 1.2
139 NEXT
141 The NEXT policy is just an alias to the DEFAULT policy.
142 FUTURE
144 A conservative security policy that is believed to withstand any
145 near-term future attacks at the expense of interoperability. It may
146 prevent communication with many commonly used systems that only
147 offer weaker security. This policy does not allow the use of SHA-1
148 in signature algorithms. The policy also provides some (not
149 complete) preparation for post-quantum encryption support in form
150 of 256-bit symmetric encryption requirement. The RSA and
151 Diffie-Hellman parameters are accepted if larger than 3071 bits.
152 This policy provides at least 128-bit security.
153 • MACs: all HMAC with SHA-256 or better + all modern MACs
155 (Poly1305 etc.)
156 • Curves: all prime >= 255 bits (including Bernstein curves)
158 • Signature algorithms: with SHA-256 hash or better (no DSA)
160 • TLS Ciphers: >= 256-bit key, >= 128-bit block, only
162 Authenticated Encryption (AE) ciphers
163 • non-TLS Ciphers: same as TLS ciphers with added non AE ciphers
165 and Camellia
166 • key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
168 • DH params size: >= 3072
170 • RSA keys size: >= 3072
172 • TLS protocols: TLS >= 1.2, DTLS >= 1.2
174 FIPS
176 A policy to aid conformance to the FIPS 140-2 requirements. This
177 policy is used internally by the fips-mode-setup(8) tool which can
178 switch the system into the FIPS 140-2 mode. This policy provides at
179 least 112-bit security.
180 • MACs: all HMAC with SHA1 or better
182 • Curves: all prime >= 256 bits
184 • Signature algorithms: with SHA-256 hash or better (no DSA)
186 • TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, including
188 AES-CBC)
189 • non-TLS Ciphers: same as TLS Ciphers
191 • key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
193 • DH params size: >= 2048
195 • RSA params size: >= 2048
197 • TLS protocols: TLS >= 1.2, DTLS >= 1.2
199 EMPTY
201 All cryptographic algorithms are disabled (used for debugging only,
202 do not use).
203
205 The crypto policy definition files have a simple syntax following an
206 INI file key = value syntax with these particular features:
207 • Comments are indicated by # character. Everything on the line
209 following the character is ignored.
210 • Backslash \ character followed immediately with the end-of-line
212 character indicates line continuation. The following line is
213 concatenated to the current line after the backslash and
214 end-of-line characters are removed.
215 • Value types for integer options can be decimal integers (option =
217 1).
218 • Multiple-choice options can be specified by setting them to a list
220 of values (option = value1 value2). This list can further be
221 altered by prepending/omitting/appending values (option = prepended
222 -omitted appended). A follow-up reassignment will reset the list.
223 The latter syntax cannot be combined with the former one in the
224 same directive. Setting an option to an empty list is possible with
225 option =.
226 • Asterisk sign can be used for wildcard matching as a shortcut for
228 specifying multiple values when setting multiple-choice options.
229 Note that wildcard matching can lead to future updates implicitly
230 enabling algorithms not yet available in the current version. If
231 this is a concern, do not use wildcard-matching outside of
232 algorithm-omitting directives.
233 • In order to limit the scope of the directive and make it affect
235 just some of the backends, the following extended syntax can be
236 used: option@scope = ..., option@{scope1,scope2,...} = ....
237 Negation of scopes is possible with option@!scope /
238 'option@{scope1,scope2,...}. Scope selectors are case-insensitive.
239 The available options are:
241 • mac: List of allowed MAC algorithms
243 • group: List of allowed groups or elliptic curves for key exchanges
245 for use with other protocols
246 • hash: List of allowed cryptographic hash (message digest)
248 algorithms
249 • sign: List of allowed signature algorithms
251 • cipher: List of allowed symmetric encryption algorithms (including
253 the modes) for use with other protocols
254 • key_exchange: List of allowed key exchange algorithms
256 • protocol: List of allowed TLS, DTLS and IKE protocol versions; mind
258 that some backends do not allow selectively disabling protocols
259 versions and only use the oldest version as the lower boundary.
260 • min_dh_size: Integer value of minimum number of bits of parameters
262 for DH key exchange
263 • min_dsa_size: Integer value of minimum number of bits for DSA keys
265 • min_rsa_size: Integer value of minimum number of bits for RSA keys
267 • sha1_in_certs: Value of 1 if SHA1 allowed in certificate
269 signatures, 0 otherwise (Applies to GnuTLS back end only.)
270 • arbitrary_dh_groups: Value of 1 if arbitrary group in
272 Diffie-Hellman is allowed, 0 otherwise
273 • ssh_certs: Value of 1 if OpenSSH certificate authentication is
275 allowed, 0 otherwise
276 • ssh_etm: Value of 1 if OpenSSH EtM (encrypt-then-mac) extension is
278 allowed, 0 otherwise
279 Full policy definition files have suffix .pol, subpolicy files have
281 suffix .pmod. Subpolicies do not have to have values set for all the
282 keys listed above.
283 The effective configuration of a policy with subpolicies applied is the
285 same as a configuration from a single policy obtained by concatenating
286 the policy and the subpolicies in question.
287 Policy file placement and naming:
289 The policy files shipped in packages are placed in
291 /usr/share/crypto-policies/policies and the subpolicies in
292 /usr/share/crypto-policies/policies/modules.
293 Locally configured policy files should be placed in
295 /etc/crypto-policies/policies and subpolicies in
296 /etc/crypto-policies/policies/modules.
297 The policy and subpolicy files must have names in upper-case except for
299 the .pol and .pmod suffix as the update-crypto-policies command always
300 converts the policy name to upper-case before searching for the policy
301 on the filesystem.
302
304 update-crypto-policies(8)
305 This command manages the policies available to the various
306 cryptographic back ends and allows the system administrator to
307 change the active cryptographic policy.
308 fips-mode-setup(8)
310 This command allows the system administrator to enable, or disable
311 the system FIPS mode and also apply the FIPS cryptographic policy
312 which limits the allowed algorithms and protocols to these allowed
313 by the FIPS 140-2 requirements.
314
316 Known notable exceptions
317 • Go-language applications do not yet follow the system-wide policy.
319 • GnuPG-2 application does not follow the system-wide policy.
321 In general only the data-in-transit is currently covered by the
323 system-wide policy.
324 If the system administrator changes the system-wide policy with the
326 update-crypto-policies(8) command it is advisable to restart the system
327 as the individual back-end libraries read the configuration files
328 usually during their initialization. The changes in the policy thus
329 take place in most cases only when the applications using the back-end
330 libraries are restarted.
331 Removed cipher suites and protocols
333 The following cipher suites and protocols are completely removed from
335 the core cryptographic libraries listed above:
336 • DES
338 • All export grade cipher suites
340 • MD5 in signatures
342 • SSLv2
344 • SSLv3
346 • All ECC curves smaller than 224 bits
348 • All binary field ECC curves
350 Cipher suites and protocols disabled in all predefined policies
352 The following ciphersuites and protocols are available but disabled in
354 all predefined crypto policies:
355 • DH with parameters < 1024 bits
357 • RSA with key size < 1024 bits
359 • Camellia
361 • RC4
363 • ARIA
365 • SEED
367 • IDEA
369 • Integrity only ciphersuites
371 • TLS CBC mode ciphersuites using SHA-384 HMAC
373 • AES-CCM8
375 • all ECC curves incompatible with TLS 1.3, including secp256k1
377 • IKEv1
379 Notable irregularities in the individual configuration generators
381 • OpenSSL and NSS: Disabling all TLS and/or all DTLS versions isn’t
383 actually possible. Trying to do so will result in the library
384 defaults being applied instead.
385 • OpenSSL: The minimum length of the keys and some other parameters
387 are enforced by the @SECLEVEL value which does not provide a fine
388 granularity. The list of TLS ciphers is not generated as an exact
389 list but by subtracting from all the supported ciphers for the
390 enabled key exchange methods. For that reason there is no way to
391 disable a random cipher. In particular all AES-128 ciphers are
392 disabled if the AES-128-GCM is not present in the list; all AES-256
393 ciphers are disabled if the AES-256-GCM is not present. The CBC
394 ciphers are disabled if there isn’t HMAC-SHA1 in the hmac list and
395 AES-256-CBC in the cipher list. To disable the CCM ciphers both
396 AES-128-CCM and AES-256-CCM must not be present in the cipher list.
397 • GnuTLS: The minimum length of the keys and some other parameters
399 are enforced by min-verification-profile setting in the GnuTLS
400 configuration file which does not provide fine granularity.
401 • GnuTLS: PSK key exchanges have to be explicitly enabled by the
403 applications using them.
404 • GnuTLS: HMAC-SHA2-256 and HMAC-SHA2-384 MACs are disabled due to
406 concerns over the constant-timedness of the implementation.
407 • OpenSSH: DH group 1 is always disabled on server even if the policy
409 allows 1024 bit DH groups in general. The OpenSSH configuration
410 option HostKeyAlgorithms is set only for the SSH server as
411 otherwise the handling of the existing known hosts entries would be
412 broken on client.
413 • Libreswan: The key_exchange parameter does not affect the generated
415 configuration. The use of regular DH or ECDH can be limited with
416 appropriate setting of the group parameter.
417 • Sequoia: only hash_algorithms, symmetric_algorithms and
419 asymmetric_algorithms are controlled by crypto-policies.
420 asymmetric_algorithms is not controlled directly, but deduced from
421 sign and group.
422
424 The ECDHE-GSS and DHE-GSS algorithms are newly introduced and must be
425 specified in the base policy for the SSH GSSAPI key exchange methods to
426 be enabled. Previously the legacy SSH GSSAPI key exchange methods were
427 automatically enabled when the SHA1 hash and DH parameters of at least
428 2048 bits were enabled.
429 Before the introduction of the custom crypto policies support it was
431 possible to have an completely arbitrary crypto policy created as a set
432 of arbitrary back-end config files in
433 /usr/share/crypto-policies/<POLICYNAME> directory. With the
434 introduction of the custom crypto policies it is still possible but
435 there must be an empty (possibly with any comment lines)
436 <POLICYNAME>.pol file in /usr/share/crypto-policies/policies so the
437 update-crypto-policies command can recognize the arbitrary custom
438 policy. No subpolicies must be used with such an arbitrary custom
439 policy. Modifications from local.d will be appended to the files
440 provided by the policy.
441 The use of the following historaically available options is
443 discouraged:
444 • min_tls_version: Lowest allowed TLS protocol version (recommended
446 replacement: protocol@TLS)
447 • min_dtls_version: Lowest allowed DTLS protocol version (recommended
449 replacement: protocol@TLS)
450 The following options are deprecated, please rewrite your policies:
452 • ike_protocol: List of allowed IKE protocol versions (recommended
454 replacement: protocol@IKE, mind the relative position to other
455 protocol directives).
456 • tls_cipher: list of allowed symmetric encryption algorithms for use
458 with the TLS protocol (recommended replacement: cipher@TLS, mind
459 the relative position to other cipher directives).
460 • ssh_cipher: list of allowed symmetric encryption algorithms for use
462 with the SSH protocol (recommended replacement: cipher@SSH, mind
463 the relative position to other cipher directives).
464 • ssh_group: list of allowed groups or elliptic curves for key
466 exchanges for use with the SSH protocol (recommended replacement:
467 group@SSH, mind the relative position to other group directives).
468 • sha1_in_dnssec: Allow SHA1 usage in DNSSec protocol even if it is
470 not present in the hash and sign lists (recommended replacements:
471 hash@DNSSec, sign@DNSSec).
472
474 /etc/crypto-policies/back-ends
475 The individual cryptographical back-end configuration files.
476 Usually linked to the configuration shipped in the crypto-policies
477 package unless a configuration from local.d is added.
478 /etc/crypto-policies/config
480 A file containing the name of the active crypto-policy set on the
481 system.
482 /etc/crypto-policies/local.d
484 Additional configuration shipped by other packages or created by
485 the system administrator. The contents of the
486 <back-end>-file.config is appended to the configuration from the
487 policy back end as shipped in the crypto-policies package.
488 /usr/share/crypto-policies/policies
490 System policy definition files.
491 /usr/share/crypto-policies/policies/modules
493 System subpolicy definition files.
494 /etc/crypto-policies/policies
496 Custom policy definition files as configured by the system
497 administrator.
498 /etc/crypto-policies/policies/modules
500 Custom subpolicy definition files as configured by the system
501 administrator.
502 /usr/share/crypto-policies/<'POLICYNAME'>
504 Pre-generated back-end configurations for policy POLICYNAME.
505
507 update-crypto-policies(8), fips-mode-setup(8)
508
510 Written by Tomáš Mráz.
511crypto-policies 03/01/2023 CRYPTO-POLICIES(7)