A Geek With Guns

Chronicling the depravities of the State.

Archive for the ‘Encrypt Everything’ Category

Guns, Weed, and Crypto

without comments

Because I advocate apolitical action to achieve change in the world I periodically get political types snidely asking, “Well what have you done for liberty?” It’s a fair question. My recent efforts have been primarily focused on teaching people how to defend themselves online. Fortunately I’m not alone. I’ve been working with some phenomenal people to run CryptoPartyMN, and organization created specifically to teach people how to use security means of communications.

Our work hasn’t gone unnoticed either. A few weeks ago James Shiffer from the Star Tribune contacted us. He was working on an article covering Crypto War II and wanted to interview members of CryptoPartyMN to understand the counterarguments to the State’s claims that effective cryptography puts everybody at risk. In addition to interviewing several of us he also attended the last CryptoParty. The result was this article. As you can tell from the article we’ve got everything you could possibly want:

The three CryptoParty presenters were Burg, 32, a Twin Cities software developer and Second Amendment supporter whose blog is called “A Geek With Guns.” The two others are cannabis activists Cassie Traun, 26, an IT professional who “never really trusted the government,” and Kurtis Hanna, 30, an unsuccessful candidate for Minneapolis mayor and state Legislature who said he became interested in the issue after the revelations of NSA spying.

Guns, weed, and crypto. Between the three of us we’ve got pretty much every important freedom issue covered!

So, yeah, that’s one of the things I’ve been up to.

Written by Christopher Burg

December 8th, 2015 at 10:00 am

Let’s Encrypt To Enter Public Beta On December 3rd

without comments

Unfortunately there are a lot of websites that still aren’t utilizing HTTPS to ensure confidential and unaltered communications between them and their users. One of the excuses often given by website administrators for not using HTTPS is that certificates cost money. Another excuse is that managing certificates is a huge pain in the ass.

StartSSL has been providing free certificates for years but administrators still have to manually manage them. A while ago a group of people decided to kill both birds with a single stone and began work on Let’s Encrypt. Let’s Encrypt is a certificate authority and software package that work together to provide automatically managed certificate to websites. It’s been in closed beta for a while and starting December 3rd it will be making the beta test available to the public.

This means anybody wanting a certificate will be able to request one. It also means there will no longer be any excuses for websites not to implement HTTPS. And with the ever more pervasive surveillance state it’s absolutely necessary to make HTTPS the default.

Written by Christopher Burg

November 13th, 2015 at 10:30 am

LastPass Sold To LogMeIn

with 2 comments

LastPass, a password manager I have been recommending for years due to its ease of use and compatibility with pretty much everything, was bought out by LogMeIn. Based on what I’ve read on Twitter, Ars Technica, and Reddit LogMeIn is not a well liked company. In my experience acquisitions usually end up badly for users of the product being acquired. The fact that LogMeIn is viewed so negatively by a huge portion of the Internet further exacerbates my concerns that his acquisition is not good news for LastPass users.

I believe password managers are one of the easiest ways for the average person to improve their security. Due to this acquisition I can’t as confidently recommend LastPass as I have been previously doing. While I’m not going to go so far as to say you shouldn’t use LastPass, as the future is not known, I want to have other recommendations available if things go south.

To that end I’m going to recommend two products. The first is KeePassX. KeePassX is a free password manager that’s available for Windows, Linux, and OS X. It’s an open source product and seems to be well respected amongst users. Unfortunately syncing isn’t available out of the box (there are ways you can setup syncing though), which limits its utility for people who commonly use multiple devices. For many people this could be seen as a feature though as having your passwords, even in an encrypted formate, stored on a third-party server creates more opportunities for compromise. There also seems to be an absence of decent mobile clients.

The second password manager I’m going to recommend, and it’s the one I’m not using, is 1Password. 1Password was the runner up when I was first choosing a password manager. The two reasons I chose LastPass over it were price, LastPass Premium is much cheaper than 1Password, and the fact 1Password isn’t compatible with Linux. It is, however, compatible with OS X, Windows, iOS, and Android. Since I only use Linux and Windows in virtual machines the fact I don’t have password manager for those platforms isn’t that big of a deal (in fact I’ve never used LastPass on either platform outside of initial testing). 1Password can also sync your passwords across your devices with iCloud, Dropbox, or on your local network (although the last option only works between a single Mac and iOS devices so it’s severely limited). Right now the price is pretty reasonable as the developers are having a 40% off sale that is totally because of Cybersecurity Awareness Month and not at all because LastPass’s customers are pretty unhappy right now (it’s just a coincidence the sale start shortly after the news of LastPass’s acquisition broke).

It’s too early to panic over the LastPass acquisition. LogMeIn is promising to keep LastPass’s currently business model in place although those promises don’t seem to be well received due to the company’s history. I switched immediately because the writing on the wall isn’t to my liking and because I want to be familiar with an alternative in case things go south. If you’re happy with LastPass and the acquisition isn’t a concern for you (and let’s be honestly, it won’t be a concern for anybody for a while as it takes some time for the consequences of company acquisitions to manifest) keep using it.

Written by Christopher Burg

October 9th, 2015 at 6:00 pm

Verizon To Sell Customer Data To AOL

without comments

There is a battle between Verizon and AT&T to determine which of the two companies is the most evil. Both companies have gone to tremendous lengths to fuck their customers over but Verizon’s latest ploy may be enough to put it ahead:

Verizon is giving a new mission to its controversial hidden identifier that tracks users of mobile devices. Verizon said in a little-noticed announcement that it will soon begin sharing the profiles with AOL’s ad network, which in turn monitors users across a large swath of the Internet.

That means AOL’s ad network will be able to match millions of Internet users to their real-world details gathered by Verizon, including — “your gender, age range and interests.” AOL’s network is on 40 percent of websites, including on ProPublica.

Here again we see the need for HTTPS everywhere. The key to Verizon’s tracking technology is its ability to inject a tracking number into its customers’ web traffic. HTTPS is not only good at preventing people in the middle of a client-server communication from seeing content. It’s also good at preventing people in the middle from altering the content in any way.

Verizon’s tracking technology works by exploiting the fact insecure web traffic can be modified. The modification, in this case, is including a traffic number, that is invisible to the user, into a customer’s web traffic. This is made possible by the fact Verizon, the customer’s Internet service provide, sits in the middle of all communications between its customers and the Internet. By using HTTPS to secure the connect between the customer and websites on the Internet Verizon can no longer alter the traffic and therefore cannot inject its tracking number.

I’m obviously beating a dead horse on this one but I will continue to do so until every website using HTTPS exclusively.

Written by Christopher Burg

October 8th, 2015 at 10:00 am

AT&T Demonstrates Why HTTPS Is Needed Everywhere

without comments

Ads have become a notable threat to computer security. While they are a fact of life for accessing content without paying directly for it you wouldn’t expect a company that you pay money to to infest your web experiences with ads. But some companies like to double dip. AT&T is one of those companies. In addition to getting customers to pay for hotspots AT&T is also maliciously inserting ads into websites visiting through its hotspots:

While traveling through Dulles Airport last week, I noticed an Internet oddity. The nearby AT&T hotspot was fairly fast—that was a pleasant surprise.

But the web had sprouted ads. Lots of them, in places they didn’t belong.

[…]

Curious, and waiting on a delayed flight, I started poking through web source. It took little time to spot the culprit: AT&T’s wifi hotspot was tampering with HTTP traffic.

The ad injection platform appears to be a service from RaGaPa, a small startup. Their video pitch features “MONETIZE YOUR NETWORK” over cascading dollar signs. (Seriously.)

When an HTML page loads over HTTP, the hotspot makes three edits. (HTTPS traffic is immune, since it’s end-to-end secure.)

First, the hotspot adds an advertising stylesheet.

[…]

Next, it injects a backup advertisement, in case a browser doesn’t support JavaScript. It appears that the hotspot intercepts /ragapa URLs and resolves them to advertising images.

[…]

Finally, the hotspot adds a pair of scripts for controlling advertisement loading and display.

The title of this post promised Hypertext Transfer Protocol Secure (HTTPS) so some may be wondering what HTTPS has to do with ad injection. Simply put, this kind of bullshit can’t happen when the connection between a client and the server is encrypted. A man in the middle, which AT&T is in this case, cannot see the contents of an encrypted communication and if attempts to make any sort of alteration the decryption process will fail.

You won’t see any AT&T injected ads on this blog because everything is secured with HTTPS (the insecure HTTP interface just 301 redirects to the HTTPS connection). If every website did this the business model being used by RaGaPa, the ad injection services being used by AT&T, would be a total failure.

Securing connections doesn’t just protect against eavesdropping. It also protects again altering the contents, which can be just as big of a problem if not an even bigger one. In fact content integrity is another reason why the “nothing to hide” crowd should be ignored in discussions of pervasive cryptography. Cryptography is about so much more than hiding content.

Written by Christopher Burg

August 27th, 2015 at 10:00 am

The Best Argument For Encryption Yet

without comments

I’ve made a lot of good arguments favoring effective encryption. Effective encryption protects at risk people from oppressors by concealing their identities and communications, ensures data integrity by preventing third parties from altering data unknowingly, provides a way to verify authenticity and the identity of content creators, etc. Ironically though Jeb Bush made have inadvertently made the best argument for effective encryption:

“If you create encryption, it makes it harder for the American government to do its job—while protecting civil liberties—to make sure that evildoers aren’t in our midst,” Bush said in South Carolina at an event sponsored by Americans for Peace, Prosperity, and Security, according to The Intercept.

Effective encryption makes the American government’s job harder?

grumpy-cat-good

Assault, murder, theft, extortion, and kidnapping should be hard and anything that makes those criminal activities harder is a good thing.

Written by Christopher Burg

August 21st, 2015 at 10:30 am

OpenVPN

without comments

After getting my business Internet account the first thing I did was setup a virtual private network (VPN) server. VPN servers have a million and one uses but the most important feature they offer me is the ability to have a secure tunnel when connected to networks that aren’t mine. I settled on L2TP/IPSec since that was the more secure of the two options offered by OS X Server (as you can tell the running theme with my network has been migrating away from OS X Server).

L2TP/IPSec served its purpose, it gave me a secure tunnel to my home network, but there were several notable downsides. The biggest of which was the way it was handled by iOS. iOS disconnects from an L2TP/IPSec VPN server when the device is turned off and doesn’t automatically reconnect when it is turned on again. That means I had to go into the settings and manually turn it on whenever I wanted to use it (which is often). I know, first world problems.

Last week I began setting up a replacement VPN server, this one using OpenVPN. This ended up being a phenomenal leap forward. OpenVPN uses OpenSSL for encryption and authentication. That gives you a lot of options. For my purposes I restricted my OpenVPN server to only use TLSv1.2 (the latest), forward secrecy, and known strong encryption and authentication algorithms. Instead of using a pre-shared key, which is an option, I’m using certificates. Using certificates offers several advantages but the most important one to me is that iOS will automatically reconnect to a VPN server if authentication is performed with certificates. OpenVPN has a great, albeit ugly as sin, client for iOS that can import OpenVPN profiles. Best of all the app doesn’t need to be running for the VPN connection to remain connected (so you don’t have to worry about the tunnel closing after 10 minutes since that’s the longest amount of time an app can run in the background on iOS). Now when I turn my phone on it automatically connects to my VPN server.

Since OpenVPN utilizes TLS it’s supposedly difficult to distinguish from HTTPS traffic, which means it’s less likely a network filter will block you from connecting to your VPN server. I don’t have access to a network that hostile so I can speak to the effectiveness of this but it’s something to keep in mind if you regularly find yourself connecting devices to a heavily filtered network.

If you’re interested in setting up a VPN server I highly recommend OpenVPN. It’s fairly simple to setup and clients are available for most operating systems.

Written by Christopher Burg

June 30th, 2015 at 11:00 am

Why Everybody Should Use Encryption

with 2 comments

Using encryption requires individuals to put forth the effort to learn. Because people tend to be lazy they usually spend more time coming up with excuses for not learning encryption than they do learning how to use it. Ultimately the excuse they end up settling on is that they have nothing to hide. This is bullshit, of course. If they truly didn’t have anything to hide they would put Internet accessible cameras and microphones in every room of their house and allow anybody to check in on what they’re doing at any time. But they don’t.

Besides the fact that we all have something to hide there is another reason why the “nothing to hide” excuse doesn’t work. To quote Bruce Schneier:

Encryption should be enabled for everything by default, not a feature you turn on only if you’re doing something you consider worth protecting.

This is important. If we only use encryption when we’re working with important data, then encryption signals that data’s importance. If only dissidents use encryption in a country, that country’s authorities have an easy way of identifying them. But if everyone uses it all of the time, encryption ceases to be a signal. No one can distinguish simple chatting from deeply private conversation. The government can’t tell the dissidents from the rest of the population. Every time you use encryption, you’re protecting someone who needs to use it to stay alive.

By not using encryption you are putting lives in danger. Specifically the lives of people who need encryption to stay alive. So long as a majority of people utilize unencrypted forms of communication the presence of encryption becomes a signal that indicates to a snoop that the captured data is important. If all data, from e-mails wishing grandma a happy birthday to plans for protesting the latest act of police brutality, is encrypted then the spies can’t use it to indicate what is and isn’t important. At that point their costs skyrocket because the only way for them to learn what is and isn’t important is to decrypt everything, which isn’t feasible for any organization.

So stop making excuses and learn how to encrypt your data. There are plenty of people out there, including myself, willing to help you. If you don’t then you’re contributing to a problem that puts real lives in danger.

Written by Christopher Burg

June 26th, 2015 at 11:30 am

The Sorry State of E-Mail

with 3 comments

As I briefly mentioned last week I’ve been spending time setting up a new e-mail server. For years I’ve been using OS X Server to run my e-mail server because it was easy to setup. But there are a lot of things I dislike about OS X Server. The biggest problem was with the change from 10.6 to 10.7. With that update OS X Server went from being a fairly serious piece of server software that a small business could use to being almost completely broken. Apple slowly improved things in later released of OS X but its server software remains amateur hour. Another thing that I dislike about OS X Server is how unstable it becomes the moment you open a config file and make some manual changes. The graphical tool really doesn’t like that but it also don’t give you the options necessary to fine tune your security settings.

My e-mail server has grown up and now runs on CentOS. I’ve tried to tighten up security as much as possible but I’ve quickly learned how sorry of a state e-mail is in. One of my goals was to disable broken Transport Layer Security (TLS) settings. However this presents a sizable problem because there are a lot of improperly configured e-mail servers out there. Unlike web servers where you can usually safely assume clients will be able to establish a connection with a sever using properly configured TLS no such assumptions can be made with e-mail servers. Some e-mail servers don’t support any version of TLS or Secure Socket Layer (SSL) and those that do often have invalid (expired, self-signed, etc.) certificates. In other words you can’t disable unsecured connections without being unable to communicate with a large number of e-mail servers out there. Let me just say that as much as I hate how everybody uses Google because it makes the government’s surveillance apparatus cheaper to implement I appreciate that the company actually has properly configured e-mail servers.

Another problem with securing e-mail servers is that they rely on the STARTTLS protocol. I say this is a problem because the first part of establishing a secure connection via STARTTLS is asking the server if it supports it through an unsecured connection. This has allowed certain unscrupulous Internet service providers (ISPs) to intercept and edit out the mention of STARTTLS support from a server’s reply, which causes the client to revert to an unsecured connection for the entire communication. This wouldn’t be a problem if we could safely assume all e-mail servers support TLS because then you could configure servers to only use TLS.

What’s the answer? Ultimately I would say it is to move away from e-mail as we currently know it. But that’s easier said than done so I will continue to strong urge people to utilize Pretty Good Privacy (PGP) to encrypt and sign their e-mails. Even if a PGP encrypted e-mail is transmitted over an unsecured connection the amount of data a snoop can collect on you is far less (but since PGP can only really encrypt the contents of the e-mail a great deal of metadata is still available to anybody observing the communication between e-mail servers).

I also urge people to learn how to setup their own e-mail servers and to do it. Ars Technica and Sealed Abstract have good guides on how to setup a pretty secure e-mail server. However there is the problem that many ISPs block the ports used by e-mail server on their residential packages. So implementing an e-mail server out of your home could require getting a business account (as well as a static Internet protocol (IP) address). A slightly less optimal (because your e-mail won’t be stored on a system you physically control) option of setting up your e-mail server on a third-party host is a way to bypass this problem. Unless people stop relying on improperly configured e-mail servers there isn’t a lot of hope for salvaging e-mail as a form of secure communication (this should give people involved in professions that require confidentiality, such as lawyers, a great deal of concern).

Many people will probably become discouraged after reading this post and tell themselves that securing themselves is impossible. That’s not what you should take away from this post. What you should take away from this post is that the problem requires us to roll up our sleeves, further our knowledge, and fix it ourselves. Securing e-mail isn’t hopeless, it just requires us to actually do something about it. For my part I am willing to answer questions you have regarding setting up an e-mail server. Admittedly I won’t know the answer to every question but I will do my best to provide you with the knowledge you need to secure yourself.

Written by Christopher Burg

June 22nd, 2015 at 11:00 am

Is Your App a Benedict Arnold

without comments

Most smartphone users rely on apps to access much of their online data. This can be problematic though since many app developers have little or no knowledge about security. A research project has unveiled a number of Android apps, many of which are developed by companies with deep enough pockets to hire dedicated security personnel, that communicate user credentials over plaintext:

Researchers have unearthed dozens of Android apps in the official Google Play store that expose user passwords because the apps fail to properly implement HTTPS encryption during logins or don’t use it at all.

The roster of faulty apps have more than 200 million collective downloads from Google Play and have remained vulnerable even after developers were alerted to the defects. The apps include the official titles from the National Basketball Association, the Match.com dating service, the Safeway supermarket chain, and the PizzaHut restaurant chain. They were uncovered by AppBugs, a developer of a free Android app that spots dangerous apps installed on users’ handsets.

By communicating your credentials over plaintext these apps are betraying your account security to anybody listening on the network. What makes this particular problem especially worrisome is that it’s difficult for the average user to detect. How many users are going to connect their phone to their wireless network, open up Wireshark, and ensure all of their apps are communicating over HTTPS?

Developers should be expected to understand HTTPS if they’re communicating user credentials back to a server. But the real source of this problem is the fact plaintext is still allowed at all. We’re well beyond the point where HTTP should be deprecated, in fact Mozilla is planning to do exactly that, in favor of HTTPS only. If HTTP is no longer allowed then we don’t have to worry about apps communicating data over it (we still have to worry about improperly configured HTTPS but that’s something we have to worry about currently).

Written by Christopher Burg

June 22nd, 2015 at 10:30 am