[OpenSSL] Bleeding edge: do you dare to run it straight from Github?


Not really Let’s Encrypt related, but as we’re quite the tech-savvy’s here (at least a few of you ;)), I thought we might as well discuss it :stuck_out_tongue:

At the moment there’s code waiting on Let’s Encrypts GitHub which adds support for RFC 7633/TLS Feature extension, i.e. OCSP Must Staple.

So I thought to myself: cool, let’s generate a CSR in light of this new feature, so we can generate the certificate when the feature is implemented!

Error Loading request extension section v3_req
140307257013904:error:22097082:X509 V3 routines:DO_EXT_NCONF:unknown extension name:v3_conf.c:125:
140307257013904:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:v3_conf.c:95:name=tlsfeature, value=status_request

Darn… :fearful: It turns out: OpenSSL does have the feature: v3_tlsf.c, but it only exists in the master repository as far as I can tell… :grimacing: (v3_tlsf.c @ 1.0.2-stable = 404)

Now, as I am not running some mission critical server here and I’m running Gentoo, it’s actually quite easy to compile ánd maintain a piece of software directly from Git. Actually, my current OpenSSL is the 1.0.2-stable branch directly from Git, because 1.0.2d was missing a feature I wanted :stuck_out_tongue:

But I was wondering: how do you think of running bleeding edge security software like OpenSSL directly from Git? Could it actually be móre safe, because some bugs might be patched sooner? Or do the costs outweigh the benefits?


This worked for me:



I guess that’s a way to force something into your CSR :yum: Didn’t know that “feature” :open_mouth:

But also very interesting! I’d like to know how one comes to the DER encoded value of status_request? I can see it in the commit, but where does it come from?

I’ve already found the X.690: ASN.1 encoding rules, which would suggest it’s a BIT STRING (0x03) of length 3 (0x03) with contents 0x020105. The 0x02 identifies the “unused bits in the final subsequent octet”. Visual example: BIT STRING (Yes, from Microsoft, but hey, visual, so easy to understand :stuck_out_tongue:) Euuuh, but… 0x05… That’s 101b… That doesn’t make any sense… 3003020104 would be equal. Proof: https://lapo.it/asn1js/#0303020104 and https://lapo.it/asn1js/#0303020105 give the same result: BIT STRING(14 bit) 00000001000001 How does one arrive at the 3003020105 sequence? Google didn’t give me much results…


On that question, I’m not in favor of running the latest bleeding edge code. There’s always a chance of a major issue in function let alone security. As OpenSSL is used by many system components, it’s also one of those things you want stable and that will necessitate a lot of recompilation when changed. As a sysadmin, the very last thing I want is an OpenSSL upgrade leading to an unbootable system or having to re-build a lot of core system packages because the ABI has changed.

For me, this is one of those things where absent very specific circumstances the risks far outweigh the benefits.


Unbootable system b/c of a OpenSSL upgrade? How on earth would you get that? :stuck_out_tongue:

But indeed, there’s most certainly the issue of breakage… Unfortunately, I’ve got no clue if OpenSSL’s ABI has changed significantly between 1.0.2. and 1.1.0… :confused:

Oh, BTW, @selecadm: In the GitHub commit it says: 0303020105 and you say: 3003020105… Typo? :stuck_out_tongue: Even so, still wondering where that value exactly comes from…

Guess your version (30…) was correct: I’ve installed the master repository from GitHub (yes, I’m stubborn :astonished:) and it returns:

    TLS Feature: 


The 03-version results in:

    TLS Feature: 


Nice, I understand the DER-encoding now: 0x30: Universal, Constructed content of the SEQUENCE or SEQUENCE OF type. 0x03: length of constructed content = 3. 0x02 = type of content (INTEGER), 0x01 = length (1), 0x05 = value (5 = ‘status_request’).