weil immer wieder Fragen bezüglich unverständlicher Zeichen oder der signature.asc im Anhang kommen. Führte kürzlich dazu, das jemand aus Panik den Computer ausschaltete, weil ein Angriff vermutet wurde.
Nun schicke ich immer den Link in der Signatur mit.
Kopieren erwünscht, Verbesserungsvorschläge für den Text auch!! Nur kein technischen Firlefanz, also DAU-verträglich...
(Entwurf) https://www.blubbablasen.de/openpgp.html
ich würde empfehlen, auf s/mime umzusteigen, dies hat bei den Clients eine hinreichende Verbreitung sodaß derartiges wie mit PGP/GnuPG nicht passiert;
oder anders, das mit der signature.asc können nur die verwenden, welche auch entsprechendes in deren Mail agents dazu erweitert haben, von Haus können das die wenigsten; hingegen bei S/MIME gibt es kaum einen Mail agent, der es nicht kann; und somit wird derartiges immer sauber angezeigt;
On 12.03.2019 19:30, Denny Hanschke wrote:
weil immer wieder Fragen bezüglich unverständlicher Zeichen oder der signature.asc im Anhang kommen. Führte kürzlich dazu, das jemand aus Panik den Computer ausschaltete, weil ein Angriff vermutet wurde.
Nun schicke ich immer den Link in der Signatur mit.
Kopieren erwünscht, Verbesserungsvorschläge für den Text auch!! Nur kein technischen Firlefanz, also DAU-verträglich...
(Entwurf) https://www.blubbablasen.de/openpgp.html
Am 2019-03-12 20:51, schrieb Walter H.:
ich würde empfehlen, auf s/mime umzusteigen, dies hat bei den Clients eine hinreichende Verbreitung sodaß derartiges wie mit PGP/GnuPG nicht passiert;
Technisch gesehen finde ich S/MIME auch besser, Problem ist nur ein Zertifikat zu bekommen (möglichst kostenlos). Daran scheitern die meisten, und deswegen wird sich das auch nie weiter durchsetzen. :-(
On Tue, March 12, 2019 21:28, J. Fahrner wrote:
Am 2019-03-12 20:51, schrieb Walter H.:
ich würde empfehlen, auf s/mime umzusteigen, dies hat bei den Clients eine hinreichende Verbreitung sodaß derartiges wie mit PGP/GnuPG nicht passiert;
Technisch gesehen finde ich S/MIME auch besser, Problem ist nur ein Zertifikat zu bekommen (möglichst kostenlos). Daran scheitern die meisten, und deswegen wird sich das auch nie weiter durchsetzen. :-(
das ist gar nicht das Problem; das Problem ist ganz was anderes;
das die End-to-End Verschlüsselung bei Mails ganz anders funktioniert und vor allem kritischer was jeden einzelnen betrifft, setzt es sich auch nicht wirklich durch; stell Dir nur vor, Du holst Dir jedes Jahr ein kostenloses S/MIME Zertifikat, dann hast Du ein riesiges Problem, solltest Du nach Jahren auf ein altes Mail - welches verschlüsselt ist - zugreifen wollen, und hast das Zertifikat, welches damals gültig war nicht mehr ...
aber das andere Feature - zu verifizieren, ob eine Mail auch tatsächlich vom Absender stammt und wenn dann auch nicht verändert wurde: Datenintegrität ist mit PGP gar nicht möglich, denn dies ist aus dem Stadium des selbstsignierten noch nicht aus sich herausgewachsen ...
und von daher schadet PGP mehr als es nützt;
hier: https://secure.comodo.net/products/frontpage?ap=Secorio&area=SecureEmail.... solltest f. 1 Jahr ein kostenloses S/MIME bekommen ...
HI!
On 13.03.19 07:22, Walter H. wrote:
Datenintegrität ist mit PGP gar nicht möglich, denn dies ist aus dem Stadium des selbstsignierten noch nicht aus sich herausgewachsen ...
Aha, hmmm, kannst Du uns das mal genau erläutern, wie Du zu dieser These gekommen bist?
Bitte, DANKE!
ttyl Django
On Wed, March 13, 2019 08:07, Django wrote:
HI!
On 13.03.19 07:22, Walter H. wrote:
Datenintegrität ist mit PGP gar nicht möglich, denn dies ist aus dem Stadium des selbstsignierten noch nicht aus sich herausgewachsen ...
Aha, hmmm, kannst Du uns das mal genau erläutern, wie Du zu dieser These gekommen bist?
anders herum, wie sollte bei Verwendung eines selbstsignierten Zertifikates selbiges bei S/MIME denn funktionieren?
sprich: wenn es nicht möglich ist festzustellen, ob eine Mail auch tatsächlich vom besagten Absender kommt, spielt es auch keine Rolle mehr, ob diese Mail verändert wurde oder nicht ...
Griasde Walter,
On 13.03.19 10:06, Walter H. wrote:
anders herum, wie sollte bei Verwendung eines selbstsignierten Zertifikates selbiges bei S/MIME denn funktionieren?
Moment, das ist aber nun die falsche Antwort zu meiner Frage, warum Du meintest "... Datenintegrität ist mit PGP gar nicht möglich".
Also Du kannst Dich z.B. jederzeit davon überzeugen, dass z.B. Pakete aus (m)einem Repository integer sind, also vom Maintainer des Paketes erstellt wurde. Warum soll das mit PGP nicht möglich sein, die Datenintegrität zu prüfen?
Auch soll sowas durchaus auch beim Medium eMail funktionieren. Ich sitze hier z.B. vor einem Gateway welches für 2500 Benutzer durchaus in der Lage ist, an Hand der hinterlegten Schlüsselmaterials zum einen den Absender zweifelsfrei zu identifizieren wie auch die Integrität der Daten selbst zu prüfen.
sprich: wenn es nicht möglich ist festzustellen, ob eine Mail auch tatsächlich vom besagten Absender kommt, spielt es auch keine Rolle mehr, ob diese Mail verändert wurde oder nicht ...
Kommt auf den Anwendungsfall und auf die Anforderung des Kunden/Nutzers an.
ttyl Django
On 14.03.2019 16:04, Django wrote:
On 13.03.19 10:06, Walter H. wrote:
anders herum, wie sollte bei Verwendung eines selbstsignierten Zertifikates selbiges bei S/MIME denn funktionieren?
Moment, das ist aber nun die falsche Antwort zu meiner Frage, warum Du meintest "... Datenintegrität ist mit PGP gar nicht möglich".
ne ist sie nicht; daher die Gegenfrage: wie willst Du feststellen, ob der Inhalt verändert wurde, wenn Du nicht mal sagen kannst, ob die Mail überhaupt vom Absender stammt?
Also Du kannst Dich z.B. jederzeit davon überzeugen, dass z.B. Pakete aus (m)einem Repository integer sind, also vom Maintainer des Paketes erstellt wurde. Warum soll das mit PGP nicht möglich sein, die Datenintegrität zu prüfen?
unzulässiger Vergleich, Du vertraust hier darauf, dass der Key dazupasst; sprich es handelt sich hier strenggenommen nicht um self-sigend äquivalent;
Auch soll sowas durchaus auch beim Medium eMail funktionieren.
ohne Authentizität keine Integrität ...
Ich sitze hier z.B. vor einem Gateway welches für 2500 Benutzer durchaus in der Lage ist, an Hand der hinterlegten Schlüsselmaterials zum einen den Absender zweifelsfrei zu identifizieren wie auch die Integrität der Daten selbst zu prüfen.
unzulässiger Vergleich; hinterlegtes Schlüsselmaterial heißt ja bereits, daß es nicht mehr self-signed ist;
daher das klassische Szenario: Du findest einen Webshop - und jetzt aufpassen, ich hatte irgendwo bewußt geschrieben, daß hier zumindest ein OV SSL-Zertifikat notwendig ist; wir nehmen aber an, es wird ein Let's Encrypt verwendetl; daher nur DV Du gibst dort eine Bestellung ein, und bekommst jetzt eine per PGP signiertes Mail, mit einem PDF (Vorauskassarechnung) als Anhang; Du stellst hier fest, daß die IP, welche sich mit Deinem Mailserver verbunden hat, eine andere ist, als welche zur Website des Shops gehört; auch stellst Du fest, daß der Absender nichts mit der Domain des Webshops gemein hat; PGP ist bei PDFs nicht vorgesehen, also ist diese gar nicht signiert; an Hand dieses Szenarios sag ich Dir, daß ich die Mail verwerfe und der Deal geplatzt ist;
eine etwaige Datenintegrität, welche Du hier f. gut befindest ist nur zweitrangig; oder anders: mit PGP scheiterst am Erstkontakt;
sprich: wenn es nicht möglich ist festzustellen, ob eine Mail auch tatsächlich vom besagten Absender kommt, spielt es auch keine Rolle mehr, ob diese Mail verändert wurde oder nicht ...
Kommt auf den Anwendungsfall und auf die Anforderung des Kunden/Nutzers an.
stimmt, es gibt im E-mailverkehr nur keinen, bei dem die Datenintegrität ohne entsprechender Authentizität eine Rolle spielt ...
Am 2019-03-13 07:22, schrieb Walter H.:
aber das andere Feature - zu verifizieren, ob eine Mail auch tatsächlich vom Absender stammt und wenn dann auch nicht verändert wurde: Datenintegrität ist mit PGP gar nicht möglich, denn dies ist aus dem Stadium des selbstsignierten noch nicht aus sich herausgewachsen ...
und von daher schadet PGP mehr als es nützt;
Das sehe ich jetzt nicht als Nachteil an. Bei S/MIME vertraust du dem Aussteller des Zertifikats, dass der die verknüpfte Mailadresse ordentlich überprüft hat. Die Vergangenheit hat gezeigt, dass es durchaus auch gefälschte Zertifikate gibt. Sogar Google-Zertifikate wurden schon gefälscht (ich glaube eine holländische Zertifizierungsstelle hatte mal falsche Zertifikate ausgestellt).
Bei PGP bin ich da auf der sicheren Seite, weil ich da selbst per Fingerprint überprüfen kann ob der public Key auch wirklich der von meinem Gegenüber ist. Natürlich brauche ich für die Überprüfung einen zweiten Kommunikationsweg, und ich darf mich schon gar nicht auf public Keyserver verlassen (da kann wirklich jeder Schrott drin stehen).
Jochen
Am 13.03.2019 um 18:44 schrieb J. Fahrner:
Bei PGP bin ich da auf der sicheren Seite, weil ich da selbst per Fingerprint überprüfen kann ob der public Key auch wirklich der von meinem Gegenüber ist. Natürlich brauche ich für die Überprüfung einen zweiten Kommunikationsweg, und ich darf mich schon gar nicht auf public Keyserver verlassen (da kann wirklich jeder Schrott drin stehen).
Du kannst Deinen Schlüssel auch per DNS verteilen (Stichwort OPENPGPKEY). Das ist meines Erachtens nach ein guter Ansatz und mit DNSSEC auch rechts sicher, hat sich allerdings (noch) nicht durchgesetzt.
On 13.03.2019 19:00, Alex JOST wrote:
Du kannst Deinen Schlüssel auch per DNS verteilen (Stichwort OPENPGPKEY).
auch den S/MIME-Key kannst im DNS eintragen (Typ SMIMEA bzw. RFC 8162 https://tools.ietf.org/html/rfc8162 )
Das ist meines Erachtens nach ein guter Ansatz und mit DNSSEC auch recht sicher, hat sich allerdings (noch) nicht durchgesetzt.
hier scheiden sich die Geister; selbstsignierte SSL-Zertfikate wären mit DANE auch möglich; und wo gibt es heute im Jahr x nach DANE, nach TLS1.2, ... einen Support auf Client-Seite, welcher derartiges auch validiert und im Falle eines Validierungsfehlers auch unüberwindbar abblockt;
On 13.03.2019 18:44, J. Fahrner wrote:
Am 2019-03-13 07:22, schrieb Walter H.:
aber das andere Feature - zu verifizieren, ob eine Mail auch tatsächlich vom Absender stammt und wenn dann auch nicht verändert wurde: Datenintegrität ist mit PGP gar nicht möglich, denn dies ist aus dem Stadium des selbstsignierten noch nicht aus sich herausgewachsen ...
und von daher schadet PGP mehr als es nützt;
Das sehe ich jetzt nicht als Nachteil an. Bei S/MIME vertraust du dem Aussteller des Zertifikats, dass der die verknüpfte Mailadresse ordentlich überprüft hat.
eigentlich sieht hier die Logik anders herum aus ...
bei S/MIME setzt Du voraus, daß das Zertifikat, mit welchem eine Mail signiert wurde, auch dem Inhaber der Mailadresse gehört; und Du hast lokal nur einen Anker um die Zertifikatskette damit verifizieren zu können; und erst dann wenn dies fehlerfrei möglich ist, macht eine Prüfung ob die Mail verändert wurde oder nicht Sinn ... wenn Du mein Mail ansiehst, merkst sogar, daß hier nicht nur die Mailadresse sondern auch die Person (meine Wenigkeit) durch die CA validiert wurde; mit der CT kannst sogar nachsehen, weil dort sind nicht nur SSL sondern auch S/MIME verzeichnet;
Die Vergangenheit hat gezeigt, dass es durchaus auch gefälschte Zertifikate gibt. Sogar Google-Zertifikate wurden schon gefälscht (ich glaube eine holländische Zertifizierungsstelle hatte mal falsche Zertifikate ausgestellt).
Du sprichst hier von SSL-Zertifikaten (eine andere Baustelle); bei S/MIME hat man von derartigem noch nie gehört;
Bei PGP bin ich da auf der sicheren Seite, weil ich da selbst per Fingerprint überprüfen kann ob der public Key auch wirklich der von meinem Gegenüber ist.
das halte ich mal f. ein Gerücht; weil woher hast Du denn die Kenntnis vom Fingerprint Deines Gegenübers? (baust Du hier auf Domain-Validiertes SSL auf, hast Du genaugenommen gar nichts)
Am 2019-03-13 19:27, schrieb Walter H.:
Du sprichst hier von SSL-Zertifikaten (eine andere Baustelle); bei S/MIME hat man von derartigem noch nie gehört;
Sind die gleichen (unzuverlässigen) Firmen, die diese Zertifikate ausstellen. Warum sollte ich denen bei den Mailzertifikaten mehr vertrauen?
das halte ich mal f. ein Gerücht; weil woher hast Du denn die Kenntnis vom Fingerprint Deines Gegenübers?
Wie ich schon schrieb, kann mir mein Gegenüber den Fingerprint auf einem separaten Kommunikationsweg zukommen lassen (Am Telefon vorlesen, per Threema schicken, ...). Nur so hat man absolute Sicherheit. Sobald ich einem Dritten vertrauen soll, ist mein Vertrauen dahin. ;-)
On Wed, March 13, 2019 21:33, J. Fahrner wrote:
Am 2019-03-13 19:27, schrieb Walter H.:
Du sprichst hier von SSL-Zertifikaten (eine andere Baustelle); bei S/MIME hat man von derartigem noch nie gehört;
Sind die gleichen (unzuverlässigen) Firmen, die diese Zertifikate ausstellen. Warum sollte ich denen bei den Mailzertifikaten mehr vertrauen?
Ja, aus Sichtweise hast Du Recht; es sind die gleichen;
das halte ich mal f. ein Gerücht; weil woher hast Du denn die Kenntnis vom Fingerprint Deines Gegenübers?
Wie ich schon schrieb, kann mir mein Gegenüber den Fingerprint auf einem separaten Kommunikationsweg zukommen lassen (Am Telefon vorlesen, per Threema schicken, ...). Nur so hat man absolute Sicherheit.
Ja, und unterscheidest Du hier die Technologie? das kannst ja bei self-signed S/MIME auch haben ...
Sobald ich einem Dritten vertrauen soll, ist mein Vertrauen dahin. ;-)
d.h. Dir ist ein Wildwuchs aus personalCAs und dem damit verbundenen unüberschaubaren CAs im Browser/Mailer lieber?
Hallo,
als gpg und CaCert Veteran kann und will ich diese Diskussion nicht unkommentiert lassen ;)
Ich stelle in letzter Zeit fest, dass mit einer reihe fadenscheiniger Argumente sehr stark gegen gpg/pgp argumentiert wird und frage mich ein bisschen wo wir falsch abgebogen sind.
Zunächst meine Probleme mit S/MIME:
Ich vertraue hier darauf, dass keine einzige der hunderten bis tausenden Zertifizierungsstellen und Unter-CAs einen Fehler in ihrer Validierung haben, da - wie bei SSL-Zertifikaten für Webseiten - eine Ca für beliebige Emailadressen ein Zertifikat ausstellen kann.
Du brauchst hier also auch einen zweiten Kommunikationsweg um die Authentizität sicherzustellen, eigentlich brauchst du sogar zwei.
Der erste out-of-band Kommunikationsweg ist dein Client oder dein Betriebssystem, das eine lange Liste an 'vertrauenswürdigen' CAs mitliefert. In der Regel bedeutet das aber nur, dass sie genug Geld hatten um einen Wirtscahftsprüfer zu bezahlen der die Kriterien zur Zertifizierung prüft.
Dass es immer wieder fehlerhafte Zertifikate gibt ist hinreichend bekannt. Sowohl sind Fehler in der Validierung in den Webseiten der CAs bekannt geworden, als auch missbräuchliche Ausstellung von Zertifikaten. Zuletzt ging durch die Medien, dass auch Zertifikate zum Code-Signieren missbraucht wurden.
Die Reaktion von Banken und google ist nun, dass sie bei besonders 'wichtigen' Zertifikaten auf ZErtifikatspinning setzen. Also das Zertifikat in der Applikation die es prüfen soll fest codieren oder andere Schritte zur Validierung einbauen. Also habe ich schon zwei Validierungsschritte.
Das ist eigentlich eine Bankrotterklärung des Systems zentraler CAs.
Ein Ausweg ist das hier schon erwähnte DANE - dann muss man sich aber fragen wozu ich dann noch eine kommerzielle CA bezahlen soll, die mir ausser Kosten, zusätzlichem Aufwand und potentiell Kontrollverlust beim Ausstellen von Zertifikaten nichts bringt.
Was ist nun der Unterschied zu gpg?
Es handelt sich hier um ein komplett dezentrales System!
Ich habe eben nicht tausende von Zertifizierungsstellen von denen eine reicht um ein ZErtifikat auszustellen, sondern ich habe im idealfall ein Web of Trust.
Ich habe ein paar Jahre lang jede Gelegenheit genutzt und meinen gpg-key von Leuten die ich getroffen habe bestätigen lassen.
Insgesamt haben 773 Personen meinen Personalausweis geprüft und mir ihre Signatur per Email zugeschickt. Insgesamt habe ich fast 4000 Signaturen auf meinen Key für die uids.
Damit ist mein key Teil des Strongsets. Mein Fingerprint findest Du an jeder Ecke, unter mails die ich versende, auf meiner Webseite und auf meinen Visitenkarten.
Wenn ich aktuell den torbrowser runterlade, sehe ich dass ich dem Paket vertrauen kann, weil ich die Person, die ihn signiert, persönlich getroffen habe und den Ausweis in meiner Hand hatte. Und das geht auch indirekt. Bei debian paketen sehe ich dass die keys der maintainer von diversen Leuten signiert wurden die ich alle getroffen habe. Selbsts wenn ich den Uploader nicht direkt kenne oder selbst den key verifiziert habe, reicht mir zu wissen dass 5 meiner Freunde das getan haben.
S/Mime ist im Unternehmenskontext super, weil ich eine zentrale Stelle habe die Keys revoken können sollte und Zertifikate prüfen kann - und auch verifiziert dass zum Beispiel nur die offizielle Firmen Emailadresse drinsteht.
Das habe ich bei gpg so natürlich nicht - dafür aber auch mehr Freiheit und muss nicht allen CAs vertrauen.
Grüße, Florian
HI!
On 13.03.19 18:44, J. Fahrner wrote:
Bei PGP bin ich da auf der sicheren Seite, weil ich da selbst per Fingerprint überprüfen kann ob der public Key auch wirklich der von meinem Gegenüber ist.
So ist es, wir hinterlegen Schlüssel z.B. im Gateway erst, wenn wir den zugehörigen Fingerprint abgeglichen haben.
Genau so machen wir das bei der verpflichtenden TLS-Verschlüsselung beim MTA, wenn beide Kommunikationspartner ein Interesse an einer gesicherten und validen Übertragung der Daten haben wollen - opportunistische Verschlüsselung ist ja ganz nett, nur für wirklich vertrauliche Kommunikation ist das nun wirklich ungeeignetste Mittel.
ttyl Django
On 14.03.2019 16:10, Django wrote:
HI!
On 13.03.19 18:44, J. Fahrner wrote:
Bei PGP bin ich da auf der sicheren Seite, weil ich da selbst per Fingerprint überprüfen kann ob der public Key auch wirklich der von meinem Gegenüber ist.
So ist es, wir hinterlegen Schlüssel z.B. im Gateway erst, wenn wir den zugehörigen Fingerprint abgeglichen haben.
und müsstest strenggenommen jede Mail, welche einen Key verwendet, welcher nicht hinterlegt ist verwerfen; oder anders der Erstkontakt ist mit PGP unmöglich;
dieses Problem hast mit S/MIME gar nicht; oder genau hier verwirfst Du die Mails, welche mit Keys signiert wurden, und Du keine Zertifikatskette validieren kannst ...
Am 2019-03-14 19:49, schrieb Walter H.:
und müsstest strenggenommen jede Mail, welche einen Key verwendet, welcher nicht hinterlegt ist verwerfen;
Warum denn gleich verwerfen? Zunächst mal brauche ich ja nur anzweifeln ob die Mail wirklich von dem Absender stammt, den er vorgibt. Wie bei jeder anderen Mail auch. Wenn ich Wert darauf lege, den Absender zu verifizieren, dann tue ich das halt. Über einen zweiten unabhängigen und vertrauenswürdigen Kanal. Wo ist das Problem?
oder anders der Erstkontakt ist mit PGP unmöglich;
Wieso denn? Keiner zwingt mich die Mail abzuweisen.
dieses Problem hast mit S/MIME gar nicht;
Nur wenn ich den 1000 CAs da drausen wirklich vertraue. Tust du das? Wenn die CA "Türktrust" heisst (gibts wirklich), wäre ich zumindest vorsichtig ;-)
On 14.03.2019 20:03, J. Fahrner wrote:
Am 2019-03-14 19:49, schrieb Walter H.:
und müsstest strenggenommen jede Mail, welche einen Key verwendet, welcher nicht hinterlegt ist verwerfen;
Warum denn gleich verwerfen?
Django spricht von einem Gateway - einer Maschine;
Zunächst mal brauche ich ja nur anzweifeln ob die Mail wirklich von dem Absender stammt, den er vorgibt.
Ja Du, aber was macht eine Maschine? nebenbei sollen durch derartige Mechanismen, nicht die durchgelassenen Mails sondern die geblockten/verworfenen Mails maximiert werden; oder anders: die Mails welche nichts zu suchen haben auf ein Minimum reduziert werden; aus heutiger Sicht ist es tatsächlich besser entweder sauberes S/MIME zum Signieren verwenden oder es bleiben lassen;
Wie bei jeder anderen Mail auch. Wenn ich Wert darauf lege, den Absender zu verifizieren, dann tue ich das halt.
hier wieder, Du als Mensch, aber eine Maschine hat hier genau 0 Möglichkeiten;
Über einen zweiten unabhängigen und vertrauenswürdigen Kanal. Wo ist das Problem?
rate mal ...
oder anders der Erstkontakt ist mit PGP unmöglich;
Wieso denn? Keiner zwingt mich die Mail abzuweisen.
nein, aber jeder der ein Gateway betreibt ist gut beraten, dies so einzustellen, weil sonst der Sinn von so einem Gateway in Frage zu stellen ist ...
dieses Problem hast mit S/MIME gar nicht;
Nur wenn ich den 1000 CAs da drausen wirklich vertraue.
Zusatzfrage: wenn ich Dir eine Mail sende, würdest Du meiner CA vertrauen - hier würde ich Dir den Token meiner CA auf einem sicheren 2ten Kanal übermitteln ..., und was damit dann alles geht brauche ich Dir wohl nicht sagen, oder? (vor allem dann, wenn der Certstore vom Mail-client der selbe ist wie vom Browser ...)
Tust du das? Wenn die CA "Türktrust" heisst (gibts wirklich), wäre ich zumindest vorsichtig ;-)
ich weiß was es da so f. CAs gibt; wobei - ich verwende ein Release meiner Wahl/meines Vertrauens vom ThunderBird und da ist die CA-Liste ohnehin etwas kleiner;
wobei zum Thema CAs, letztes Jahr hatte CentOS einen tabu la rasa veranstaltet; vorher hatte der ca-bundle.trust.crt etwa 1064 kBytes, nachher nur noch etwa 408 kBytes, also deutlich weniger als die Hälfte ...
Am 12.03.19 um 20:51 schrieb Walter H.:
ich würde empfehlen, auf s/mime umzusteigen, dies hat bei den Clients eine hinreichende Verbreitung sodaß derartiges wie mit PGP/GnuPG nicht passiert;
Ich nutze GnuPG, weil ich es ebenfalls im OS integrieren kann mit den selben Mechanismen zum verschlüsseln/entschlüsseln und signieren von Kontent. Als Linux-User bietet sich das an, da es in vielen Distributionen schon nativ integriert ist. PGP ist in meinen Augen wesentlich flexibler Einsetzbar als S/MIME.
oder anders, das mit der signature.asc können nur die verwenden, welche auch entsprechendes in deren Mail agents dazu erweitert haben, von Haus können das die wenigsten; hingegen bei S/MIME gibt es kaum einen Mail agent, der es nicht kann; und somit wird derartiges immer sauber angezeigt;
On 12.03.2019 19:30, Denny Hanschke wrote:
weil immer wieder Fragen bezüglich unverständlicher Zeichen oder der signature.asc im Anhang kommen. Führte kürzlich dazu, das jemand aus Panik den Computer ausschaltete, weil ein Angriff vermutet wurde.
Nun schicke ich immer den Link in der Signatur mit.
Kopieren erwünscht, Verbesserungsvorschläge für den Text auch!! Nur kein technischen Firlefanz, also DAU-verträglich...
(Entwurf) https://www.blubbablasen.de/openpgp.html
On Tue, March 12, 2019 22:22, Denny Hanschke wrote:
Am 12.03.19 um 20:51 schrieb Walter H.:
ich würde empfehlen, auf s/mime umzusteigen, dies hat bei den Clients eine hinreichende Verbreitung sodaß derartiges wie mit PGP/GnuPG nicht passiert;
Ich nutze GnuPG, weil ich es ebenfalls im OS integrieren kann mit den selben Mechanismen zum verschlüsseln/entschlüsseln und signieren von Kontent. Als Linux-User bietet sich das an, da es in vielen Distributionen schon nativ integriert ist. PGP ist in meinen Augen wesentlich flexibler Einsetzbar als S/MIME.
diese in Deinen Augen flexiblere Einsetzbarkeit ist genau das Problem; Linux hat nicht mal in 2% der Desktop Systemen Einzug gehalten und MacOS, welches im inneren Kern ein BSD-Ableger ist, ist auch gerade mal mit 10% bei den Desktop systemen vertreten;
Mail agents kennen PGP kaum, und manche auch nur durch Integration von irgendwelchen Dritthersteller Plugins;
nebenbei: wie willst Du mit etwas, das niemand wirklich vertraut etwas signieren? (PGP ist dem Stadium des selbstsignierten noch nicht wirklich entwachsen)
dass PGP - der mangelnden Unterstüztung durch Mail agents sei Dank - auch Schaden anrichten kann, hast mit Deiner Eingangsschilderung eindrucksvoll gezeigt;
auch MS hat damals schon erkannt, daß man in anderen Bereichen derartiges verwenden kann; sprich mit einem x509-Zert. kannst Du auch Files auf Deinem Windows PC selektiv verschlüsseln - unabhängig von einer etwaigen Plattenverschlüsselung; und das schon seit Windows 2000; nicht uninteressante Lektüre: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt...
participants (7)
-
Alex JOST -
Denny Hanschke -
Django -
Florian Streibelt -
J. Fahrner -
Walter H. -
Walter H.