AtNotes Übersicht Willkommen Gast. Bitte einloggen oder registrieren.
02.12.21 - 13:36:15
Übersicht Hilfe Regeln Glossar Suche Einloggen Registrieren
News:
Schnellsuche:
+  Das Notes Forum
|-+  Domino 9 und frühere Versionen
| |-+  ND9: Entwicklung (Moderatoren: Axel, eknori, Thomas Schulte, koehlerbv, m3)
| | |-+  periodischer Server-Agent und verschlüsselte Mails
« vorheriges nächstes »
Seiten: [1] Nach unten Drucken
Autor Thema: periodischer Server-Agent und verschlüsselte Mails  (Gelesen 1173 mal)
MALTKU
Frischling
*
Offline Offline

Beiträge: 12


« am: 26.07.21 - 16:25:50 »

Hallo zusammen!

Ich habe in einer Datenbank einen periodischen Agenten, der von Haus aus schon Mails versendet. Aus Sicherheitsgründen habe ich den Agenten dahingehend anpassen wollen, dass diese Mails verschlüsselt versendet werden.

Schnipsel:
Dim maildoc As New NotesDocument(db)
<maildoc befüllen>
maildoc.EncryptOnSend = True
Call maildoc.Send( False )    


Ich habe also nur das maildoc.EncryptOnSend = True eingefügt.

Das Ganze klappt prima, solange der Agent in meinem User-Kontext läuft (RunOnBehalfOf) (Die Mail kommt verschlüsselt an).
Läuft er im Kontext der betreffenden Server-ID, ist die Mail unverschlüsselt.

Nach meinem Verständnis sollte zum Verschlüsseln nur öffentliche Schlüssel des Empfängers eine Rolle spielen. Dass der Server als Absender keinen öffentlichen Schlüssel hat, sollte doch ohne Belang sein.

Was übersehe ich?
« Letzte Änderung: 26.07.21 - 16:34:34 von MALTKU » Gespeichert
jBubbleBoy
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 1224



« Antworten #1 am: 27.07.21 - 07:50:28 »

Darf der Agent beschränkte Operationen ausführen?
Gespeichert

Gruss Erik :: Freelancer :: Notes, Java, Web, VBA und DomNav 2.5 / NSE 0.11
--
Nur ein toter Bug, ist ein guter Bug!
MALTKU
Frischling
*
Offline Offline

Beiträge: 12


« Antworten #2 am: 27.07.21 - 18:00:01 »

Hallo Erik,

"Allow restricted operations" ist aktiv.

Wie gesagt:
Mit leerem RunOnBehalfOf und Serversignatur kommt die Mail unverschlüsselt (Absender=Server), mit RunOnBehalfOf=<mein User>  und Serversignatur kommt die Mail verschlüsselt (Absender=ich).

Sehr misteriös!

Gruß Thomas
Gespeichert
jBubbleBoy
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 1224



« Antworten #3 am: 27.07.21 - 18:55:43 »

Steht dieser im Serverdokument unter Sicherheit bei "darf beschränkte Agenten ausführen"?
Gespeichert

Gruss Erik :: Freelancer :: Notes, Java, Web, VBA und DomNav 2.5 / NSE 0.11
--
Nur ein toter Bug, ist ein guter Bug!
Werner Götz
Aktives Mitglied
***
Offline Offline

Geschlecht: Männlich
Beiträge: 194



« Antworten #4 am: 28.07.21 - 07:58:44 »

Hilft das hier vielleicht etwas weiter?
https://atnotes.de/index.php?topic=62584.0;prev_next=next

Im Beitrag
https://atnotes.de/index.php?topic=38949.0
wird außerdem davon gesprochen, dass beim Verschlüsseln auch der public key des Senders im Spiel wäre.
Warum ist der bei Dir nicht eingetragen?
Gespeichert
CarstenH
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 451



« Antworten #5 am: 28.07.21 - 08:53:22 »

Nach meinem Verständnis sollte zum Verschlüsseln nur öffentliche Schlüssel des Empfängers eine Rolle spielen. Dass der Server als Absender keinen öffentlichen Schlüssel hat, sollte doch ohne Belang sein.

Ja und Nein.
Ja: nur der Public Key der Empfänger wird verwendet.
Nein: auch ein Server hat ein Private/Public Schlüsselpaar - wie jede Notes-ID.
Trotzdem spielt der Schlüssel des Servers in diesem Szenario hier keine Rolle, soweit korrekt.

Steht dieser im Serverdokument unter Sicherheit bei "darf beschränkte Agenten ausführen"?

Prinzipiell wäre die Frage berechtigt - wenn es sich nicht um die ausführende Server-ID handeln würde.
Die Server-ID selbst sowie "Lotus Notes Template Development" sind immer zur Ausführung berechtigt.

Im Beitrag
https://atnotes.de/index.php?topic=38949.0
wird außerdem davon gesprochen, dass beim Verschlüsseln auch der public key des Senders im Spiel wäre.
Warum ist der bei Dir nicht eingetragen?

Diese Aussage ist falsch, hier hat der Leser des Redbooks Signatur und Verschlüsselung verwechselt.
Sonst könnte ja jeder die verschlüsselte Mail lesen wenn diese mit einem öffentlichen (!) Schlüssel, egal von wem, so einfach zu entschlüsseln wäre.

Ich habe das dann mal nachgestellt, weil ich zuerst auch dachte, so problematisch kann das doch nicht sein.
Um es auf die absoluten Basics zu reduzieren habe ich als Ausgangspunkt das offizielle HCL Beispiel zur Property EncryptOnSend verwendet.
Quelle: https://help.hcltechsw.com/dom_designer/12.0.0/basic/H_EXAMPLES_ENCRYPTONSEND_PROPERTY.html

Getestet habe ich auf einem Domino 9.0.1FP10 HF747 for Windows/64 und einem Client mit Release 10.0.1FP4 (hatte gerade keinen aktuell gepatchten 9er Client zur Verfügung - aber ich vermute anhand der Google-Ergebnisse dass das eh keinen Unterschied macht).

Weiterhin habe ich alle Tests mit drei Nutzern und zwei Orten (Desktop/Server) durchgeführt:
a) als Benutzer (mit meiner ID)
b) als Server (mit der ID des Servers, der den Agenten auch ausführt)
c) als Spezieller Name (technisch ein beliebiger, auch ein ausgedachter, Notes-Name für den ein Personen- oder Mail-In-Dokument angelegt ist, unabhängig davon ob eine ID oder Schlüssel existieren oder eingetragen wurden)

1. Erkenntnis: das Beispiel-Script funktioniert nicht
Zumindest nicht ohne Änderungen (siehe später) - unabhängig davon, wo und in wessen Kontext es ausgeführt wird
Und nein, natürlich meine ich damit nicht die Änderung von Datenbank- und Empfängernamen.

2. Erkenntnis: Variante (b) verschlüsselter Versand im Namen des ausführenden Servers funktioniert nicht
Es wird kein Bulk-Schlüssel generiert und in der Mail mitgeschickt (Item $Seal fehlt in empfangener Mail).
Das hat NICHTS damit zu tun, dass ein Serverdokument keine Mailadresse hat oder dass es ein Server ist.

3. Erkenntnis: Sobald im Namen einer real im DD existierenden Adresse (Typ a oder c) versendet wird funktioniert es
Bedingung: die "Adresse" muss auch unter "darf restricted Agents ausführen" aufgeführt sein und Zugriffsrechte in der DB und auf dem Server haben, in der der Agent läuft sowie mindestens Depositor in den mail.box(en) sein.

4. Erkenntnis: der Mailer-Demon weiß von sich aus nicht WAS verschlüsselt werden soll
Mit Sender = (a) oder (c) ändert sich das Verhalten. Jetzt wird zwar ein Schlüssel generiert und in der Mail auch mitgeschickt ($Seal) aber es findet keine Verschlüsselung eines Feldes statt ($SealData mit verschlüsseltem Body fehlt).
Erläuterung: in der normalen Memo-Maske hat das Body-Feld mehrere zusätzliche Attribute, die beim Beispiel-Script nicht gesetzt werden.
Damit weiß der Client-Mailer-Demon (der mit der Methode Send ausgelöst wird) nicht welche Items verschlüsselt werden müssen. Lösung: dem Body-Feld muss die Isencrypted=True Property hinzugefügt werden.

Wenn man das alles auf einen Punkt bringt ergibt sich das folgende, absolute Minimum an Script:

Code:
Sub Initialize
Dim s As New NotesSession
Dim db As NotesDatabase

Set db = s.CurrentDatabase
Dim memo As New NotesDocument( db )
Dim recipients ( 1 To 2 ) As String

memo.Subject = "Test encrypted Mail"
memo.Body = "Test encrypted memo from " + db.Title

Dim itm As Notesitem
Set itm = memo.Getfirstitem("Body")
itm.Isencrypted = True

memo.EncryptOnSend = True
recipients( 1 ) = "Vorname Name/Meine Organisation"
recipients( 2 ) = "#Meine-Verteiler-Liste"
Call memo.Send( False, recipients )
End Sub

(Fun)Facts anhand der Tests:

- Es ist egal, ob "Name" im OnBehalfOf steht oder nur als Signierer/Ausführender fungiert.
- Es ist egal, ob "Name" ein Servername ist solange er im DD steht und NICHT identisch mit dem ausführenden Server ist (aber nicht empfehlenswert da DEAD-Mails entstehen können und werden).
- Es ist egal ob zu "Name" eine ID (mit einem Schlüsselpaar) existiert oder es nur ein fiktivier Name mit einem Mail-In-Dok ist - Hauptsache der Name steht im DD.
- Es ist egal, ob Empfänger ein Notes-Name, eine Gruppe oder Mail-In ist. Sofern ein Public Key gefunden wurde wird verschlüsselt.
- Sobald ein Schlüssel ($Seal) in der Mail steckt erkennen Traveler/Verse die Mail als verschlüsselt und weigern sich den Inhalt anzuzeigen - unabhängig davon ob der Body überhaupt verschlüsselt wurde.

Insgesamt muss ich gestehen - spannende Geschichte. Ich mache seit langer Zeit viel mit Verschlüsselung und Mail aber bin bisher nie auf die Idee gekommen, Mails als Server zu versenden da damit zwangsläufig DEAD-Mails bei Rückläufern entstehen. Vermutlich bin ich dadurch auch noch nie auf das Problem gestoßen.

Also umstellen auf eine reale Adresse, ggf. eine Mail-In wie "Infomailer/Meine Org" anlegen, und das Problem hat sich erledigt. Und keine DEAD-Mails gibt's als gratis Zugabe dazu Wink

HTH
Carsten
« Letzte Änderung: 28.07.21 - 09:36:24 von CarstenH » Gespeichert
Werner Götz
Aktives Mitglied
***
Offline Offline

Geschlecht: Männlich
Beiträge: 194



« Antworten #6 am: 28.07.21 - 09:10:04 »

Vielen Dank für Deine Tests und Erklärungen!

Das betrachte ich dann allerdings als Fehler im Produkt:
Zitat
2. Erkenntnis: Variante (b) verschlüsselter Versand im Namen des Servers funktioniert nicht
Es wird kein Bulk-Schlüssel generiert und in der Mail mitgeschickt (Item $Seal fehlt in empfangener Mail).
Das hat NICHTS damit zu tun, dass ein Serverdokument keine Mailadresse hat.
Gespeichert
CarstenH
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 451



« Antworten #7 am: 28.07.21 - 09:22:47 »

Vielen Dank für Deine Tests und Erklärungen!

Das betrachte ich dann allerdings als Fehler im Produkt:
Zitat
2. Erkenntnis: Variante (b) verschlüsselter Versand im Namen des Servers funktioniert nicht
Es wird kein Bulk-Schlüssel generiert und in der Mail mitgeschickt (Item $Seal fehlt in empfangener Mail).
Das hat NICHTS damit zu tun, dass ein Serverdokument keine Mailadresse hat.

Da stimme ich dir zu.

Wenn wenigstens konsequent alle Namen aus Serverdokumenten oder alle nicht antwortfähigen Namen ausgeschlossen wären hätte ich noch einen sicherheitsrelevanten Sinn dahinter gesehen.
Andererseits sind das jetzt nur meine Tests, vielleicht mag sich jemand anders die Zeit nehmen und das auch testen, vielleicht auch mit anderen Versionen.

Carsten
Gespeichert
Werner Götz
Aktives Mitglied
***
Offline Offline

Geschlecht: Männlich
Beiträge: 194



« Antworten #8 am: 28.07.21 - 10:36:01 »

Hallo Carsten,

das hat mir jetzt keine Ruhe gelassen und ich habe das selbst mit Deinem Code ausprobiert.
Bei mir kommen die Mail immer verschlüsselt an, auch in der bei Dir problematischen Variante (b)

Server waren aber V12 sowie V11.

-Werner
Gespeichert
CarstenH
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 451



« Antworten #9 am: 28.07.21 - 11:28:20 »

Hallo Werner,

vielen Dank für's Testen. Ich werde das dann am Wochenende auch noch einmal auf anderen Systemen testen, vorher komme ich jetzt nicht mehr dazu. Vielleicht ist das ja wirklich ein behobener Bug aus 9.x

Carsten
Gespeichert
MALTKU
Frischling
*
Offline Offline

Beiträge: 12


« Antworten #10 am: 29.07.21 - 07:58:00 »

Guten Morgen zusammen!

Vielen Dank für Eure Mühen und Eure Tests. Die Ergebnisse decken sich mit meinen Beobachtungen. Zumindest unter Domino 9 scheint es dann so zu sein. Ich nehme es mal auf meine Agenda, die DB inkl. Agent auf meinem 11er Testserver zu packen und zu testen.

Der Beitrag https://atnotes.de/index.php?topic=62584.0;prev_next=next beschreibt gut mein Problem. Leider gab es dort keine (so tollen) Antworten wie hier.

Zu einem von Carstens Punkten habe ich dann doch noch eine Nachfrage / Anmerkung:
- Es ist egal, ob "Name" ein Servername ist solange er im DD steht und NICHT identisch mit dem ausführenden Server ist (aber nicht empfehlenswert da DEAD-Mails entstehen können und werden).
(ich habe das mit dem korrekten Zitieren nicht hinbekommen?!)

Frage: Was macht den Unterschied, ob der Agent auf Server A läuft und mit Server B signiert wurde (oder RunOnBehalfOf=Server B)
Anmerkung: Zum Umgehen von DEAD-Mail bei Mails, die als Absender einen der Server haben, habe ich seinerzeit für alle Server je ein Mail-In-Dokument angelegt, sodass diese Mails nicht tot laufen, sondern in einer zentralen Server-Mail-In-Datenbank auflaufen. Das funktioniert soweit prima und hat mir bis jetzt nur im Zusammenhang mit YTRIA kurz Probleme gemacht. Theoretisch könnte das aber auch eine Ursache des Problems sein - praktisch hattet ihr das Problem aber auch, ohne das für den Server ein Mail-In-Eintrag exisitiert.

Liebe Grüße und nochmal vielen Dank
Thomas
« Letzte Änderung: 29.07.21 - 12:33:28 von MALTKU » Gespeichert
CarstenH
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 451



« Antworten #11 am: 29.07.21 - 08:40:25 »

Frage: Was macht den Unterschied, ob der Agent auf Server A läuft und mit Server B signiert wurde (oder RunOnBehalfOf=Server B)

Wissen wir auch (noch) nicht. Fakt ist aber, dass es nach bisherigen Erkenntnissen unter N/D 9.x zu dem beschriebenen Verhalten kommt.

Anmerkung: Zum Umgehen von DEAD-Mail bei Mails, die als Absender einen der Server haben, habe ich seinerzeit für alle Server je ein Mail-In-Dokument angelegt, sodass diese Mails nicht tot laufen, sondern in einer zentralen Server-Mail-In-Datenbank auflaufen. Das funktioniert soweit prima und hat mir bis jetzt nur im Zusammenhang mit YTRIA kurz Probleme gemacht.

Auch wenn es (erstaunlicherweise) technisch funktioniert ist diese Konstellation eigentlich nicht zulässig da jeder Notesname im DD eindeutig sein muss. D.h., der gleiche Name darf nicht doppelt eingetragen sein - unabhängig davon, ob das jetzt Personen, Gruppen, Server oder ein Mix davon ist. Insbesondere bei Servern und Administratoren(-gruppen) sollte man da sehr sensibel sein um sich keine Hintertüren aufzureißen oder ungewollt Server oder Admins auszusperren. Spätestens wenn man sich auf die Art auch bei FullAccess bei aktiver DB Verschlüsselung/konsistenter ACL ausgesperrt hat kann keiner mehr helfen.

Vorschlag: wenn du sowieso schon ein Mail-In-Dokument dafür angelegt hast - was hindert dich daran, den derzeitigen Namen des Mail-In leicht abzuändern (z.B. indem du -Service an den Common Name Teil anhängst) und diesen so bei den betreffenden Agenten als Run-on-behalf einzutragen? Dann wären das Verschlüsselungsproblem UND das Namen-Dopplungs-Problem gelöst.

HTH
Carsten
Gespeichert
MALTKU
Frischling
*
Offline Offline

Beiträge: 12


« Antworten #12 am: 29.07.21 - 13:57:16 »

Frage: Was macht den Unterschied, ob der Agent auf Server A läuft und mit Server B signiert wurde (oder RunOnBehalfOf=Server B)

Wissen wir auch (noch) nicht. Fakt ist aber, dass es nach bisherigen Erkenntnissen unter N/D 9.x zu dem beschriebenen Verhalten kommt.

Hmm. Komme immer noch nicht ganz mit.
Bei mir ist beides gleich. Server A hat den Agenten signiert (RunOnBehalfOf ist nicht gesetzt). Server A führt den Agenten aus. Die Mail kommt unverschlüsselt an. Ist nach deiner Beschreibung und den Tests der anderen dem Anschein nach zumindest unter Notes 9 so.
Was ist anders, wenn Server A den Agenten signiert hat und Server B den Agenten ausführt. Die Mail ist dann doch auch unverschlüsselt. Oder habe ich was überlesen / übersehen?

Anmerkung: Zum Umgehen von DEAD-Mail bei Mails, die als Absender einen der Server haben, habe ich seinerzeit für alle Server je ein Mail-In-Dokument angelegt, sodass diese Mails nicht tot laufen, sondern in einer zentralen Server-Mail-In-Datenbank auflaufen. Das funktioniert soweit prima und hat mir bis jetzt nur im Zusammenhang mit YTRIA kurz Probleme gemacht.

Auch wenn es (erstaunlicherweise) technisch funktioniert ist diese Konstellation eigentlich nicht zulässig da jeder Notesname im DD eindeutig sein muss. D.h., der gleiche Name darf nicht doppelt eingetragen sein - unabhängig davon, ob das jetzt Personen, Gruppen, Server oder ein Mix davon ist. Insbesondere bei Servern und Administratoren(-gruppen) sollte man da sehr sensibel sein um sich keine Hintertüren aufzureißen oder ungewollt Server oder Admins auszusperren. Spätestens wenn man sich auf die Art auch bei FullAccess bei aktiver DB Verschlüsselung/konsistenter ACL ausgesperrt hat kann keiner mehr helfen.

Vorschlag: wenn du sowieso schon ein Mail-In-Dokument dafür angelegt hast - was hindert dich daran, den derzeitigen Namen des Mail-In leicht abzuändern (z.B. indem du -Service an den Common Name Teil anhängst) und diesen so bei den betreffenden Agenten als Run-on-behalf einzutragen? Dann wären das Verschlüsselungsproblem UND das Namen-Dopplungs-Problem gelöst.

HTH
Carsten

Bzgl. des eindeutigen Notesnamen hast Du recht. Ich habe das in meinem wilden Sturm- und Drangzeiten mal als quick&dirty-Lösung hinterlegt und danach - um Jahre weiser - nicht wieder hinterfragt. Das Hinterfragen mache ich dann jetzt mal. Genau wie ich deinen Vorschlag bedenken. Machst Du das bereits so? Ist das also quasi eine erprobte BestPractice?

Gruß
Thomas
Gespeichert
CarstenH
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 451



« Antworten #13 am: 29.07.21 - 14:17:47 »

Was ist anders, wenn Server A den Agenten signiert hat und Server B den Agenten ausführt. Die Mail ist dann doch auch unverschlüsselt.

Nein. In diesem Fall wird die Mail erfolgreich verschlüsselt. Ausführender Server ist nicht gleich dem Namen, in dessen Kontext es läuft. Also Variante (c).

Bzgl. des eindeutigen Notesnamen hast Du recht. Ich habe das in meinem wilden Sturm- und Drangzeiten mal als quick&dirty-Lösung hinterlegt und danach - um Jahre weiser - nicht wieder hinterfragt. Das Hinterfragen mache ich dann jetzt mal. Genau wie ich deinen Vorschlag bedenken. Machst Du das bereits so? Ist das also quasi eine erprobte BestPractice?

Ja. In den meisten Fällen lege ich beim Kunden einfach eine (oder mehrere, je nach Zweck) Mail-In-DB mit einer Adresse z.B. Info-Service/Company und der Internetadresse do-not-reply @ company.xyz an. Da das keine User-ID ist hat das mit dem Signieren auch nichts zu tun, dieser Name wird einfach in allen relevaten DB's als Leser/Autor/Editor (je nach Zweck) in die ACL aufgenommen und in den Newsletter- und Benachrichtigungsagenten als "Ausführen im Namen von" hinterlegt. Schon gehen die Mails mit dieser Adresse raus und wenn jemand antwortet löscht man entweder alle Mails an do-not-reply ungesehen oder hat sie zumindest an einer zentralen Stelle.

Kostet keine Lizenz und verstößt nicht gegen Namenskonventionen oder andere Dinge. Und man gibt auch bei Mails, die gewollt oder ungewollt nach draußen wandern nicht gleich im Absender seine Unternehmensstruktur und das verwendete Mailsystem preis.

HTH
Carsten
Gespeichert
Seiten: [1] Nach oben Drucken 
« vorheriges nächstes »
Gehe zu:  


Einloggen mit Benutzername, Passwort und Sitzungslänge

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006, Simple Machines Prüfe XHTML 1.0 Prüfe CSS
Impressum Atnotes.de - Powered by Syslords Solutions - Datenschutz | Partner: