Why Open Source Matters For Sensitive Email 73
Jason Baker writes Can you really trust your email provider? And even if you self-host your email server, can you really trust its security if you can't see the code? Over on Opensource.com, Olivier Thierry makes three cases for using open source to power your email solution: The power of numbers, the value of trust, and the importance of leverage.
Paranoia abound (Score:4, Interesting)
Can you really trust your email provider?
Yes, because I'm not a paranoid idiot. If someone wanted to do something malicious with your email, they probably could anyway, because so much of the world's email servers transmit in plaintext, the provider (other than the choice of one that does encrypt when possible) is the least of my concerns.
Re:Paranoia abound (Score:5, Insightful)
Even beyond that, e-mail can be encrypted client-side when necessary, meaning you don't have to trust anyone. There's no reason to trust your e-mail provider in the first place if the contents are truly sensitive. For everything else, e-mail should be considered about as secure as a postcard.
If you need to protect the metadata as well as the content, then e-mail shouldn't even be used for that sort of correspondence. E-mail has never been secure. It probably never will be either, at least not for what we consider "e-mail" today, because there's too much legacy crap that would break if we lock it down (at least if we are trying to secure metadata).
If we're OK with simply encrypting content as needed, then there are ways of building that sort of infrastructure into the system. We're seeing a lot of 3rd party messaging solutions that are using very good "trust no one" client-side encryption technologies and methods, such as What's App (now that they've integrated Open Whisper Systems security) or Threema.
Re: (Score:3)
Re: (Score:2)
Come on. There are many products that handle email/calendar/collaboration which are better than Outlook. Outlook is a very good standard and rather feature rich for an email client. It is designed to work well with a popular enterprise email solution. But it is far from the richest solution and further still from the only solution. There is even a fairly good solution which is rather close to Outl
Re: (Score:2)
Re: (Score:2)
Every major corporate network does not run Outlook. I've worked with enterprises that use in house solutions. There are corporations on Google. I've worked with many major corporations that use Lotus Notes example BTI. Texas Instruments uses Zimbra which is a major corporation. Novell Groupwise is used by corporations. Mirapoint & CriticalPath are still in use and migrating their customers not to Outlook / Exchange but to Open-Exchange. I know several hospitals that were on Scalix up till a few y
Re: (Score:2)
Re: (Score:2)
"it's not pure chance that every major corporate network runs it." is not "Exchange/Outlook still takes the lion's share of the market,"
Those are very different statements. You were defending the statement, " there really is only one product in the Enterprise email/calendar/collaboration space worth a damn " which is why you had to make the case it was the unique solution.
The fact is Exchange/Outlook is a pretty good solution. But it is far from the only solution or only viable solution. The big features
Re: (Score:2)
Re:Paranoia is actually warranted these days (Score:2, Insightful)
Trust? Let me tell you about trust, there is no more trust...
You cannot trust Microsoft, or Google or anyone else with your mail for that matter. Every commercial mail provider and software maker is either already in bed with your adversary, or subject to your adversaries whim. For that matter, you cannot trust the 1.5 BILLION transistors in your CPU. But let's ignore that for now.
You CAN generally trust open source software for your MUA and MSA/MTA, and for your crypto.
You NEED crypto.
Then, you cannot send
Because EVERYONE is qualified to read code (Score:1)
Especially encryption code necessary to truly protect your email.
Jeez, what color is the sky on your planet?
Re: (Score:2)
Brownish white with some moisture stains in the corner over there.
Open Source not a silver bullet (Score:5, Insightful)
Re: Open Source not a silver bullet (Score:3, Insightful)
Also of import: what's the status of turnkey open source email packages these days anyway? What is out there that exchange admins can switch to that won't make them hack on features or make their users ask WTF they just did? That is the elephant in the room and the million dollar question.
FOSS email LONG before Exchange, most mail FOSS (Score:5, Informative)
Email was flowing through open source systems for DECADES before Exchange came out. Today, the vast majority of mail is handled by open source systems.
If you're accustomed to Exchange and want to get that same bloated feeling without the six figure license fees, there are many open source packages designed,for that. Examples include OpenChange, Open X-change, Zumbra, Citadel ...
Of course the vast majority of mail is handled more in the Unix philosophy, rather than one software package that thinks it's a file server (SMB), an MTA, an MDA, a groupware calendar, an IMAP server, and six other things it does poorly, the normal Unix way is if you want IMAP, you install a good IMAP server by clicking on or typing "dovecot". It doesn't have a buggy, insecure file server sticking the out the side that you never asked for.
Re: FOSS email LONG before Exchange, most mail FOS (Score:1)
Zimbra. There are probably others: five minutes of Googling will net you answers. Or install an IMAP mail server and a separate calendaring program on the same server, and your clients won't notice that they're two programs. Ports are just standard interfaces for standard APIs.
All- OpenChange, Citadel, Zimbra .. + RSS Faceboo (Score:3)
All of the packages I mentioned provide that. Not being tied to Microsoft's ecosystem, they can also integrate your Facebook, Twitter, rss, or other notifications.
Re: (Score:2, Informative)
Completely making that up (Score:2)
Now you're just completely making stuff up. How do you think email worked for the 25 years before Microsoft said "me to"?
IMAP PUSH, RFC 3501 (Score:1)
RFC 3501is the standard for imap, including PUSH. You call Exchange Activesync "a de facto standard" - IMAP is an ACTUAL standard, and it includes push.
Btw, you called it ActiveSync, but that's the name of an older,mostly unrelated protocol, used with a PDA cradle connected to the serial port. You're thinking of Exchange ActiveSync. The difference is kind of like York vs New York; similar names, totally different things.
Fyi, with each post you only re-emphasize how completely and utterly clueless you ar
Re: (Score:1)
RFC 3501is the standard for imap, including PUSH.
It uses IDLE, which, given the amount of overhead, is not suitable for mobile devices which is why P-IMAP and Lemonade are in development. Do you understand that? Probably not.
You call Exchange Activesync "a de facto standard" - IMAP is an ACTUAL standard, and it includes push.
The IMAP standard contains IDLE which is inappropriate for mobile devices, which is why they dont support it. Oh but you didnt know that did you, that is why you just provided your stupid incorrect reply.
Btw, you called it ActiveSync, but that's the name of an older,mostly unrelated protocol, used with a PDA cradle connected to the serial port. You're thinking of Exchange ActiveSync.
I said "Microsoft brought ActiveSync with Exchange", clearly that is what I meant, in fact you even stated it "you call Exchange Act
and wrong again (Score:2)
> It uses IDLE, which, given the amount of overhead, is not suitable for mobile devices which is why P-IMAP and Lemonade are in development
And wrong again. Per the current draft, P-IMAP devices are REQUIRED to support IDLE. SMS and WAP are optional. P-IMAP uses doesn't replace IDLE, it uses IDLE.
Also note Exchange ActiveSync uses a heartbeat protocol very similar to IDLE - with pretty much the same problems. The content of the packets are a bit different, the overall scheme is rather similar.
You're o
Re: (Score:1)
How do you know you aren't just a brain in a vat? You can't trust anything, man!
Re: (Score:3)
How do you know there's a real vat?
Re: (Score:3)
How do you know there's a real vat?
How do I know YOU are real?
Re: (Score:1)
We've seen over the last year many open source, power in numbers projects have critical vulnerabilities waiting to be exposed. Those defects were sitting there for years, yet being open source didn't magically fix them.
Precisely! In theory it could be more secure but in practice, as we have seen, you could have a critical bug sitting there, unbeknownst to users, being exploited for decades before somebody fixes it. Open source is not a silver bullet for security!
I really genuinely wish people would stop tarnishing the name of open source with these garbage articles about theoretical benefits. Open source has many significant advantages, this is not one of them and crap like this is going to lead to dismissal of open sourc
Re: (Score:2)
I use many open source tools, but I've never inspected the code myself. Even if I did, I'm not going to be finding these hard-to-find defects that the people in the project can't find.
From a security perspective, even just having and being able to inspect the code is insufficient if you need top-notch security: you had better also be compiling that code yourself. It is nearly impossible to be able to verify that a binary blob didn't contain additional/modified code than what the sources contain without compiling it yourself. And even with being able to compile everything yourself, you're still at the mercy of the build chain and all of its dependencies (unless you audit/build them you
Re:Open Source not a silver bullet (Score:4, Insightful)
From a security perspective, even just having and being able to inspect the code is insufficient if you need top-notch security: you had better also be compiling that code yourself.
With a verified compiler no less. We have seen ever more sophisticated malware these days, certainly a malicious compiler could easily slip vulnerabilities into the binary.
Re: (Score:2)
With a verified compiler no less. We have seen ever more sophisticated malware these days, certainly a malicious compiler could easily slip vulnerabilities into the binary.
Yup -- I intended that to be considered part of the build chain. Compiler, standard libs, any 3rd party library dependencies, the build tools themselves (have to make sure they're using the libs you expect them to...), the OS kernel...right on down the chain.
Yaz
Re: (Score:2)
...and bootstrap the whole thing by cross-compiling on several unrelated kinds of hardware (ideally including some old enough that maybe nobody had thought to put backdoors in it yet), and then checking that the resulting binaries are identical. Maybe use a 386, an ARM or PowerPC, and something Chinese [wikipedia.org], for example.
Re: (Score:3)
And even with being able to compile everything yourself, you're still at the mercy of the build chain and all of its dependencies (unless you audit/build them yourself too).
It seems a bit foolish to worry about purely theoretical security issues when we've got so many real ones to deal with. Ken Thompons' compiler infection demonstration was an interesting experiment designed to make a particular point, but I don't think it's wise to consider tool-chain hacking a legitimate threat, as we've never seen anything remotely like this in the wild, as far as I'm aware. And frankly, I question whether it's even realistically possible beyond a very simplistic demonstration.
At some po
Re: (Score:3)
It seems a bit foolish to worry about purely theoretical security issues when we've got so many real ones to deal with. Ken Thompons' compiler infection demonstration was an interesting experiment designed to make a particular point, but I don't think it's wise to consider tool-chain hacking a legitimate threat, as we've never seen anything remotely like this in the wild, as far as I'm aware. And frankly, I question whether it's even realistically possible beyond a very simplistic demonstration.
First off, naturally the level of security I'm talking about would probably only be reserved for national governmental agencies intended to protect ultra-sensitive data. For them, that level of security is necessary, and they will spend the money and resources to audit and verify everything if necessary (which is why we have SELinux).
Additionally, the build chain comprises not only the compiler, but the standard libraries and any third-party libraries as well. If not verified, these could easily have unex
Re: (Score:2)
Yes, national security agencies probably think at that level, because they can afford to think at that level - same with top industry security experts such as Bruce Schneider. Even so, I'd still posit that it's still very much a hypothetical threat or method of attack. It's fun to theorize about what-ifs, but we should probably recognize it as such, with the understanding that it's not really relevant to nuts-and-bolts security issues in the real world. There's a pretty significant difference between "th
Re: (Score:2)
Ken Thompson modified the original C compiler to put a back door into the Unix login program, as well as to modify any compiler that was compiled with that compiler to include the backdoor function. So for generations of code, and backdoor was inserted, with no evidence of its existence in any code you could examine.
http://cm.bell-labs.com/who/ke... [bell-labs.com]
Re: (Score:1)
The trouble with proprietary software is that those defects will persist forever. And, if the NSA inserts nefarious code into a proprietary TLS/SSL project, you'll still never know, and you'll still have no recourse. If it was open source, at least there's a chance it will get noticed and fixed.
Someday, we might have formally verified open source security software. But, that's not really a valid point until we start seeing it, and making formally verified software is hard.
Re: (Score:2)
I can't deny that - the "many eyes" argument hasn't quite held up over the years. However, the reason I prefer an open source solution is because they tend to acknowledge and fix the issue much faster than their closed source counterparts. Most of the serious security issues in open source
Not really ... (Score:4, Insightful)
Re: (Score:3)
Unless you're using encryption, it doesn't matter, since there are many points of 'interest" between the sender and receiver.
Yeah, for external mail no doubt. But for internal mail you probably wouldn't bother, then it's a pretty huge juicy target for sensitive information. Even when you're not passing the juiciest details by email like blueprints and source code there'll be tons of business information in attached presentations and so on.
Re: (Score:1)
Re: Not really ... (Score:1)
Internal mail is easier to encrypt if your clients use provisioned SMIME certs. Set up an internal CA and push its root to all devices, thrn generate keys for users and push them to the right places for your OS/mail app combo, and most mail apps will use them automatically or with some minimal config that you can push to your network. Keep a backup of employees keys for data retention policies so you can recover subpoenaed mail. You can still be defeated by a determined adversary who gets the private keys f
Trust (Score:4, Insightful)
Sigh. Now somebody is going to bring up Ken Thompson's "Reflections on Trusting Trust" in 3... 2... oops, too late.
Re: (Score:1)
What are Bennet Hasselton's thoughts on Ken Thompson's "Reflections on Trusting Trust"?
Re: (Score:2)
Fucking Clickbait (Score:1)
There was no informational value at the linked page. All of those arguments have been made/refuted many times over the years. If you're actually worried about email security then a self-hosted open-source mail server isn't going to help you... you need to be using encrypted mail.
Re: (Score:3)
Olivier Thierry is the chief marketing officer of Zimbra, and has more than 30 years of experience increasing market visibility and developing go-to-market strategies for high-volume software organizations,
Stupid article is stupid (Score:5, Insightful)
Open source is a source licensing model. It has no magic powers for creating secure solutions to anything.
Stupid headline: Why open source matters for sensitive email
Stupid headline: Why closed-source matters for sensitive email
Smart headline: Why security matters for sensitive email
Code audits for security defects can happen regardless of source licensing model.
Coders authoring a service, no matter how security conscious, and no matter how many eyeballs they have, will likely miss many exploitable defects.
Re: (Score:3)
It points out yet again people are mistaking open source with security.
You'd think after heartbleed a few would have caught on.
Re: (Score:2)
Open source does matter for any security sensitive software, which these days is pretty much all of it. It's not that open source is inherently more secure than closed source, it's that the support is better.
When a vulnerability is found in closed source software someone has to contract the vendor. That in itself can be difficult. Then they take some time to fix the problem, maybe months or years, and until then the problem remains secret. With open source it's usually easy to contact the developers, the pe
X.org? (Score:3)
If I was publishing an article talking about how huge numbers of eyeballs solves security problem I'm not sure that I'd choose to publish it the day after it was announced [x.org] that the X window server code has had some serious security bugs for 25 years that have only just been discovered. Clearly open source code can have serious security holes that go unnoticed for a very long time.
Re: (Score:3)
In that the main difference with closed source is that open source shows it's dirty laundry. Why do you think a closed source solution would not have flaws of similar severity?
Open source client does (Score:3)
Truly sensitive e-mails should be encrypted, so open source and other characteristics of the service do not matter.An ideal client would support zero knowledge multihop forwarding so that even sender/recipient metadata can not be analyzed.
Email is not suitable for sensitive material (Score:3)
Why marketers should not write articles. (Score:2)
Perhaps rename article. "An Example, Why marketers should not write articles"
Trust is of utmost value (Score:2)
What an absurd statement this is making. I like the one about "Trust is of utmost value". No, not at all and let me explain why.
If I use open source software I use binaries. I have no more faith in those binaries than any other piece of closed source software, there's no guarantee that the binary matches the source, even if the source is somehow magically free of bugs because as we all know open source is infallible [heartbleed.com].
Ok so there's the potential for me to do an audit. So I have the choice, I could sit down a
Open Source == DOES get a fine tooth comb. (Score:1)
I am the prime author of CRM114 (the spam filter) and IT DEFINITELY GOT CHECKED BY SMART PEOPLE. There were at least a dozen people who would dependably read the code, and they'd find the pickiest things (luckily, not anything serious; thank you Valgrind!)
So, it's absolutely, demonstrably, provably (read the mail archive!) the case that at least SOME mail-oriented open source gets the all-orifices examination, and that examination is effective.
Whether or not security software gets the same thing, I can't
Open Source matters for sensitive *anything* (Score:2)
Captain Obvious submitted again.
Open Source matters for sensitive anything. In fact, I, and any professional I've talked to, would say if it's not FOSS or at least using a free open standard in data format, it's of no use for anything sensitive or mission critical. We've arrived at the point where critical systems that are not FOSS aren't even considered to be enterprise ready by a large portion if not even the majority of IT experts. Which is a good thing, IMHO.
For instance, anybody nowadays talking Unix a