Kalender-Protokoll Sicherheit - wie handlet Ihr das? FTP/SFTP/WEBDAV/VPN ?

  • Hi zusammen,


    wie löst Ihr das Problem der unverschlüsselten Übertragung der Daten via I-Net ?


    SFTP scheidet aus, das TB das nicht kann (wenn ich auf dem laufenden bin)

    VPN setzt clientseitig einen gewissen Aufwand voraus

    plain FPT scheidet aus


    bleibt also nur WEBDAV per HTTPS

    (habe ich noch nicht ausprobiert)


    oder kennt Ihr andere Lösungsmöglichkeiten?


    BTW: kann jemand ein Script zur externen Auswertung des .ICS-Formats empfehlen?

    (also zum Zerlegen in Datum, Zeit, Ort, Text usw...)

  • Ich verstehe dein Szenario glaube ich noch nicht ganz: was ist dein Ziel, und was ist dein Angriffsszenario?


    Dein Ziel bestimmt zunächst einmal, was überhaupt infrage kommt. Beispiele:

    1. Einen Kalender auf einem Gerät verwalten. Fast jede Lösung erfüllt dies – auch ein lokaler Kalender ganz ohne Internet.
    2. Einen Kalender automatisch zwischen mehreren Geräten austauschen. Das kann über CalDAV über einen Server laufen – sofern ein Server existiert, dem du vertraust. Bei Geräten die gelegentlich im selben Netzwerk sind, kann man aber z.B. auch mit dem von mir entwickelte GeneralSync direkt synchronisieren, ohne dass die Daten durch das Internet oder auf einen Server müssen. (Beachte das WebDAV, FTP und SFTP alleine keine sinnvollen Optionen sind, sobald es mehr als ein gleichzeitig genutztes Gerät gibt. Nutze ein Protokoll, das für mehrere Geräte gedacht ist, sonst droht Datenverlust!)
    3. Ein Kalender muss mit einem bestimmten Server synchronisiert werden (z.B. Arbeitgeber). Dann ist die entscheidende Frage, welche Protokolle dort unterstützt werden. Alles andere kommt schließlich gar nicht infrage.

    Angriffsszenarien können dir dann helfen, eine Lösung auszuwählen. Beispiele:

    1. Du willst dich gegen "zufällige" Angreifer aus dem Internet schützen, die keinen direkten Zugriff auf den Server haben. Du hast aber kein Problem damit, dass ein Angreifer mit Zugriff auf den Server (z.B. der Server-Betreiber selbst) alle Termine einsehen und ändern kann. Dann reicht eine Transportverschlüsselung und ein für dich vertrauenswürdiger Hoster: solange die Daten nur verschlüsselt übertragen werden und der Server nicht erfolgreich angegriffen wird, sind deine Daten dann sicher. (Bei gewerblichen Kalendern bestehen wegen der Weitergabe der Daten an Dritte aber ggf. Prüf-, Informations- und Dokumentationspflichten.)
    2. Du willst zusätzlich, dass Angreifer auf dem Server ebenfalls nicht mitlesen oder ändern können. Dafür braucht es eine Ende-zu-Ende-Verschlüsselung, d.h. deine Daten dürfen nur auf Geräten entschlüsselbar sein, die deiner Kontrolle unterstehen. Im Gegensatz zu E-Mail gibt es bei Kalendern keine etablierte Lösung, bei der die Daten dennoch auf einem unvertrauten Server gespeichert werden. Entsprechend besteht oft nur die Wahl zwischen dem Betrieb eines eigenen Servers oder einem lokalen Synchronisationstool wie GeneralSync.
    3. Du willst dich auch vor Angreifern schützen, die den Datenverkehr des Internets großflächig aufzeichnen und erst in ein paar Jahrzehnten mit der dann modernsten Technik entschlüsseln wollen. Es gibt derzeit keinen praktischen Weg, deinen Kalender in irgendeiner Weise über das Internet zu übertragen der einem derartigen Angriff standhalten würde – es bleiben also nur noch rein lokale Server und Synchronisationstools.

    Ich persönlich nutze – als Entwickler des Tools wenig verwunderlich – GeneralSync. Da PC, Smartphone und Laptop oft im selben Netzwerk sind ist das für mich genauso komfortabel wie die Cloud, ohne meine Daten dem Internet auszusetzen.

  • Ich verstehe dein Szenario glaube ich noch nicht ganz: was ist dein Ziel, und was ist dein Angriffsszenario?

     

    Es geht lediglich darum, dass die Termindaten und user/passwort nicht

    "im klartext" übers Netz laufen sollen.


    Nachtrag:


    heisst das obige, dass TB nicht selbständig sowas wie "locking" betreibt und

    User a

    den Kalender von

    User b

    überschreibt, wenn er einen Termin einträgt - und User b 1 Sekunde vorher

    ebenfalls einen eingetragen hat ?

    (wenn beide den gleichen Account benutzen)

    und es somit nur einen schreibberechtigten User pro Kalender geben darf?

  • Thunderbird wird nicht von sich aus die Kalender unterschiedlicher User überschreiben. Das was du beschreibst ist wohl eher das Überschreiben eines einzelnen Termins in einem Kalender.


    Und ja, das liegt in der Natur der Sache: derjenige der zuletzt ändert, dessen Daten werden gespeichert und sind fortan für alle anderen die synchronisieren gültig. Wenn zwei Personen auf deren Smartphones den gleichen Termin ändern, wird nach erfolgreicher Synchronisierung auch wieder der letzte gespeicherte Stand derjenige sein, der nun gültig ist.


    Ich denke nicht, dass das CalDAV Protokoll in der Lage sein wird, lediglich einzelne Terminfelder abzugleichen und auszutauschen, das wäre mir neu. Ich denke es wird der komplette Termin immer wieder aufs Neue in die CalDAV Datenbank geschrieben, auch wenn User A nur den Starttermin und User B nur den Endetermin geändert hat.

    Thunderbird 78.6.1 (nur IMAP-Konten), Windows 10 Pro

  •  

    Ich denke nicht, dass das CalDAV Protokoll in der Lage sein wird, lediglich einzelne Terminfelder abzugleichen und auszutauschen, das wäre mir neu. Ich denke es wird der komplette Termin immer wieder aufs Neue in die CalDAV Datenbank geschrieben, auch wenn User A nur den Starttermin und User B nur den Endetermin geändert hat.

    ich glaube, das ist alles noch viel schlimmer:

    da wird offenbar nicht der aktutelle stand eines termins

    auf dem server mit dem aktuellen lokalen stand abgeglichen

    oder ge"diff"t und ggf. gewarnt.

    da wird einfach das gesamte ics-file auf dem server mit dem inhalt

    des lokalen ersetzt.


    so sieht es jedenfalls nach einem ersten test aus.

  • Hallo wicki_w,


    wohin genau willst du denn überhaupt übertragen? Es liest sich so, als würdest du keinen Kalenderserver oder ähnliches Tool nehmen, sondern lediglich eine Termindatei hin- und herschicken zu/von einem Dateiserver.


    CalDAV ist übrigens was Anderes als die Übersendung von Termindateien (*.ICS).

    wie löst Ihr das Problem der unverschlüsselten Übertragung der Daten via I-Net ?

    Ich habe für meine Termine ein separates Konto bei einem der sicheren einheimischen Anbieter. Dort werden die Termine gepflegt und alle Clients (2x Windows, ipad, Android, ab und zu auch Test-Linuxe) greifen darauf zu per CalDAV-Protokoll. Der Serverzugriff geht über https, ist also transportverschlüsselt.


    Den Spielkram mit Kalenderdateien tue ich mir nicht an, viel zu umständlich.


    MfG

    Drachen



    PS: bei deiner vorherigen Antwort ist die Shifttaste kaputt gegangen .... ;) :P

  • Es liest sich so, als würdest du keinen Kalenderserver oder ähnliches Tool nehmen, sondern lediglich eine Termindatei hin- und herschicken zu/von einem Dateiserver.


    ++ Drachen. Ich habe ebenfalls den Eindruck. Hier unterliegt wicki_w augenscheinlich einem ganz dicken Missverständnis. Nackter Dateizugriff ist völlig untauglich sobald es um mehr als einen Computer geht. Wichtig auch das von generalsync Geschriebene. HTTPS sichert das Passwort bei der Übertragung. Das ist nur die halbe Miete solange der Kalender selbst nicht sicher ist.

  • Um das (vermutliche) Missverständnis nochmal auf den Punkt zu bringen:


    Wenn es um mehrere Geräte geht, brauchst du zwingend ein Protokoll, das dafür ausgelegt ist, Kalender zwischen Geräten auszutauschen. Daher oben schon meine Anmerkung "Beachte das WebDAV, FTP und SFTP alleine keine sinnvollen Optionen sind, sobald es mehr als ein gleichzeitig genutztes Gerät gibt. Nutze ein Protokoll, das für mehrere Geräte gedacht ist, sonst droht Datenverlust!". Jede Lösung die direkt mit "rohen" ics-Dateien Dateien hantiert ist für deine Anwendung nicht geeignet. Du kannst aber z.B. zu Sicherungszwecken weiterhin jederzeit ics-Dateien aus Thunderbird exportieren!


    Du hast also die Wahl zwischen CalDAV oder einem anderen Client-Server-Protokoll (du brauchst dann einen Server, den du selbst betreiben oder bei einem Anbieter anmieten kannst – der Server hat immer Vollzugriff auf alle Daten) oder einem lokalen Synchronisationsprotokoll (ohne Server, z.B. GeneralSync).


    Und ja, das liegt in der Natur der Sache: derjenige der zuletzt ändert, dessen Daten werden gespeichert und sind fortan für alle anderen die synchronisieren gültig. Wenn zwei Personen auf deren Smartphones den gleichen Termin ändern, wird nach erfolgreicher Synchronisierung auch wieder der letzte gespeicherte Stand derjenige sein, der nun gültig ist.

    Bei Client-Server-Lösungen gibt es oft dieses Problem, ja. Muss aber nicht so sein: z.B. erkennt GeneralSync solche Situationen ("Konflikt"), synchronisiert beide Versionen und bietet dem Nutzer hinterher an, die richtige Fassung auszuwählen. CalDAV kann so etwas nicht – die "Lösung" dafür ist es, Änderungen nur online vorzunehmen: dann ist das Risiko sehr gering, dass solche Fälle auftreten bzw. relevante Konsequenzen haben. Für eine längerfristige Offline-Nutzung ist eine Cloud-/Server-Lösung halt nicht ausgelegt.

  • > Nackter Dateizugriff ist völlig untauglich sobald es um mehr als einen Computer geht


    eigentlich ging es erst mal nur darum, die daten nicht im klartext übers netz zu schicken.

    das ist jetzt mit https/webdav gelöst.

    das war der primäre grund für diesen thread.

    da war ich noch davon ausgegangen, das TB in der lage ist, zu erkennen ob jemand

    zwischenzeitlich den kalender verändert hat. aber das ist ja nicht der fall.


    also die nächste stufe: jeder bekommt seinen eigenen kalender und jeder andere

    bekommt darauf lesezugriff.

    das setzt aber wiederum den "guten willen" des benutzers voraus.

    (dass er nicht einfach in meinem kalender rumschreibt).


    da ich keine lust habe, das auf verzeichnisebene zu handlen, werde ich wohl ein

    filter-servlet vorschalten, dass user nur auf ihre eigenen kalender schreiben und

    alle anderen nur lesen dürfen.


    scheint mir momentan das sinnvollste zu sein.

    ich möchte zunächst bei .ics bleiben - aber es gibt doch bestimmt auch fertige tools,

    die .ics nach .sonstwas portieren können.


    hintergrund/endziel: ich möchte termindaten zwischen bestehenden

    alt-anwendungen und TB hin- und her schieben können.

  • Mehr als dir zu erklären, dass deine Methode eine schlechte Wahl ist, kann man nicht machen. generalsync hat wie ich finde sehr gut erläutert, wie es besser geht.

    Was bitte ist dran eine schlechte Wahl?


    Ich möchte die Daten für alle berechtigten User lesbar als plain-ASCII

    auf einem Server haben.


    Die Übertragung soll nicht im Klartext erfolgen.


    Jeder darf _alle_ Termine _lesen_.


    _schreiben_ darf nur der Eigentümer des Kalenders.


    Das Problem "Schreibrechte" löse ich entweder durch ein Servlet-Filter

    oder durch Verzeichnishierarchie.


    Damit ist genau das erfüllt, was ich wollte.

  • Was bitte ist dran eine schlechte Wahl?

    Falls das eine ernst gemeinte Frage ist, lies in Ruhe Beitrag #8. Deine selbstgestrickte Lösung hat viele Nachteile und Einschränkungen. Mit dem für Kalender vorgesehenen Protokoll CalDAV oder mit Generalsync hättest du die nicht.

  • Was bitte ist dran eine schlechte Wahl?

    Falls das eine ernst gemeinte Frage ist, lies in Ruhe Beitrag #8. Deine selbstgestrickte Lösung hat viele Nachteile und Einschränkungen. Mit dem für Kalender vorgesehenen Protokoll CalDAV oder mit Generalsync hättest du die nicht.

    ja, das ist eine "ernst gemeinte Frage".


    Ich habe ganz bestimmte Anforderungen. s.o.

    Und genau die werden alle erfüllt.

    Und WEBDAV/.ics mit zusätzlicher Rechteverwaltung ist weder "selbstgestrickt"

    noch hat sie "Nachteile und Einschränkungen" für _diesen_ Anwendungsfall.


    Wären die Anforderungen anders, würde ich anders daran gehen.

    Aber in diesem Fall wird halt genau das Problem gelöst. Mit Standardmitteln,

    die alle vorhanden sind.


    Wenn es mal eine Zeit lang im Einsatz ist, denke ich vielleicht anders darüber.