Beiträge von Alfredo534

  • Enterprise Policy Generator

    Zitat von Sören Hentzschel

    Der Enterprise Policy Generator 9.0 ist gerade erst mit zahlreichen Verbesserungen erschienen ...

    Die installierte Version hat sich wie von Zauberhand selber aktualisiert.
    Das Design sieht schick aus, die thematischen Gruppierungen, incl. die Gruppierungen in der Cipher Konfiguration gefallen mir. Die neue Optionen werde ich mir in den nächsten Tagen ansehen.

    Besten Dank.

    Unterstützt die 9.0 Version auch den Thunderbird und wo schaltet man gegebenenfalls zwischen Firefox und Thunderbird Datei Erstellung um?

  • Enterprise Policy Generator

    Zitat

    Ist das hiermit klarer?

    Das ist aus Nutzersicht sicher eine sehr schöne Detailoptimierung.
    Besten Dank

    Zu dem ursprünglich angesprochenen Punkt der für mich, eine Ebenen höher, eingeschränkt intuitiven Bedienung, habe ich eine Idee, die jedoch erst noch reifen muss. Mal sehen.

  • Enterprise Policy Generator

    Zitat

    Und deswegen fiel die Entscheidung, bei der aktuellen Button-Beschriftung „Konfiguration laden” zu bleiben.

    An der Stelle an der ich mir aus Gründen der intuitiven Bedienbarkeit eine andere Beschriftung wünsche, ist nichts was ich als Button bezeichnen würde. Auch wäre vom Platz her bei mir genügend Platz für einen vielfach breiteren Button. Aber ich arbeite am PC. Mgl. Weise besteht am Handy ein Platzproblem, welches ich am PC nicht sehe.

    Screenshot der Stelle die ich meine:



    Originaltext:
    Load configuration

    Gewünschter auszudrückender Inhalt, der mit dem Button auszudrückenden Aussage:
    Configuration: load, delete, export

    Lösungsansätze:

    Unterschiedlich lange Darstellungsmöglichkeiten.:
    Load configuration
    Configuration: load, delete, export
    Configuration: load, del., exp.
    Config.: load, del., exp.
    Conf. load, del., exp.
    Conf load del exp

    Weiter Schrumpfungsmöglichkeiten für die Buttonbreite:
    * Den Button in zwei Textzeilen übereinander darstellen
    Configuration:
    load, del., exp.


    * Anders als vermutet scheint es im Unicode mgl. Weise keine schmaleren Zeichen zu geben als sie normal verwendet werden.

    Aber es gibt wohl schmalere Schriftarten als Lösungsmöglichkeit:
    Übliche Bezeichnungen sind zum Beispiel Condensed, Narrow oder Compressed; bekannte Beispiele sind etwa Arial Narrow, Helvetica Condensed oder PT Sans Narrow.

    CSS als Lösungsansatz:
    Kann je nach Font-Familie zum Beispiel font-stretch: condensed; verwenden oder gleich eine kondensierte Schrift laden. Nicht jede Schrift unterstützt echte Breitenvarianten, daher ist die verfügbare Font-Familie entscheidend.

  • Enterprise Policy Generator

    Zitat von Sören Hentzschel

    Eventuell könnte ich an dieser Stelle noch einen Satz ergänzen, dass .policy-Dateien aus dem Enterprise Policy Generator exportiert werden können.

    Ohh. Danke. Jetzt habe ich das verstanden. Ich entsinne mich jetzt dunkel daran das vor Jahren schon einmal erfolgreich kurzzeitig exportiert zu haben.

    Der von dir gepostete Screenshot sieht für mich sehr gut aus.
    Einen darüber hinaus gehenden erklärenden Satz würde ich als Nutzer vmtl. nicht benötigen. Aber er kann natürlich trotzdem gut sein.

    Was ich mir wünsche ist jedoch etwa folgendes: Das der Text des Punktes "Load configuration", gegen den Text "Configuration: load, delete, export" ersetzt wird. Dann wäre das restliche, zumindest für mich klar und auch in diesem Punkt intuitiv zu bedienen.

    Danke noch mal für deine Arbeit und deine Erklärung.

  • Enterprise Policy Generator

    @ Sören,

    Wünsche bzgl. der nächsten Version des Enterprise Policy Generators.

    Zu einem bestimmten Bereich hast du mir einmal freundliche Weise folgende Erklärung geschrieben:


    Zitat

    Speichern → Damit kann die auf der linken Seite vorgenommene Konfiguration gespeichert werden, sodass du diese zu einem beliebigen Zeitpunkt später erneut laden und ggf. anpassen kannst, ohne alles neu konfigurieren zu müssen.

    Laden → Das Gegenstück zum Speichern. Alle gespeicherten Konfigurationen werden darüber aufgelistet und können geladen werden. Über den Dialog können gespeicherte Konfigurationen auch gelöscht oder exportiert werden. Der Export erlaubt es, die Konfiguration für den Enterprise Policy Generator auch auf anderen Geräten zu nutzen.

    Hierbei wünsche ich mir eine wie auch immer geartete Erklärung, wie vlt. etwa folgende:

    "Speichern" ersetzen durch: "Speichern im Enterprise Policy Generator" oder "Speichen Addon intern" oder "Speichern im EPG" o.ä.
    "Laden" ersetzen durch: "Laden aus Enterprise Policy Generator" oder "Laden aus Addon" oder "Laden aus EPG" o.ä.

    Zitat

    Download [policies.json] → Nach der Konfiguration auf der linken Seite wird auf der rechten Seite der Button zur Generierung der Richtlinien gedrückt. Dann erscheint die Ausgabe für die Datei policies.json und unter anderem auch die Download-Option. Die macht nichts anderes, als den Inhalt, der darüber steht, als Datei policies.json abzuspeichern. Dann muss die Datei nur noch an den richtigen Ort kopiert werden. Wo dieser ist, wird zu Beginn der rechten Seite erklärt.

    "Download policies.json"
    Diesen Punkt kann ich so versehen. Würde ihn jedoch evtl. als "policies.json lokal speichern" verständlicher finden. Aber das ist vlt. nicht wichtig und auch eher nur eine Geschmacksfrage.

    Zitat

    Importieren [Import Konfiguration]→ Dort kann die Konfiguration, die zuvor exportiert worden ist, neu importiert werden. Nach dem Import steht die Konfiguration über den Dialog zum Laden von Konfigurationen zur Verfügung.

    Bei diesem Punkt "Import Konfiguration" habe ich noch nie heraus bekommen, wie man damit etwas tun kann. Wenn man diesen Punkt aufruft, bekommt man ein Menü, wo man eine Datei "*.policy" auswählen könnte, wenn man eine solche hätte. Wenn ich unter Debian eine Suche über mein System laufen lasse, sieht es mir nicht so aus, als ob ich eine solche irgend wo hätte die etwas mit einem Firefox zu tun hat. Ich habe zwar ein paar solche Dateien, die jedoch vmtl. etwas mit Java zu tun zu haben scheinen.

    Auch habe ich sonst keine sachdienlichen Hinweise gefunden, wo ich eine solche Datei herbekommen könnte. Meine Vermutung wäre, das ich hier eine policys.json Datei laden können sollte. Dies scheint jedoch nicht der Fall zu sein.

  • Enterprise Policy Generator

    @Sören,

    Anpassungsidee für zukünftige Enterprise Policy Generator Versionen:

    Die Cipher Suites in etwa folgender Reihenfolge und Kenntlichmachung der Sicherheitskategorie anordnen. Dann können auch Nutzer die sich nicht mit Ciphern auskennen, vlt. trotzsdem eine sinnvolle Wahl treffen.

    Die Cipher-Suites lassen sich nach Sicherheit in Gruppen einteilen, basierend auf TLS-Version, Key-Exchange (PFS-fähig oder nicht), Verschlüsselungsmodus (AEAD wie GCM/ChaCha20 vs. CBC), Schlüssellänge und bekannten Schwachstellen.
    Höchste Sicherheit: TLS 1.3 (AEAD, PFS integriert)

    In Zukunft werden da sicher vlt. als Post Quantum Cipher oder TLS 1.4 Cipher bezeichnete dazu kommen. Zur Standardisierung gibt es da wohl seit geraumer Zeit bereits Beiträge durch NIST. Aktuell sieht die Situation für mich wie folgt aus:

    Höchste Sicherheit: Diese Gruppe nutzt ausschließlich TLS 1.3 mit integriertem Forward Secrecy (PFS) durch eingebaute Ephemeral-Key-Exchange-Mechanismen und moderne AEAD-Verschlüsselung (GCM oder ChaCha20). Sie sind resistent gegen bekannte Angriffe wie BEAST, Lucky Thirteen oder Padding Oracle und bieten die stärkste Quantensicherheit.

    TLS_AES_128_GCM_SHA256 (Firefox 138+, Firefox ESR 128.10+)
    TLS_AES_256_GCM_SHA384 (Firefox 138+, Firefox ESR 128.10+)
    TLS_CHACHA20_POLY1305_SHA256 (Firefox 138+, Firefox ESR 128.10+)

    Hohe Sicherheit: TLS 1.2 (ECDHE, AEAD, PFS)

    TLS 1.2 mit ECDHE (ECDH mit Ephemeral Keys für PFS), AEAD-Modi (GCM/ChaCha20) und starken Schlüsseln (AES-128/256, SHA256/384). Diese bieten hervorragende Sicherheit, sind aber etwas anfälliger für Implementierungsfehler als TLS 1.3, da CBC-Fallbacks möglich sind.

    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
    TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

    Mittlere Sicherheit: TLS 1.2 (ECDHE, CBC, PFS)

    TLS 1.2 mit ECDHE (PFS), aber veraltetem CBC-Modus (AES-128/256, SHA1/SHA256). CBC ist anfällig für Padding-Oracle-Angriffe (Lucky Thirteen) und erfordert strenge Implementierungen; SHA1 schwächt die Integrität.

    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

    Niedrige Sicherheit: TLS 1.2 (DHE, CBC, PFS)

    TLS 1.2 mit DHE (Ephemeral Diffie-Hellman für PFS), aber schwachem RSA-Auth und CBC-Modus. DHE ist langsamer und potenziell anfälliger für Logjam-Angriffe bei schwachen DH-Gruppen; CBC-Probleme persistieren.

    TLS_DHE_RSA_WITH_AES_128_CBC_SHA
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA

    Unsicher: TLS 1.2 (RSA, AEAD/CBC, kein PFS)

    TLS 1.2 mit statischem RSA-Key-Exchange (kein PFS, ermöglicht Session-Wiederaufnahme-Angriffe). Selbst mit AEAD (GCM) oder CBC fehlt Ephemerality; RSA-only ist gegen zukünftige Key-Kompromittierungen vulnerabel.

    TLS_RSA_WITH_AES_128_GCM_SHA256
    TLS_RSA_WITH_AES_256_GCM_SHA384
    TLS_RSA_WITH_AES_128_CBC_SHA
    TLS_RSA_WITH_AES_256_CBC_SHA

    Kritisch unsicher: TLS 1.2 (RSA, 3DES, kein PFS)

    TLS 1.2 mit 3DES (56-Bit-Sicherheit, Sweet32-Birthday-Attacke) und statischem RSA (kein PFS). Vollkommen veraltet, aktiv angreifbar und sollte sofort deaktiviert werden.

    TLS_RSA_WITH_3DES_EDE_CBC_SHA

    Aus meiner Sicht, wäre es 2026-05 für den Normalnutzer sinnvoll beim Firefox, alle älteren Cipher als die folgenden zu sperren. Eventuell wäre so etwas in der Art auch im Enterprise Policy Generator als Empfehlung, Vorlage o.ä. sinnvoll.

    Im Firefox alles andere sperren bis auf die folgenden Cipher:

    Höchste Sicherheit: TLS 1.3 (AEAD, PFS integriert)

    TLS_AES_128_GCM_SHA256 (Firefox 138+, Firefox ESR 128.10+)
    TLS_AES_256_GCM_SHA384 (Firefox 138+, Firefox ESR 128.10+)
    TLS_CHACHA20_POLY1305_SHA256 (Firefox 138+, Firefox ESR 128.10+)

    Hohe Sicherheit: TLS 1.2 (ECDHE, AEAD, PFS):

    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
    TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • Konfiguration von Firefox & Firefox-esr, per Enterprise Policy Generator und policies.json

    Zitat von Chris23tr

    Ich hab ...

    Vlt. hilft dir folgende Einschätzung bei der Wahl der Cipher die du nicht sperrst oder nicht sperrst. Die Cipher die nicht einmal TS1.2 schaffen stehen da nicht drin und die sollte man ohnehin meiner Meinung nach sperren.

    Die Cipher-Suites lassen sich nach Sicherheit in Gruppen einteilen, basierend auf TLS-Version, Key-Exchange (PFS-fähig oder nicht), Verschlüsselungsmodus (AEAD wie GCM/ChaCha20 vs. CBC), Schlüssellänge und bekannten Schwachstellen.
    Höchste Sicherheit: TLS 1.3 (AEAD, PFS integriert)

    Diese Gruppe nutzt ausschließlich TLS 1.3 mit integriertem Forward Secrecy (PFS) durch eingebaute Ephemeral-Key-Exchange-Mechanismen und moderne AEAD-Verschlüsselung (GCM oder ChaCha20). Sie sind resistent gegen bekannte Angriffe wie BEAST, Lucky Thirteen oder Padding Oracle und bieten die stärkste Quantensicherheit.

    TLS_AES_128_GCM_SHA256 (Firefox 138+, Firefox ESR 128.10+)

    TLS_AES_256_GCM_SHA384 (Firefox 138+, Firefox ESR 128.10+)

    TLS_CHACHA20_POLY1305_SHA256 (Firefox 138+, Firefox ESR 128.10+)

    Hohe Sicherheit: TLS 1.2 (ECDHE, AEAD, PFS)

    TLS 1.2 mit ECDHE (ECDH mit Ephemeral Keys für PFS), AEAD-Modi (GCM/ChaCha20) und starken Schlüsseln (AES-128/256, SHA256/384). Diese bieten hervorragende Sicherheit, sind aber etwas anfälliger für Implementierungsfehler als TLS 1.3, da CBC-Fallbacks möglich sind.

    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

    TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

    TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

    Mittlere Sicherheit: TLS 1.2 (ECDHE, CBC, PFS)

    TLS 1.2 mit ECDHE (PFS), aber veraltetem CBC-Modus (AES-128/256, SHA1/SHA256). CBC ist anfällig für Padding-Oracle-Angriffe (Lucky Thirteen) und erfordert strenge Implementierungen; SHA1 schwächt die Integrität.

    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

    Niedrige Sicherheit: TLS 1.2 (DHE, CBC, PFS)

    TLS 1.2 mit DHE (Ephemeral Diffie-Hellman für PFS), aber schwachem RSA-Auth und CBC-Modus. DHE ist langsamer und potenziell anfälliger für Logjam-Angriffe bei schwachen DH-Gruppen; CBC-Probleme persistieren.

    TLS_DHE_RSA_WITH_AES_128_CBC_SHA

    TLS_DHE_RSA_WITH_AES_256_CBC_SHA

    Unsicher: TLS 1.2 (RSA, AEAD/CBC, kein PFS)

    TLS 1.2 mit statischem RSA-Key-Exchange (kein PFS, ermöglicht Session-Wiederaufnahme-Angriffe). Selbst mit AEAD (GCM) oder CBC fehlt Ephemerality; RSA-only ist gegen zukünftige Key-Kompromittierungen vulnerabel.

    TLS_RSA_WITH_AES_128_GCM_SHA256

    TLS_RSA_WITH_AES_256_GCM_SHA384

    TLS_RSA_WITH_AES_128_CBC_SHA

    TLS_RSA_WITH_AES_256_CBC_SHA

    Kritisch unsicher: TLS 1.2 (RSA, 3DES, kein PFS)

    TLS 1.2 mit 3DES (56-Bit-Sicherheit, Sweet32-Birthday-Attacke) und statischem RSA (kein PFS). Vollkommen veraltet, aktiv angreifbar und sollte sofort deaktiviert werden.

    TLS_RSA_WITH_3DES_EDE_CBC_SHA


    Meine Empfehlung für Leute die nicht zu viel sperren wollen und bei dieser Wahl GEWÖHNLICH nicht auf die Funktion von kommerziellen o.ä. Webseiten im Jahre 2026 verzichten müssen :

    Im Firefox alles andere sperren bis auf die folgenden Cipher:

    Höchste Sicherheit: TLS 1.3 (AEAD, PFS integriert)

    TLS_AES_128_GCM_SHA256 (Firefox 138+, Firefox ESR 128.10+)

    TLS_AES_256_GCM_SHA384 (Firefox 138+, Firefox ESR 128.10+)

    TLS_CHACHA20_POLY1305_SHA256 (Firefox 138+, Firefox ESR 128.10+)

    Hohe Sicherheit: TLS 1.2 (ECDHE, AEAD, PFS):

    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

    TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

    TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

    Aus Sicherheitssicht wäre es im Jahr 2026 wohl richtig, wenn man alle anderen Cipher, bis auf die beiden folgenden sperrt. Aber dann lassen sich einige Webseiten nicht mehr aufrufen, bei denen es die Admins es nicht so mit dem Stand der Technik haben. Auch gibt es mindestens noch eine Zertifikat ausstellende Stelle, die im Jahr 2026 noch immer RSA basierende Verfahren verwendet. Daher kann man in der Praxis, die folgende Wahl bisher nicht wirklich treffen.

    Höchste Sicherheit: TLS 1.3 (AEAD, PFS integriert)

    TLS_AES_256_GCM_SHA384 (Firefox 138+, Firefox ESR 128.10+)

    TLS_CHACHA20_POLY1305_SHA256 (Firefox 138+, Firefox ESR 128.10+)

  • Konfiguration von Firefox & Firefox-esr, per Enterprise Policy Generator und policies.json

    Zitat von Chris23tr

    Die steht auf....


    Vlt. doch lieber noch mal einen Blick auf folgendes werfen:

    Zitat


    Aus meiner Sicht hat man im Jahr 2026 keine Einschränkungen im täglichen Gebrauch bei , wenn man die 9 neuesten Cipher verwendet (drei pro Kategorie). Wie man diese aussuchen könnte ohne sich in das Thema einarbeiten zu müssen, steht im Eingangspost. Wer gerne etwas lesen möchte um das auf Plausibilität zu prüfen oder einen Einstiegspunkt sucht um zu wissen wonach er suchen muss, wenn er sich tiefer mit dem Thema tiefer zu befassen will, kann einen Blick in z.B. folgendes werfen:
    * https://www.zi.uzh.ch/dam/jcr:3bf073…uites_V_1_1.pdf

  • Konfiguration von Firefox & Firefox-esr, per Enterprise Policy Generator und policies.json

    Zitat von Sören Hentzschel

    Ebenso. Der Begriff „Perfect Forward Secrecy" ist bislang in diesem Thema kein einziges Mal gefallen und du wirfst jetzt auch nur einfach blind ohne Erklärung ein Zitat in den Raum.

    Da steht in der aktuellen Version des Eingangsbeitrags die folgende etwas unscharfe Formulierung zu:

    Zitat

    Bsp. für potentiell sinnvolle Konfigurationsmöglichkeiten per policies.json:
    * erwägen Cipher Suites zu deaktivieren, die nicht einmal TLS 1.2 unterstützen und die kein PFS unterstützen.
    ...

    Habe die Passage soeben durch folgende eindeutigere ersetzt:

    Zitat

    Bsp. für potentiell sinnvolle Konfigurationsmöglichkeiten per policies.json:
    * erwägen Cipher Suites zu deaktivieren, die nicht einmal TLS 1.2 unterstützen und Chiper Suiten die zwar wenigstens TLS 1.2 unterstützen, jedoch kein PFS (Perfekt Forward Security).
    ...

  • Konfiguration von Firefox & Firefox-esr, per Enterprise Policy Generator und policies.json

    Was eine Webseite im konkreten Fall für eine Cipher mit einem bei einem Aufruf per Firefox verwendet, kann man sich vermeintlich wie folgt ansehen:
    FF Adressleiste--Schlossymbol--Connection secure--More information

    Eine teils völlig anderes Bild erhält an jedoch, wenn man einen Blick auf folgendes wirft. Ich will nicht sagen das an dieser Stelle Chipher genannt werden, jedoch Protokolle. Und wenn man weiß welche Cipher welche Protokolle eben nicht unterstützen, kann man vermuten das das was unter obiger Quelle zu sehen bekommt, eben nur ein Teil der Wahrheit ist.
    about:networking

    Aus meiner Sicht hat man im Jahr 2026 keine Einschränkungen im täglichen Gebrauch bei , wenn man die 9 neuesten Cipher verwendet (drei pro Kategorie). Wie man diese aussuchen könnte ohne sich in das Thema einarbeiten zu müssen, steht im Eingangspost. Wer gerne etwas lesen möchte um das auf Plausibilität zu prüfen oder einen Einstiegspunkt sucht um zu wissen wonach er suchen muss, wenn er sich tiefer mit dem Thema tiefer zu befassen will, kann einen Blick in z.B. folgendes werfen:
    * https://www.zi.uzh.ch/dam/jcr:3bf073…uites_V_1_1.pdf

  • Konfiguration von Firefox & Firefox-esr, per Enterprise Policy Generator und policies.json

    Zitat von Sören Hentzschel

    Was ist …

    a) … der Unterschied zu deinem letzten Thema?
    b) … deine Frage?

    a) Das Letzte Thema bezog sich auf die Konfigurierung des Thunderbird. Dieses Thema bezieht sich auf den Firefox.
    b) Ich habe aktuell keine Fragen zu dem Thema. Das Thema dient dazu das es etwas im Internet gibt, was sich mit der Anwendung beschäftigt und vltl. somit einen kleinen Beitrag zur Bekanntheit des für mich hilfreichen Tools Enterprise Policy Generator leistet.

  • Konfiguration von Firefox & Firefox-esr, per Enterprise Policy Generator und policies.json

    Folgendes Thema bezieht sich auf ein Linux Debian 13 (LMDE7), 64 Bit, mit Cinnamon Desktop. Nutzer von Windows oder MAC OS, müssten vmtl. ein paar Pfade und Befehle bei der Nutzung von unten stehendem anpassen.

    Mit den nicht nur per Hand, sondern auch komfortabel per Enterprise Policy Generator erstellbaren policies.json Dateien, lassen sich eine ganze Reihe von Einstellungen beim Firefox und Firefox-esr vornehmen.

    An dieser Stelle herzlichen Dank an Sören Hentzschel, für die neue 8.0 Version des Enterprise Policy Genenerators.

    Bekanntmachung über Erscheinen der 8.0 Version:
    * https://www.camp-firefox.de/artikel/1182-g…-zwischenablage

    Downloadmöglichkeit:
    * https://addons.mozilla.org/en-US/firefox/…licy-generator/

    Potentieller Vorteil:
    * Konfiguration ist für alle Nutzer eines Rechners über eine Datei pro Rechner möglich
    * Bei entsprechendem Anmeldescript, kann man das als Admin auch auf alle Rechner eines Netzwerks verteilen
    * Es kann auch unterbinden, das bestimmte Einstellungen vom Nutzer, Programmupdates als auch manchen Schadroutinen verändert werden können
    * usw.

    Links zu Dokus:
    * https://firefox-admin-docs.mozilla.org/reference/policies/
    * https://mozilla.github.io/policy-templates/

    Bedienungsanleitung:
    * https://www.soeren-hentzschel.at/firefox-webext…term=enterprise

    Firefox Support:
    * https://support.mozilla.org/en-US/products/firefox

    Ablageort der policies.json Datei (Ist anders als man vermuten könnte, für Firefox und Firefox-esr identisch !!!)
    * /etc/firefox/policies/policies.json # bei gewünschter systemweiter Anwendung.

    Entfernen einer alten Datei, wenn gewünscht:

    Code
    sudo rm /etc/firefox/policies/policies.json

    Anlage des Ordners (wenn nicht vorhanden), mit den mutmaßlich richtigen Verzeichnisrechten:

    Code
    sudo mkdir -p /etc/firefox/policies

    Anlage der policies.json (mit den mutmaßlich richtigen Dateirechten:

    Code
    sudo touch /etc/firefox/policies/policies.json

    Editieren von policies.json mit Systemtechten per xed Editor (man kann auch einen anderen nehmen):

    • die folgende Variante lässt einem die policies.json mit Systemrechten editieren, ohne dabei den Editor mit Systemrechte auszuführen und ohne die Systemrechte der zu editierenden Datei zu ändern.
    Code
    xed admin:///etc/firefox/policies/policies.json

    Beispiel für eine einfache policies.json:

    Code
    {
  "policies": {
    "SSLVersionMin": "tls1.2",
    "SSLVersionMax": "tls1.3"
  }
}

    Anwendung der policies.json einleiten:
    * den Firefox neu starten

    Kontrolle ob die Datei policies.json tatsächlich verwendet wird:
    Zumindest eine Einstellung vor und nach der Änderung per policies.json auf geänderte Anwendung überprüfen, in dem man sich den zu überprüfenden Wert per folgende Einstiegspunkt per Eingabe in der Adresszeile heraus sucht:
    about:config

    Bsp. für potentiell sinnvolle Konfigurationsmöglichkeiten per policies.json:
    * erwägen Cipher Suites zu deaktivieren, die nicht einmal TLS 1.2 unterstützen und Chiper Suiten die zwar wenigstens TLS 1.2 unterstützen, jedoch kein PFS (Perfekt Forward Security). Hierzu z.B. auf der folgenden Seite vor dem deaktivieren irgend welcher Cipher Suiten anzeigen lassen, welche der Cipher suiten dort als Recommend angezeigt werden und dann erwägen alle anderen Cipher Suiten per policies.json zu deaktivieren:
    * https://browserleaks.com/tls
    * usw., usw.

    Ablageort der policies.json:
    In meinem Fall lautet der richtige systemweite Ablageort wie folgt. Bei anderen Linux Versionen, und anderen Art und Weisen den Thunderbird zu installieren, mag das anders sein.
    /etc/firefox/policies/policies.json

    Vmtl. Ablageort für Nutzer abhängige Konfigurationen (ungetestet):
    /usr/lib/firefox/distribution/policies.json

    Verwandte Diskussion zur Konfigurierbarkeit von Thunderbird per policies.json:
    * Konfiguration von Thunderbird, per Enterprise Policy policies.json

    Nachtrag:
    Anregungen und Beispiel zur Auswahl und Sperrung von Cipher:
    * RE: Konfiguration von Firefox & Firefox-esr, per Enterprise Policy Generator und policies.json
    * RE: Konfiguration von Firefox & Firefox-esr, per Enterprise Policy Generator und policies.json

  • Konfiguration von Thunderbird, per Enterprise Policy policies.json

    So, jetzt habe ich eine Angabe in einer offiziellen Quelle gefunden:
    " Linux: place the file into thunderbird/distribution, where thunderbird is the installation directory for Thunderbird. You can also specify a system-wide policy by placing the file in /etc/thunderbird/policies."
    * https://thunderbird.github.io/policy-templat…plates/central/

    Daraus ergibt sich dann ersteinmal folgendes:
    /etc/thunderbird/policies/policies.json

    Jetzt kann ich das testen.