Tutanota: GPLv3-licensed, end-to-end encrypted email(tutanota.de)
tutanota.de
Tutanota: GPLv3-licensed, end-to-end encrypted email
https://tutanota.de
11 comments
I'd say these things are fixable so far [1].
- Image loading: I'd assume that this is possible to implement, given the current implementation?
- text/plain & multipart mails: I'd expect the same, really. Doesn't sound too bad to build it.
- same for session storage
I agree with all your points, but these are things that are conceptually quite viable, imo. I'd expect these to be valid issues on Github [1] and reasonably easy fixes, no?
1: https://github.com/tutao/tutanota
- Image loading: I'd assume that this is possible to implement, given the current implementation?
- text/plain & multipart mails: I'd expect the same, really. Doesn't sound too bad to build it.
- same for session storage
I agree with all your points, but these are things that are conceptually quite viable, imo. I'd expect these to be valid issues on Github [1] and reasonably easy fixes, no?
1: https://github.com/tutao/tutanota
Yeah, they can be fixed. FWIW, I used their feedback form to mention the automatic image loading privacy leak.
I am one of the founders. Thanks for your feedback. We will fix this early next year!
FWIW, I discovered the image loading problem by using https://emailprivacytester.com/ with a test account. Might be worth testing any such changes that you make there. (I am the author of that website).
I'd be wary about potential lock-in. The service seems to rely on everyone using their product. I'd like to see an end goal where they can communicate with other clients that support PGP or S/MIME.
I do like how their approach avoids ever having an email sent from Tutanota in plain text other than when either the sender or receiver views it. Of course the main issue is the receiver has to jump through hoops if they don't use Tutanota. I imagine most people will not enjoy the hoop jumping.
I do like how their approach avoids ever having an email sent from Tutanota in plain text other than when either the sender or receiver views it. Of course the main issue is the receiver has to jump through hoops if they don't use Tutanota. I imagine most people will not enjoy the hoop jumping.
And no way to access your mail via IMAP or .. any mail client, really.
That's a no-go.
>Can I retrieve my Tutanota emails via IMAP to another email client?
>This is not possible as we could not guarantee end-to-end encryption for your data. [1]
1: https://tutanota.de/#!faq
>Can I retrieve my Tutanota emails via IMAP to another email client?
>This is not possible as we could not guarantee end-to-end encryption for your data. [1]
1: https://tutanota.de/#!faq
Well, it is possible. They'd need to write an IMAP proxy which can run on the end users machine which sits inbetween the client and the server and handles the encryption/decryption transparently.
The statements about german law are wrong or at least very misleading, and that might be important here.
Mail Providers of a specific size here are obliged to implement Lawful Interception interfaces. It is quite obvious that in the current climate, there is no guarantee at all that those won't be used by the german intelligence and then transported to the NSA.
Note also that their source-link in that paragraph is not working.
However, the situation might actually work. If they have a true zero knowledge system, it could indeed be very hard in Germany to force them to produce additional data, and what they can't have they can't deliver. That is however not as clear-cut as they make it look like.
That is comparable to the Vorratsdatenspeicherung, ISPs saving the traffic metadata. While the effort to force them to do that failed, all ISPs still save those data - meaning that Germany is not the described data heaven.
Mail Providers of a specific size here are obliged to implement Lawful Interception interfaces. It is quite obvious that in the current climate, there is no guarantee at all that those won't be used by the german intelligence and then transported to the NSA.
Note also that their source-link in that paragraph is not working.
However, the situation might actually work. If they have a true zero knowledge system, it could indeed be very hard in Germany to force them to produce additional data, and what they can't have they can't deliver. That is however not as clear-cut as they make it look like.
That is comparable to the Vorratsdatenspeicherung, ISPs saving the traffic metadata. While the effort to force them to do that failed, all ISPs still save those data - meaning that Germany is not the described data heaven.
I doubt any system designed in such a way that the provider simply can't access the information, could be forced by authorities to provide some kind of backdoor into it, if it's a somewhat lawful country, and not one such as North Korea or whatever. Whether companies can be intimidated into doing it is a whole other story, but legally, I doubt any democratic government should be able to force them to do that.
Hushmail is a similar service, but uses a java applet for the client side crypto. It's my understanding that they have been legally compelled at least once to deliver a backdoored applet to the client in order to access the clear text email. I think they're Canadian. I don't have references to hand, but a Google search should turn some stuff up.
Whilst yu, "doubt any democratic government should be able to force them to do that", I on the other hand suspect that most (if not all) democratic governments have ways of doing exactly this.
Whilst yu, "doubt any democratic government should be able to force them to do that", I on the other hand suspect that most (if not all) democratic governments have ways of doing exactly this.
Except those two things are mutually exclusive: A provider that can put a backdoor in can access the data, they're just choosing not to right now. Relevant example:
http://www.daemonology.net/blog/2012-01-19-playing-chicken-w...
http://www.daemonology.net/blog/2012-01-19-playing-chicken-w...
Here's an example of that for PrivateSky:
http://www.ibtimes.co.uk/gchq-forced-privatesky-secure-email...
PrivateSky looks like it had the same failing as LavaBit in that the service provider actually had access to the decryption key for your email. So encryption in these services was vulnerable to a court order imposed on the service provider to use or share the key.
I'm not saying Tutanota don't have an issue like this but their main selling point appears to be that this isn't the case.
I'm not saying Tutanota don't have an issue like this but their main selling point appears to be that this isn't the case.
Looks like they have a true zero knowledge system, up to the point when they have to implement logging of the password on the client side, and transmitting it to the server. At that point, if I understand the system, they have access to everything.
I don't see much point in this, as long as you can't host your own mail servers (you can host your own "server" in order to have somewhere to get the client from -- which is a step in the right direction -- but as I understand it, you can't use this as a webmail front-end for your own server(s)).
I don't see much point in this, as long as you can't host your own mail servers (you can host your own "server" in order to have somewhere to get the client from -- which is a step in the right direction -- but as I understand it, you can't use this as a webmail front-end for your own server(s)).
Just with regards to the password being transmitted to the server. A quick look at the source code shows a bunch of crypto files. They could, and probably are, encrypting client side and just comparing the cypher text. Someone need to do a bit more digging to verify that.
From the FAQ:
> Your private key is encrypted with your password and then stored on our servers in encrypted form so that only you have access to it. In this design your login password receives the status of the private key. Your password is salted and hashed on your device before being transmitted to Tutanota. With this method we guarantee an integrated confidentiality and we allow you to access and decrypt your emails from desktops and mobile devices instantly.
And:
> Your private and your public keys are generated locally within your browser upon registration. Your private key is encrypted with your password. This way your login password receives the status of the private key. The key is encrypted so strong that only you can use the key for encrypting and decrypting data. This is why a strong password is essential. An automatic password check on the client makes sure that you use a strong password. Your password is never transmitted to the server in plain text. It is salted and then hashed with bcrypt locally on your device so that neither the server nor we have access to your password. We can not reset your password. With this innovative design you can access your encrypted inbox from any device (desktop, mobile) easily.
I've not looked at their "automatic password check", but generally passwords such as "Password2014" are considered secure (Three character groups, long password...).
At any rate, if you host your own client, and one can turn off loading of images and other in-line resources -- this looks better than most "secure web mail" clients I've heard of.
But if you allow them to host the client, I don't see how they can't just change the js to log your password. And they only have to do it once, because they then have access to your private key (they store a copy, and only need your password for access).
> Your private key is encrypted with your password and then stored on our servers in encrypted form so that only you have access to it. In this design your login password receives the status of the private key. Your password is salted and hashed on your device before being transmitted to Tutanota. With this method we guarantee an integrated confidentiality and we allow you to access and decrypt your emails from desktops and mobile devices instantly.
And:
> Your private and your public keys are generated locally within your browser upon registration. Your private key is encrypted with your password. This way your login password receives the status of the private key. The key is encrypted so strong that only you can use the key for encrypting and decrypting data. This is why a strong password is essential. An automatic password check on the client makes sure that you use a strong password. Your password is never transmitted to the server in plain text. It is salted and then hashed with bcrypt locally on your device so that neither the server nor we have access to your password. We can not reset your password. With this innovative design you can access your encrypted inbox from any device (desktop, mobile) easily.
I've not looked at their "automatic password check", but generally passwords such as "Password2014" are considered secure (Three character groups, long password...).
At any rate, if you host your own client, and one can turn off loading of images and other in-line resources -- this looks better than most "secure web mail" clients I've heard of.
But if you allow them to host the client, I don't see how they can't just change the js to log your password. And they only have to do it once, because they then have access to your private key (they store a copy, and only need your password for access).
I am one of the founders, thanks for your discussion. We only load the app into your browser cache upon an update of which the app notifies you. However, we are very aware of the challenges that come along with making browser-based encryption secure. We are looking into ways how to easily verify that the JS executed in the browser matches the published open source code on Github. If you have any recommendations here, let us know!
As long as it is only a client-side app, why not refactor it so it can be hosted directly from github? What you're saying is that users can a) verify a release and host it themselves, b) trust you to serve up good code, c) trust the code you release on github. In b) they trust you're not complying with demands from a covert or overt agency, in c) they're trusting that you are not publishing subtly subverted code, or that github is complying with demands from a covert or overt agency (and in a) they're trusting that their host/colo isn't complying with demands from some agency.
In all a), b) and c) users are also trusting the transport layer, which in general means trusting the CA systems -- which of course means that the whole thing is moot -- the system is hopelessly insecure.
At least with a) you can host the client inside the firewall/security boundary -- and so a) can be as secure as any other solution.
It'd still be a lot more interesting if you at least published an API, so that other's could implement and run their own server (network) -- and not need to rely on a single company for access to their data.
In all a), b) and c) users are also trusting the transport layer, which in general means trusting the CA systems -- which of course means that the whole thing is moot -- the system is hopelessly insecure.
At least with a) you can host the client inside the firewall/security boundary -- and so a) can be as secure as any other solution.
It'd still be a lot more interesting if you at least published an API, so that other's could implement and run their own server (network) -- and not need to rely on a single company for access to their data.
Thanks for your feedback! Hosting directly from github might be a good idea for the ones that regard github as a trusted third party. However, github would gain the possibility to manipulate the code to gain access to your accounts...
We plan to create an API and already started brainstorming on it: https://github.com/intermail/api/wiki
Regarding trusting the CA systems: We use DANE to secure your connection to our servers.
We plan to create an API and already started brainstorming on it: https://github.com/intermail/api/wiki
Regarding trusting the CA systems: We use DANE to secure your connection to our servers.
I've just signed up for this. It looks like exactly what we want from 'secure' email:
(0) you can send unencrypted email just like any other webmail service.
PLUS
(1) end-to-end encrypted if sender&receiver use tutanova.
(2) if receiver does not use tutanova, you can still send them encrypted email if you want to: they get an email saying - 'you have an encrypted mail, click this link to view it' - on clicking the link, they decrypt the mail by entering a pre-agreed password.
(3) it is free. they seem to be making money from the 'enhanced features' in their 'Outlook Addin' package.
(0) you can send unencrypted email just like any other webmail service.
PLUS
(1) end-to-end encrypted if sender&receiver use tutanova.
(2) if receiver does not use tutanova, you can still send them encrypted email if you want to: they get an email saying - 'you have an encrypted mail, click this link to view it' - on clicking the link, they decrypt the mail by entering a pre-agreed password.
(3) it is free. they seem to be making money from the 'enhanced features' in their 'Outlook Addin' package.
I don't know, it's missing (4) "Host your own (encrypted or not) email" ?
Even GMail could launch end-to-end encrypted email if they wanted to do so for all GMail users. They own the entire infrastructure end-to-end; that's not the hard part.
The hard part is encrypting email for anyone -- even if they don't use your service.
The hard part is encrypting email for anyone -- even if they don't use your service.
Well the hardest part is to persuade most users that end to end encryption is something they actually want.
If GMail would launch an integration with PGP (or similar), call it "Secure GMail - now extra private" or something and start to refer to unencrypted Mail as "unsafe", "untrusted" or something like this much would have been won.
If GMail would launch an integration with PGP (or similar), call it "Secure GMail - now extra private" or something and start to refer to unencrypted Mail as "unsafe", "untrusted" or something like this much would have been won.
The problem with GMail launching browser-encrypted email is that you have two groups of people:
(a) People that don't care about encryption. Unlikely to get any signifacant amount of adoption. (b) People who do. This group of people know that browser-based encryption can't be done in a trusted manner, hence, won't want to use such a product.
(a) People that don't care about encryption. Unlikely to get any signifacant amount of adoption. (b) People who do. This group of people know that browser-based encryption can't be done in a trusted manner, hence, won't want to use such a product.
Luckily Google's thought of that. They're working on an extension: https://code.google.com/p/end-to-end/
Don't use web mail for secure messaging.
I'd like to send email messages to people without them being routinely read, stored and indexed by my govt, other govts, the hosting company, etc. Naively, this sounds simple enough to do, and you'd imagine that everyone would want&use such a system.
How to I persuade other non-technical people to use something that is moderately secure? Tutanota seems like something I might be able to persuade people to use - 'hey, sign up for this, it is free, it is just like your current webmail plus if we both use it, our mail is encrypted.' That is an improvement on what they currently use, no?
Do you know of any 'good' (or just 'good enough' (or even just 'better')) options?
How to I persuade other non-technical people to use something that is moderately secure? Tutanota seems like something I might be able to persuade people to use - 'hey, sign up for this, it is free, it is just like your current webmail plus if we both use it, our mail is encrypted.' That is an improvement on what they currently use, no?
Do you know of any 'good' (or just 'good enough' (or even just 'better')) options?
Wow! This is new "encrypted email" service is just like good old encrypted email (eg: GPG), but with user lock-in!
When reading these things you can save a lot of time by just skimming the front page to see what standard protocols they implement. In the case of this thing time was saved...
I don't know what people think when they put their code under GPL (especially v3) when they want to make a better version of an already open standard.
One reason why tcp ip was so successful was that everybody could copy the implementation from BSD into their product.
One reason why tcp ip was so successful was that everybody could copy the implementation from BSD into their product.
Probably because they want people to use their own systems and apps.
I'm waiting for someone respected in the crypto circles reviewing their crypto soundness before even considering using this.
Being GPL is a good point but it doesn't mean they don't have a fatal flaw in their code.
I wish I had the skills to review the crypto I use.
Being GPL is a good point but it doesn't mean they don't have a fatal flaw in their code.
I wish I had the skills to review the crypto I use.
It's hosted web mail that does crypto in Javascript. How closely do you expect crypto engineers to look at it?
Don't use web mail for secure messaging.
Don't use web mail for secure messaging.
They say it was "subject to an extensive penetration test by the SySS GmbH", but don't point to any report or even quote the conclusions.
Yes, I love the service, someone respected looking into the crypto would be fantastic!
Not a viable webmail client for anyone who expects privacy.
[edit] The email that it sends to external addresses does not have a text/plain part, only html
[edit] Stores your email address in session storage and then pre-fills next time you log in. Does not let you opt in or out and doesn't warn you that this will happen. Unsuitable for a "public" machine.
[edit] Nice, they support DANE. When I email a Tutanota user, or a Tutanota user emails me (@grepular.com), SMTP is forced to use SSL or fail, and the certificate is forced to verify with the fingerprint published in our DNSSEC secured DNS zones. No SMTP MITM's here.