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.
Personally, I stay clear from any hosted e-mail services. I don't care if their backend is open source or not. RMS explains all problems with SaaS in his essay "Who does that server really serve?".
It's sad that the current selection of open source e-mail clients is not that great. Especially, for less technically inclined people.
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.
Curious: is that just a personal preference? I still use Google Apps for almost everything, but have a couple domains on Fastmail and have been extremely happy with their service. I have often considered moving more of my business there, and would greatly appreciate a substantive warning if it's warranted.
How do you send encrypted mail with Fast Mail?
How is the following different from how Gmail (for example) does it? https://www.fastmail.com/help/ourservice/security.html
We're probably similar in security to gmail - they're very good as well - most of the big services are. The main comparison at that level is the unpatched server running in the basement of a business somewhere - or indeed the "roll your own" where it gets updated once every few months if the person running it remembers and isn't on holiday at the time... it's nice having a team and always someone on duty for security.
At the risk of sounding too negative, er... well, do you?
I'm a paid FastMail user right now, and after first signing up a couple years ago, I filed my first and only bug against FastMail last month about the inability to use spaces in passwords. (I feel like it should go without saying, but it's painful to have to use symbols instead of spaces on mobile, and even a bit jarring at a real keyboard, and it makes password input prone to typos.)
What I got in response was some handwaving about the problem that amounted to a "REQUEST DENIED". (In truth, I did find that a bit frustrating. The free email service I also use that's notorious for offering no support finds spaces in passwords to be perfectly acceptable, but the one I have a subscription for won't let me? The one whose benefits are frequently touted as including, "Believe us, it's totally worth it. Look how you can talk to a real human being." If the choices are not being able to talk to a human being but not needing to, and being able to talk to one who doesn't accept that there's a problem, much less provide a solution for it, then the former pretty clearly wins out.) But the frustration from that ends up amounting to a minor one wrt the digression that the developer who was responding went on to write:
> Probably later this year we plan to require client specific passwords for all external software. When we do that, we won't allow people to use their login password for IMAP/POP/SMTP/etc clients, you'll have to use a generated one. At that point, the only login place for your password will be the web browser
Okay, so here's how my security setup works now:
Create a very secure password, and then... just use it. Every time. I.e., do not ask Thunderbird to save it, and do not set up a client to receive messages on mobile.
In the proposed new scheme, users will be forced to choose between memorizing whatever unmemorable thing the generator spews out for a non-web client, or enter it one time and set up their clients to save it. Which is no choice at all; the latter is effectively the only one available (see "unmemorable"). What this all means is that your pursuit of trying to make account access more secure actually ends up demanding that it be very un-
The end result is that at some point "later this year", I'm going to have to take the same approach as noinsight and run my own mailserver[1], point my domain away from FastMail, and hope that my request for a refund will be granted due to the conditions changing during the middle of my subscription.
As for the autogenerated password thing. You might have followed that Google are making it more and more difficult to "just use your very secure password everywhere" as well, because they find that it leads to a higher account compromise rate than per-device password or oauth. We also see a higher account compromise rate than we would like, and so we have to design our processes to be robust against human error and phishing.
What we might do for the zero point something percent of users like you is offer a way to re-enable password based login for clients (just like Google do) after you read a warning pointing out the security downsides of not having selective revokability and guarnteed non-password-reuse of device passwords.
Personally, I'd like to see a thorough look at existing and new providers to do a point-by-point analysis of such strengths and weaknesses of each. It's work worth a government grant or something.
> Tutanota automatically encrypts all your data on your device. Your emails as well as your contacts stay private. You can easily communicate with any of your friends end-to-end encrypted. Even subject and attachments are encrypted.
It might have been better to submit a different blog post or web page which might have provided more context. Or the submitter could have left a comment about what Tutanota is to provide the extra context.
Note that I don't really mean to single out this submitter, this seems to be a common problem. It's probably also worth pointing out that posts on official company blogs should not assume that readers of any one blog post are regular readers of the blog.
Edit: As an addendum, I should probably point out that I agree with rossjudson's comment to which I am replying.
[1] http://www.symantec.com/desktop-email-encryption/
Note: Not endorsing the above product. It was search result with good description.
Open source:
- Mailpile (https://www.mailpile.is/)
- PEPS (https://github.com/MLstate/PEPS)
Proprietary:
- Protonmail (https://protonmail.ch/)
and https://lavaboom.com/ (also open source I think)
Tutanota, Whiteout and Lavaboom are also all from Germany, which I find pretty interesting.
My temporary solution is to combine endpoint encryption (eg GPG), MyKolab for address/storage, air gaps, and a guard. The MyKolab account gets me Swiss storage with associated legal protection & lack of clever Google-style snooping. I assume the servers are compromised along with messages. To deal with those threats, people send me either GPG messages or otherwise encrypted files. For protection, I can download them to a disposable, hardened PC; send them through a guard or data diode for reading; use a separate computer for writing and signing with a data diode. This is Markus Ottela's architecture for Tinfoil Chat. His diodes with separate PC's are simpler than my guards with KVM-connected PC's. So I recommend it his way these days.
You can swap out MyKolab for any other service for delivery or storage. You just have to make sure they're totally untrusted, incoming messages can't compromise your keys, and keys/secrets can't leak out. Tricky stuff for any of these developers. TFC already does this. I suggest these people modify its latest incarnation to do email (maybe apply GPG), find any other flaws it has, and improve on docs/distribution. Will get more mileage.
Do you mean a PC booted with a non-persistent OS like Tails or a Linux Live CD?
How would you rate a Qubes VM for this purpose?
Mailpile does not host mail, it is just the front end - you still need an email account elsewhere.
I use runbox.com as my main email provider - not free (pricewise), but is doesn't cost much.
And it's not US based either which is another plus.
For those who will point out that some of our servers are in the US, see:
http://blog.fastmail.com/2014/12/15/security-confidentiality/
http://blog.fastmail.com/2015/04/09/fastmail-is-not-required-to-implement-the-australian-metadata-retention-laws/https://www.fastmail.com/help/ourservice/security.html
Physical location security
Our main servers are located at New York Internet (NYI) in New York City, USA. Their facility is a high security, video monitored location; with backup power, air conditioning, fire systems, 24x7x365 monitoring, and onsite technical support.
The security of fastmail is really the security of end to end TLS with forward security. All good practices but industry standard, no?
Do you encrypt traffic between servers? ie http://www.forbes.com/sites/benkepes/2014/03/20/in-an-attemp...
What differenitates Fastmail sec practices?
Just curious. Are you referring to the classic interface, or our super slick Ajax interface?
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-...
"When the serial cable used to transmit information between two computers is enforced with an RS-232 data diode to funciton in unidirectional fashion, exfiltration of encryption and signing keys without physical access becomes impossible."
Right. Or use a smart-card. I'm not sure it's more sane to trust a typical pc to not have a hw backdoor (eg: intel managment cpu with wlan access -- does need to be enabled in bios. At least that's what Intel says) -- rather than trust a smart-card (idea is to send data to card, get signed/encrypted data back. Keys never leave card).
Interesting idea though.
Similar ideas for a pair of plugins for pidgin:
https://github.com/maqp/tfc-cev
The modules look huge though. Plenty of room for someone to slip in a listening device with burst-capable transmission. I don't think the actual security is much higher than just using a smartcard?
Later we told him OTP wasn't going to get takeup. I described my cascading cipher. That led to his multiple encryption etc version. I told him high assurance crypto NSA uses defeats covert channels with (a) fixed sized transmissions, (b) fixed rate transmissions and (c) not letting errors have a visible effect on that. Goes way back. He changed it to do that.
So, he was clever with the design and has been responsive to updates. Those are just a few I remember. He used Python because it's easy to read. He only has so much time for the project. Other stuff I suggested included converting it to a language like C, Ada, or Pascal for control over memory & extra visibility. Also, using the Dresden Nizza architecture (or MILS architecture) on transport and sending stack to further enforce isolation and secure decomposition. More work to be done but it's a nice executable specification of something that can give NSA hell with low end equipment.
Far as email, that must be a side project he started as a result of some of us suggesting he port GPG or something to the architecture. I'm not familiar with it. I only endorse main chat architecture with encouragement that implementation keeps improving. :)
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.
"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."
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.
I mean, encrypted email is a hard problem because nobody supports it except you, and that means you can never encrypt your emails, but Tutanotas UX of making users view the messages on their site (and the fact you cannot use it with even GPG friendly mail clients) kind of sucks. I'd rather just use OTR XMPP for encrypted private communications. Or my mumble server, which is ironically the best implementation of encrypted chat I can use with other people because I can use certs or passwords at my discretion.
(same problem with their iOS clients, no connection to the servers = no access to any of your e-mails)
So that people would actually know you exist?