Threema Safe mit Nextcloud nutzen

Stelle deine Frage öffentlich an die Threema-Forum-Community - über 4.600 Mitglieder helfen dir weiter. > Frage stellen <
  • Hallo zusammen,

    bin auch gerade dabei, mir einen privaten Server einzurichten.
    Hier habe ich zur Auswahl GMX und meine Synology.

    Leider bekomme ich das nicht so hin wie gewünscht - habe in meiner Synology einen extra User angelegt.
    Bei GMX bekommt einen Freigabelink, welchen ich aber nicht "lesen" kann.

    Hier ist mal ein Testordner von GMX

    https://c.gmx.net/@324830000995899867/X8PXZPCnTWyu2ZZ_Wy0cQQ (Passwort ist "threema")
    Der normale Zugriff erfolgt über folgenden Link - https://webdav.mc.gmx.net

    Habe es mal mit Passwort im Link probiert, aber irgendwie gehts net...

    Hat jemand eine Idee?

    Gruß
    [hr]


    Leider bekomme ich das nicht so hin wie gewünscht - habe in meiner Synology einen extra User angelegt.

    Habe den Link zu meiner Synology mal gemacht, bekomme aber einen Zertifikatsfehler "trust anchor certification path not found" und daher nicht zugreifen.
    https://<user>:<pass>@synology:5006/threematest

    Einmal editiert, zuletzt von mr-magoo (15. Dezember 2018 um 17:59)

  • Hm - irgendwas klappt nicht. Vielleicht sieht jemand von Euch, was mir die Tomaten auf den Augen verbergen?

    Ich hab mich für Linkfreigabe á la Magrathea für meinen existierenden Nutzer in Nextcloud 15.0 entschieden. Verzeichnis Threema/ erstellt, config-Datei erstellt, Ordner backups/ erstellt, Linkfreigabe mit Paßwort (Hochladen und bearbeiten erlaubt) erstellt.
    Wenn ich diesen Link jetzt im Desktopbrowser aufrufe bekomme ich den Paßwortscreen eingeblendet -> eingeben -> Ordner Threema/ wird wie erwartet angezeigt.

    Wenn ich die Link-ID nach Schema umbaue

    Code
    https://<Link-ID>:<$password>@mein.server.fnord/public.php/webdav/


    , dann bekomme ich von Nextcloud 'unauthorized' angezeigt.

    Die URL in Threema eingegeben erzeugt eine Fehlermeldung "HTTPS IO Exception" mit der anschließenden Ausgabe der URL mit angehängtem /config

    Details:

    • ich nutze NGinX mit PHP 7.2-fpm, die Verbindung läuft unter TLS 1.3 (Relevanz? Problem tritt auch im Desktopbrowser auf)
    • mein Paßwort beinhaltet ein Komma
    • im Access-Log des Servers wird mir ein GET public.php/webdav/ mit Status 401 verzeichnet
    • das Error-Log bleibt leer


    Any hints anyone?

  • Moin
    Dein Problem ist die "HTTPS IO Exception".
    Vermutlich will dein Webserver HTTPS Parameter vorschreiben, die dein Smartphone nicht unterstützt.

    Reduziere mal die Anforderungen

    Code
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
  • Zitat von "mr-magoo" pid='41755' dateline='1544890726'


    Habe den Link zu meiner Synology mal gemacht, bekomme aber einen Zertifikatsfehler "trust anchor certification path not found" und daher nicht zugreifen.
    https://<user>:<pass>@synology:5006/threematest


    Das hatte ich zunächst auch. Dagegen hilft es, dass Synology CA Zertifikat auf dem Smartphone zu installieren. Auf der DiskStation dazu unter Systemsteuerung / Sicherheit / Zertifikat das "Zertifikat exportieren", dann syno-ca-cert.pem aus dem erzeugten ZIP vom .pem-Format ins .der-Format konvertieren (das habe ich mit Firefox gemacht: .pem importiert, und dann als .der exportiert), auf's Smartphone übertragen und Zertifikat dort installieren.

    Allerdings erhalte ich nun ständig in Threema die Fehlermeldung: "Test fehlgeschlagen: HTTPS IO Exception: Connection closed by peer", obwohl eigentlich alles passen sollte?! Username, Passwort (Sonderzeichen darin URL-codiert), und Port (5006) stimmen (https://username.passwort@192.168.178.2:5006/pfad/zum/safe) und das Verzeichnis dort auf der DiskStation enthält auch die korrekte config-Datei und das "backups"-Verzeichnis - allesamt mit Schreibrechten für den Nutzer...
    Hat jemand eine Idee, was mir diese Fehlermeldung sagen möchte?

    Andy

    Einmal editiert, zuletzt von andyg (15. Dezember 2018 um 23:09)

  • Hm.
    Laut SSLlabs sollte ab Android 7.0 TLS 1.2 unterstützt sein, und das spricht mein Server auch - hier der Auszug aus der SSL-Analyse:

    Zitat


    [font="Arial, Helvetica, sans-serif"]Android 7.0    RSA 2048 (SHA256)     TLS 1.2 > h2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp384r1  FS[/font]

    Und, was mich noch viel mehr wundert - es klappt auch auf dem Desktop nicht (Chrome 71, Firefox 64, Opera 57, alles unter Linux))

    Aber ok - ich hab dem Server gesagt, TLS 1.2 ist das höchste der Gefühle, und die Ciphers auch etwas eingegrenzt:

    Code
    ssl_protocols TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;

    Restart - gleiches Bild, auch mit TLS 1.2: auf dem Desktop bekomme ich von Nextcloud 'nen Fehler "unauthorized" und unter Android (8.1) innerhalb Threemas kommt die HTTPS IO Exception.
    Chrome auf Android verlangt dann Username/Passwort.

    Kann es am PHP-FPM bzw. wie das eingebunden ist liegen? Config ist direkt copy/paste aus dem Nextcloud-Manual kopiert

    Einmal editiert, zuletzt von Husky (16. Dezember 2018 um 00:45)

  • Schnelle Bestätigung von mir: habs gerade nach der aktualisierten Anleitung auf einer frischen NC15-Instanz gemacht, hat einwandfrei funktioniert.

    +1, tausend Dank für die gute Dokumentation!

  • Hallo,

    ich kann das Problem von von Husky nur bestätigen.



    Details:

    • Apache mit PHP 7.2-fpm unter TLS 1.2 auf Sub-domain
    • Nextcloud 14.0.4
    • Passwort enthällt ein $ (mit %24 habe ich es auch versucht)
    • Error-Log leer.


    Wenn diese Kinderkrankheiten noch behoben werden und vielleicht die config-Datei und der backups-Ordner automatisch angelegt werden, ist diese Funktion richtig gut (Aber für mich jetzt leider noch nicht einsetzbar).

  • Hallo,

    meine Erfahrung ist wie folgt:

    ich habe einen Account "Threema_User" mit einem Passwort "Passwort" auf meiner Nextcloud angelegt.

    Dann mußte ich nur noch im Threema

    Code
    https://Threema_User:Passwort@nextcloudserver.com/remote.php/dav/files/Threema_User/threema_safe

    einsetzen und schon wurde der Server erkannt.

    Es ist aber darauf zu achten keine Sonderzeichen im User oder Passwort zu verwenden, da sich Threema ansonsten beim laden der URL verschluckt. Ich weiß nicht ob oder wie man in einer URL Worte einklammern kann, vielleicht weiß ja hier jemand ob es etwas gibt wie ' ` " um klar zu machen, dass das Passwort ein abgeschlossener String ist. Dann kann man auch wieder starke Passwörter nutzen.

    Ein :daumen: für eine separate Eingabemaske für User und Passwort bei der Servereingabe in der Threema GUI. Und schon jetzt ein :rock: für den Threema-Safe, coole Sache.

    Christian

    P.S. Bitte, bitte Feedback, wenn ich groben Mist schreibe, aber nett bitte.

    Einmal editiert, zuletzt von Suho0211 (17. Dezember 2018 um 17:13)

  • Zitat von "Suho0211" pid='41810' dateline='1545062848'


    Es ist aber darauf zu achten keine Sonderzeichen im User oder Passwort zu verwenden, da sich Threema ansonsten beim laden der URL verschluckt.


    Ach das könnte das Problem bei meiner Kofiguration sein! Hatte schon versucht, das Sonderzeichen in URL-Kodierung zu verwenden (die %-Schreibweise), aber auch das klappte nicht. Werde bei Gelegenheit mal ein sonderzeichenfreies Passwort versuchen.


    Andy


  • Hallo,

    ich kann das Problem von von Husky nur bestätigen.

    Details:

    • Apache mit PHP 7.2-fpm unter TLS 1.2 auf Sub-domain
    • Nextcloud 14.0.4
    • Passwort enthällt ein $ (mit %24 habe ich es auch versucht)
    • Error-Log leer.


    Wenn diese Kinderkrankheiten noch behoben werden und vielleicht die config-Datei und der backups-Ordner automatisch angelegt werden, ist diese Funktion richtig gut (Aber für mich jetzt leider noch nicht einsetzbar).

    Hmm. Ich hab mal 'n anderes PW versucht, ohne Sonderzeichen. Ergebnis - klappt immer noch nicht.

    Wir haben also die Gemeinsamkeit, daß das PHP als FPM angebunden ist. Da der Rest unterschiedlich ist dürfte da also das Problem liegen, oder?

    Und nu?
    [hr]
    Nach ein wenig RTFM hab ich mal ins Nextcloud-Log geguckt - hier das Ergebnis:

    Code
    {"reqId":"fRXNAWxGNSJHxL0vmjiL","level":0,"time":"2018-12-17T22:31:09+00:00","remoteAddr":"91.59.53.226","user":"--","app":"webdav","method":"GET","url":"\/public.php\/webdav\/","message":{"Exception":"Sabre\\DAV\\Exception\\NotAuthenticated","Message":"No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured","Code":0,"Trace":[{"function":"beforeMethod","class":"Sabre\\DAV\\Auth\\Plugin","type":"->","args":[{"absoluteUrl":"https:\/\/mein.server.fnord\/public.php\/webdav\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]},{"file":"\/var\/www\/nextcloud\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php","line":105,"function":"call_user_func_array","args":[[{"autoRequireLogin":true,"__class__":"Sabre\\DAV\\Auth\\Plugin"},"beforeMethod"],[{"absoluteUrl":"https:\/\/mein.server.fnord\/public.php\/webdav\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]]},{"file":"\/var\/www\/nextcloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php","line":466,"function":"emit","class":"Sabre\\Event\\EventEmitter","type":"->","args":["beforeMethod",[{"absoluteUrl":"https:\/\/mein.server.fnord\/public.php\/webdav\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]]},{"file":"\/var\/www\/nextcloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php","line":254,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->","args":[{"absoluteUrl":"https:\/\/mein.server.fnord\/public.php\/webdav\/","__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]},{"file":"\/var\/www\/nextcloud\/apps\/dav\/appinfo\/v1\/publicwebdav.php","line":107,"function":"exec","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"\/var\/www\/nextcloud\/public.php","line":78,"args":["\/var\/www\/nextcloud\/apps\/dav\/appinfo\/v1\/publicwebdav.php"],"function":"require_once"}],"File":"\/var\/www\/nextcloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Auth\/Plugin.php","Line":168,"CustomMessage":"--"},"userAgent":"Mozilla\/5.0 (X11; Linux x86_64) AppleWebKit\/537.36 (KHTML, like Gecko) Ubuntu Chromium\/71.0.3578.80 Chrome\/71.0.3578.80 Safari\/537.36","version":"15.0.0.10"}


    Gleichzeitig fragt mich Chrome nach Username/Paßwort. Wenn ich das abbrehce (mein normaler Username/Paßwort funktioniert nicht), dann kommt folgendes:


    Und ich bekomme die Meldung, der Zugriff sei 'unauthorized'

    Anscheinend werden Username/Paßwort nicht korrekt an das PHP-FPM übergeben.
    [hr]
    Hm.
    Stand bisher: Es gibt ein Problem bei der Übergabe von Nutzername/Paßwort an das PHP-FPM. Das ist mindestens für Owncloud bekannt, aber auch für Nextcloud.
    Bisher habe ich aber nur 'ne Lösung für das Anpassen eines Apaches gefunden - da müssen die RewriteConditions angepaßt werden.

    Vielleicht hat jemand anders 'ne bessere Suchstrategie als ich?

    Einmal editiert, zuletzt von Husky (18. Dezember 2018 um 16:01)

  • Husky Zuerst sei dir bitte bewusst, dass du mit dem Log deine Owncloud/Nextcloud-URL geleakt hast.

    Abgesehen davon sehe ich in den Logs keinen Zugriff auf eine config oder den backups-Ordner.

    Abgesehen davon, funktioniert denn der normale Login via Web oder Owncloud/Nextcloud-App/Desktop-Anwendung bei dir? Wenn nciht, scheint dies ja wirklich ein größeres Problem zu sein und wenig mit Threema zu tun haben.
    [hr]
    Wichtiger Hinweis übrigens: Vergesst das "s" bei dem Ordner "backups" am Ende nicht! Bis jetzt stand es falsch in der Anleitung (aber richtig im Screenshot), ich habe das mal korrigiert und nochmal deutlich hervorgehoben.
    [hr]


    Was ich auch noch komisch finde: Der Knopf "Jetzt sichern" ist zu klein. Bei mir steht "JETZT S...HERN". Ist das niemandem aufgefallen?

    Das scheint übrigens mit der Größe deines Bildschirms (oder Schriftart oder so) zu tun zu haben. Bei mir wird es vollständig ausgeschrieben.


  • Das scheint übrigens mit der Größe deines Bildschirms (oder Schriftart oder so) zu tun zu haben. Bei mir wird es vollständig ausgeschrieben.

    Natürlich hat es mit der Größe meines Bildschirms zu tun. Aber das ist ja keine Ausrede für denjenigen, der das Activity gestaltet hat. Android bietet die Möglichkeit, das ohne Programmieraufwand flexibel an die Gegebenheiten anzupassen.

    Erstmal ist unklar, warum der Knopf so schmal ist. Erst wenn das erste Backup durch ist, gibt es links daneben einen Knopf, auf dem "PASSWOR...ÄNDERN" steht.

    Im Hochformat müßten die Knöpfe übereinander stehen. Wenn man so viel Text draufschreibt, müßte das eigentlich einleuchten. Zumal zwischen dem "i"-Icon für die Anleitung und den beiden Knöpfen mehr als genug Platz ist.

    Einmal editiert, zuletzt von uwes (18. Dezember 2018 um 15:53)

  • Auf meinem Gerät mit 1080 x 1920 Pixeln ist die Beschriftung der Buttons vollständig. Selbst schnelle Anpassungen der Schrift- und Anzeigegröße haben das nicht geändert. Ich habe allerdings Threema Safe nach den Änderungen nicht neu aufgerufen.

    Geräte mit weniger Pixeln haben halt weniger Platz. Was hast Du für ein Gerät?

    Einmal editiert, zuletzt von Aries (18. Dezember 2018 um 16:04)


  • Husky Zuerst sei dir bitte bewusst, dass du mit dem Log deine Owncloud/Nextcloud-URL geleakt hast.

    Abgesehen davon sehe ich in den Logs keinen Zugriff auf eine config oder den backups-Ordner.

    Abgesehen davon, funktioniert denn der normale Login via Web oder Owncloud/Nextcloud-App/Desktop-Anwendung bei dir? Wenn nciht, scheint dies ja wirklich ein größeres Problem zu sein und wenig mit Threema zu tun haben.

    Danke für den Hinweis - hab das mal angepaßt.


    Der normale Login über die Linkfreigabe-URL funktioniert. Scheitern tut's, sobald ich Link-ID und Paßwort in der URL zu übergeben versuche.

    Ich werd mal im Nextcloud-Forum um Hilfe brüllen ;)

  • Hallo,

    Bei mir lag es daran, dass ich eine Option in Nextcloud nicht angeschaltet hatte:

    Code
    Settings → Administration → Sharing → Allow users on this server to send shares to other servers


    Quelle: Nextcloud Dokumentation


  • Hallo,

    Bei mir lag es daran, dass ich eine Option in Nextcloud nicht angeschaltet hatte:

    Code
    Settings → Administration → Sharing → Allow users on this server to send shares to other servers

    Danke für das Detail. hat bei mir aber auch nix genützt - es scheint wirklich am PHP-FPM zu liegen.

    Einmal editiert, zuletzt von Husky (18. Dezember 2018 um 22:11)