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

Mailpile – taking e-mail back

indiegogo.com

Post reply on HN
Print view View original

21–30 of 157 posts

Re: Mailpile – taking e-mail back

#21

Post by gioele »

sipior wrote: post #13
harrytuttle wrote: post #4

How many times do people have to say this: There is no such thing as secure email. Assume everything is being read. You can't bolt security on (SSL, mailbox encryption, PKI). You have to design it in from the start. SMTP/IMAP etc have crudely hacked on TLS implementations which aren't even guaranteed to be operational site to site. PGP is just an encapsulation which is rarely used. It's a mess. This is just a repacka…

Okay, Harry, let us know when you're done with that :-) I suspect most of the rest of us would prefer the perfect not be an enemy of the good.

In encryption there is no "good": it is either "perfectly working" or "fundamentally compromised".

If there is only a small flaw in an encryption system, be assured that it will be exploited to break down the whole system. A simple example are all the issues with random number generators producing not perfectly random numbers; yes, it is just a slight problem in an otherwise good solution but that problem completely debases the overall system.

Re: Mailpile – taking e-mail back

#22

Post by mikegioia »

devx wrote: post #5

Why even bother with S/MIME? How long until the government corrupts the certificate for it if Mailpipe becomes as important to them as Lavabit was, in the future? And I hope their PGP implementation is really user-friendly. This sounds like more of the same of what we've had so far, perhaps with the ability to become a little more mainstream, but I don't see any breakthroughs in terms of encryption here, like say the…

    Why even bother with S/MIME? How long until the
    government corrupts the certificate for it if Mailpipe 
    becomes as important to them as Lavabit was, in the
    future?
The way I see it, Mailpile won't be issuing certificates for people to use, they merely enable you to use your existing certificate infrastructure.

I have a machine with a certificate authority that issues S/MIME certs for us to use internally for sensitive emails. Currently we use Thunderbird and Mac Mail to handle this but people like web mail and we need a system that can run a web interface (or phone app) to handle these certificates.

Re: Mailpile – taking e-mail back

#23

Post by HerraBRE »

jvehent wrote: post #14

* User-friendly support for both OpenPGP and S/MIME encryption and signatures * A very fast, scalable search engine I'd like to know how they achieve both without having the keys, and without shipping code (JS, java applet) that has access to the keys. Also, excuse my lack of trust, but why should I trust a SaaS created by a Google employee, as opposed to trusting a SaaS created by Google ? That makes no sense to me.…

This is not a SaaS. This is an open source mail client you run yourself. So that's why. :-)

Re: Mailpile – taking e-mail back

#24

Post by mikegioia »

jvehent wrote: post #14

* User-friendly support for both OpenPGP and S/MIME encryption and signatures * A very fast, scalable search engine I'd like to know how they achieve both without having the keys, and without shipping code (JS, java applet) that has access to the keys. Also, excuse my lack of trust, but why should I trust a SaaS created by a Google employee, as opposed to trusting a SaaS created by Google ? That makes no sense to me.…

I don't understand, are you generally concerned that Mailpile's web JS can search emails, and therefore has access to private user keys/certificates? I mean, doesn't that just come to whether or not you trust the javascript that Mailpile is writing? I don't think this any less secure than say Thunderbird with respect to PGP/SMIME.

Re: Mailpile – taking e-mail back

#25

Post by mike-cardwell »

harrytuttle wrote: post #20
toomuchtodo wrote: post #15

Earlier quoted context omitted.

Silly question: If you can trust DNS, and require every client to connect to an SMTP server with TLS/SSL, and only permit SMTP server->SMTP server connections over SSL, how does that not fix the problem? End to end encryption and MITM countermeasures should solve the issue, no? Then all the NSA knows is which mail server is talking to which mail server. I admit, I could be very wrong. Please tell me why.

Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don't support TLS", what are you supposed to do? Email only works at the moment because in this scenario, usually the sending MTA just says "what the hell" and delivers it over the wire in plain text anyway. The moment you force TLS as a requirement, the internet…

"Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don't support TLS", what are you supposed to do?"

If the DNSSEC secured DANE records specify that connections to this server must be encrypted, then I guess at that point, you drop the connection and bounce the message back to the sender.

I know of at least the Exim and Postfix projects which are both working on adding DANE support to their MTAs.

Also, even without any certificate verification, opportunistic SSL is extremely useful. It may not be able to stop targetted surveilance, but it can sure stop a large chunk (most?) of the dragnet style surveilance that has recently been reported.

We should do the best we can with our current system until a new system is deployed. We don't know how long we'll be waiting.

Re: Mailpile – taking e-mail back

#26

Post by harrytuttle »

crocowhile wrote: post #19
harrytuttle wrote: post #12

Earlier quoted context omitted.

Yes. Being a bit Theo de Raadt here, but it's a stupid proposition which makes security guarantees that are disingenuous. a) This assumes that everyone is going to be using Mailpile or something which makes PGP easy to use. This is unrealistic. The moment you fart out an email to gmail, it's useless. b) this assumes people actually understand PKI. This is unrealistic. Most people can't even manage their own data let…

It seems to me the mailpile people are quite aware of what they are building and do not oversell their product. They even talk of risk assessment right in the indiegogo webpage. Regarding your points: a-d) I assume that mailpile to mailpile communications will be PGP armed by default. It's enough for them to clear this unambiguously (for instance with a STAR next to "secure" addresses or a popup that says "you are se…

Well your point F nullifies your point about A-D does it not?

As for a second point F, the identity can be derived from the unencrypted headers in PGP.

Before PGP:

    From: bob@alqaeda.org
    To: bill@gmail.com
    Subject:  The snow this year is better at Innsbrook.
    But not at St. Moritz.
After PGP:

    From: bob@alqaeda.org
    To: bill@gmail.com
    Mime-shit....
    DEFKJiwfou3hoqwdnhoqiwfhoqifowqihwqoidhqwod==
PGP is an encapsulation and the MTA still needs the recipient and sender to work properly.

Hmm.

Re: Mailpile – taking e-mail back

#27

Post by jvehent »

HerraBRE wrote: post #23
jvehent wrote: post #14

* User-friendly support for both OpenPGP and S/MIME encryption and signatures * A very fast, scalable search engine I'd like to know how they achieve both without having the keys, and without shipping code (JS, java applet) that has access to the keys. Also, excuse my lack of trust, but why should I trust a SaaS created by a Google employee, as opposed to trusting a SaaS created by Google ? That makes no sense to me.…

This is not a SaaS. This is an open source mail client you run yourself. So that's why. :-)

I had missed that. Thanks for clarifying.

Re: Mailpile – taking e-mail back

#28

Post by harrytuttle »

mike-cardwell wrote: post #25
harrytuttle wrote: post #20

Earlier quoted context omitted.

Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don't support TLS", what are you supposed to do? Email only works at the moment because in this scenario, usually the sending MTA just says "what the hell" and delivers it over the wire in plain text anyway. The moment you force TLS as a requirement, the internet…

"Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don't support TLS", what are you supposed to do?" If the DNSSEC secured DANE records specify that connections to this server must be encrypted, then I guess at that point, you drop the connection and bounce the message back to the sender. I know of at least the…

DNSSEC+DANE is fine and all that, but that's another layer of hack job on top of another lacker of hackjob. It's turtles (or turds in this case) all the way down.

The fact that a simple delivery stack turns into a mish-mash of SpamAssassin, virus scanning, DKIM, DNSSEC, DANE, SPF, PGP, certificates, CA's, numerous ports open, severla products and many more TLA's is the problem.

Complexity does not breed security.

Re: Mailpile – taking e-mail back

#29

Post by alan_cx »

tokenizer wrote: post #3

So will this bypass prism-like surveillance methods?

Im not sure anything can or will.

IMHO, the plus for this is that if more and more people move to encrypted communication across the board, it will a) increase the work load of the likes of the NSA and GCHQ, and b) send a message to government.

Nothing, of course, will work as well as people actually voting for real change. Of course the tragedy of that is that after the scary Bush years, the US people thought they were voting for changes, and all they got was more of the same. I despised Bush, but like we Brits used to say about Thatcher, at least we all knew where we stood. (Blair was our Obama, we thought we were voting for change.)

Sooner or later, we will realize we need to break away from our traditional parties, and vote for something very different, instead of voting int he same thing over and over again because we are too scared of fundamental change, and frankly risk.

For now, we are all too spaced out with our retail and media narcotics to notice or want to change.

Re: Mailpile – taking e-mail back

#30

Post by dangerlibrary »

jvehent wrote: post #14

* User-friendly support for both OpenPGP and S/MIME encryption and signatures * A very fast, scalable search engine I'd like to know how they achieve both without having the keys, and without shipping code (JS, java applet) that has access to the keys. Also, excuse my lack of trust, but why should I trust a SaaS created by a Google employee, as opposed to trusting a SaaS created by Google ? That makes no sense to me.…

Unless I'm misunderstanding, the goal of the Mailpile project is to create a user-friendly client for an arbitrary (including self-hosted) email server.
Post reply on HN