[Postfixbuch-users] PGP und S/MIME am äußeren MX

[Igor Sverkos]

Hallo,

Michael Nausch schrieb:
>> Das beantwortet noch nicht die Frage nach dem eigentliche Ziel.
> 
> Tja, da wird es schon sehr schwierig werden, denn hier gibt es erst 
> einmal grundlegend das Thema, dass man begriffen haben muss, wie eine
> asymetrische Verschlüsselung funktioniert und was im Gegensatz bei
> einer symetrischen Verschlüsselung abgeht.

Das verstehe ich nicht. Verschlüsselung ist doch bereits ein Mittel, um
etwas zu erreichen. Quasi die Medizin. Doch bevor ich zu irgendeiner
Behandlung/Medizin greife, sollte ich doch erst einmal ein Problem
diagnostiziert haben... oder zumindest in der Lage sein, Symptome die
ich bekämpfen will, klar zu benennen.


> Nicht nur dass es derartige Vollhonks gibt, die aus der technisch 
> versierten Ecke kommen und zum Thema "sichere eMail" ihre Klappe 
> aufreissen. Nein, i.d.R. schlägt man sich mit Leuten aus der 
> Marketing, Unternehmenskommunikation, Vertriebleitung, 
> Geschäftsleitung etc. pp. herum. Jeder hat in den einschlägigen 
> Computerbildzeitungen, Managementzirkeln, Businessgroups, 
> Unternehmensberater, Expertenrunden und/oder Newsletter irgendetwas 
> gehört und sei es am Golfplatz. Meiner Erfahrung nach denkt jeder er 
> habe es voll begriffen und jeder müsse dem anderen erklären, was 
> "sichere eMail" denn nun genau bedeutet.

Ja, ich selber habe mit Leuten zu tun, welche von der Marketingabteilung
der Deutschen Post AG zuvor eingeladen worden sind und nun glauben, man
müsse unbedingt auf ePost umstellen. Ich habe es schon erlebt, dass nach
so einem Wochenende in Unternehmen der Mailserver abgeschaltet werden
sollte, weil man erfahren habe, dass alles unsicher sei. :)

Übrigens schwirren auch Marketing-Drohnen einzelner DE-Mail
Service-Provider bereits herum... Vorsicht ;-)

Die Werbung scheint bei den Produkten also zumindest zu funktionieren. :]


> Zurück zu Deiner Frage: "die Frage nach dem eigentliche Ziel" wird 
> mir und dir keiner zufriedenstellend beantworten können. Schade,
> aber so ist das Leben nun mal ... :-/

Ohne zu wissen, was ich erreichen ("bekämpfen") will, ist es sehr
sinnfrei überhaupt in den Kampf zu ziehen ;)


> Nix, weil kein Bedarf von Kundenseite genannt wurde/wird.

Ähm... kein Bedarf? Weswegen dann dieses Thema? Es dreht sich gerade bei
mir einiges...


> Meiner Wahrnehmung nach wird hier lediglich die Argumente "das 
> machen/bieten andere auch", "unser großer IT-Dienstleister bietet
> das out-of-the-box" herangeführt.

Ja da hätten wir ja schon einmal so etwas wie einen Bedarf. Du bist bei
einem Serviceprovider tätig und ihr wollte irgendetwas was zu "sichere
E-Mail" passt in euer Portfolio aufnehmen - kann man das so sagen?


> Dass kaum ein Mensch begriffen hat, mit was er sich bei dem Thema 
> eMailverschlüsselung mit PGP und/oder S/MIME beschäftigen muss, wird
>  geflissentlich ignoriert. Frag' mal in deinem 
> Verwandten-/Bekannten-/Freundeskreis und Deinen (Fach)Kollegen nach,
>  wer alles ein x.509 Zertifikat und/oder PGP-key hat und auch nutzt.
>  Würde mich mal interessieren, auf wie viel Promille du da kommst!
> ;)

Schlechtes Beispiel. Würdest du mich kennen, würdest du mich das nicht
fragen. :-)

Ansonsten stimme ich dir da aber zu: Kennt kaum jemand und
haben und oder gar nutzen tut es erst recht niemand...
Wobei hier auch die Frage der Notwendigkeit und damit nach der
eigentlich Absicht gestellt werden muss: Wenn ich meinen Eltern neue
Bilder ihrer Enkel via E-Mail zukommen lasse, so halte ich eine
Verschlüsselung selber für nicht notwendig. Ich weiß auch nicht ob ich
meiner Frau vorwerfen sollte, dass sie Rezepte unverschlüsselt durch das
Internet sendet...

Anders sieht es wiederum aus, wenn ich bspw. einem Geschäftspartner
Zugangsdaten zukommen lassen möchte: Wenn ich hier einem Kollegen ein
Kennwort mailen muss, kann ich mich auf unsere Policy verlassen. Ich
weiß, dass nur nach unseren definierten Regeln vertrauenswürdige Rechner
Zugriff auf das Netzwerk und damit den Mailserver haben. Sollte der
geschätzte Kollege gerade in irgendeinem Internetcafé eines
Urlaubsparadieses sitzen, kann ich mich darauf verlassen, dass der
Zugriff durch den One-Time-Password Token sicher authentifiziert wurde
und danach innerhalb der Browser-Anwendung eine sichere Verbindung hat,
worüber er auf die Daten zugreift...
Sobald es aber an einen Partner geht, verlassen die Daten unsere
gesicherte Festung. Ob der Partner ähnliche Sicherheitsstandards hat,
weiß ich nicht. Folglich würde ich dann beispielsweise als quasi
Mindeststandard wollen, dass ich ihm die Daten verschlüsselt an seinen
PGP-Key zukommen lasse.

Tada... damit hätten wir soeben ein erstes Ziel definiert. :)


> Bei (m)einen Folien, die ich bei Zeiten dem interessierten Publikum 
> vorlege, steht auf Seite 9: 
> =====================================================================
>
>
>
>
> 
Ziele bei der Verschlüsselung von Daten und der Übertragung
> 
> Vertrauen in die Kommunikation ist erreicht, wenn folgende Punkte 
> erreicht sind:
> 
> ° Vertraulichkeit Nachrichten durch Dritte _nicht_ entziffert werden 
> können!
> 
> ° Integrität der Nachricht: Nachrichten durch Dritte _nicht_ 
> manipuliert werden können!
> 
> ° Echtheit der Kommunikationspartner Absenderangaben _nicht_ durch 
> Dritte manipuliert werden können!
> 
> =====================================================================

Ich kenne das jetzt etwas anders:
a) Authentizität
b) Privatheit
c) Unabstreitbarkeit

Vermutlich meinen wir das gleiche, benennen es nur etwas anders. Mich
stört jetzt speziell die Formulierung "Echtheit der
Kommunikationspartner Absenderangaben". Bei PGP bzw. S/MIME
interessieren mich diese Angaben nicht.
Die Daten des Umschlages werden einen möglichen DKIM-Check ect.
interessieren, aber bei PGP bzw. S/MIME schaue ich nur noch auf den
Body. Wenn dieser mit dem mir bekannten Key desjenigen signiert ist, den
ich als Kommunikationspartner bezeichne, reicht mir das.


> Meiner Wahrnehmung nach, ist es genau das, was viele haben wollen, 
> wenn man mal ein wenig tiefer in die Thematik einsteigt und die 
> wahren Beweggründe hinterfrägt.

Da habe ich ganz vergessen, dass wir noch immer nach einem Ziel suchen.
Aber ich stimme dir zu: Unter sicherer Kommunikation würde ich die drei
Punkte erwarten.

Im Geschäftsumfeld würde ich womöglich auf Privatheit verzichten wollen.
Auch wenn hier ein Brief adressiert an "Zu Händen Herrn Sverkos"
eintrifft, liest womöglich mein Kollege diesen Brief. Das kann mehrere
Ursachen haben:

1) Wir arbeiten beide in der gleichen Abteilung. Jeder ist für diese
Abteilung Ansprechpartner. Somit muss eh jeder wissen was los ist.

2) Vertretung

...niemand möchte schließlich, dass etwas liegen bleibt, nur weil ein
Kollege verhindert ist. Das kann ganze Betriebe lahmlegen.


>> Du sprichst zu erst von Gruppen-Keys ...
> 
> Wo genau?

In deiner Nachricht vom 05.05.2011 17:01. Dort habe ich den Satz

> Die Zertifikate und keys sind dabei nicht personen- sondern 
> stellenbezogen, also ohne Passphrase.

zumindest so verstanden. Denn später schreibst du noch

> Der Empfänger kann dann wie gewohnt die verschlüsselten Nachrichten 
> an seinem MUA mit seinem privat-key oder privat-certificate 
> aufmachen.

Wenn der Empfänger in der Lage sein soll, an seinem MUA Mittels
*eigenem* Key irgendetwas zu verifizieren, dann muss die Nachricht auch
an den Pub-Key desjenigen adressiert gewesen sein.

Somit wären also zwei Keys im Spiel: Die Gruppe und einzelne Empfänger.


>> und anschließend von Privaten-Schlüsseln. D.h. die ausgehende 
>> Nachricht wird sowohl mit dem Pub-Key der Empfänger-Gruppe, als 
>> auch mit dem individuellen Pub-Key des Empfängers verschlüsselt, 
>> ja?
> 
> Nö, eine Nachricht wird immer mit dem public-key des oder der 
> Empfänger verschlüsselt. Ob nun ein Empfänger in Besitz des 
> zugehörigen privat-key ist, ob es mehrere Empfänger gibt, die
> Zugriff auf diesen Schlüssel haben, oder ob der privat-key auf einem
> Gateway liegt, kann und muss mir egal sein. Das liegt im 
> Verantwortungsbereich des Empfängers.

Und genau hier liegt das Problem:
Sobald ich individuelle Verschlüsselung zulasse, d.h. das der MUA neben
der Anweisung für den MTA noch weiteres können soll, würde ich an der
Stelle eben den MTA ausnehmen. Dazu später mehr...


> Von einem Gruppen-Pub-key, der mit einem individuellen Pub-Key und 
> einem privat key matheamtisch verboben ist, habe ich noch nichts 
> mitbekommen.

Mir auch nicht - so war es von mir auch nie gemeint.


>> Aber ok... wenn ich will, dass auf MUA-Seite die Integrität 
>> verifiziert werden kann, braucht es einen Privaten-Key.
> 
> Sicher? Ich könnte mir vorstellen, dass ein smtp_proxy_filter ev. 
> AMaViS, die Nachrichten annimmt und mit Hilfe der passenden 
> keys/certificates die Signaturen prüfen kann, so ala DKIM.

Stopp. Hier sind wir wieder bei der Frage des Ziels: Was genau soll der
MTA prüfen können? ;)

Das tolle an PKI ist, dass jeder zu jeder Zeit die Authentizität
überprüfen kann. Das wäre also auch hier kein Problem.

Du wolltest aber Anfangs bspw. auch den möglichen Anhang prüfen. Da
dieser aber wie der Nachrichtentext selber verschlüsselt ist, kann der
MTA das nur, wenn er entschlüsseln kann.

Gleiches gilt für eine mögliche Inhaltsanalyse, bspw. auf SPAM.

Eine MIM-Lösung wie bei heutigen Internet-Gateway-Lösungen, die auch in
SSL-Verkehr schauen können, ist hier (grundsätzlich) nicht möglich.


>> Den Gruppen-Key wirst du nie herausgeben wollen, denn wenn jemand 
>> das Unternehmen verlässt, könnte er ja weiterhin unter dem Key 
>> zeichnen.
> 
> Wäre in meinem skiziertem Fall auch gar nicht notwendig, dass ein 
> Mitarbeiter ein key mitnimmt, da er diesen nicht hat. Er - der key 
> bzw. das certifikate - liegt ja an zentraler Stelle. Das x.509 
> Zertifikat unseres Postfix nutzt auch jeder Mitarbeiter, aht aber 
> weder das Zertifikat noch den zugehörigen key.

Dann ist keine echte End-to-End Verschlüsselung möglich. Du selbst
hattest ja das Beispiel mit dem CEO gebracht. Sobald alle Schlüssel -
auch die privaten - beim Server sind, hast du keine End-to-End
Verschlüsselung mehr. Dann war es das auch mit der Privatheit. Weshalb
du dann überhaupt noch unterteilst, statt nur einen einzelnen Hauptkey
zu nutzen, ist mir ein Rätsel. Bedenke, dass bei deiner
Passphrase-freien Lösung nur einmal jemand deinen MTA kompromittieren
brauch - dann hat er alles, denn dort liegt alles an einem Platz :-)

Um kurz noch etwas richtig zu stellen: Was ich bislang als Recovery-Key
bezeichnet habe, heißt im PGP-Fachausdruck "Additional Decryption Key"
(ADK). Im Handbuch heißt es:

> An additional decryption key (ADK) is a key generally used by
> security officers of an organization to decrypt messages that have
> been sent to or from employees within the organization.
> 
> Messages encrypted by a key with an ADK are encrypted to the public
> key of the recipient and to the ADK, which means the holder of the
> ADK can also decrypt the message.
> 
> ADKs are rarely used or needed outside of a PGP Universal
> Server-managed environment. Although your PGP administrator should
> not ordinarily need to use the additional decryption keys, there may
> be circumstances when it is necessary to recover someone’s email. For
> example, if someone is injured and out of work for some time, or if
> email records are subpoenaed by a law enforcement agency and the
> corporation must decrypt mail as evidence for a court case.

Der Vorteil des ADKs ist einfach, dass man wirklich nur noch eigentlich
Empfänger auswählt. Dadurch wird automatisch auch für den ADK
verschlüsselt. Ich hoffe jetzt, dass das zu GPG auch transparent ist ;-)

Bislang hatte ich also folgende Idee:
Wir: firmaA.tld
Partner: partnerA.tld

Ich (ich at firmaA.tld) will nun an Peter Partner (peter at partnerA.tld) eine
sichere Nachricht senden. Echte sichere End-to-End Kommunikation.

Unsere Policy erlaubt es aber nicht, dass bestimmte Anhänge unser Haus
verlassen.

Ich schreibe nun die Nachricht und sage meinem MUA "verschlüssle bitte
für Pater Partner!". Jetzt sollte neben dem Key von Peter Partner
automatisch auch der Key mailscanner at firmaA.tld ausgewählt werden. Ich
sehe das Ergebnis, gebe die Passphrase meines privaten Keys ein und die
Mail wird durch unseren MTA entgegen genommen.

Dieser prüft nun die Nachricht. Er stellt fest, dass sie verschlüsselt
ist. Deswegen probiert er sie nun zu entschlüsseln. Siehe da - klappt.
Keine bösen Anhänge gefunden... original Mail darf das Haus verlassen.

Hätte ich jetzt einen unzulässigen Anhang angefügt oder es irgendwie
geschafft, die Nachricht nicht auch für mailscanner at firmaA.tld zu
verschlüsseln, würde unser MTA die Mail ablehnen. Entweder weil

a) der MTA nicht reinschauen konnte. Somit kann die Policy nicht
gewährleistet werden.

b) Es wurde ein unzulässiger Anhang gefunden.

Ich habe also das Ziel "sichere End-To-End Kommunikation" erreicht.
Problem: Mein Partner wird ein ähnliches Setup benötigen. Eigentlich
müsste ich an mindestens drei Empfänger senden:

- Peter Partner persönlich
- mailscanner at firmaA.tld
- mailscanner at partnerA.tld

...und mein Partner muss gleiches in andere Richtung tun. Ob das
praktikabel ist?

Rekapitulieren wir noch einmal: Wir wollten echte sichere End-To-End
Kommunikation. Haben wir die wirklich? Nein! Der Mailserver und damit
dessen Admin kann die eigentlich vertrauliche Nachricht einsehen.
Lediglich wenn er sie auch verändert, würde dies auffallen. Aber unser
Ziel haben wir klar verfehlt.

Im Ergebnis haben wir einen riesen Aufwand betrieben, brauchen bei jedem
Teilnehmer ein identisches Setup, und haben eigentlich nur das erreicht,
was wir Mittels TLS bei SMTP schon lange problemlos nutzen können.

Das führt uns zurück zum Anfang: Definiere das Ziel. Wenn es sichere
End-to-End Kommunikation sein soll, so ist die derzeitige Antwort: Nicht
erreichbar, da es es keine End-To-End Verbindung gibt - ein MTA ist
dazwischen.

Wenn du alle Keys, auch die privaten, auf den MTA legen möchtest,
erkläre mir bitte den Mehrwert gegenüber der heutigen Lösung, wo TLS bei
SMTP den Verkehr zweier Server gegen das Abhören sichert.


>> Hier können sehr komplexe Regeln gebildet werden, die imho deine 
>> Wünsche erfüllen. Somit wäre die "Sicherheit" auch bei Webmailern 
>> gewährleistet.
> 
> Bei meinem Webmailhoster (o.k., bin ich selber) liegt auch einer 
> meiner Schlüssel, klar da kann ich das Thema "Sicherheit" bei der 
> Kommunikation erschlagen.

Du hast bei einem Hoster einen Key hinterlegt? Ich hoffe doch nicht
deinen privaten Schlüssel... - wozu überhaupt?


>> Inwieweit PGP mit nicht-PGP-S/Mime klar kommt, weiß ich nicht.
> 
> PGP und S/MIME nutzen vom Grundsatz her beide asymetrische Schlüssel.
> Sie unterscheiden sich aber im dahinterliegenden Vertrauensnetzwerk
> bzw. zentraler Zertifizierungsstelle. "Kompatibel" im eigentlichen
> Sinne sind jedoch beide Verfahren definitiv nicht!

Das war anders gemeint... PGP selber kann auch S/MIME. Du kannst auch
beides mischen. Folglich kann das angesprochene PGP Produkt auch etwas
S/MIME. Der Hinweis war so gemeint, dass ich nicht weiß, wieviel und es
nur den PGP S/MIME Kram kann oder S/MIME Grundsätzlich und wie es dann
hier mit dem Regelwerk aussieht. Anders gesagt: Ich kann nichts zur
Qualität der S/MIME Unterstützung in PGP Universal sagen...

Ups... ist doch etwas länger geworden die Antwort ;-)


-- 
Ich Grüße,
Igor