Cert-ifiable: How my Mac didn’t trust a new secure site from the Feds

For about three minutes on Monday, I thought I’d uncovered a gigantic security flaw in a new government site set up to push other .gov sites towards secure browsing: When I tried visiting The HTTPS-Only Standard, my iMac’s copy of Safari reported that it couldn’t verify that site’s identity and its copy of Chrome said my connection wasn’t private.

https.cio.gov cert errorBut when you think you’ve uncovered an obvious error in a site that’s been out for over a week, it’s usually your own setup at fault. And within minutes of my tweeting about those warnings, I got a reply from the guy who configured the site saying he couldn’t reproduce the problem.

After some quick testing on this computer, my MacBook Air, my iPad and my phone (during which I silently congratulated myself for editing some accusatory sarcasm out of that tweet before posting it), I realized this fault was confined to Safari and Chrome on my two Macs. Every other browser, including Firefox on my iMac, got through to that HTTPS-Only site normally.

Further Twitter conversations pointed me to each Mac’s store of saved site certificates, accessible in the Keychain Access app. For Safari and Chrome to encrypt a connection to that government site, OS X needed to match its digital certificate against a sort of master key, a “root certificate” stored in the system.

old Comodo certificate(For a better description of how the mathematical magic of encrypted browsing happens, consult my friend Glenn Fleishman’s 2011 explainer for the Economist.)

Both Macs had an old copy of Comodo Group’s root certificate, one not listed on Apple’s inventory of trusted root certs. I tried deleting that certificate, figuring it probably wouldn’t make things worse–and that was all it took for the HTTPS-Only site to work as advertised and for one or two other sites to stop coughing up security warnings.

With my encrypted browsing back to normal, I’m left to wonder how my system keychains got tangled up like that. Any theories? Before you ask: Yes, I’ve done a full scan with the ClamXav malware scanner and haven’t found any issues.

Correlation or causation: Verizon, LastPass and last weekend’s USAT column

The reaction to last weekend’s USA Today column has been interesting and a little confusing.

LastPass logoOn one hand, I’ve seen a variety of reader reports–more in reader e-mail and in comments on the post I wrote here first to see if this was a wider problem as well as on the Facebook page post in which I shared the column than in comments on the column itself–of other Verizon login failures.

On the other hand, Verizon is now thinking that this is related to my using LastPass. My PR contact there said that one of his colleagues had noticed the screenshot in my post here revealed that I use that password-manager service and suggested I try disabling its extension in the problematic copy of Safari.

I thought that a somewhat ridiculous suggestion, since each time I’d typed in the password instead of letting LastPass enter it for me. But once I did that, I could log in normally. And when I enabled it again, I got the same login failure as before. There’s correlation here. Causation? I don’t know.

I e-mailed LastPass’s CEO Joe Siegrist (not because I thought this a CEO-level issue, but because we met a few years ago and I’ve always found him quick to reply to a query) to ask his people to look into things.

If they can reproduce and, better yet, document a problematic interaction, that would be good to know and a good thing to add to the column. If they can’t (a distinct possibility considering that the guy I quoted in the column having a similar problem, PhoneScoop editor Rich Brome, told me he doesn’t use LastPass), the mystery will continue.

In the meantime, I’ll throw this question out there: If you use LastPass, have you seen any other cases of a login with a valid password failing?

PGP and me

If you’ve received an e-mail from me in the past week or so, you may have noticed something extra in the message’s headers: an indication that it was digitally signed with my Pretty Good Privacy key.

GPGTools iconAs yet, no recipient has asked about that, much less complimented my digital hygiene or sent a reply encrypted with my PGP public key. Which is pretty much what I expected: The last time I had a PGP setup in operation, I had to ask Post readers to send me an encrypted message before I got any.

A few weeks later, my inbox once again featured only un-encrypted e-mail.

Then some fumbled corporate transitions and the switch to OS X left the open-source MacGPG as the most appealing option on my Mac–and a slow and slowing pace of updates left it an increasingly awkward fit. Without ever consciously deciding to give up on e-mail encryption, I gave up.

(I should have felt guiltier than I did when I offered a Post colleague a tutorial on crypto that I didn’t bother to operate on my own machine. On that note, if you have a key for robp@washpost.com or rob@twp.com in your own PGP keychain, please delete it.)

I finally returned to the fold two weeks ago, when I ducked into a “crypto party” tutorial at the Computers, Freedom & Privacy conference. Jon Camfield of Internews explained that things had gotten a lot better and pointed me to a newer, far more elegant open-source implementation called GPGTools. I downloaded it, installed it, and within minutes had a new set of public and private keys plugged into my copy of Mail (no need to copy and paste a message into a separate decryption app as I did in MacGPG), with my public key uploaded to a keyserver for anybody else to use to encrypt mail to me.

My key ID is 03EE085A, my key fingerprint is FD67 6114 46E8 6105 27C3 DD92 673F F960 03EE 085A, and the key itself is after the jump. Do I expect to get a flood of encrypted messages after this post? Not really. But if somebody does want to speak to me with that level of privacy, they now have an option I should have provided all along, and that’s what counts.

Continue reading

Mail merge? Work, home and other e-mail addresses

I keep telling myself that one of ways I maintain what’s left of my work/life balance is to have separate home and work e-mail addresses. And yet I have to ask who I’m kidding when these two Google Apps accounts, each at its own domain name, constitute separate lines or windows in a mail client, and when I’m sometimes corresponding with the same person from each address on alternate days. Meanwhile, many people I know seem to function perfectly fine with one all-purpose e-mail address.

MailboxIn a prior millennium, it was an easier call. After having lost a bunch of messages from friends during a transition from one e-mail system to another at the Post–and then discerning the dreadfulness of the new Lotus Notes system–I had little interest in trusting personal correspondence to my employer’s IT department.

I also figured that I would have less trouble staying on top of friends-and-family e-mail if it weren’t competing for space and attention in the first screen of my inbox with random PR pitches, interoffice memos and chit-chat with other journalists. And the address that wasn’t listed on a major newspaper’s Web site should, in theory, get vastly less spam.

(Because I am this persnickety about my communications tools, I also have a regular Gmail account that I use for almost all of my online commerce, financial transactions and other things that are neither personal- nor work-related. I don’t mind the ads there, while my Google Apps inboxes have no such distractions, courtesy of Google ending ad scanning for Apps users–even those on the free version it no longer offers to new users.)

It’s been years since I’ve had to worry about IT-inflicted mail misery. What about the other virtues of this split setup?

  • Being able to flag messages for follow-up means I’m now less likely to forget to answer an important message, whatever address it was sent to.
  • But I don’t need 11 different folders to sort my home e-mail after I’ve dealt with it. Less cognitive load is a good thing.
  • Having to ask myself nit-pick questions like “since I’m asking a friend about something that may lead to him being quoted in a story, should I send this message from my work address?” increases my cognitive load.
  • Searching for messages and then looking over the results is faster when I’m excluding an entire account’s worth of e-mail. But when I ask Mail for OS X to query all of the gigabytes of messages that have accumulated at both addresses… ugh.
  • My anti-spam strategy has been a total bust. When I checked earlier this morning, Google had quarantined almost 1,500 spam messages in my home account, about 100 of which were messages on my neighborhood mailing list that shouldn’t have been screened as junk.

On that last note, here’s a question for you all to ponder: That mailing list will soon be moving to a commercial hosting service subsidized by ads, and of course I haven’t yet read its privacy policy. Should I switch my subscription to my Gmail address, where I can read those messages alongside those from my neighborhood’s smaller Nextdoor group, or should I keep using my home address there?

 

Heartbleed and bleeding-heart open-source advocacy

For at least the last decade, I’ve been telling readers that open-source development matters and helps make better software. If everybody can read the code of an application or an operating system, there can’t be any hidden backdoors; if anybody can rewrite that code to fix vulnerabilities and add features, the software’s progress can’t be thwarted by any one company’s distraction, fraud or bankruptcy.

OpenSSL pitchMy glowing endorsement of Mozilla Firefox 1.0 in November 2004 set the tone:

…the beauty of an open-source product like this is that you can participate in its evolution. Firefox’s code is open for anybody to inspect and improve...

Since then, I’ve recommended open-source operating systems, office suites, anti-virus utilitiessecure-deletion tools, file-encryption software, two-factor authentication apps, PDF exporters, DVD rippers and video-playback toolkits. And I’ve had one phrase in mind each time: Given enough eyeballs, all bugs are shallow.

My experience using open-source software tells me this is true–even if that doesn’t guarantee a constant rate of improvement or an elegant interface.

And if any genre of software should benefit from this method of development, it ought to be code that Web sites use to secure their interactions with users from eavesdropping: Everybody sending or storing private information needs this feature, billions of dollars of transactions are at stake, and you don’t even have to worry about wrapping a home-user-friendly UI around it.

True, right? Except Heartbleed happened. Two years ago, an update to the widely-used OpenSSL encryption library added a “heartbeat” function that made it easier for sites to keep an encrypted session going. But it also harbored an disastrous vulnerability to buffer-overflow attacks that would cause a site to return 64 kilobytes of whatever happened to be adjacent in the server’s memory to an attacker: usernames, passwords, e-mail content, financial transactions, even the private key the site uses to encrypt the session. And the attacked site can’t check afterwards to see if it got hit. I defy the NSA to script a better hack.

And despite buffer overflows being a well-known risk with documented defenses, nobody caught this for two years. Two years! It took a Google researcher and engineers at the Finnish security firm Codenomicon to find the bug separately and report it to the OpenSSL team.

How bad is this? Ask security researcher Bruce Schneier:

“Catastrophic” is the right word. On the scale of 1 to 10, this is an 11.

It seems that everything that could go right in open source development went wrong in this case. As an excellent story from Craig Timberg in the Post outlines, the free nature of OpenSSL made it an obvious choice for hundreds of thousands of sites and something of a natural monopoly, that same enormous deployment of OpenSSL encouraged people to assume that they themselves didn’t need to inspect the code that carefully, and OpenSSL developers got so little financial support from the corporations relying on their work that they couldn’t even subject their code to a proper security audit.

The stupid thing is, we knew this could happen. See John Viega’s 2000 essay, “The myth of open source security,” in which he outlines how thousands of users failed to catch “a handful of glaring security problems” in code he’d contributed to the Mailman mailing-list manager:

Everyone using Mailman, apparently, assumed that someone else had done the proper security auditing, when, in fact, no one had.

That doesn’t mean that closed-source development suddenly looks better. (When all this is done, Microsoft’s proprietary and hideous Internet Explorer 6 may still have greased the skids for more successful attacks than OpenSSL.) But it does mean that selfishness/laziness/distraction and open source can become a toxic mix, one we should have seen coming.

Updated, 10:25 a.m., to add a link to Viega’s prescient article.

I don’t like sketchy ads either

Almost two years ago, I got invited to join WordPress.com’s WordAds program, and for the most part it’s worked well–aside from these advertisements failing to earn me truckloads of money, as opposed to enough for a nice dinner every now and then.

Walmart voucher adBut a week or so ago, a few of the ads sent here by this program started looking distinctly sketchier. One made diet claims unlikely to survive scrutiny by the Food and Drug Administration, while another made the economically implausible offer of a free $1,000 Walmart voucher. And sometimes the appearance of these ads was followed by one of those spammy pop-up ads for the MacKeeper app–also served by the same Tribal Fusion ad network.

That’s not the “high quality” content WordPress promised when it launched this partnership with Federated Media. So I posted a cranky tweet about it and then followed up with a complaint sent through the appropriate form, saying that “If you don’t kick these garbage advertisers out of WordAds, I’ll drop out of the program.” (That was an easy threat to make, since I don’t have that much money at stake.)

I got a quick acknowledgment saying that my gripe was legitimate, followed the next day by a report that the advertiser had removed the offending items and pledged to clean up its act.

I haven’t seen any objectionable ads since; it appears the system worked. But if you see ads making a pitch that looks dodgy, let me know about it. Bad ads are a Web-wide problem, and the least I can do is not have my little corner of the Web contribute to it.