Canonical Voices

Posts tagged with 'openssl'

Dustin Kirkland


Upon learning about the Heartbleed vulnerability in OpenSSL, my first thoughts were pretty desperate.  I basically lost all faith in humanity's ability to write secure software.  It's really that bad.

I spent the next couple of hours drowning in the sea of passwords and certificates I would personally need to change...ugh :-/

As of the hangover of that sobering reality arrived, I then started thinking about various systems over the years that I've designed, implemented, or was otherwise responsible for, and how Heartbleed affected those services.  Another throbbing headache set in.

I patched DivItUp.com within minutes of Ubuntu releasing an updated OpenSSL package, and re-keyed the SSL certificate as soon as GoDaddy declared that it was safe for re-keying.

Likewise, the Ubuntu entropy service was patched and re-keyed, along with all Ubuntu-related https services by Canonical IT.  I pushed an new package of the pollinate client with updated certificate changes to Ubuntu 14.04 LTS (trusty), the same day.

That said, I did enjoy a bit of measured satisfaction, in one controversial design decision that I made in January 2012, when creating Gazzang's zTrustee remote key management system.

All default network communications, between zTrustee clients and servers, are encrypted twice.  The outer transport layer network traffic, like any https service, is encrypted using OpenSSL.  But the inner payloads are also signed and encrypted using GnuPG.

Hundreds of times, zTrustee and I were questioned or criticized about that design -- by customers, prospects, partners, and probably competitors.

In fact, at one time, there was pressure from a particular customer/partner/prospect, to disable the inner GPG encryption entirely, and have zTrustee rely solely on the transport layer OpenSSL, for performance reasons.  Tried as I might, I eventually lost that fight, and we added the "feature" (as a non-default option).  That someone might have some re-keying to do...

But even in the face of the Internet-melting Heartbleed vulnerability, I'm absolutely delighted that the inner payloads of zTrustee communications are still protected by GnuPG asymmetric encryption and are NOT vulnerable to Heartbleed style snooping.

In fact, these payloads are some of the very encryption keys that guard YOUR health care and financial data stored in public and private clouds around the world by Global 2000 companies.

Truth be told, the insurance against crypto library vulnerabilities zTrustee bought by using GnuPG and OpenSSL in combination was really the secondary objective.

The primary objective was actually to leverage asymmetric encryption, to both sign AND encrypt all payloads, in order to cryptographically authenticate zTrustee clients, ensure payload integrity, and enforce key revocations.  We technically could have used OpenSSL for both layers and even realized a few performance benefits -- OpenSSL is faster than GnuPG in our experience, and can leverage crypto accelerator hardware more easily.  But I insisted that the combination of GPG over SSL would buy us protection against vulnerabilities in either protocol, and that was worth any performance cost in a key management product like zTrustee.

In retrospect, this makes me wonder why diverse, backup, redundant encryption, isn't more prevalent in the design of security systems...

Every elevator you have ever used has redundant safety mechanisms.  Your car has both seat belts and air bags.  Your friendly cashier will double bag your groceries if you ask.  And I bet you've tied your shoes with a double knot before.

Your servers have redundant power supplies.  Your storage arrays have redundant hard drives.  You might even have two monitors.  You're might be carrying a laptop, a tablet, and a smart phone.

Moreover, important services on the Internet are often highly available, redundant, fault tolerant or distributed by design.

But the underpinnings of the privacy and integrity of the very Internet itself, is usually protected only once, with transport layer encryption of the traffic in motion.

At this point, can we afford the performance impact of additional layers of security?  Or, rather, at this point, can we afford not to use all available protection?

Dustin

p.s. I use both dm-crypt and eCryptFS on my Ubuntu laptop ;-)

Read more
Ben Howard

Many of our Cloud Image users have inquired about the availability of updated Ubuntu Cloud Images in response to the Heartbleed OpenSSL Vulnerability [1]. Ubuntu released update Ubuntu packages for OpenSSL 08 April 2014 [2]. Due to the exceptional circumstances and severity of the Heartbleed OpenSSL bug, Canonical has released new 12.04.4 LTS, 12.10 and 13.10 Cloud Images at [3].

Canonical is working with Amazon to get the Quickstart and the AWS Marketplace links updated. In the meantime, you can find new AMI ID's at [3] and [4]. Also, the snapshot's for Amazon have the volume-create permission granted on the latest images.

Windows Azure [5], Joyent [6] and HP [7, 8, 9] all have updated Cloud Images in their respective galleries.

If you are running an affected version of OpenSSL on 12.04 LTS, 12.10 or 13.10, you are strongly encouraged to update. For new instances, it is recommended to either use an image with a serial newer than 20140408, or update your OpenSSL  package immediately upon launch. Finally, if you need documentation on enabling unattended upgrades, please see [10].


[1] https://www.openssl.org/news/secadv_20140407.txt
[2] http://www.ubuntu.com/usn/usn-2165-1/
[3] 12.04.4 LTS: http://cloud-images.ubuntu.com/releases/precise/release-20140408/
     12.10: http://cloud-images.ubuntu.com/releases/quantal/release-20140409/
     13.10: http://cloud-images.ubuntu.com/releases/saucy/release-20140409.1/
[4] http://cloud-images.ubuntu.com/locator/ec2/
[5] Azure: Ubuntu-12_04_4-LTS-amd64-server-20140408-en-us-30GB
                 Ubuntu-12_10-amd64-server-20140409-en-us-30GB
                 Ubuntu-13_10-amd64-server-20140409.1-en-us-30GB
[6] Joyent Images:
        "ubuntu-certified-12.04", fe5aa6c0-0f09-4b1f-9bad-83e453bb74f3
        "ubuntu-certified-13.10", 049dfe64-6c37-4b88-8e89-4b8aa0f129f2
[7] HP US-West-1:
          12.04.4: 27be722e-d2d0-44f0-bebe-471c4af76039
          12.10: 065bb450-e5d0-4348-997d-e4d9e359b8fb
          13.10: 9d7d22d0-7d43-481f-a7eb-d93ea2791409
[8] HP US-East-1:
          12.04.4 8672f4c6-e33d-46f5-b6d8-ebbeba12fa02
          12.10: cbb44038-2602-48d5-b609-e05f4b61be9a
          13.10: 00398423-7429-4064-b781-fa0af00449c8
[9] Waiting on HP for replication to legacy regions az-{1,2,3}
[10] https://help.ubuntu.com/community/AutomaticSecurityUpdates

Read more