6 ms·

Tutonota: An end-to-end encrypted email client and hosted service

52 points by livatlantis 10y ago

Flimm 10y ago
> Tutanota is the end-to-end encrypted mail client that enables you to communicate securely with anyone. Is this promising end-to-end encryption over email even if one of the two parties is not using Tutanota?
- x1798DE 10y ago
  Looks to me like no: https://tutanota.uservoice.com/knowledgebase/articles/470785 https://tutanota.uservoice.com/knowledgebase/articles/470785 There is some voodoo in there about them storing your unencrypted mail encrypted on their server, but from that diagram it looks like it's only end to end between people registered with Tutanota (it looks like they may also allow federation, since they mention "or another service").
  - troublord 10y ago
    Tutanota never stores unencrypted mails on the server. If you send an encrypted mail to an external recipient, the recipient will receive a link to his end-to-end encrypted mailbox. He can open his encrypted mailbox only with the passphrase that you (the sender) shared with him.
    - x1798DE 10y ago
      I would certainly hope that no one stores unencrypted mail on their servers, but that's just a "promise not to look" situation, not an "impossible to look" situation. As for the "encrypted mailbox", what you are describing sounds to me like the decryption is done client-side using javascript (unless the recipient needs to download something in order to decrypt the mail), in which case I would consider that to be essentially insecure anyway, as that is also a "promise not to look". It's the same situation as Protonmail, which I personally consider to be crypto snakeoil.
      - troublord 10y ago
        Just use a local client, if you do not want to trust Tutanota for delivering the code as published on github. You can use apps (iOS and Android) and even compile and install the client locally if you want to. There will also be apps for Windows and MacOS in the future.
        x1798DE 10y ago
        I'm not sure what you mean by a local client. If you are suggesting that even the Tutanova users are decrypting things using browser crypto, that's absurd. I assumed this was all done either with a local client or a browser extension. If you mean that the non Tutanova user should have to install a Tutanova client, I might as well just have them set up PGP. If you mean a local server using the github code, it's a fair enough point - it's more complicated and likely insecure than using PGP, but at least the burden of complexity and security falls on the power user.
    - dingaling 10y ago
      > He can open his encrypted mailbox only with the passphrase that you (the sender) shared with him. Presumably that passphrase would be shared out-of-band to prevent Tutanota peeking, at which point... Why bother sending an e-mail at all?
- deleted 10y ago
  [deleted]
- mr_sturd 10y ago
  If you send an email to someone without Tutanota. They email the recipient with a link to their server. Allowing the recipient to decrypt the email in the browser, using a password agreed on, by the communicating parties.[0] [0]-https://tutanota.uservoice.com/knowledgebase/articles/470795-how-do-i-send-an-encrypted-email-to-an-external-re https://tutanota.uservoice.com/knowledgebase/articles/470795...
  - skrowl 10y ago
    If I'm going to go the route of sharing a password, why wouldn't I just put a .txt or .html file with my email body in a password-protected/encrypted .7z or .zip and just send it with plain old gmail? My buddy doesn't have to change his email provider or click on any special links. In addition to not having forward secrecy (if a 3rd party gets his crypto password, they get ALL of my messages to him), this seems to fail the classic "In order to exchange a secret, first exchange a secret" crypto usability test.
mirimir 10y ago
They nuke accounts created using Tor. That's not very privacy friendly.
- troublord 10y ago
  That is simply not true. We have a very high degree of Tor users. Unfortunately, some spammers also hide behind Tor. That is why we disable accounts that are used for spamming purposes. You can always contact our support if you feel that your account has been disabled without reason. We check every case... :) -- Matthias Founder tutanota.com
  - mirimir 10y ago
    Thanks. That's good to hear :) But I've had it happen more than once, without warning, and without any mail sent. Also, contacting support isn't really a viable option, for new personas with no other email address.
    - troublord 10y ago
      That is true for users without an email address. Don't mind to share your ideas for improving this at https://tutanota.uservoice.com/ https://tutanota.uservoice.com/. We will change this, if there is a better way that provides protection against spammers...
      - mirimir 10y ago
        Thank you. But is spamming through Tor really such a huge problem? I vaguely recall the argument that there wasn't enough bandwidth. And maybe there is now, with faster relays.
        troublord 10y ago
        Unfortunately yes. A single user is not a problem. But if hundreds of users abuse TOR for spamming via Tutanota, this becomes a serious issue. At least for the spam recipients and other users of our service, that might get classified as spammers by the receiving mail servers.
Already__Taken 10y ago
What extra do the encrypted messaging services offer on top of say, forcing a regular mail server to only user tls1.2. Must we all move onto a single provider? I'm just curious why that's not good enough where sysadmins collectively pester whoever they require secure communication with to also have a tls1.2 mailserver. Would that not be job done?
- dsr_ 10y ago
  That would not be end-to-end. Email is a store-and-forward service, so even if you guarantee that every network hop is protected, the message is in cleartext (and thus inspectable, alterable and censorable) on every server.
- stephenr 10y ago
  Forcing TLS for the MTA at each end is about network encryption (i.e. akin to HTTPS) this "solution" is about encrypting the contents of the message envelope, i.e. restricting who can read the contents of the message regardless of how its transferred. As I mentioned elsewhere, it is however yet another non-solution, for the same reason you queried - it's all reliant on a single provider. Real end-to-end encrypted email is when your mail client uses either S/MIME or PGP/GPG to encrypt your message using the recipient's public key(s). In that situation, it doesn't matter what mail service they use, or what network transport the MTA's use - it's readable only by them (well technically only by anyone with the appropriate private key - I'm going to assume people are protecting their keys).
g4k 10y ago
It seems this is browser only. Would be great to have Thunderbird integration.
- troublord 10y ago
  Please vote for the following feature request: https://tutanota.uservoice.com/forums/237921-general/suggestions/7013569-creating-an-add-on-for-an-open-source-mail-client https://tutanota.uservoice.com/forums/237921-general/suggest...
DavideNL 10y ago
Beware, does not support local (encrypted) backups. If their servers disappear for whatever reason (legal issues or hardware problems), you end up with 0 e-mails. Nothing.
stephenr 10y ago
So yet another "end to end encrypted" email "solution", where both ends are controlled by a single vendor. There are already two, count them, TWO, existing, open, well-understood ways to both sign and encrypt email between two parties: PGP, and S/MIME. Currently, the UX around setting up and using each of these tools is.. less than stellar. Now. Just go with me here. What if all the people who keep claiming to have "solved the encryption problem" by locking everyone into their own little silo, instead of doing that, WORKED ON SOLVING THE USABILITY PROBLEMS?
- vox_mollis 10y ago
  PGP is entirely useless if you wish to hide metadata about origin, destination, precise timestamps, etc. Use cases exist in which you need to communicate securely and authenticated, but can NOT leak the above. Some combination of Pond( message inboxes, timestamp randomization ) and Ricochet( authentication, origin/destination obfuscation ) is sorely needed.
  - stephenr 10y ago
    > if you wish to hide metadata about origin, destination, precise timestamps Sounds like email in general is not the transmission medium you want then.
    - wccrawford 10y ago
      But by that same token, it doesn't appear that this is actually "email" either. It's sending messages via the internet, securely, using a custom client. If you send to someone without their client, they end up with a link (via actual email) to the website and have to use a password to view it. I think we're at a point where any long messages sent via the internet are going to be called "email" regardless of the actual transmission process. Especially if they aren't meant to be some kind of real-time chat system, as that is usually called "instant messaging".
      - stephenr 10y ago
steaminghacker 10y ago
how does this compare to protonmail ?
- stephenr 10y ago
  In that it claims to be 'end to end' encryption, but that both 'ends' are from the same vendor, it's exactly the same. So if you use protonmail and your colleague uses this, and you want to have a secure conversation over email, you're each going to be clicking clicking a fuck load of "view this message on <service you don't use>" links.
  - mookerific 10y ago
    At least ProtonMail is working towards full compatibility with the OpenPGP standard, thereby allowing non-Protonmail users to encrypt emails using a standard PGP key - according to their stated roadmap, ProtonMail will eventually allow you to export your keypair and will also allow you to upload keys you've generated outside of their service instead of relying on their service to do the key generation. Tutanota has implemented their own variation of encryption which is not OpenPGP compliant. Their justification for this deviation rests on their desire to be able to encrypt all aspects of communications (metadata, subject, etc) while PGP doesn't not offer this.
muloka 10y ago
Curious why they went with Cordova instead of React Native for their mobile apps. Are there security considerations between each solution that they took into account when deciding?

52 points by livatlantis 10y ago

Flimm 10y ago

> Tutanota is the end-to-end encrypted mail client that enables you to communicate securely with anyone. Is this promising end-to-end encryption over email even if one of the two parties is not using Tutanota?

x1798DE 10y ago
Looks to me like no: https://tutanota.uservoice.com/knowledgebase/articles/470785 https://tutanota.uservoice.com/knowledgebase/articles/470785 There is some voodoo in there about them storing your unencrypted mail encrypted on their server, but from that diagram it looks like it's only end to end between people registered with Tutanota (it looks like they may also allow federation, since they mention "or another service").
- troublord 10y ago
  Tutanota never stores unencrypted mails on the server. If you send an encrypted mail to an external recipient, the recipient will receive a link to his end-to-end encrypted mailbox. He can open his encrypted mailbox only with the passphrase that you (the sender) shared with him.
  - x1798DE 10y ago
    I would certainly hope that no one stores unencrypted mail on their servers, but that's just a "promise not to look" situation, not an "impossible to look" situation. As for the "encrypted mailbox", what you are describing sounds to me like the decryption is done client-side using javascript (unless the recipient needs to download something in order to decrypt the mail), in which case I would consider that to be essentially insecure anyway, as that is also a "promise not to look". It's the same situation as Protonmail, which I personally consider to be crypto snakeoil.
    - troublord 10y ago
      Just use a local client, if you do not want to trust Tutanota for delivering the code as published on github. You can use apps (iOS and Android) and even compile and install the client locally if you want to. There will also be apps for Windows and MacOS in the future.
      - x1798DE 10y ago
        I'm not sure what you mean by a local client. If you are suggesting that even the Tutanova users are decrypting things using browser crypto, that's absurd. I assumed this was all done either with a local client or a browser extension. If you mean that the non Tutanova user should have to install a Tutanova client, I might as well just have them set up PGP. If you mean a local server using the github code, it's a fair enough point - it's more complicated and likely insecure than using PGP, but at least the burden of complexity and security falls on the power user.
  - dingaling 10y ago
    > He can open his encrypted mailbox only with the passphrase that you (the sender) shared with him. Presumably that passphrase would be shared out-of-band to prevent Tutanota peeking, at which point... Why bother sending an e-mail at all?
deleted 10y ago
[deleted]
mr_sturd 10y ago
If you send an email to someone without Tutanota. They email the recipient with a link to their server. Allowing the recipient to decrypt the email in the browser, using a password agreed on, by the communicating parties.[0] [0]-https://tutanota.uservoice.com/knowledgebase/articles/470795-how-do-i-send-an-encrypted-email-to-an-external-re https://tutanota.uservoice.com/knowledgebase/articles/470795...
- skrowl 10y ago
  If I'm going to go the route of sharing a password, why wouldn't I just put a .txt or .html file with my email body in a password-protected/encrypted .7z or .zip and just send it with plain old gmail? My buddy doesn't have to change his email provider or click on any special links. In addition to not having forward secrecy (if a 3rd party gets his crypto password, they get ALL of my messages to him), this seems to fail the classic "In order to exchange a secret, first exchange a secret" crypto usability test.

mirimir 10y ago

They nuke accounts created using Tor. That's not very privacy friendly.

troublord 10y ago
That is simply not true. We have a very high degree of Tor users. Unfortunately, some spammers also hide behind Tor. That is why we disable accounts that are used for spamming purposes. You can always contact our support if you feel that your account has been disabled without reason. We check every case... :) -- Matthias Founder tutanota.com
- mirimir 10y ago
  Thanks. That's good to hear :) But I've had it happen more than once, without warning, and without any mail sent. Also, contacting support isn't really a viable option, for new personas with no other email address.
  - troublord 10y ago
    That is true for users without an email address. Don't mind to share your ideas for improving this at https://tutanota.uservoice.com/ https://tutanota.uservoice.com/. We will change this, if there is a better way that provides protection against spammers...
    - mirimir 10y ago
      Thank you. But is spamming through Tor really such a huge problem? I vaguely recall the argument that there wasn't enough bandwidth. And maybe there is now, with faster relays.
      - troublord 10y ago
        Unfortunately yes. A single user is not a problem. But if hundreds of users abuse TOR for spamming via Tutanota, this becomes a serious issue. At least for the spam recipients and other users of our service, that might get classified as spammers by the receiving mail servers.

Already__Taken 10y ago

What extra do the encrypted messaging services offer on top of say, forcing a regular mail server to only user tls1.2. Must we all move onto a single provider? I'm just curious why that's not good enough where sysadmins collectively pester whoever they require secure communication with to also have a tls1.2 mailserver. Would that not be job done?

dsr_ 10y ago
That would not be end-to-end. Email is a store-and-forward service, so even if you guarantee that every network hop is protected, the message is in cleartext (and thus inspectable, alterable and censorable) on every server.
stephenr 10y ago
Forcing TLS for the MTA at each end is about network encryption (i.e. akin to HTTPS) this "solution" is about encrypting the contents of the message envelope, i.e. restricting who can read the contents of the message regardless of how its transferred. As I mentioned elsewhere, it is however yet another non-solution, for the same reason you queried - it's all reliant on a single provider. Real end-to-end encrypted email is when your mail client uses either S/MIME or PGP/GPG to encrypt your message using the recipient's public key(s). In that situation, it doesn't matter what mail service they use, or what network transport the MTA's use - it's readable only by them (well technically only by anyone with the appropriate private key - I'm going to assume people are protecting their keys).

g4k 10y ago

It seems this is browser only. Would be great to have Thunderbird integration.

troublord 10y ago
Please vote for the following feature request: https://tutanota.uservoice.com/forums/237921-general/suggestions/7013569-creating-an-add-on-for-an-open-source-mail-client https://tutanota.uservoice.com/forums/237921-general/suggest...

DavideNL 10y ago

Beware, does not support local (encrypted) backups. If their servers disappear for whatever reason (legal issues or hardware problems), you end up with 0 e-mails. Nothing.

stephenr 10y ago

So yet another "end to end encrypted" email "solution", where both ends are controlled by a single vendor. There are already two, count them, TWO, existing, open, well-understood ways to both sign and encrypt email between two parties: PGP, and S/MIME. Currently, the UX around setting up and using each of these tools is.. less than stellar. Now. Just go with me here. What if all the people who keep claiming to have "solved the encryption problem" by locking everyone into their own little silo, instead of doing that, WORKED ON SOLVING THE USABILITY PROBLEMS?

vox_mollis 10y ago
PGP is entirely useless if you wish to hide metadata about origin, destination, precise timestamps, etc. Use cases exist in which you need to communicate securely and authenticated, but can NOT leak the above. Some combination of Pond( message inboxes, timestamp randomization ) and Ricochet( authentication, origin/destination obfuscation ) is sorely needed.
- stephenr 10y ago
  > if you wish to hide metadata about origin, destination, precise timestamps Sounds like email in general is not the transmission medium you want then.
  - wccrawford 10y ago
    But by that same token, it doesn't appear that this is actually "email" either. It's sending messages via the internet, securely, using a custom client. If you send to someone without their client, they end up with a link (via actual email) to the website and have to use a password to view it. I think we're at a point where any long messages sent via the internet are going to be called "email" regardless of the actual transmission process. Especially if they aren't meant to be some kind of real-time chat system, as that is usually called "instant messaging".
    - stephenr 10y ago

steaminghacker 10y ago

how does this compare to protonmail ?

stephenr 10y ago
In that it claims to be 'end to end' encryption, but that both 'ends' are from the same vendor, it's exactly the same. So if you use protonmail and your colleague uses this, and you want to have a secure conversation over email, you're each going to be clicking clicking a fuck load of "view this message on <service you don't use>" links.
- mookerific 10y ago
  At least ProtonMail is working towards full compatibility with the OpenPGP standard, thereby allowing non-Protonmail users to encrypt emails using a standard PGP key - according to their stated roadmap, ProtonMail will eventually allow you to export your keypair and will also allow you to upload keys you've generated outside of their service instead of relying on their service to do the key generation. Tutanota has implemented their own variation of encryption which is not OpenPGP compliant. Their justification for this deviation rests on their desire to be able to encrypt all aspects of communications (metadata, subject, etc) while PGP doesn't not offer this.

muloka 10y ago

Curious why they went with Cordova instead of React Native for their mobile apps. Are there security considerations between each solution that they took into account when deciding?