9 ms·

Open-sourcing Tutanota: Why it was important to us

87 points by winstonschmidt 11y ago

lmb 11y ago
Has anyone tried this? How does it compare to https://www.mailpile.is/ https://www.mailpile.is/?
- newsboard 11y ago
  Indeed, it would be great to have a review of several projects in that space. Open source: - Mailpile (https://www.mailpile.is/ https://www.mailpile.is/) - PEPS (https://github.com/MLstate/PEPS https://github.com/MLstate/PEPS) Proprietary: - Protonmail (https://protonmail.ch/ https://protonmail.ch/)
  - higherpurpose 11y ago
    There's also https://whiteout.io/ https://whiteout.io/ (open source) and https://lavaboom.com/ https://lavaboom.com/ (also open source I think) Tutanota, Whiteout and Lavaboom are also all from Germany, which I find pretty interesting.
    - Arnt 11y ago
      I'm an expat living in Germany. The attitude here is remarkable. There's wide awareness of privacy issues. You know the joke about how to apply for a job at the NSA? Most of the parents at my childrens' school would get that.
- bainsfather 11y ago
  I have tried it out. As a user, it seemed ok, and it is free (pricewise). 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.
- nickpsecurity 11y ago
  Most of them use risky web tech, insecure endpoints, hosting (always risky), or developers/servers under risk of coercion by major nation-states in surveillance game. All untrustworthy. My main post above outlines what it takes to make a strong assurance argument and let's just say there's few that can do it. Their time is also expensive. 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.
  - walterbell 11y ago
    > a disposable, hardened PC 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?
    - nickpsecurity 11y ago
      Security-oriented Live CD's or virtualization tech can be used for any of these except the links between systems (eg guard, diodes). QubesOS lowers its attack surface by using Xen instead of a full Linux distro, albeit with risk in Dom0 & hardware attacks. That they isolate their firewall and such is a good thing. Linux or FreeBSD, more mature but larger attack surface, should include full usage of any hardening guides, software protections (eg Softbound, Control Pointer Integrity), mandatory access controls (eg SELinux, SMACK), device protection (eg IOMMU or PIO interface), and so on. Whatever the most paranoid people use basically and do this in any applicable parts of QubesOS as well. You just want these systems hardened from attack as much as possible along with ease of detection and easy recovery. The disposable part means exactly what it says: the Internet-connected computer is the target and filter of the most risky functionality. It will be toast at some point, maybe often. So, use a throwaway device for it.
brongondwana 11y ago
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.
- masida 11y ago
  You've forgotten to include the plug for FastMail. And maybe you should include the fact that you work for FastMail (it's not that you're hiding it, it's in your profile, but it's nice to mention in the text if you're working for the competitor). 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.
hannob 11y ago
There recently was a post about Tutanota on Full Disclosure: http://seclists.org/fulldisclosure/2015/Jun/58 http://seclists.org/fulldisclosure/2015/Jun/58 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.
- winstonschmidt 11y ago
  They commented on this on Reddit: http://www.reddit.com/r/fulldisclosure/comments/3anfjk/tutanota_encrypted_email_service_malleable/ 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."
Numberwang 11y ago
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.
- alfiedotwtf 11y ago
  FastMail isn't based in the US (we are in Melbourne, Australia). 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/ For those who will point out about the new Australian data retention laws: http://blog.fastmail.com/2015/04/09/fastmail-is-not-required-to-implement-the-australian-metadata-retention-laws/
  - Numberwang 11y ago
    Thank you for a comprehensive answer. Another final question if you find the time. Do you have any Americans on your team?
    - brongondwana 11y ago
      Not directly, though we collaborate with Americans on open source projects - one of the main contributers to Cyrus is based at CMU (which is where it came from in the first place) and of course we run plenty of other software developed by people all over the place!
    - vincvinc 11y ago
      Is this an OK question to ask? Should I value firms according to which nationalities they hire?
      - alfiedotwtf 11y ago
        I don't think Numberwang is interested in our developer's nationalities because of any patriotism/racism. I think the question was more about if any of us can be compelled to compromise our user's privacy by either the PATRIOT Act (no), National Security Letters (no), or some other insane US law.
johnchristopher 11y ago
At the end of the day only PGP and IRL discussions offer some kind of privacy.
- nickpsecurity 11y ago
  And Snowden leaks explicitly endorse one and implicitly endorse the other. All I needed for confirmation of what I should use. Anything wanting to be better should build on the good properties of PGP while not possessing the drawbacks.
rossjudson 11y ago
After clicking through the link, I have no idea what "Tutanota" is. Am I supposed to know? Hubris (of course everyone knows what Tutanota is)? Proximity (working with it every day, forgot to give a one-sentence explanation)? Deviousness (reader says, "what the hell is Tutanota? I better click through and find out)?.
- curtis 11y ago
  Here's what I found with a little research. From https://tutanota.com/ https://tutanota.com/: > 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.
  - nickpsecurity 11y ago
    I upvoted him because I could see the problem immediately. There were a lot things said but with little real information for comparison to other things. Had to dig around the site a bit before that. A number of these new offerings have this problem. Compare to this product [1] where I know at a glance exactly what the thing does with enough specifics to begin mental comparisons and know what its likely strengths/weaknesses are. Anyone doing reviews would benefit if the new stuff was that clear at a glance. [1] http://www.symantec.com/desktop-email-encryption/ http://www.symantec.com/desktop-email-encryption/ Note: Not endorsing the above product. It was search result with good description.
- ddrum001 11y ago
  Agreed, that was my reaction as well. I suppose that's the tradeoff of a descriptive name for your project.
mbubb 11y ago
Do one thing and do it well... I like how simple the interface is and how trivial it is to toggle between sending encrypted emails and non-encrypted. 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.
- zanny 11y ago
  Except it isn't using actually encrypted shared key emails, its just sending links to open the email with a shared password on their website. 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.
nickpsecurity 11y ago
Highly secure messaging, email, and Internet services has a long history in military and defense sector with issues well-understood. I mention here [1] the framework I used in high assurance security engineering. The system must be built using strongest engineering techniques with the right requirements. It must run on an endpoint with specialist security engineering techniques resistant to talented hackers. The protocols, parsers, networking stacks, and so on must be carefully implemented to prevent problems. Modern attackers are hitting various firmware, too, so protection is needed from devices. Then, we must be sure the software displayed to us for all this is what's actually running, on non-subverted hardware, and with non-malicious insiders. 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-ma.html#c1102869 https://www.schneier.com/blog/archives/2013/01/essay_on_fbi-...
patrickg_zill 11y ago
From what I could tell, this is only the Web front-end client, not the backend server stack. Therefore, it is not possible to run a full Tutanota server using the open-sourced code. I would love to be wrong about this, but I don't think I am.
DavideNL 11y ago
What bothers me most is that i can't download any e-mail (like normal e-mail clients) to my local machine (on OS X and/or Linux). So, i can't make any backups either and if the Tutanota servers disappear (for whatever reason, maybe beyond their control like Lavabit), i no longer have access to any of my e-mails :s (same problem with their iOS clients, no connection to the servers = no access to any of your e-mails)
angrybits 11y ago
> Why it was important to us So that people would actually know you exist?

lmb 11y ago

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

newsboard 11y ago
Indeed, it would be great to have a review of several projects in that space. Open source: - Mailpile (https://www.mailpile.is/ https://www.mailpile.is/) - PEPS (https://github.com/MLstate/PEPS https://github.com/MLstate/PEPS) Proprietary: - Protonmail (https://protonmail.ch/ https://protonmail.ch/)
- higherpurpose 11y ago
  There's also https://whiteout.io/ https://whiteout.io/ (open source) and https://lavaboom.com/ https://lavaboom.com/ (also open source I think) Tutanota, Whiteout and Lavaboom are also all from Germany, which I find pretty interesting.
  - Arnt 11y ago
    I'm an expat living in Germany. The attitude here is remarkable. There's wide awareness of privacy issues. You know the joke about how to apply for a job at the NSA? Most of the parents at my childrens' school would get that.
bainsfather 11y ago
I have tried it out. As a user, it seemed ok, and it is free (pricewise). 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.
nickpsecurity 11y ago
Most of them use risky web tech, insecure endpoints, hosting (always risky), or developers/servers under risk of coercion by major nation-states in surveillance game. All untrustworthy. My main post above outlines what it takes to make a strong assurance argument and let's just say there's few that can do it. Their time is also expensive. 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.
- walterbell 11y ago
  > a disposable, hardened PC 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?
  - nickpsecurity 11y ago
    Security-oriented Live CD's or virtualization tech can be used for any of these except the links between systems (eg guard, diodes). QubesOS lowers its attack surface by using Xen instead of a full Linux distro, albeit with risk in Dom0 & hardware attacks. That they isolate their firewall and such is a good thing. Linux or FreeBSD, more mature but larger attack surface, should include full usage of any hardening guides, software protections (eg Softbound, Control Pointer Integrity), mandatory access controls (eg SELinux, SMACK), device protection (eg IOMMU or PIO interface), and so on. Whatever the most paranoid people use basically and do this in any applicable parts of QubesOS as well. You just want these systems hardened from attack as much as possible along with ease of detection and easy recovery. The disposable part means exactly what it says: the Internet-connected computer is the target and filter of the most risky functionality. It will be toast at some point, maybe often. So, use a throwaway device for it.

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.

masida 11y ago
You've forgotten to include the plug for FastMail. And maybe you should include the fact that you work for FastMail (it's not that you're hiding it, it's in your profile, but it's nice to mention in the text if you're working for the competitor). 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.

hannob 11y ago

There recently was a post about Tutanota on Full Disclosure: http://seclists.org/fulldisclosure/2015/Jun/58 http://seclists.org/fulldisclosure/2015/Jun/58 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.

winstonschmidt 11y ago
They commented on this on Reddit: http://www.reddit.com/r/fulldisclosure/comments/3anfjk/tutanota_encrypted_email_service_malleable/ 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."

Numberwang 11y ago

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.

alfiedotwtf 11y ago
FastMail isn't based in the US (we are in Melbourne, Australia). 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/ For those who will point out about the new Australian data retention laws: http://blog.fastmail.com/2015/04/09/fastmail-is-not-required-to-implement-the-australian-metadata-retention-laws/
- Numberwang 11y ago
  Thank you for a comprehensive answer. Another final question if you find the time. Do you have any Americans on your team?
  - brongondwana 11y ago
    Not directly, though we collaborate with Americans on open source projects - one of the main contributers to Cyrus is based at CMU (which is where it came from in the first place) and of course we run plenty of other software developed by people all over the place!
  - vincvinc 11y ago
    Is this an OK question to ask? Should I value firms according to which nationalities they hire?
    - alfiedotwtf 11y ago
      I don't think Numberwang is interested in our developer's nationalities because of any patriotism/racism. I think the question was more about if any of us can be compelled to compromise our user's privacy by either the PATRIOT Act (no), National Security Letters (no), or some other insane US law.

johnchristopher 11y ago

At the end of the day only PGP and IRL discussions offer some kind of privacy.

nickpsecurity 11y ago
And Snowden leaks explicitly endorse one and implicitly endorse the other. All I needed for confirmation of what I should use. Anything wanting to be better should build on the good properties of PGP while not possessing the drawbacks.

rossjudson 11y ago

After clicking through the link, I have no idea what "Tutanota" is. Am I supposed to know? Hubris (of course everyone knows what Tutanota is)? Proximity (working with it every day, forgot to give a one-sentence explanation)? Deviousness (reader says, "what the hell is Tutanota? I better click through and find out)?.

curtis 11y ago
Here's what I found with a little research. From https://tutanota.com/ https://tutanota.com/: > 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.
- nickpsecurity 11y ago
  I upvoted him because I could see the problem immediately. There were a lot things said but with little real information for comparison to other things. Had to dig around the site a bit before that. A number of these new offerings have this problem. Compare to this product [1] where I know at a glance exactly what the thing does with enough specifics to begin mental comparisons and know what its likely strengths/weaknesses are. Anyone doing reviews would benefit if the new stuff was that clear at a glance. [1] http://www.symantec.com/desktop-email-encryption/ http://www.symantec.com/desktop-email-encryption/ Note: Not endorsing the above product. It was search result with good description.
ddrum001 11y ago
Agreed, that was my reaction as well. I suppose that's the tradeoff of a descriptive name for your project.

mbubb 11y ago

Do one thing and do it well... I like how simple the interface is and how trivial it is to toggle between sending encrypted emails and non-encrypted. 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.

zanny 11y ago
Except it isn't using actually encrypted shared key emails, its just sending links to open the email with a shared password on their website. 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.

nickpsecurity 11y ago

Highly secure messaging, email, and Internet services has a long history in military and defense sector with issues well-understood. I mention here [1] the framework I used in high assurance security engineering. The system must be built using strongest engineering techniques with the right requirements. It must run on an endpoint with specialist security engineering techniques resistant to talented hackers. The protocols, parsers, networking stacks, and so on must be carefully implemented to prevent problems. Modern attackers are hitting various firmware, too, so protection is needed from devices. Then, we must be sure the software displayed to us for all this is what's actually running, on non-subverted hardware, and with non-malicious insiders. 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-ma.html#c1102869 https://www.schneier.com/blog/archives/2013/01/essay_on_fbi-...

patrickg_zill 11y ago

From what I could tell, this is only the Web front-end client, not the backend server stack. Therefore, it is not possible to run a full Tutanota server using the open-sourced code. I would love to be wrong about this, but I don't think I am.

DavideNL 11y ago

What bothers me most is that i can't download any e-mail (like normal e-mail clients) to my local machine (on OS X and/or Linux). So, i can't make any backups either and if the Tutanota servers disappear (for whatever reason, maybe beyond their control like Lavabit), i no longer have access to any of my e-mails :s (same problem with their iOS clients, no connection to the servers = no access to any of your e-mails)

angrybits 11y ago

> Why it was important to us So that people would actually know you exist?