Seiten: [1] 
|
 |
|
|
Autor
|
Thema: Web Key Directory (WKD) (Gelesen 815 mal)
|
|
Sebastian
Sr. Member
 Offline
Einträge: 487
|
 |
Web Key Directory (WKD)
« am: 23. September 2023, 18:11:00 »
|
|
Hallo Suletuxe,
Ich bin grade dabei mich über das WKD (Web Key Directory) zu informieren.
Nachfolgend werde ich hier meine gesammelten Erkenntnisse und Anmerkungen posten.
Damit nachvollzogen werden kann, wie man vorgehen könnte, um sich einem unbekannten Thema anzunähern.
Deswegen werde ich hier explizit auch meine Wissenslücken erwähnen, die ich beizeiten schließen werde.
Was ist ein Web Key Directory (WKD)?
Ich finde, WKD ist die optimale Methode, seinen PGP Key zu verbreiten.
Denn den Key von selben Server zu beziehen, der in Besitz der Domain der E-Mail-Adresse ist sollte man besser vertrauen können, als einen Key Server wo jeder einen x-beliebigen Key ablegen kann.
Nach dem Studium folger Seiten:
https://wiki.gnupg.org/WKD
https://wiki.gnupg.org/WKDHosting
https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Freie-Software/E-Mail-Verschluesselung/EasyGPG/easygpg.html
https://www.uriports.com/blog/setting-up-openpgp-web-key-directory/
https://wiki.gnupg.org/WKD/UsabilityOfWKD
https://github.com/mihalyr/openpgpkey
Gibt es zwei Möglichkeiten, WKD zu implementieren.
Eine davon ist die Advanced Methode, die schwieriger einzurichten ist und ein von einer Zertifizierungsstelle signiertes und vertrauenswürdiges Zertifikat für die openpgpkey-Subdomäne erfordert.
Für die Direct Methode sind keine zusätzlichen DNS-Einträge erforderlich, es muss jedoch sichergestellt sein, dass die Subdomäne „openpgpkey“ nicht existiert und keinem Platzhalterzeichen unterliegt. Wenn ein Platzhalter für die Domäne verwendet wird, muss ein leerer TXT RR (todo: Nachschlagen, was das ist) für die openpgpkey-Subdomäne eingefügt werden.
Zudem können auch beide Methoden gleichzeitig angeboten werden. Wobei, wenn nur eine Methode verwendet werden soll, die Advanced Methode vorgezogen werden sollte.
https://wiki.gnupg.org/WKD/UsabilityOfWKD
C2 - Advanced method: The product allows fetching pubkeys somehow, by the preferred, "advanced" method of WKD.
Why? - Not all servers are able to offer the Direct method. Implementing both direct and advanced method means a higher chance that users get a key and can use encryption.
|
|
Nun da Andreas immer ganz vorne mit dabei ist, was den Stand der Technik anbelangt, habe ich mal seine öffentliche E-Mail-Adresse mit diesem WKD Checker untersucht:
https://metacode.biz/openpgp/web-key-directory
dabei kam folgendes Ergebnis heraus:
Direct: key: https://suletuxe.de/.well-known/openpgpkey/hu/mg6owx9w8c3ejg3tu31f4tha5n17d4rj?l=info
Direct: found key: 3A551DA1A31B8D07E18CE339C7B1F010BB65E1A0
Direct: Key contains correct User ID: Andreas Richter <info@suletuxe.de>
Direct: CORS header is correctly set up
Direct: Policy file is present
Advanced: key: https://openpgpkey.suletuxe.de/.well-known/openpgpkey/suletuxe.de/hu/mg6owx9w8c3ejg3tu31f4tha5n17d4rj?l=info
Advanced: key missing
Advanced: `Access-Control-Allow-Origin: *` header is missing
Advanced: Policy file is missing
|
|
Man erkennt das Andreas auf seinen Server die direkte WKD Methode anbietet.
Moderne E-Mail-Clients sollten so in der Lage sein, den öffentlichen Schlüssel von Andreas E-Mail Adresse von seinem Web Server automatisch zu beziehen. Sodass, man von Anfang an eine verschlüsselte E-Mail Kommunikation herstellen kann.
Also probiere ich das doch gleich mal aus:
Der folgende Befehl ist unnötig lang um zu erzwingen, dass nur über WKD versucht wird den Key zu beziehen. Im Alltag geht es mit gpg --locate-keys einfacher.
gpg --auto-key-locate clear,wkd,nodefault --verbose --locate-key info@suletuxe.de
gpg: enabled compatibility flags:
gpg: verwende Vertrauensmodell pgp
gpg: WARNUNG: HTTP Weiterleitung wurde gesäubert
gpg: (weitere Infos: changed from 'https://suletuxe.de/.well-known/openpgpkey/hu/mg6owx9w8c3ejg3tu31f4tha5n17d4rj?l=info' to 'https://www.suletuxe.de/.well-known/openpgpkey/hu/mg6owx9w8c3ejg3tu31f4tha5n17d4rj?l=info')
gpg: pub rsa2048/C7B1F010BB65E1A0 2016-05-03 Andreas Richter <info@suletuxe.de>
gpg: Schlüssel C7B1F010BB65E1A0: "Andreas Richter <info@suletuxe.de>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg: unverändert: 1
gpg: auto-key-locate found fingerprint 3A551DA1A31B8D07E18CE339C7B1F010BB65E1A0
gpg: `info@suletuxe.de' automatisch via WKD geholt
pub rsa2048 2016-05-03 [SCEA]
3A551DA1A31B8D07E18CE339C7B1F010BB65E1A0
uid [ unbekannt ] Andreas Richter <info@suletuxe.de>
sub rsa2048 2016-05-03 [SEA]
|
|
Es hat also geklappt, ich konnte Andreas Pubkey von seiner eigenen Domain beziehen.
Was hier noch auffällt ist das Andreas sein Server automatisch eine HTTP Anfrage auf das HTTPS Protokoll umleitet, dass gut ist.
Zudem ist der PGP Key von Andreas für heutige Verhältnisse ein wenig klein, zumindest für einen RSA Schlüssel. Das nicht heisen soll das dieser unsicher ist. Hier muss jeder für sich eine Risikoeinschätzung durchführen das für jeden anders ausfallen kann.
https://wiki.gnupg.org/LargeKeys
From GnuPG version 2.2.22 (August 2020) the default is an 3072 RSA keypair. (Before, GnuPG's default was an 2048 bit RSA keypair and the FAQs on keysize (accessed 2020-08-28) still has the old reasoning.)
The recommendation is made to serve most users best.
|
|
Ich persönlich nutze den Ed25519 Algorithmus, der von der Stärke her mit einem 3072 RSA Key verglichen werden kann. Aber eine wesentliche kürzere Schlüssellänge hat. Diese wird übrigens seit ca. 1 Jahr auch gerne für ssh Keys nun verwendet.
Nun wollte ich das ganze jetzt auch von meinen E-Mail Provider wissen:
Direct: key: https://proton.me/.well-known/openpgpkey/hu/dj3498u4hyyarh35rkjfnghbjxug6b19?l=contact
Direct: key missing
Direct: `Access-Control-Allow-Origin: *` header is missing
Direct: Policy file is missing
Advanced: key: https://openpgpkey.proton.me/.well-known/openpgpkey/proton.me/hu/dj3498u4hyyarh35rkjfnghbjxug6b19?l=contact
Advanced: found key: B60F01A95A6231F9F3D3CEADF05782D4B09C06B9
Advanced: Key contains correct User ID: contact@proton.me <contact@proton.me>
Advanced: `Access-Control-Allow-Origin: *` header is missing
Advanced: Policy file is present
|
|
Mein E-MAil Provider unterstützt also die Advanced Methode.
Hier fehlt auf das hier etwas nicht zu stimmen scheint:
Advanced: `Access-Control-Allow-Origin: *` header is missing
https://portswigger.net/web-security/cors/access-control-allow-origin
https://stackoverflow.com/questions/10636611/how-does-the-access-control-allow-origin-header-work
Das hat wohl was mit Domain Sicherheit zu tun. Damit Webbrowser nicht einfach Inhalt von einer anderen Domain laden können.
Da Proton in puncto Sicherheit weis, was sie da machen, gehe ich da erst mal ganz stark davon aus das deswegen kein Wildcard benutz wird das jede Domain erlaubt, sondern nur auf ihre eigene Restriktiert. (Todo: Ergründen, wie man dies überprüfen kann.)
Machen wir also trotzdem den Check, ob wir einen Key per WKD holen können, da Proton schließlich seid 2019 behauptet, dass dies unterstützt wird.
https://proton.me/de/blog/security-updates-2019
Diese Funktion erleichtert das Versenden von PGP-verschlüsselten E-Mails an Personen, die Proton Mail nicht nutzen. Das Web-Key-Verzeichnis (WKD) ermöglicht es Domains, ihre eigenen Schlüssel bereitzustellen, anstatt sich auf potenziell nicht vertrauenswürdige Schlüssel zu verlassen, die auf öffentliche Server hochgeladen werden. Unsere Server verwenden automatisch das WKD, um nach Schlüsseln auf externen Domains zu suchen und aktivieren automatisch die Ende-zu-Ende-Verschlüsselung, wann immer dies möglich ist.
|
|
gpg --auto-key-locate clear,wkd,nodefault --verbose --locate-key contact@proton.me
gpg: enabled compatibility flags:
gpg: verwende Vertrauensmodell pgp
gpg: pub ed25519/F05782D4B09C06B9 2022-05-03 contact@proton.me <contact@proton.me>
gpg: Schlüssel F05782D4B09C06B9: Öffentlicher Schlüssel "contact@proton.me <contact@proton.me>" importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg: importiert: 1
gpg: 1 Schlüssel bislang bearbeitet (0 Validity Zähler gelöscht)
gpg: keine ultimativ vertrauenswürdigen Schlüssel gefunden
gpg: auto-key-locate found fingerprint B60F01A95A6231F9F3D3CEADF05782D4B09C06B9
gpg: `contact@proton.me' automatisch via WKD geholt
pub ed25519 2022-05-03 [SC]
B60F01A95A6231F9F3D3CEADF05782D4B09C06B9
uid [ unbekannt ] contact@proton.me <contact@proton.me>
sub cv25519 2022-05-03 [E]
|
|
Das hat auch geklappt. Hier sieht man das Proton den cv25519 Algorithmus für seinen Schlüssel benutzt.
Also scheint es das Access-Control-Allow-Origin im Header keine Auswirkung auf die Funktion hat, wenn dieser Strickter festgelegt wurde.
Jetzt muss ich nur noch ergründen, wie das im Detail funktioniert und warum die meisten Guides empfehlen, diesen Teil des Headers für alle Domains zuzulassen. Für mich sieht das nach einen Angriff Schwachpunkt aus, falls man hier alle Domains zulässt. Zumindest könnte man so glaube ich eine Pfisching Webseite vorbereiten, indem man Inhalt von einer externen Domain von einer anderen abruft. Aber das ist jetzt gefährliches Halbwissen von mir und nur ein Gefühl in welche Richtung es gehen könnte, ohne jegliche Erfahrung darüber (todo: Nachforschen, ob diese Vermutung richtig ist)
Wenn jemand mehr dazu weis, der darf es mir gerne erklären, wenn Zeit dafür vorhanden ist. Oder mich auf die richtigen Informationsquellen führen. Dafür dann schon mal danke
LG
Sebastian
Edit:
Die OpenPGP Web Key Directory specification erklärt es ein wenig genauer das die Erweiterte Methode der direkten vorzuziehen ist.
https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service#name-key-discovery
There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if an address for the required sub-domain does not exist, they SHOULD fall back to the direct method. A non-responding server does not mean that the fall back should be carried out.
|
|
Demnach ist die direkte Methode als Fallback zu betrachten.
The benefit of the advanced method is its greater flexibility in setting up the Web Key Directory in environments where more than one mail domain is hosted. DNS SRV resource records, as used in earlier specifications of this protocol, posed a problem for implementations which have only limited access to DNS resolvers. The direct method is kept for backward compatibility and to allow providing a Web Key Directory even without DNS change requirements.
|
|
Das erklärt warum Proton auf die Advanced Methode setzt. Nicht nur das diese nach dem Standard zu bevorzugen ist sondern auch weil diese als grade als E-Mail Provider mit mehren Domains zu tun haben.
Sites which do not use the advanced method but employ wildcard DNS for their sub-domains MUST make sure that the openpgpkey sub-domain is not subject to the wildcarding. This can be done by inserting an empty TXT RR for this sub-domain.
|
|
Und das erklärt schon mal warum ein empty TXT RR für die sub-domain angelegt werden sollte. (todo: immer noch klären was ein TXT RR Eintrag ist)
Über diese Seite bin ich übrigends noch auf ein Tool gestoßen das dem core/gnupgp Paket mit beiliegt. Das genau für den zweck gemacht wurde zu prüfen ob ein WKD funktioniert.
man gpg-wks-client
The gpg-wks-client is used to send requests to a Web Key Service provider.
|
|
usr/lib/gnupg/gpg-wks-client
Es fehlt auf das dieses Tool nicht in einem Standard Pfad der PATH Variable liegt und deswegen auch nicht mit Auto complete erst mal gefunden werden kann
|
| « Letzte Änderung: 23. September 2023, 19:24:00 von Sebastian » |
 Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:Web Key Directory (WKD)
« Antwort #1 am: 23. September 2023, 18:19:37 »
|
|
Ich nutze WKD auf meinem Server seit ca. 4 Jahren  . Damit sind auch Emailadressen die auf @suletuxe.de enden eingeschlossen. DKIM nutze ich seit ca. 5 Jahren.
DKIM erlaubt aber nicht ein "verschlüsseln von Emails"! Vielmehr werden auch Mails die mit unsicheren Mailclients versendet werden (und daher nicht gleich dort signiert werden) vom Server signiert. Dabei werden alle Absender die auf "@xyz.abc" enden alle gleichermaßen behandelt - es ist also kein Emailadressen bezogenes System, sondern ein domainbezogenes System. Es wird also nur die Strecke vom Mailausgangsserver bis zum Maileingangsserver berücksichtigt. Aber besser nur eine Teilstrecke als gar nichts. Kommerzielle Betriebssysteme (Windows, Mac-OS) sind nur mit erheblichen Klimmzügen in der Lage mit gpg behandelten Mails umzugehen, und selbst DKIM stellt 99,99% aller kommerziellen Mail-Clients vor unlösbare Aufgaben. Mailserver die mit "Enterprise Outlook" arbeiten erkennen meine DKIM-Signatur sogar als falsch! Der Fehler existiert schon längere Zeit - er wird nicht beseitigt. Auf jeden Fall habe ich in den Einstellungen meines Mailservers festgelegt, dass Mails, deren DKIM-Signatur fehlt oder falsch ist vom annehmenden Mailserver abgelehnt werden soll. Es gibt eben intelligente Methoden der Spamflut Herr zu werden - wenn man in der Lage ist sie zu nutzen.
Ich bin immer wieder erstaunt wie hartnäckiges Ignorieren von guten Standards durch "die Großen" dazu führt, dass es nicht voran geht. Was mich aber nicht daran hindert voran zu gehen.
Allerdings scheint es aktuell immer mehr "in" zu sein zu verblöden. Da macht aber ein echter Linux-Nutzer (hoffentlich) nicht mit...
Ich freue mich schon auf das nächste Treffen!
LG
Andreas
|
| « Letzte Änderung: 23. September 2023, 18:33:31 von Andreas » |
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
