Beiträge von markus147

Stelle deine Frage öffentlich an die Threema-Forum-Community - über 4.800 Mitglieder helfen dir weiter. > Frage stellen <

    Signal aktualisiert das Protokoll um sich gegen Quantencomputer abzusichern: https://signal.org/blog/pqxdh/

    Bin gespannt, ob Signal jetzt auch die Empfehlung von Kuketz verliert bis das neue Protokoll von jemand anderem auditiert wurde.

    Interessanterweise wurde die Matrix angepasst und Threema wird wieder empfohlen. Dabei hatte ich nicht gelesen, dass er Threema wegen des Sicherheitsbeweises wieder vertraut. Oder habe ich was übersehen? Bei Signal steht aber noch nichts zum neuen Protokoll da.

    Hallo M-Punkt,

    mir sind das noch etwas zu wenige Infos. Was meinst du mit Konsole. Meinst du ein Linux-Terminal oder eine Powershell oder was genau ist bei dir eine Konsole? Ich wäre dazu in der Lage, habe aber aktuell kaum bis gar keine Zeit. Ich weiß auch gar nicht in welcher Programmiersprache oder Scriptsprache ihr arbeitet. Deswegen beschreibe ich nur ganz kurz und grob, was zu tun wäre. :

    1. Ihr müsst irgendeine Script- oder Programmiersprache wählen

    2. Macht euch damit vertraue, wie man in der jeweiligen Sprache Requests (POST und GET, manchmal auch DELETE oder PUT) benutzt.
    3. Bildet einen Request nach dem Muster der API-Doku und fügt zusätzlich ein Header-Field ein. Gebt dem den Namen X-Api-Key und als Value für diesen Namen gebt ihr deinen API-Key ein

    4. Wenn ihr das Toll nun startet sollte ein entsprechender Request zurück kommen.

    Hallo

    Ich nutze die Work-API nicht weiter, aber laut Doku muss dafür ein Header gesetzt werden. Das heißt, du kannst die URL nicht einfach in deinen Browser kopieren, sondern musst das mit einem Script oder anderem Tool abfragen.
    In der Doku steht dazu folgendes API-Doku :

    Header parameter name:X-Api-Key. Daraus lese ich, dass du einen Header mit dem Namen X-Api-Key in deine Anfrage (über Script oder Tool möglich) einsetzen musst. Als Wert dafür muss der Key rein. Dann sollte der Aufruf passen.

    Ich will nicht ausschliessen, dass es keine Lösung gibt, aber ich wüsste nicht wie das gehen soll. Wenn nicht du das Passwort hast, dann muss es der Server haben. Und das ist naheliegendermassen inakzeptabel. Vielmehr ist es wohl ein Gewohnheitsproblem: Würde man nicht davon ausgehen, dass man den Zugang über Email oder Telefonnummer wiederherstellen kann, so wie quasi überall üblich (und absolut grenzwertig - wenn das Passwort zum Email-Account abhanden kommt, dann gute Nacht), dann wäre klar, dass man sich Passwörter gut merken (oder eine Merkhilfe verwenden) muss.

    Ich glaube, dass ist eine Art "Henne-Ei-Problem"

    Was ich mir noch vorstellen könnte, ist eine Passworthinweis, der dann gespeichert wird. Der sollte aber nicht das Passwort selbst enthalten. Aber das kann man ja prüfen. Der Hinweis könnte dann auf den ThreemaSafe geladen werden.

    Am Ende ruft der Nutzer beim Umzug auf ein neues Handy die ID vom Safe ab und erhält den Passworthinweis, wenn er x mal das falsche Passwort eingegeben hat.

    Allerdings habe ich keine Idee, wie er auf ThreemaSafe gespeichert werden müsste, dass er nicht von jedem gelesen werden. Am Ende müsste ja die App diesen Hinweis einblenden. Wenn der verschlüsselt ist, braucht es dafür wieder einen Schlüssel und irgendwo muss die App den ja haben.

    Nein, so meinte ich das nicht.
    Ich gehe davon aus dass dieses TextSample im Prinzip via Threema Gateway genutzt wird. Das heißt, die nutzen ja auch das SDK von Threema. Und ich wüsste nicht, in welchem SDK vom Threema Gateway die gesendeten Orte entschlüsselt werden können. Soweit ich weiß, können alle SDK 's von Threema das Ver- bzw. Entschlüsseln von Text oder Bildern oder Files. Aber nicht von gesendeten Orten.

    Das Hantieren mit Datenbackups ist bei Threema schon immer hakelig und problematisch. In den seltensten von mir begleiteten Fällen hat ein Geräteumzug bisher wirklich reibungslos geklappt (Backups > 2GB sind für mich mittlerweile die Regel). Im Fall iPhone <-> Android geht es erst gar nicht. Es ist für mich als jemand der die Installation mehrerer Familienmitglieder betreut jedes mal mit großem Zeit- und Nervenaufwand verbunden. Es wird wahrscheinlich auch der Grund sein, dass ich Threema bald abschreibe. Mir egal, wer dann was mitliest. Ich habe keine Zeit für diese Fummelei. Riesige Zip Dateien von Telefon zu Telefon schieben ist eine sehr schlechte Lösung.

    Nur mal aus Neugier: Wie sollte denn deiner Meinung nach, der Geräteumzug mit Threema funktionieren ?

    Hallo

    ich baue gerade an einer Anwendung, die mit dem Threema-Gateway agiert. Dabei kann es passieren, dass Kunden an das Gateway eine Sprachnachricht senden, die ich dann automatisiert entschlüsseln will. Bei Text oder Files klappt das ohne Probleme, nur reine Sprachnachrichten an das Gateway klappen nicht. Ich benutzte das Java-SDK.
    Weiß jemand, ob es dafür schon eine neuere Version des Java-SDK's gibt oder müsste ich das selbst programmieren?

    Weiterhin wollte ich fragen, ob es ein "Auto-Detect"-Modus gibt? Ich weiß ja im Leben nie, ob man mir einen Text oder eine Datei (Bilder, allgemeine Dateien) schickt. Ich mache das aktuell so, dass ich die Nachricht als Text entschlüssel und, wenn eine Exception kommt, ich das gleiche als File versuche. Aber gibt es da vielleicht eine Auto-Detect ? Denn die Nachrichten haben ja verschiedene Message-Types?

    Guten Morgen zusammen,

    ich habe seit ein paar Tagen ein Samsung S7 mit Lineage 15 bestückt und musste feststellen, dass, nachdem sämtliche Einstellungen korrekt gesetzt sind, Signal problemlos pusht, während Threema nur mit Polling funktioniert. Wie gesagt: Beide Apps sind in Sachen Energieeinstellungen/Akkuoptimierungen identisch konfiguriert.

    Das ist nun kein Weltuntergang, da durch das Polling spätestens alle 15 Min. Nachrichten ankommen. Es wundert mich aber doch, warum Signal das ohne Google-Services kann und Threema nicht.

    Threema funktioniert auch ohne Google-Services. Das benutzt du gerade mit dem Polling. Alternativ benutzt es FCM von Google

    Das Problem ist und bleibt die Sicherheit. Wie ich schon mal hier erwähnt hatte, kann man bei einer zurückgezogenen Nachricht nie garantieren, dass die Nachricht auch wirklich nicht mehr beim Gegenüber existiert. Daran ändert auch eine Nachricht mit "wurde zurückgezogen" nichts.

    Mal ein Beispiel: Nehmen wir an, ich sende dir eine Nachricht und habe mich vertan. Also rufe ich die Nachricht zurück. Was muss denn passieren, damit die Nachricht auch wirklich nicht mehr bei dir existiert ?

    1. Zuerst müsste die App eine Steuernachricht senden, die deine App empfängt. Damit aber nicht irgendjemand, diese Nachricht sendet, muss diese am besten vom Sender signiert werden. Sonst könnte man jede Nachricht auf einem beliebigen Endgerät löschen.

    2. Der Empfänger müsste die Steuernachricht validieren und dann die Nachricht aus der Datenbank (DB) holen und die Nachricht entweder als gelöscht markieren (Damit könnte ein Angreifer sie aber noch aus der DB lesen) oder die Nachricht komplett löschen und einen Vermerk setzten, dass die Nachricht gelöscht wurde.

    3. Es müsste ein Trigger in der App ausgelöst werden, die merkt, dass die Datenbank verändert wurde und die Nachricht auch aus dem Chatbereich "löschen" (Normalerweise wird die DB einfach nur gelesen. Ich weiß auch nicht wie hier die DB-Struktur aussieht, aber vermutlich existieren hier Querverweise zu zitierten Chats etc. Diese müssen ebenfalls rückgängig gemacht werden)

    Wie du siehst, ist das viel Aufwand. Und die Sicherheit das du die Nachricht nicht trotzdem gelesen hast ist gleich null. Denn was passiert, wenn du eine Nachricht bekommst, den Flugmodus einschaltest und ich dann die Nachricht zurückrufe ? Dann kannst du die Nachricht lesen.
    Weiterhin besteht das Problem auch in der DB. Wer sagt mir denn, dass zwischen dem Eingang der Nachricht und dem Zurückrufen nicht ein Backup von deinem Handy stattfand und die Nachricht so auch wieder gelesen werden kann. Es kann außerdem nicht garantiert werden, wenn du die Nachricht löschst, dass sie wirklich aus dem Speicher des Handys gelöscht wurde.

    Außerdem sind hier viele Sonderfälle: Was passiert, wenn ein Backup der Daten stattfand, danach die Nachricht "gelöscht" wurde und du das Backup einspielst. Woher soll Threema da wissen, dass eine Nachricht bereits zurückgezogen wurde ? Das würde wenn nur über den Server gehen. Damit werden unnötig Metadaten gesammelt.

    So oder so, ist dieses Feature nicht sinnvoll. Du kannst stattdessen auch vor dem Senden noch mal die Nachricht durchlesen und den Sender kontrollieren.

    Analogie: Wenn du eine Mail an einen falschen Absender schreibst, dann kann dir auch niemand garantieren, dass die Nachricht gelöscht wurde, bevor der Empfänger sie gelesen hat.

    TLSv1.2 kann man ab Android API 16 (4.1) explizit aktivieren, allerdings ist Android ziemlich heterogen, weil die Handy-Hersteller oft essentielle Funktionen des Betriebssystems wie den HTTP-Client durch eigene Implementierungen ersetzen.

    Deshalb kann man nicht sagen, ob TLSv1.2 wirklich auf jedem Handy mit Android 4.1 und höher funktioniert.

    Auf jeden Fall kann man sagen, dass ab Januar 2020 mit Android 4.0 keine HTTPS-Verbindungen zu Threema mehr möglich sind.

    Ab Android 4.1 ist die Wahrscheinlichkeit gross, dass es keine Probleme gibt.

    Ob eine Benachrichtigung kommt oder nicht, kann ich zwar nicht sagen, aber ich bezweifle es, denn der Entwickler kann zwar ein Protokoll verlangen, ob es dann auch genutzt wird, merkt man erst, wenn die Verbindung nicht zustande kommt.

    Vielen Dank für die Antwort. Ich stimme dir da zu.
    Bei der Benachrichtigung bin ich mir unsicher. Möglich wäre es, wenn es bereits einen Server von Threema gibt, die diese Funktion (TLS 1.2) testet. Dann könnte die App versuchen, sich damit zu verbinden. Wenn es scheitert, dann wird bis Januar ein Fallback auf den alten Server gezeigt und eine Warnung gezeigt.

    Aber ich glaube, es wäre am besten, wenn hier Threema was dazu sagen könnte.