-
Notifications
You must be signed in to change notification settings - Fork 502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manual key verification #768
Comments
Hey |
Note that I don't really appreciate minimization of the issue; this is a core part of any kind of system that performs authenticated encryption, just like SSL would not mean anything without Certificate Authorities. It's not only improvement, I have to disagree on the label. It's a core issue that should have been part of the design from the beginning. The Tutanota servers currently have the ability to MITM anyone using the service without any way for the user to know about it (the UI does not expose anything about what keys are!), which is the same thing as trusting Gmail for NOT reading your emails, you are trusting Tutanota for NOT doing MITM and then reading the emails, and as there's no way for users to actually detect such an MITM attack, it's practically the exact same thing. The big problem here, is that your user base is now used to feel safe with the current user interface, when they are not; and changing the usage flow of your application now, is going to make people confused, and affect terribly the actual safety of users. |
Well, issues are not for "your service is not good and should have been different from the very beginning", it's small, actionable things for us. I'm sorry that I misunderstood your proposal. If you have another one, we could open another issue. |
It is unfortunate that it was not done from the beginning and shows lack of understanding or laxity, but you can still change it now while in Beta. It may scare some users however, it is the ONLY way to do end to end encrypted messaging, else it's not end to end; and thus you are falsely advertising it as end-to-end. There's a lot of people that do this with GPG trustdb, and it is standard. I would save contacts with key/trust information in localStorage and automatically verify those have not been tampered with. Add a button to trust a key, and to save this localStorage copy offline for comparing later if the browser storage is emptied. You can have QR codes similar to Signal for verification of keys on mobile through the device's camera, and same thing for the browser. And an ecoji (https://github.com/keith-turner/Ecoji) encoded representation in the case of non-functional camera. There's still the issue with mixing webapps and cryptography, Tutanota's servers could start shipping a different version of the webapp with a backdoor and undermine security measures in place, I am awaiting for the web standard to include a system to trust some version of a webapp and in the case it changes, you get a notice, and you must approve/deny that. |
Option with local store is no different from adding it to the account, encrypting and putting it to the server (so we still cannot read or change it) or do I miss something? Otherwise on each new login (let's say you don't save session) you would have to go and verify all your contacts. |
Hi charlag, |
I know of no other E2EE communication tool where you can't check the authenticity of your contacts. We're not talking about forcing anyone to verify their contacts. Tuta can still choose to hide that option behind a "more details" button. But not offering such a basic option at all that is so vital for E2EE is very detrimental and perhaps even almost as bad as ignoring Kerckhoffs's principle.
That has not happened to WhatsApp, Signal, Threema and even Telegram, who all allow their users to manually check the cryptographic fingerprints of their contacts. |
The client does not expose key verification to the user, all users of Tutanota must trust Tutanota to not provide forged keys and perform an MITM attack, this defeats the whole security model of Tutanota, rendering end to end encryption useless. To solve this problem, you must ensure users keep a local copy of a verified keys database, and make sure users do maintain that database and verify their public keys through a side channel such as a physical meeting or several other platforms. The current Tutanota solution does not provide any superior security to Gmail as you still trust Tutanota to not spy on their users by performing an MITM attack.
The text was updated successfully, but these errors were encountered: