Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open-sourcing Tutanota: Why it was important to us

tutanota.de

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Open-sourcing Tutanota: Why it was important to us

#31

Post by mbubb »

alfiedotwtf wrote: post #14
Numberwang wrote: post #10

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.

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/

Not just 'some' of your servers. Looks like infrastructure is US based.

https://www.fastmail.com/help/ourservice/security.html

   Physical location security
   Our main servers are located at New York Internet (NYI) in  New York City, USA. Their facility is a high security, video monitored location; with backup power, air conditioning, fire systems, 24x7x365 monitoring, and onsite technical support.
I am familiar with NYI - they are a good datacenter - but I do not think they are in any way more or less secure than the Equinixes, Internaps, Telxs, etc.

The security of fastmail is really the security of end to end TLS with forward security. All good practices but industry standard, no?

Do you encrypt traffic between servers? ie http://www.forbes.com/sites/benkepes/2014/03/20/in-an-attemp...

What differenitates Fastmail sec practices?

Re: Open-sourcing Tutanota: Why it was important to us

#32

Post by nickpsecurity »

lmb wrote: post #2

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

Re: Open-sourcing Tutanota: Why it was important to us

#33

Post by curtis »

rossjudson wrote: post #27

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

Here's what I found with a little research. From 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.

Re: Open-sourcing Tutanota: Why it was important to us

#34

Post by nickpsecurity »

curtis wrote: post #33
rossjudson wrote: post #27

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

Here's what I found with a little research. From 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 t…

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/

Note: Not endorsing the above product. It was search result with good description.

Re: Open-sourcing Tutanota: Why it was important to us

#35

Post by nickpsecurity »

brongondwana wrote: post #4

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 a…

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.

Re: Open-sourcing Tutanota: Why it was important to us

#36

Post by ddrum001 »

rossjudson wrote: post #27

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

Agreed, that was my reaction as well. I suppose that's the tradeoff of a descriptive name for your project.

Re: Open-sourcing Tutanota: Why it was important to us

#37

Post by carussell »

brongondwana wrote: post #4

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

Re: Open-sourcing Tutanota: Why it was important to us

#38

Post by carussell »

ddrum001 wrote: post #36
rossjudson wrote: post #27

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

Agreed, that was my reaction as well. I suppose that's the tradeoff of a descriptive name for your project.

The title originally submitted here was more descriptive before it got changed to the text of the heading from the blog post in the link. Regular readers of the Tutanota blog will presumably already be aware of what it is, by virtue of being regular readers of the Tutanota blog.

Re: Open-sourcing Tutanota: Why it was important to us

#39

Post by tptacek »

brongondwana wrote: post #4

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 a…

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.

Re: Open-sourcing Tutanota: Why it was important to us

#40

Post by zanny »

mbubb wrote: post #28

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 somet…

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.

Post reply on HN