Page MenuHomePhabricator

openssl 1.0.2 packaging for jessie
Closed, ResolvedPublic

Description

We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN.

It's currently available in Stretch, and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment.

Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:

  • Patch - We could patch in a high-perf implementation of chacha20poly1305 from Cloudflare. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/
  • Sec Non-Issue According to Debian's Security Tracker, the Stretch 1.0.2c-1 package lacks fixes for CVE-2015-4000 / Logjam which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:
    1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue.
    2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.

Event Timeline

BBlack raised the priority of this task from to Needs Triage.
BBlack updated the task description. (Show Details)
BBlack added projects: acl*sre-team, Traffic.
BBlack added subscribers: BBlack, MoritzMuehlenhoff, faidon.

I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:
The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000.

I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny.

As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639).

I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:
The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000.

I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny.

As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639).

I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with "upstream" branch tracking openssl.org orig tarballs and "master" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl

I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component "backport" of jessie-wikimedia. However, the reprepro command had some failure output:

root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes
.changes put in a distribution not listed within it!
Ignoring as --ignore=wrongdistribution given.
Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents!

This seems to be related to /srv/wikimedia/conf/distributions jessie stanza lacking backports in UDebComponents?

Origin: Wikimedia
Label: Wikimedia
Suite: jessie-wikimedia
Codename: jessie-wikimedia
AlsoAcceptFor: jessie jessie-backports
Version: 8
Architectures: source amd64 i386
Components: main backports thirdparty
UDebComponents: main
Update: hwraid cassandra
Description: Wikimedia packages for Debian Jessie
SignWith: default
DebOverride: deb-override
Log:
 log

But I'm not sure if the right answer is to fix it there or not...

BBlack triaged this task as Medium priority.Jun 29 2015, 6:53 PM
BBlack moved this task from Triage to In Progress on the Traffic board.

(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)

(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)

That would work as well; the udebs are only needed for d-i.

BBlack claimed this task.
BBlack moved this task from In Progress to Done on the Traffic board.

Do we have jessie package already in stable ?

@Remware: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.

I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.

My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...

My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...

jessie will stick with 1.0.1, the update to 1.0.2 was requested by the OpenSSL maintainer during the freeze, but declined by the release managers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767661