Erklärung PGP/GnuPG,

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Erklärung PGP/GnuPG,

Denny Hanschke
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

--
Denny Hanschke

         /"\
         \ /     ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
          X                            - AGAINST M$ ATTACHMENTS
         / \

   http://www.asciiribbon.org/

   /!\ I'll keep fightin' against M$ HTML-eMails...


Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

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;

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
>


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

J. Fahrner
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. :-(
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Denny Hanschke
In reply to this post by Walter H.
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
>>
>
>

--
Denny Hanschke

         /"\
         \ /     ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
          X                            - AGAINST M$ ATTACHMENTS
         / \

   http://www.asciiribbon.org/

   /!\ I'll keep fightin' against M$ HTML-eMails...

---------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Walter H.
In reply to this post by J. Fahrner
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=SecureEmailCertificate&product=9&days.
solltest f. 1 Jahr ein kostenloses S/MIME bekommen ...


Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Walter H.
In reply to this post by Denny Hanschke
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/_content/m/m04/m04147.html

Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Django [BOfH]
In reply to this post by Walter H.
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
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Walter H.
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 ...

Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

J. Fahrner
In reply to this post by Walter H.
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
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Alex JOST
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.

--
Alex JOST
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Walter H.
In reply to this post by J. Fahrner
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)



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Walter H.
In reply to this post by Alex JOST
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;



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

J. Fahrner
In reply to this post by Walter H.
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. ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Walter H.
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?


Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Florian Streibelt

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




--
Florian Streibelt                          mail: [hidden email]
St. Johanner Str. 41-43                    mobile:    +49 173 475 39 71
66111 Saarbrücken                          fax:       +49 32 22683 6666
GPG-Fingerprint:     5BE7 F008 8B83 9357 1108  984A 3B8E A41F 82F6 1240
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Django [BOfH]
In reply to this post by Walter H.
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

Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Django [BOfH]
In reply to this post by J. Fahrner
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
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Walter H.
In reply to this post by Django [BOfH]
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 ...



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

Walter H.
In reply to this post by Django [BOfH]
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 ...



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Erklärung PGP/GnuPG,

J. Fahrner
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 ;-)
12