Hintergrundaktvitität hätte ich konkretisieren sollen: Bei Apple war es AFAIK problematisch, Sockets im Hintergrund offen zu lassen und das wird für den Web Client benötigt.
Threema Web- Client (Beta)
Stelle deine Frage öffentlich an die Threema-Forum-Community - über 4.600 Mitglieder helfen dir weiter. > Frage stellen <
-
-
Haben die Beta-Tester eigentlich irgendeine Info, wann es public gehen soll?
-
Selbst wenn sie es hätten, dürften sie es nicht sagen.
-
Habe aus streng geheimer Quelle gehört das es Anfang dieses Jahres soweit sein soll: https://threema.ch/de/blog
-
Hallo,
wann kommt den nun der Web-Clint, bekommt man dann auf den Threema Channel bescheid? wenn der da ist.
-
Wenn du News abonniert hast dann ja.
-
Wenn du News abonniert hast dann ja.Super und wie mache ich das, bekomme es nicht hin?, sorry.
-
Du kannst es hier detailliert durchlesen https://threema.ch/de/faq/Threema_Channel
-
Leg einen Kontakt an.
ID *THREEMADem Kontakt schreibt du dann eine Nachricht.
Z.b.Start News
Oder
Start Android
Usw.
(Siehe Bild vom Bär)#comfortablyNumb
-
Threema sollte nichtsdestotrotz auch an einem nativen Desktop-Client arbeiten. Bei einem Web-Client ist die TLS-Verbindung zum Threema-Server die Schwachstelle und irgendwie fühle ich mich nicht ganz wohl damit. Wer sagt schon, dass man beim Aufruf von https://web.threema.ch eben auch die „richtige“ Seite geliefert bekommt? Man-in-the-middle-Attacken wären hier möglich.
Bei einem nativen Desktop-Client muss ich „nur“ dafür sorgen, dass ich den Client 1x richtig heruntergeladen habe. Das ist schon ein großer Vorteil. Außerdem sind native Clients ergonomisch betrachtet meist immer etwas besser als Web-Clients.
Ich will den Web-Client nicht schlecht machen, das ist definitiv eine gute Sache. Trotzdem sollte ein nativer Client das Ziel sein.
-
Und deswegen kannst du dir den Web Client runterladen. Die Entwicklungsarbeit, dann noch einen nativen Client oben drauf zu setzen, wird sich Threema nicht machen.
-
Und deswegen kannst du dir den Web Client runterladen. Die Entwicklungsarbeit, dann noch einen nativen Client oben drauf zu setzen, wird sich Threema nicht machen.Das ist ja schon einmal gut zu hören. Danke für die Info!
-
Wer sagt schon, dass man beim Aufruf von https://web.threema.ch eben auch die „richtige“ Seite geliefert bekommt? Man-in-the-middle-Attacken wären hier möglich.Deswegen ist der Aufruf ja verschlüsselt und mit Zertifikat authentifiziert. Oder woher weißt du, dass sich der Android, iOS oder Dekstopclient mit dem richtigen Server verbindet? Eine MITM-Attacke ist hier genauso möglich/unmöglich.
-
Erschwert die Authentifizierung über den QR-Code MITM-Attacke nicht extrem. Man stellt ja somit sicher, dass man mit dem richtigem Kommuniziert. Eine Attacke wäre zumindest sehr kompliziert.
-
Deswegen ist der Aufruf ja verschlüsselt und mit Zertifikat authentifiziert. Oder woher weißt du, dass sich der Android, iOS oder Dekstopclient mit dem richtigen Server verbindet? Eine MITM-Attacke ist hier genauso möglich/unmöglich.
Das ist so nicht richtig. Mit einer Man-in-the-middle-Attacke könnte die TLS-Verbindung umgangen werden. Deshalb ist es eine kluge Entscheidung, den Webclient zum Download bereitzustellen. So muss man nur sicherstellen, dass eben jener 1x ordnungsgemäß heruntergeladen wurde, anstatt jedes mal wenn man ihn benutzt.
Woher die Clients wissen, dass sie mit dem richtigen Server verbunden sind?
Threema hat das Zertifikat der Server in den Clients „hardgecoded“, eine Man-in-the-middle-Attacke dürfte deshalb zwecklos sein. -
Ich verstehe nicht so recht auf was du hinaus willst. Natürlich sind die Zertifikate im Client. Ebenso überprüft der Browser, ob ein valides Zertifikat vorliegt, wenn der Webclient aufgerufen wird. Und die Zertifikatprüfung muss natürlich sowohl beim Client als auch beim Browser bei jedem Verbindungsaufbau zum Server gemacht werden.
Der einzige Unterschied, den ich erkennen kann, ist, dass man als Angreifer dem Browser ein scheinbar valides Zertifikat unterjubelt. Dagegen gibt es allerdings auch Techniken: https://de.wikipedia.org/wiki/HTTP_Public_Key_Pinning
Vertraut man HTTPS im Browser nicht, dürfte man streng genommen auch kein Webmail, Online-Banking oder Online-Shopping im Browser nutzen.
[hr]
Erschwert die Authentifizierung über den QR-Code MITM-Attacke nicht extrem. Man stellt ja somit sicher, dass man mit dem richtigem Kommuniziert. Eine Attacke wäre zumindest sehr kompliziert.Es geht darum, dass dir ein Angreifer eine gefälschte Webclient-Seite unterjubelt. Dadurch könnte er alle Eingaben abfangen.
-
Es geht einfach darum, das bestmögliche zu tun:
Und es ist definitiv besser, HTTPS nur 1x vertrauen zu müssen, als eben jedes Mal. Selbst HPKP ist kein hundertprozentiger Schutz, auch wenn es einige Verbesserungen mit sich bringt.HTTPS hat einige Schwachstellen und deshalb sollte die Sicherheit nicht darauf basieren. Und ja, streng genommen hast du recht, wenn man Online-Banking oder ähnliche Dinge macht, sollte man eigentlich am besten manuell überprüfen, ob man mit der richtigen Stelle spricht, also das Zertifikat mal angucken.
Das tut in der Praxis vermutlich fast niemand, was aber nicht heißt, dass das dann gut so ist.
-
HTTPS hat einige Schwachstellen und deshalb sollte die Sicherheit nicht darauf basieren.Das ist dann auch der Grund, warum SaltyRTC auch mit kaputtem TLS nicht auseinanderfällt
-
Das ist dann auch der Grund, warum SaltyRTC auch mit kaputtem TLS nicht auseinanderfällt
Jap, tolle Sache! :freuen:
Und da man sich das dann herunterladen kann, muss man nur ein einziges mal (beim Download) auf HTTPS vertrauen. Und selbst dann kann man hoffentlich den Hash checken oder Threema signiert den Download.
-
Können eigentlich auch Sprachnachrichten über den Web-Client angehört werden?
-