by winstonschmidt on 6/27/15, 10:26 AM with 63 comments
by hannob on 6/27/15, 12:49 PM
What I find even more worrying than the issue itself is the reaction. It indicates that the developers lack basic crypto skills and that this service was never reviewed by anyone with crypto knowledge.
by rossjudson on 6/27/15, 3:56 PM
by lmb on 6/27/15, 11:35 AM
by mbubb on 6/27/15, 4:09 PM
Great move opensourcing this. I respect the devs stated ethos and reasons for doing this. Hopefully this project will benefit from 'Linus' Law' and will get help to address the sec issues noted in the full disclosure.
I would like to be able to integrate this with something like keybase - but where i hold the private key (which you can do with keybase but it is not the default).
An interesting project and seemingly moving in the right direction.
by DavideNL on 6/27/15, 8:19 PM
(same problem with their iOS clients, no connection to the servers = no access to any of your e-mails)
by brongondwana on 6/27/15, 11:59 AM
Which means that if the user connects to a wifi connection that you control, you can trivially inject something which will cause the browser to make a http connection to www.tutanota.com and leak the cookie.
There's more to security than encryption and open source code. #include plug for FastMail - we know what we're doing.
We don't do the end-to-end encryption, because pre-agreeing to a high security password is nearly as much work as setting up PGP - and with PGP you're not trusting that Tutanota are actually running the code that they claim to be running.
Besides which, Tutanota don't actually send an encrypted email, they send a link back to their server where you can read the secure message - which means you're going to need to be online whenever you're reading a tutanota message - with access to their server, and you're going to have to agree on a highly secure password with everyone you correspond with.
I haven't tried unsending an email or revoking a password yet... maybe I'll try revoking the password...
WOAH. OK, so I did this:
Account A == brong@tutanota.com, signed up for testing Account B == brong@brong.net, my personal email.
I created a shared password "this is bound to work" on account A and sent myself an email to account B. It came with a link that I clicked, which asked for the shared password, and logged me into the tutanota interface as brong@brong.net I guess, then I:
1) deleted the contact from my tutanota account to try to revoke the send message.
2) clicked the link from brong@brong.net, which took me to the email.
3) replied from the tutanota interface as brong@brong.net.
4) replied from the tutanota interface to THAT email as brong@brong.net. It asked for a new shared password, because I had removed the old one when I deleted the contact.
5) clicked the new link in my brong@brong.net account. I got an error, because my shared password was now wrong. I entered my password, and I could read BOTH the emails, including the one only sent with the old shared password.
At least the old link is invalid, but any new links shows old email that was sent with a different shared password.
I am left concluding that this is so much snake oil. sigh. I know encrypted email is all the rage these days, but I'm not sure that I would trust a site just because it used the right buzzwords. Two massive security fails in 15 minutes' testing.
by johnchristopher on 6/27/15, 2:48 PM
by nickpsecurity on 6/27/15, 4:56 PM
The whole thing is beyond tricky to the point that no hosted service is rated to high security in any honest way (eg outside hand-waiving arguments). The only proven model has standalone apps (eg PGP, Nexor Sentinel) acting as proxies between trusted mail/messaging apps and untrusted side. Ideally, user-controlled, vetted code handles secrets with untrusted side (eg Internet host) simply a transport or storage layer that has no influence on endpoint or security past availability. The trusted software must also run on strong endpoints that don't run any other risky software. Given target market, that disqualifies most users of email and messaging software in general.
So, about this one. It seems to not meet many of these requirements and its users don't either. That puts it in Low-Medium assurance category where it might still be helpful against regular black hats, snoops, and attackers without 0-days in what their users have. That will necessarily require decent design & implementation. I commend them on having it pen-tested & open-sourced for review to that effect.
Meanwhile, users wanting to increase resistance to High Strength Attackers should use air gapped, hardened NIX boxes with GPG or Markus Ottela's Tinfoil Chat. Snowden leaks showed using GPG correctly, esp with Tor correctly, gave NSA hell. Markus has also improved TFC many times in response to our critiques to the point that many attack vectors are impossible, risk is lower in others, and endpoint risks are possibly lower than all solutions if right hardware is used. Still work to be done but he's way ahead of the competition.
Note: I second rossjudson that the site, although with beautiful artwork, should be redesigned so it's clear what the app does without a lot of digging. I've seen competing apps where they were clear on the specifics upfront while still not drowning readers in technical detail. The technical detail was a link or so away if I needed it. Right not, it looks too much like a marketing team's work.
[1] https://www.schneier.com/blog/archives/2013/01/essay_on_fbi-...
by angrybits on 6/28/15, 1:53 AM
So that people would actually know you exist?
by patrickg_zill on 6/27/15, 7:45 PM
by Numberwang on 6/27/15, 1:04 PM
And it's not US based either which is another plus.