Open-sourcing Tutanota: Why it was important to us

Has anyone tried this? How does it compare to https://www.mailpile.is/?

I think this service proves the lack of value of code review or code release in isolation. They give you the option to save your login on a "private computer", which stores a cookie that will be sent over non-encrypted connections.

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.

I figured the "we" after FastMail said that I work here. Quite a lot of our backend source is open too (particularly the Cyrus IMAP server, which makes up the bulk of my work now that I have people with a more dedicated ops role for day-to-day tasks).

We encrypt everything to disk, and everything on the wire that is practical (connecting to other providers still falls back to plaintext if they don't support STARTTLS, because encrypted-only isn't practical yet)

But client connections are ONLY secured now, we don't allow any plaintext channels where you could accidentally send your password.

https://www.fastmail.com/help/technical/ssltlsstarttls.html

So you're stuck trusting us, but only us. The only sane alternative that I can see is to run your own server, on your own hardware, preferably hosted inside your own home for maximum legal protection. Of course, unless you really know your stuff then your data could well be at greater risk from both legal and illegal intercept.

(and that's nice if you're providing it just for yourself - as soon as it's for anyone else, even just family, you become on-call tech support)

Bron.

They commented on this on Reddit: http://www.reddit.com/r/fulldisclosure/comments/3anfjk/tutan...

"This is not a vulnerability in Tutanota. We have built Tutanota with multiple layers of protection for our users. We currently use TLS and DANE to protect authentication and data integrity and (only tunneled) RSA-OAEP and AES-CBC to provide confidentiality. We have always communicated this transparently, it is nothing new. Neither the confidentiality nor the integrity of our users' data has been at risk. However, we know that the implementation is not perfect regarding this detail. That is why we are going to implement the following features as soon as possible: - Signatures/MAC - 2-factor authentication - Algorithms resistant to attacks of quantum computers - Simple verification of downloaded Tutanota apps Regarding the described issue, we know of two possible attacks on AES-CBC. Neither of them is feasible against Tutanota users: - Bit flipping: You need access to the plain text email and you have to be the MITM. - -Plaintexts are available at the sender and recipient only. We use secure TLS algorithms and DANE to protect against MITM. - Padding oracle: There is no padding oracle in Tutanota. Tl;dr There is no known vulnerability in Tutanota. Security is the heart of Tutanota, and we will fix vulnerabilities immediately."

Probably just a personal preference, but I must say this looks a lot better than the Fastmail interface.

And it's not US based either which is another plus.