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.
Open-sourcing Tutanota: Why it was important to us
41–50 of 64 posts
Re: Open-sourcing Tutanota: Why it was important to us
#42After 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)?.
Deviousness? You're saying you're too clever to fall for their diabolical plan to give you the information you're looking for?
Re: Open-sourcing Tutanota: Why it was important to us
#43What 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)
Re: Open-sourcing Tutanota: Why it was important to us
#44I 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 a…
> #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…
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.
Re: Open-sourcing Tutanota: Why it was important to us
#45Has anyone tried this? How does it compare to https://www.mailpile.is/ ?
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…
> 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?
Re: Open-sourcing Tutanota: Why it was important to us
#46Earlier quoted context omitted.
> 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…
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 :)
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.
Re: Open-sourcing Tutanota: Why it was important to us
#47Earlier quoted context omitted.
> #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…
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…
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?
Re: Open-sourcing Tutanota: Why it was important to us
#48Earlier quoted context omitted.
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…
> 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?
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.
Re: Open-sourcing Tutanota: Why it was important to us
#49> Why it was important to us
So that people would actually know you exist?
Re: Open-sourcing Tutanota: Why it was important to us
#50Earlier quoted context omitted.
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 tha…
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,…
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