[brongondwana]

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 == [e-mail], signed up for testing Account B == [e-mail], 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 [e-mail] I guess, then I:

1) deleted the contact from my tutanota account to try to revoke the send message.

2) clicked the link from [e-mail], which took me to the email.

3) replied from the tutanota interface as [e-mail].

4) replied from the tutanota interface to THAT email as [e-mail]. 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 [e-mail] 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]

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]

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

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]

> 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).

[gablegab]

You wouldn't happen to have that set up available via Docker/Packer etc? I like being able to stand on the shoulders of giants :)

[noinsight]

Unfortunately no, I haven't really gotten into that stuff. It doesn't take that much time though if you have a basic knowledge, it took me like a night to set it up.

[e12e]

Great points.

One thing that bothers me about these "encrypted webmail"-services, is that they all depend on TLS for whatever thin sliver of security they provide. Then they go and use something that's not S/MIME and/or x509 for end-to-end (or whatever kind of) encryption/authentication.

At least leaning on pgp makes sense in because it is already somewhat deployed and in-use.

But since they all fall apart if TLS has a hole, it seems odd to add another layer. The complexity of any other solution for encryption/authentication must surely outweigh the benefits of OurCleverCryptoSystem(tm)?

I'm not aware of any advances that have changed the possibilities of asynchronous secure messaging: you can't have PFS, key distribution is hard.

At least with x509/gnupg you can partner with someone like youbikey, and at least pretend to lower the ux friction and increase the real-world security of the system.

/rant

[masida]

You're right about you're being clear about working there, I'm sorry if I've sounded a bit harsh. Thank you for your analysis BTW. I think it's always useful to provide constructive review to fellow developers.

I agree with you that the only alternative is self hosting. That's why I'm anticipating a new wave of low power mini-computers with solid state memory, a fully configured embedded GNU/Linux or *BSD distro, and a webbased interface for management which would make it possible to host our own services at home using OSS only. The FreedomBox is an example of this.

[tptacek]

I'm not a Fastmail fan, but it's sad that what appears to be the only substantive technical commentary about Tutanota on this thread has been voted down by people who can't see past tit-for-tat between email services. Tutanota exists to provide security, and appears to do so poorly. That seems like one of the more relevant things to discuss.

[napoleond]

> I'm not a Fastmail fan

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.

[tptacek]

I trust Google's security team more than almost any other security team, and I trust Google's lawyers even more.

[mbubb]

Genuine questions - I do not know as much as I should about this stuff:

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

[brongondwana]

We don't allow a way to send encrypted email directly, because the intersection between people who wanted it and the people who would trust us with their private keys was too small to be worth it. Instead, we provide standard protocols (IMAP/POP/SMTP) so you can run the crypto software on your own computer and submit and receive through us. This gives you full encryption support.

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.

[mbubb]

Ok - I initially misunderstood that you were saying FastMail does the same thing as Tutanota. When I reread your comment I see that you aren't saying that - just that you secure transit with TLS, etc.

[carussell]

> #include plug for FastMail - we know what we're doing.

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.

1. https://news.ycombinator.com/item?id=9790053

[brongondwana]

So we have an FAQ link which amounts to "too many clients have bugs around spaces in passwords". I'm not as certain that this is true as it was when we instituted that rule, but it definitely was at the time.

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.

[carussell]

I'll say the same thing I said in the bug:

I can appreciate the problem of people using clients that are broken, but why does this matter here? Thunderbird is not among them. So why are we discussing whether a customer would be able to successfully use their client to access the account of someone else who has spaces in their password? (Also, could you share the data you have about those clients?)

> You might have followed that Google are making it more and more difficult to "just use your very secure password everywhere"

I haven't followed this. Do you have a link? But again I ask: why does this matter? What do Google's actions have to do with using either FastMail or running your own mail server?

> What we might do for the zero point something percent of users like you

... uh?

> 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

Again, this is a way of responding to something that is completely orthogonal to the problem. Having control over the passphrase has nothing at all to do with whether you can or cannot issue multiple ones for use on different clients so that you can maintain revocability. This isn't a complaint from me, because this is never going to come into play for me given the way I'm accessing things, but it's so weird to continue hearing approaches like this that are, with respect to the thing being discussed, just... sideways.

> and guarnteed non-password-reuse of device passwords.

How are you guaranteeing this?

[brongondwana]

Google are doing it because the risk landscape has shifted from people signing up fraudulent accounts to people stealing existing accounts in good standing and using them to spam. You can rate restrict new free-trial accounts, but it's harder to rate limit long standing good accounts without annoying legitimate users - but once their account is stolen, that means a fair bit of spam can get out before reports come back or we can block the limit.

The zero point something percent comment - most users aren't at your level of proficiency - and we do have to play the percentages here. If 10% of our users get phished and their accounts used for spam, you can't send email reliably through us any more because we'll be on every blocklist in existence.

The vector for accounts being stolen is almost never weak passwords - it's phishing or viruses or password reuse. We just don't see people enumerating passwords. You flat out don't need a super strong password, it makes no difference beyond not using one of the top 1000 most common passwords (unless our entire password DB gets stolen, but that's a different class of risk - whole system vs individual)

Well, we can't guarantee that you don't go ahead and use it on another service of course, but by generating the device access token ourselves, we can be sure that you aren't reusing a password that you are using somewhere else.

You can already do this yourself, we support alternative logins, including one-time passwords - but as I said, it's about the percentages, we need to make it easier for average people so that more accounts are more secure.

[e12e]

Carussell: have you ever worked in first-line support?

To paraphrase a friend: "If I never hear the phrase: Why isn't my email working? I have an iphone...", I'll die happy."

I can appreciate that it's nice to be able to use space as a character, any reason you can't just substitute "." or "," on mobile (in terms of UX, obviously)?

Btw, I have no affiliation with fastmail.

> and guarnteed non-password-reuse of device passwords.

This should be easy to guarantee at creation-time:

  For user A, all devices a...x
  When generating a new device password p
  Check p against all historical device passwords
    for devices a..x
  If no match, use p
  Else generate p' and try again

When a valid (non-reuse) password has been found, it can be stored in non-reversible form (salt+hash, optional stretching).

I would too like to know what fastmail actually do, though.

[nickpsecurity]

Your service, on the other hand, operates in one of the Five Eyes countries by their own citizens. Thats risky to many. Further, it's a web service (easier to attack) with a ToS that's immunizes you from about any negative event. I did like the privacy policy but above things add up to plenty risk some competing solutions don't have.

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.