5 ms·

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",

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.
- brongondwana 11y ago
  I figured the "we" after FastMail said that I work here. Quite a lot of our backend source is open too (particularly the Cyrus IMAP server, which makes up the bulk of my work now that I have people with a more dedicated ops role for day-to-day tasks). We encrypt everything to disk, and everything on the wire that is practical (connecting to other providers still falls back to plaintext if they don't support STARTTLS, because encrypted-only isn't practical yet) But client connections are ONLY secured now, we don't allow any plaintext channels where you could accidentally send your password. https://www.fastmail.com/help/technical/ssltlsstarttls.html 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.
  - noinsight 11y ago
    > 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. This is what I do. At home I have a Chromebox with FreeBSD and a fully encrypted disk. I have a VPS with an OpenVPN server and the required ports are forwarded to my own box. IMAP and SMTP submission require TLS so those are fully covered. Like you said though, the only thing you can't reasonably forcibly encrypt is SMTP itself. Most of the mail I receive comes with STARTTLS but not all. With this setup the VPS provider can't see anything when SMTP happens with STARTTLS. Obviously if they really want to read my mail they can start MITM'ing the STARTTLS away because it isn't forced but this is the best setup that's reasonable. My ISP for my home can only see encrypted OpenVPN traffic too. In fact the VPS is in another country but that's only a consequence of the silly VPS prices in my country. Obviously with this setup I don't have to surrender my private key to anyone either, it sits on my own box (and I use a legitimate CA-issued certificate).

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.

brongondwana 11y ago
I figured the "we" after FastMail said that I work here. Quite a lot of our backend source is open too (particularly the Cyrus IMAP server, which makes up the bulk of my work now that I have people with a more dedicated ops role for day-to-day tasks). We encrypt everything to disk, and everything on the wire that is practical (connecting to other providers still falls back to plaintext if they don't support STARTTLS, because encrypted-only isn't practical yet) But client connections are ONLY secured now, we don't allow any plaintext channels where you could accidentally send your password. https://www.fastmail.com/help/technical/ssltlsstarttls.html 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.
- noinsight 11y ago
  > 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. This is what I do. At home I have a Chromebox with FreeBSD and a fully encrypted disk. I have a VPS with an OpenVPN server and the required ports are forwarded to my own box. IMAP and SMTP submission require TLS so those are fully covered. Like you said though, the only thing you can't reasonably forcibly encrypt is SMTP itself. Most of the mail I receive comes with STARTTLS but not all. With this setup the VPS provider can't see anything when SMTP happens with STARTTLS. Obviously if they really want to read my mail they can start MITM'ing the STARTTLS away because it isn't forced but this is the best setup that's reasonable. My ISP for my home can only see encrypted OpenVPN traffic too. In fact the VPS is in another country but that's only a consequence of the silly VPS prices in my country. Obviously with this setup I don't have to surrender my private key to anyone either, it sits on my own box (and I use a legitimate CA-issued certificate).