Deeplinks Blog posts about Security

Noted eagle eye and EFF Investigative Researcher Dave Maass happened on an interesting item from earlier this week on FedBizOpps, the site for government agencies to post contracting opportunities. The Navy put up a solicitation explaining that the government wants “access to vulnerability intelligence, exploit reports and operational exploit binaries affecting widely used and relied upon commercial software,” including Microsoft, Adobe, Android, Apple, “and all others.” If that weren’t clear enough, the solicitation explains that “the vendor shall provide the government with a proposed list of available vulnerabilities, 0-day or N-day (no older than 6 months old). . . .The government will select from the supplied list and direct development of exploit binaries.”

When a criminal started lacing Tylenol capsules with cyanide in 1982, Johnson & Johnson quickly sprang into action to ensure consumer safety. It increased its internal production controls, recalled the capsules, offered an exchange for tablets, and within two months started using triple-seal tamper-resistant packaging. The company focused on fixing weak points in their supply chain so that users could be sure that no one had interfered with the product before they purchased it.

The discovery last week of another major flaw in TLS was announced, nicknamed "Logjam" by the group of prominent cryptographers who discovered it. It's getting so hard to keep track of these flaws that researchers at INRIA in France created a "zoo" classifying the attacks (which is not yet updated to include Logjam or the FREAK attack discovered in March). Despite the fact that these attacks seem to be announced every few months now, Logjam is a surprising and important finding with broad implications for the Internet. In this post I'll offer a technical primer of the Logjam vulnerability.

EFF recently updated our SSL certificate and configuration. This gave us an A+ rating on SSL Labs, a great jumping off point for reviewing a site's secure connection. What follows is a quick, technical guide to how we achieved this.

Generating a Certificate

First we generate an 4096-bit RSA private key with a strong passphrase. It's useful to have a "locked" version of the key for secure archival. The passphrase is stored separately in a KeePassX database.

openssl genrsa -aes256 -out example.com.aes 4096

Next we update a .cnf file to populate the fields we want filled into the final certificate. This is especially useful when the certificate uses the Subject Alternative Name field to specify additional domain names. Here's the format: