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.
