Slack is a popular team communications application for organizations that offers group chat and direct messaging for mobile, web, and desktop platforms. While Slack offers many benefits to customers, there are also downsides to using the platform, including high subscription fees and the risk of a massive leak of private data if Slack’s servers are ever breached (again).
Today there are a growing number of open-source Slack alternatives available for people who want to avoid the trap of walled gardens and have more control over the security of their data. As part of our own search for a self-hosted Slack alternative, we reviewed the options out there.
Blockchains are difficult to run on most end-user devices.
Although MITM-proof proxies are a great way to address this problem, they are unlikely to scale well to all Internet users (not everyone will be able to run their own full node). Therefore, most people will need to rely on thin client techniques to reduce the trust placed in such proxies.
This week Google learned of another batch of fraudulently issued certificates for several of their domains. At the end of the post they made a renewed call for Certificate Transparency. In this post, we'll use the acronym CT to refer to Google's implementation of the general concept of certificate transparency, and we'll explore other technologies that also provide it.
Continue reading →
It's important to remember, however, that this project is not really about new bells and whistles. It's about what kind of a world we want to live in, and for us the answer is clear: we want to live in a free world, and that means addressing these problems:
The Internet is being used as a battleground to wage "cyber war". Much of our infrastructure relies on TLS to protect us, but its protection is undermined by X.509, a system that forces everyone online to trust the bad apple.
Websites rely on TLS/HTTPS to protect them, but it does a very poor job. Even worse, it's common practice for websites to pay for this "non-protection" (although, thanks to StartSSL and Let's Encrypt, it's no longer mandatory to pay).
Ben Laurie, project lead for Google's Certificate Transparency (CT), recently published an article wherein he compared CT against various efforts to secure Internet communication world-wide from Man-In-The-Middle Attacks (MITM), including DNSChain.
In it, he made several claims about CT and related topics:
That CT leads to a situation where "It becomes impossible to misissue a certificate without detection"
That no one has come up with a way to "effectively revoke self-signed certificates"
That CT is a "Generally applicable" system where "No one is special" and where everyone "[is] able to participate"
That CT doesn't introduce trusted third-parties
That CT doesn't push decisions onto the end user
That DNSChain wastes energy and "has no mechanism for verification"
It does not help the slightest that Google continues to make these—in our opinion, inaccurate—claims about CT in its official documentation (and elsewhere), in spite of being informed about their inaccuracies.
And yet, decisions that impact the security of the entire Internet are being made based on these statements.We (the Internet community) need more eyeballs and brains on this.
We envision a future were owning and administering your own personal server is simple and commonplace. This vision naturally arises as more and more people begin to use and advocate distributed and decentralized technologies like Bitcoin and our very own DNSChain. Instead of learning to drive, they'll learn to administrate a server. 🙂
So, along a similar vein of our previous tutorial for How to update OpenSSL on Debian testing (Jessie) for #Heartbleed, today we'll show you how to downgrade a Linux kernel so that you can get the patch for the recent deadly-dangerous privilege-escalation vulnerability CVE-2014-3153 if you're running on a non-stable distribution (or are running one of the latest kernels).
Continue reading →
This post is about the OpenSSL Heartbleed vulnerability that's affecting the internet right now and not directly related to the okTurtles project.
April 8, 2014 6PM EST: Looks like for this one the Debian team moved faster than their typical "minimum two-day migration" and got the fix into testing a couple of minutes ago. Good job! You can completely ignore this blog post now! I'll leave it up in case it's still a helpful illustration of how to get security fixes for testing when they're not yet available.Continue reading →