BEZEICHNUNG¶
crypto-policies - Überblick über systemweite
Krypto-Richtlinien
BESCHREIBUNG¶
Die Sicherheit kryptographischer Komponenten des Betriebssystems
bleibt im Laufe der Zeit nicht konstant. Algorithmen, wie kryptographisches
Hashen und Verschlüsseln, haben typischerweise eine Lebensdauer, nach
der sie als zu riskant oder sogar klar unsicher betrachtet werden. Das
bedeutet, das solche Einstellungen aus den Voreinstellungen stufenweise
herausgenommen oder komplett deaktiviert werden müssen, falls sie ein
nicht reparierbares Problem hervorrufen würden.
Während in der Vergangenheit die Algorithmen nicht
konsistent deaktiviert wurden und verschiedene Anwendungen verschiedene
Richtlinien zugrunde legten, erlauben es die systemweiten
Krypto-Richtlinien, denen die Krypto-Kernkomponenten folgen, das konsistente
und systemweite Markieren von Algorithmen als veraltet und deren
Deaktivierung.
Mehrere vorkonfigurierte Richtlinien (DEFAULT,
LEGACY, FUTURE und FIPS) und Unterrichtlinien sind im
Paket crypto-policies(7) enthalten. Systemadministratoren oder
Drittparteienlieferanten können angepasste Richtlinien und
Unterrichtlinien definieren.
Der beste Weg zur Anpassung der wirksamen Konfiguration ist die
Anwendung von angepassten Unterrichtlinien ergänzend zu der
vordefinierten Richtlinie. Dies ermöglicht der Konfiguration, sich
mit zukünftigen Aktualisierungen der vordefinierten Richtlinie
weiterzuentwickeln, wobei wünschenswerte Anpassungen bestehen
bleiben. Wird die wirksame Konfiguration durch die Definition einer komplett
angepassten Richtlinie angepasst, dann kann die Konfiguration sich bei
zukünftigen Aktualisierungen der vordefinierten Richtlinie nicht mit
entwickeln. Die Syntax zur Definition der angepassten Richtlinien und
Unterrichtlinien wird im nachfolgenden Abschnitt
KRYPTO-RICHTLINIEN-DEFINITIONSFORMAT beschrieben.
Zur Begründung siehe RFC 7457 für eine Liste
von Angriffen, die Nutzen aus veralteten Kryptoalgorithmen ziehen.
ABGEDECKTE ANWENDUNGEN¶
Crypto-policies gelten für die Konfiguration der
kryptographischen Kern-Subsysteme und decken die Protokolle TLS,
IKE, IPSec, DNSSec und Kerberos ab, d.h. die
unterstützten sicheren Kommunikationsprotokolle im grundlegenden
Betriebssystem.
Sobald eine Anwendung im Betriebssystem ausgeführt wird,
folgt sie der Vorgabe oder der ausgewählten Richtlinie und lehnt es
ab, auf Algorithmen und Protokolle zurückzufallen, die nicht
innerhalb der Richtlinie liegen, außer der Anwender hat dies
ausdrücklich erbeten. Das bedeutet, dass die Richtlinie auf das
Standardverhalten der Anwendungen angewandt wird, wenn diese innerhalb der
vom System bereitgestellten Konfiguration betrieben werden, der Benutzer
dies aber für Anwendungen gezielt außer Kraft setzen kann.
Die Richtlinien stellen derzeit Einstellungen für die
folgenden Anwendungen und Bibliotheken bereit:
•BIND-DNS-Nameserver-Daemon
(Geltungsbereiche: BIND, DNSSec)
•GnuTLS-TLS-Bibliothek (Geltungsbereiche:
GnuTLS, SSL, TLS)
•OpenJDK-Laufzeitumgebung
(Geltungsbereiche: java-tls, SSL, TLS)
•Kerberos 5-Bibliothek (Geltungsbereiche:
krb5, Kerberos)
•Libreswan-IPsec- und
IKE-Protokollimplementierung (Geltungsbereiche: libreswan,
IPSec, IKE)
•NSS-TLS-Bibliothek (Geltungsbereiche:
NSS, SSL, TLS)
•OpenSSH-SSH2-Protokollimplementierung
(Geltungsbereiche: OpenSSH, SSH)
•OpenSSL-TLS-Bibliothek (Geltungsbereiche:
OpenSSL, SSL, TLS)
•libssh-SSH2-Protokollimplementierung
(Geltungsbereiche: libssh, SSH)
•sequoia PGP-Implementierung, für
die Verwendung außerhalb von rpm-sequoia (Geltungsbereiche:
sequoia)
•rpm-sequoia RPM Sequoia PGP Backend
(Geltungsbereiche: rpm, rpm-sequoia)
Anwendungen, die die obigen Bibliotheken und Werkzeuge verwenden,
sind von den kryptographischen Richtlinien abgedeckt, außer sie
werden ausdrücklich andersweitig konfiguriert.
BEREITGESTELLTE RICHTLINIEN¶
LEGACY
Diese Richtlinie stellt die maximale
Kompatibilität mit herkömmlichen Systemen bereit; sie ist
weniger sicher und unterstützt die Protokolle
TLS 1.0,
TLS
1.1 und
SSH2 und neuere. Die Algorithmen
DSA und
3DES
sind erlaubt, während die Parameter von
RSA und
Diffie-Hellman akzeptiert werden, wenn sie größer als
1024 bit sind. Diese Richtlinie stellt mindestens 64-Bit-Sicherheit bereit.
•MACs: alle HMAC mit SHA-1 oder
besser und alle modernen MACs (Poly1305 usw.)
•Kurven: alle Primzahlen >= 255 bit
(einschließlich Bernstein-Kurven)
•Signaturalgorithmen: mit Hash SHA1 oder
besser (DSA erlaubt)
•TLS-Chiffren: alle verfügbaren
>= 112-bit-Schlüssel, >= 128-bit-Block (einschließlich
3DES und ausschließlich RC4)
•Nicht-TLS-Chiffren: wie bei TLS-Chiffren
mit hinzugefügtem Camellia
•Schlüsselaustausch: ECDHE,
RSA, DHE
•DH-Parametergröße: >=
1024
•RSA-Schlüsselgröße:
>= 1024
•DSA-Parametergröße: >=
1024
•TLS-Protokolle: TLS >= 1.0,
DTLS >= 1.0
DEFAULT
Die Richtlinie
DEFAULT ist eine vernünftige
Vorgaberichtlinie gemäß heutiger Standards. Sie erlaubt die
Protokolle
TLS 1.2 und
TLS 1.3 sowie
IKEv2 und
SSH2. Die Parameter von
Diffie-Hellman werden akzeptiert, falls
sie mindestens 2048 bit lang sind. Diese Richtlinie stellt mindestens
112-bit-Sicherheit bereit, mit der Ausnahme, dass sie
SHA-1-Signaturen
in DNSSec erlaubt, wo sie immer noch verbreitet sind.
•MACs: alle HMAC mit SHA-1 oder
besser und alle modernen MACs (Poly1305 usw.)
•Kurven: alle Primzahlen >= 255 bit
(einschließlich Bernstein-Kurven)
•Signatur-Algorithmen: mit SHA-224-Hash
oder besser (kein DSA)
•TLS-Chiffren: >=
128-bit-Schlüssel, >= 128-bit-Block (AES, ChaCha20,
einschließlich AES-CBC)
•nicht-TLS-Chiffren: wie bei TLS-Chiffren
mit hinzugefügtem Camellia
•Schlüsselaustausch: ECDHE,
RSA, DHE (kein DHE-DSS)
•DH-Parametergröße: >=
2048
•RSA-Schlüsselgrößen:
>= 2048
•TLS-Protokolle: TLS >= 1.2,
DTLS >= 1.2
NEXT
Die Richtlinie NEXT ist nur ein Alias für
die Richtlinie DEFAULT.
FUTURE
Eine konservative Sicherheitsrichtlinie, von der
angenommen wird, dass sie auf Kosten der Interoperabilität allen
zukünftigen Angriffen in der nächsten Zeit widerstehen wird. Sie
könnte die Kommunikation mit vielen häufig verwandten Systemen,
die nur schwächere Sicherheit anbieten, verhindern. Diese Richtlinie
erlaubt keine Verwendung der
SHA-1-Signaturalgorithmen. Diese
Richtlinie stellt auch einige (unvollständige) Vorbereitungen
für Post-Quanten-Verschlüsselungsunterstützung in Form
von symmetrischen 256-bit-Verschlüsselungsanforderungen bereit. Die
Parameter für
RSA und
Diffie-Hellman werden akzeptiert,
wenn sie größer als 3071 bit sind. Diese Richtlinie stellt
mindestens 128-bit-Sicherheit bereit.
•MACs: alle HMAC mit SHA-256 oder
besser und alle modernen MACs (Poly1305 usw.)
•Kurven: alle Primzahlen >= 255 bit
(einschließlich Bernstein-Kurven)
•Signatur-Algorithmen: mit SHA-256-Hash
oder besser (kein DSA)
•TLS-Chiffren: >=
256-bit-Schlüssel, >= 128-bit-Block, nur Chiffren mit
authentifizierter Verschlüsselung (AE)
•nicht-TLS-Chiffren: wie bei TLS-Chiffren
mit hinzugefügten nicht-AE-Chiffren und Camellia
•Schlüsselaustausch: ECDHE,
DHE (kein DHE-DSS, kein RSA)
•DH-Parametergröße: >=
3072
•RSA-Schlüsselgrößen:
>= 3072
•TLS-Protokolle: TLS >= 1.2,
DTLS >= 1.2
BSI
Eine Sicherheitsrichtlinie, die auf den Empfehlungen der
deutschen Regierungsbehörde BSI (Bundesamt für Sicherheit in der
Informationstechnik) in seiner technischen Richtlinie BSI TR 02102 beruht. Der
BSI-Standard TR 02102 wird regelmäßig aktualisiert.
Diese Richtlinie erlaubt die Verwendung von *SHA-1* in Signaturalgorithmen
nicht (außer für *DNSSEC* und *RPM*).
Diese Richtlinie stellt eine (unvollständige) Vorbereitung für die
Unterstützung von Post-Quanten-Verschlüsselung in Form einer Anforderung
von symmetrischer 256-bit-Verschlüsselung bereit.
Die *RSA*-Parameter werden akzeptiert, wenn sie größer als 2047 bit und die
*Diffie-Hellman*-Parameter werden akzeptiert, wenn sie größer als 2071 bit
sind.
Die Richtlinie stellt mindestens 128-bit-Sicherheit bereit, außerhalb des
Übergangs von *RSA*.
•MACs: alle HMAC mit SHA-256 oder
besser und alle modernen MACs
•Kurven: alle Primzahlen >= 255 bit
(einschließlich Bernstein-Kurven)
•Signatur-Algorithmen: mit SHA-256-Hash
oder besser (kein DSA)
•TLS-Chiffren: >=
256-bit-Schlüssel, >= 128-bit-Block, nur Chiffren mit
authentifizierter Verschlüsselung (AE)
•nicht-TLS-Chiffren: wie bei TLS-Chiffren
mit hinzugefügten nicht-AE-Chiffren
•Schlüsselaustausch: ECDHE,
DHE (kein DHE-DSS, kein RSA)
•DH-Parametergröße: >=
3072
•RSA-Schlüsselgrößen:
>= 2048 (bis Ende 2023, dann wird auf 3072 umgestellt)
•
TLS-Protokolle:
TLS >= 1.2,
DTLS >= 1.2
Beachten Sie, dass im Vergleich zu anderen Profilen *Chacha20* und
*Camellia* vom BSI nicht empfohlen werden.
FIPS
Eine Richtlinie, die bei der Erfüllung der
FIPS
140-Anforderungen unterstützt. Diese Richtlinie wird intern vom
Werkzeug
fips-mode-setup(8) verwandt, das das System in den
FIPS
140-Modus umschalten kann. Diese Richtlinie stellt mindestens
112-bit-Sicherheit bereit.
•MACs: alle HMAC mit SHA1 oder
besser
•Kurven: alle Primzahlen >= 256 bit
•Signatur-Algorithmen: mit SHA-256-Hash
oder besser (kein DSA)
•TLS-Chiffren: >= 128-bit
Schlüssel, >= 128-bit-Block (AES, einschließlich
AES-CBC)
•nicht-TLS-Chiffren: wie bei
TLS-Chiffren
•Schlüsselaustausch: ECDHE,
DHE (kein DHE-DSS, kein RSA)
•DH-Parametergröße: >=
2048
•RSA-Parametergröße: >=
2048
•TLS-Protokolle: TLS >= 1.2,
DTLS >= 1.2
EMPTY
Alle kryptographischen Algorithmen sind deaktiviert (nur
zur Fehlersuche, verwenden Sie das nicht).
Die Kryptorichtlinien-Definitionsdateien haben eine einfache
Syntax, die der Syntax einer INI-Datei Schlüssel =
Wert folgt und folgende besondere Eigenschaften hat:
•Kommentare werden durch ein #-Zeichen
angezeigt. Alles, was diesem Zeichen auf der Zeile folgt, wird
ignoriert.
•Rückwärtsschrägstrichzeichen
\, denen sofort ein Zeilenendezeichen folgt, stellen eine
Zeilenfortführung dar. Die nachfolgende Zeile wird an die aktuelle
Zeile angehängt, nachdem der Rückwärtsschrägstrich
und das Zeilenendezeichen entfernt wurden.
•Wertetypen für Ganzzahloptionen
können dezimale Ganzzahlen sein (Option = 1).
•Mehrfachauswahl-Optionen können angegeben
werden, indem sie auf eine Werteliste (Option = Wert1 Wert2) gesetzt
werden. Diese Liste kann durch voranstellen/auslasssen/anhängen von
Werten (Option = vorangestellt -ausgelassen angehängt)
weiter verändert werden. Eine nachfolgende Zuweisung wird die Liste
zurücksetzen. Letztere Syntax kann nicht mit der ersteren in der
gleichen Direktive zusammen verwandt werden. Mit Option = kann eine
Option auf eine leere Liste gesetzt werden.
•Sternchen können für
Platzhaltervergleiche als Abkürzung für die Angabe mehrerer
Werte verwandt werden, wenn Mehrfachauswahl-Optionen gesetzt werden. Beachten
Sie, dass Platzhaltervergleiche dazu führen können, dass bei
zukünftigen Aktualisierungen Algorithmen aktiviert werden, die in der
aktuellen Version noch nicht verfügbar sind. Falls dies ein Bedenken
auslöst, verwenden Sie die Platzhaltervergleiche nicht außerhalb
von Direktiven, bei denen Algorithmen ausgelassen werden.
•Um den Geltungsbereich der Direktive zu begrenzen
und dafür zu sorgen, dass sie nur einige der Backends betrifft, kann
die folgende erweiterte Syntax verwandt werden: Option@Geltungsbereich =
…, Option@{Geltungsbereich1,Geltungsbereich2,…} =
…. Verneinung von Geltungsbereichen ist mit
Option@!Geltungsbereich /
'Option@{Geltungsbereich1,Geltungsbereich2,…} möglich. Die
Groß-/Kleinschreibung ist hierbei für die Geltungsbereiche
egal.
Die verfügbaren Optionen sind:
•mac: Liste der erlaubten
MAC-Algorithmen
•group: Liste der erlaubten Gruppen oder
elliptischen Kurven für den Schlüsselaustausch für die
Anwendung mit allen anderen Protokollen
•hash: Liste der erlaubten
kryptographischen Algorithmen für Hashes
(Nachrichtenzusammenfassungen)
•sign: Liste der erlaubten
Signaturalgorithmen
•cipher: Liste der erlaubten symmetrischen
Verschlüsselungsalgorithmen (einschließlich der Modi) für
die Anwendung mit den anderen Protokollen
•key_exchange: Liste der erlaubten
Schlüsselaustauschalgorithmen
•protocol: Liste der erlaubten TLS-, DTLS-
und IKE-Protokollversionen: Bedenken Sie, dass einige Backends die
Deaktivierung bestimmter Protokollversionen nicht erlauben und nur die
älteste Version als untere Grenze verwenden.
•min_dh_size: Ganzzahlwert der minimalen
Anzahl an Bits der Parameter für den
DH-Schlüsselaustausch
•min_dsa_size: Ganzzahlwert der minimalen
Anzahl an Bits für DSA-Schlüssel
•min_rsa_size: Ganzzahlwert der minimalen
Anzahl an Bits für RSA-Schlüssel
•sha1_in_certs: Wert von 1, falls
SHA1 in Zertifikatssignaturen erlaubt ist und 0 andernfalls (gilt nur
für das GnuTLS Backend)
•arbitrary_dh_groups: Wert von 1, falls
eine beliebige Gruppe in Diffie-Hellman erlaubt ist und 0
andernfalls
•ssh_certs: Wert von 1, falls
OpenSSH-Zertifikatsauthentifizierung erlaubt ist und 0
andernfalls
•ssh_etm: Wert von 1, falls die Erweiterung
EtM (verschlüsseln-dann-mac) von OpenSSH erlaubt ist und 0
andernfalls
Vollständige Richtliniendateien habe die Endung .pol,
Unterrichtlinien-Dateien die Endung .pmod. In Unterrichtlinien-Dateien
müssen nicht alle oben aufgeführten Werte für alle
Schlüssel gesetzt sein.
Die wirksame Konfiguration einer Richtlinie mit angewandten
Unterrichtlinien ist identisch zu der Konfiguration aus einer einzelnen
Richtlinie, die erhalten wurde, indem die in Frage kommenden Richtlinie und
Unterrichtlinien aneinandergehängt wurden.
Ablage und Benennung von Richtlinien-Dateien:
Die in Paketen ausgelieferten Richtliniendateien werden in
/usr/share/crypto-policies/policies und die Unterrichtlinien in
/usr/share/crypto-policies/policies/modules abgelegt.
Lokal konfigurierte Richtliniendateien sollten in
/etc/crypto-policies/policies und die Unterrichtlinien in
/etc/crypto-policies/policies/modules abgelegt werden.
Die Richtlinien- und Unterrichtlinien-Dateien müssen Namen
in Großbuchstaben haben, außer der Erweiterung
».pol« und ».pmod«, da der Befehl
update-crypto-policies immer den Richtliniennamen in
Großbuchstaben umwandelt, bevor er nach der Richtlinie in dem
Dateisystem sucht.
BEFEHLE¶
update-crypto-policies(8)
Dieser Befehl verwaltet die für die verschiedenen
kryptographischen Backends verfügbaren Richtlinien und erlaubt es dem
Systemverwalter, die aktive kryptographische Richtlinie zu
ändern.
fips-mode-setup(8)
Dieser Befehl erlaubt es dem Systemadministrator, den
System-FIPS-Modus zu aktivieren oder deaktivieren und auch die
kryptographische Richtlinie FIPS anzuwenden, die die erlaubten
Algorithmen und Protokolle auf die in der FIPS 140 geforderten
beschränkt.
ANMERKUNGEN¶
Bekannte bemerkenswerte Ausnahmen
•Anwendungen in der Sprache Go folgen der
systemweiten Richtlinie noch nicht.
•GnuPG-2-Anwendungen folgen der
systemweiten Richtlinie nicht.
Im Allgemeinen werden nur übertragene Daten bei der
systemweiten Richtlinie abgedeckt.
Falls der Systemadministrator die systemweite Richtlinie mit dem
Befehl update-crypto-policies(8) ändert, wird empfohlen, das
System neu zu starten, da die einzelnen zugrundeliegenden Bibliotheken ihre
Konfigurationsdateien normalerweise während ihrer Initialisierung
lesen. Die Änderungen der Richtlinie finden daher in den meisten
Fällen nur statt, wenn die Anwendungen, die die zugrundeliegenden
Bibliotheken verwenden, neu gestartet werden.
Entfernte Chiffre-Suiten und Protokolle
Die folgenden Chiffre-Suiten und Protokolle sind
vollständig aus den oben aufgeführten kryptographischen
Kern-Bibliotheken entfernt:
•DES
•Alle für den Export geeigneten
Chiffre-Suiten
•MD5 in Signaturen
•SSLv2
•SSLv3
•Alle ECC-Kurven kleiner als 224 bit
•Alle Binärfeld-ECC-Kurven
Chiffren-Suiten und Protokolle, die in allen vordefinierten
Richtlinien deaktiviert sind
Die folgenden Chiffren-Suiten und Protokolle sind
verfügbar, aber in allen vordefinierten Krypto-Richtlinien
deaktiviert:
•DH mit Parametern < 1024 bit
•RSA mit
Schlüsselgrößen < 1024 bit
•Camellia
•RC4
•ARIA
•SEED
•IDEA
•Reine Integritäts-Chiffre-Suiten
•TLS CBC-Modus-Chiffre-Suiten, die
SHA-384 HMAC verwenden
•AES-CCM8
•Alle ECC, die inkompatibel zu TLS
1.3 sind, einschließlich secp256k1
•IKEv1
Bemerkenswerte Unregelmäßigkeiten in den
einzelnen Konfigurationsgeneratoren
•OpenSSL und NSS: Deaktivierung
aller TLS- und/oder aller DTLS-Versionen ist tatsächlich nicht
möglich. Wird dies versucht, dann werden die Vorgaben der Bibliotheken
verwandt.
•OpenSSL: Die minimale Länge der
Schlüssel und einiger anderer Parameter wird durch den @SECLEVEL-Wert
erzwungen und bietet keine hohe Granularität. Die Liste der
TLS-Chiffren wird nicht als exakte Liste erstellt, sondern durch
Entfernung aus der für die aktivierten
Schlüsselaustauschmethoden unterstützten Chiffren. Aus diesem
Grund gibt es keine Möglichkeit, eine beliebige Chiffre zu entfernen.
Insbesondere werden alle AES-128-Chiffren deaktiviert, falls
AES-128-GCM in der Liste nicht vorhanden ist; alle
AES-256-Chiffren deaktiviert, falls AES-256-GCM in der Liste
nicht vorhanden ist. Die CBC-Chiffren werden deaktiviert, falls
HMAC-SHA1 nicht in der Hmac-Liste und AES-256-CBC in der
Chiffren-Liste ist. Um die CCM-Chiffren zu deaktivieren, dürfen
sowohl AES-128-CCM als auch AES-256-CCM nicht in der
Chiffren-Liste vorhanden sein.
•GnuTLS: Die minimale Länge der
Schlüssel und einige andere Parameter werden durch die Einstellung
»min-verification-profile« in der
GnuTLS-Konfigurationsdatei erzwungen, die keine hohe
Granularität ermöglicht.
•GnuTLS: PSK-Schlüsselaustausch
wurde explizit durch Anwendungen, die dies verwenden, aktiviert.
•GnuTLS: HMAC-SHA2-256 und HMAC-SHA2-384
sind aufgrund von Bedenken über konstantes Zeitverhalten in der
Implementierung deaktiviert.
•OpenSSH: DH-Gruppe 1 ist auf dem
Server immer deaktiviert, selbst falls die Richtlinien-Datei im Allgemeinen
1024-bit-DH-Gruppen erlaubt. Die OpenSSH-Konfigurationsoption
HostKeyAlgorithms wird nur für den SSH-Server gesetzt, da
andernfalls die Handhabung der bestehenden Einträge bekannter Rechner
auf dem Client nicht mehr funktionieren würde.
•Libreswan: Der Parameter
key_exchange betrifft nicht die erzeugte Konfiguration. Die Verwendung
der normalen DH oder ECDH kann durch geeignete Einstellungen des
Parameters group beschränkt werden.
•Sequoia: nur hash_algorithms,
symmetric_algorithms und asymmetric_algorithms werden durch
crypto-policies gesteuert. asymmetric_algorithms wird nicht direkt
gesteuert, sondern aus sign und group abgeleitet.
•NSS: Die Reihenfolge der Werte für
group wird ignoriert und es wird stattdessen die eingebaute Reihenfolge
verwandt.
GESCHICHTE¶
Die Algorithmen ECDHE-GSS und DHE-GSS sind neu
eingeführt und müssen in der Basisrichtlinie für die
SSH-GSSAPI-Schlüsselaustauschmethoden spezifiziert werden, damit sie
aktiviert werden. Früher wurden die veralteten
SSH-GSSAPI-Schlüsselaustauschmethoden automatisch aktiviert, wenn die
Parameter des SHA1-Hashes und DH mit mindestens 2048 bit
aktiviert wurden.
Vor der Einführung der Unterstützung für
angepasste Kryptorichtlinien war es möglich, eine komplett
beliebige Kryptorichtlinie zu erstellen, indem eine Gruppe von beliebigen
Backend-Konfigurationsdateien in dem Verzeichnis
/usr/share/crypto-policies/<RICHTLINIENNAME> zusammengestellt wurde.
Mit der Einführung von angepassten Kryptorichtlinien ist dies
weiterhin möglich, aber es muss eine leere Datei
(möglicherweise mit Kommentarzeilen) <RICHTLINIENNAME> in
/usr/share/crypto-policies/policies geben, so dass der Befehl
update-crypto-policies die beliebige angepasste Richtlinie erkennen
kann. Mit solchen beliebigen angepassten Richtliniendateien dürfen
keine Unterrichtlinien verwandt werden. Änderungen aus local.d
werden an die durch die Richtlinien bereitgestellten Dateien
angehängt.
Von der Verwendung folgender, historisch verfügbarer
Optionen wird abgeraten:
•min_tls_version: Niedrigste erlaubte
TLS-Protokollversion (empfohlenerErsatz: protocol@TLS)
•min_dtls_version: Niedrigste erlaubte
DTLS-Protokollversion (empfohlener Ersatz: protocol@TLS)
Die folgenden Optionen sind veraltet, bitte schreiben Sie Ihre
Richtlinien um:
•ike_protocol: Liste der erlaubten
IKE-Protokollversionen (empfohlener Ersatz: protocol@IKE, bedenken Sie
die relative Position zu anderen protocol-Direktiven).
•tls_cipher: Liste der erlaubten
symmetrischen Verschlüsselungsalgorithmen für die Anwendung mit
dem TLS-Protokoll (empfohlener Ersatz: cipher@TLS, achten Sie auf die
relative Position zu anderen cipher-Direktiven).
•ssh_cipher: Liste der erlaubten
symmetrischen Verschlüsselungsalgorithmen für die Anwendung mit
dem SSH-Protokoll (empfohlener Ersatz: cipher@SSH, achten Sie auf die
relative Position zu anderen cipher-Direktiven).
•ssh_group: Liste der erlaubten Gruppen
oder elliptischen Kurven für den Schlüsselaustausch für
die Anwendung mit dem SSH-Protokoll (empfohlener Ersatz: group@SSH,
achten Sie auf die relative Position zu anderen
group-Direktiven).
•sha1_in_dnssec: Erlaubt den Einsatz von
SHA1 im DNSSec-Protokoll, selbst wenn er nicht in den hash- und
sign-Listen enthalten ist (empfohlener Ersatz: hash@DNSSec,
sign@DNSSec)
DATEIEN¶
/etc/crypto-policies/back-ends
Die einzelnen kryptographischen
Backend-Konfigurationsdateien. Normalerweise auf die im Paket crypto-policies
ausgelieferte Konfiguration verlinkt, außer eine Konfiguration aus
local.d wurde hinzugefügt.
/etc/crypto-policies/config
Eine Datei, die den Namen der auf dem System aktiv
gesetzten Kryptorichtlinie enthält.
/etc/crypto-policies/local.d
Zusätzliche, von anderen Paketen ausgelieferte
oder vom Systemadministrator erzeugte Konfiguration. Der Inhalt der
<back-end>-file.config ist an die Konfigurationsdatei aus dem
Richtlinien-Backend, wie es vom Paket crypto-policies ausgeliefert wird,
angehängt.
/usr/share/crypto-policies/policies
Systemrichtlinien-Definitionsdateien.
/usr/share/crypto-policies/policies/modules
Systemunterrichtlinien-Definitionsdateien.
/etc/crypto-policies/policies
Angepasste Richtliniendefinitionsdateien, wie durch den
Systemadministrator konfiguriert.
/etc/crypto-policies/policies/modules
Angepasste Unterrichtliniendefinitionsdateien, wie durch
den Systemadministrator konfiguriert.
/usr/share/crypto-policies/<'RICHTLINIENNAME'>
Vorerstellte Backend-Konfigurationen für
Richtlinie RICHTLINIENNAME.
AUTOR¶
Geschrieben von Tomáš Mráz.
ÜBERSETZUNG¶
Die deutsche Übersetzung dieser Handbuchseite wurde von
Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
GNU General
Public License Version 3 oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite
finden, schicken Sie bitte eine E-Mail an die
Mailingliste
der Übersetzer.