Re: 63 bit certificate ID is libressl affected?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: 63 bit certificate ID is libressl affected?

Tom Smyth
Thanks Ingo for your (as always) good attention to detail
and detailed feedback  I really appreciate it ...


Point taken Ingo re the patch... :)  and tech@ :)
and discussion duly moved to misc@
it was more of a heads up

Ill work on my programming skills :)

cheers,

Tom Smyth

On Wed, 13 Mar 2019 at 22:32, Ingo Schwarze <[hidden email]> wrote:

>
> Hi Tom,
>
> Tom Smyth wrote on Wed, Mar 13, 2019 at 08:32:20PM +0000:
>
> > Just saw the following article and i was wondering if libressl
> > Might be affected by the bug also
> > Top bit being set to 0 always making an effective 63 bits rather than 64
> > bits
>
> If i understand the article you quote correctly, is is about a minor
> bug in some CA softwares (i.e. softwares used to operate certificate
> authorities).  As far as i am aware, LibreSSL does *not* include any
> software that can be used to operate a certificate authority.
>
> The "openssl ca" subcommand of openssl(1) definitely does not count.
> The openssl(1) utility is a *testing tool* and must not be used for
> any kind of production purposes.
>
> So i don't see how LibreSSL could possibly be affected.
>
> If you still think it might be, please consider stating more precisely
> which part of LibreSSL (i.e. which library function) you fear might
> be broken in precisely which way.
>
> > https://www.theregister.co.uk/2019/03/13/tls_cert_revoke_ejbca_config/
>
> My impression is that the most important sentence from that article is
> the following:
>
>   While the serial number security issue is largely theoretical -
>   63 bits leaves plenty of space to fend off collision attacks,
>   even if it's not compliant with the spec [...]
>
> That means this is unlikely to be a security issue in the first
> place but looks more like a minor bug where some software is
> gratutiosly violating a specification.  Sure, specifications should
> not be set aside without a good reason, and certainly not accidentally,
> and bugs ought to be fixed, but i fail to see any indication that
> this bug might be more important than other run-of-the-mill bugs.
>
> Please take this with a grain of salt: while i did occasionally
> work on LibreSSL documentation in the past, my knowledge and
> experience in matters of cryptography and PKI is very limited.
> But i thought quick feedback might help to discourage people from
> panicking.
>
> Also, if you want to continue this discussion, i suggest moving
> to misc@.  You didn't include a patch!  ;-)
>
> Yours,
>   Ingo



--
Kindest regards,
Tom Smyth

Mobile: +353 87 6193172
The information contained in this E-mail is intended only for the
confidential use of the named recipient. If the reader of this message
is not the intended recipient or the person responsible for
delivering it to the recipient, you are hereby notified that you have
received this communication in error and that any review,
dissemination or copying of this communication is strictly prohibited.
If you have received this in error, please notify the sender
immediately by telephone at the number above and erase the message
You are requested to carry out your own virus check before
opening any attachment.

Reply | Threaded
Open this post in threaded view
|

Re: 63 bit certificate ID is libressl affected?

William Ahern-2
On Wed, Mar 13, 2019 at 11:32:50PM +0100, Ingo Schwarze wrote:

> Hi Tom,
>
> Tom Smyth wrote on Wed, Mar 13, 2019 at 08:32:20PM +0000:
>
> > Just saw the following article and i was wondering if libressl
> > Might be affected by the bug also
> > Top bit being set to 0 always making an effective 63 bits rather than 64
> > bits
>
> If i understand the article you quote correctly, is is about a minor
> bug in some CA softwares (i.e. softwares used to operate certificate
> authorities).  As far as i am aware, LibreSSL does *not* include any
> software that can be used to operate a certificate authority.
>
> The "openssl ca" subcommand of openssl(1) definitely does not count.
> The openssl(1) utility is a *testing tool* and must not be used for
> any kind of production purposes.
>
> So i don't see how LibreSSL could possibly be affected.

ikectl(3) uses openssl(3) to generate and sign certificates.
 

> If you still think it might be, please consider stating more precisely
> which part of LibreSSL (i.e. which library function) you fear might
> be broken in precisely which way.
>
> > https://www.theregister.co.uk/2019/03/13/tls_cert_revoke_ejbca_config/
>
> My impression is that the most important sentence from that article is
> the following:
>
>   While the serial number security issue is largely theoretical -
>   63 bits leaves plenty of space to fend off collision attacks,
>   even if it's not compliant with the spec [...]
>
> That means this is unlikely to be a security issue in the first
> place but looks more like a minor bug where some software is
> gratutiosly violating a specification.  Sure, specifications should
> not be set aside without a good reason, and certainly not accidentally,
> and bugs ought to be fixed, but i fail to see any indication that
> this bug might be more important than other run-of-the-mill bugs.
>
> Please take this with a grain of salt: while i did occasionally
> work on LibreSSL documentation in the past, my knowledge and
> experience in matters of cryptography and PKI is very limited.
> But i thought quick feedback might help to discourage people from
> panicking.

Serials are *supposed* to be unique, for (AFAIU) both cryptographic and
administrative reasons. The *original* expectation was that a CA would
maintain a monotonically increasing counter, either a simple counter as
maintained by the -CAserial option to openssl(3) or perhaps something
similar to the convention for DNS SOA serials (i.e. YYYMMDDnn...).

ikectl(3) appears to maintain a monotonic serial. It defines the environment
variable "$ENV::CASERIAL" when invoking openssl(3), which is a macro
expanded in /etc/ssl/ikeca.cnf and /etc/ssl/x509v3.cnf. It has the same
behavior as specifying -CAserial directly to openssl(3). See
usr.bin/openssl/ca.c line 892. The serial parameter specifies a stateful
file for storing the last serial used. See lines 946 and line 1086.

The EJBCA standard, however, instructs CAs to randomly generate a serial,
presumably because stateless solutions are easier to manage. They apparently
required only a 64-bit serial even though the PKIX standard (i.e. RFC 5280)
mandates,

  Certificate users MUST be able to handle serialNumber values up to 20
  octets.

Likely not a mere coincidence that SHA-1 hashes are 160 bits. And note that
in the parlance of ASN.1 DER, "20 octets" *includes* the sign bit.

So why would EJBCA only require 64 bits when serials not only should be
unique, but should be unpredictable? (Note a randomly generated 64-bit
identifier can be expected to repeat with 50% probability after only 2^32
iterations.) Again, probably not a coincidence that EJ stands for Enterprise
Java, and Java's largest native type is a *signed* 64-bit type. It's
therefore not the least bit surprising that some ECJBA-compliant software
generated a signed 64-bit ASN.1 INTEGER because it's a fair presumption that
the reason EJBCA only required 64 bits (as opposed to the obvious 128 bits
or 160 bits) was for the benefit of poorly written software that expected to
be able to convert the serial to a Java long. And if you're accomodating
poorly written software it's perfectly reasonable to ensure conversions to
the native type always result in a positive value.

The real issue here is that the EJBCA specification wasn't just a failure in
language precision, but was and remains entirely ill considered on this
score. If ASN.1 INTEGERs must now be 65 bits, it's a good bet that most if
not all software that expected to be able to convert a serial to a Java long
is broken. They haven't thought this through very well.

Should anything change in OpenBSD? It depends.

1.a) No, because ikectl is using stateful serial management, so questions of
serial length are irrelevant.

1.b) Yes, because stateful serial management can be brittle. Are people
backing up both their CA keys *and* serial files? A randomly generated 16-
or 20-octet serial has fewer moving parts and is thus more fail-safe.

2.a) No, because the original impetus for EJBCA to move to a 64-bit serial
(now 65-bit) was a demonstrated CA forgery when using MD5-based signatures:

  https://cabforum.org/pipermail/public/2016-June/007861.html
  https://fahrplan.events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf

But the default digest in /etc/ikeca.cnf is SHA256, so nothing to worry
about at the moment.

2.b) Yes, because maybe there are other problems around the corner. I don't
know off-hand if the PKIX SHA256 signature protocol is immune to
hypothetical length extension attacks. It's arguably better that the serial
be unpredictable and long. See point 1.b.

Reply | Threaded
Open this post in threaded view
|

Re: 63 bit certificate ID is libressl affected?

William Ahern-2
On Wed, Mar 13, 2019 at 06:53:43PM -0700, William Ahern wrote:
<snip>
> The real issue here is that the EJBCA specification wasn't just a failure in
> language precision, but was and remains entirely ill considered on this
> score. If ASN.1 INTEGERs must now be 65 bits, it's a good bet that most if
> not all software that expected to be able to convert a serial to a Java long
> is broken. They haven't thought this through very well.

Correction: the latest EJBCA software defaults to 20 octets:

  http://blog.ejbca.org/2019/03/

And it looks like Apple, GoDaddy, and Google are now generating 16-octet or
larger serials. Not sure where I got 65 bits from....