If the randomly allocated serial starts with 0x80, the fix added with
e49197f15e ("pki: Don't generate negative random serial numbers in
X.509 certificates") causes the value to become zero. So the encoded
ASN.1 integer will start with a zero byte, which is only correct if the
integer would otherwise be interpreted as negative, i.e. the next byte
starts with the most significant bit set. If that isn't the case, the
encoding is technically invalid and might get rejected by strict parsers.
Note that e49197f15e did not actually fix a violation of RFC 5280 as
asn1_integer() assumes all passed numbers are positive and automatically
adds a zero prefix if the MSB is set. What it did instead (or at least
attempted to) is ensure that the generated serial is a positive 64-bit
number in two's complement. The difference can be seen in the output of
`openssl x509 -text`. While 8-byte serials with the MSB set are printed
as hex dump:
Serial Number:
af:e2:e1:47:0f:66:b5:a4
(The encoding is 02:09:00:af:e2:e1:47:0f:66:b5:a4)
those without MSB set are actually printed as number:
Serial Number: 289805014144645117 (0x405981ffa37f7fd)
(The encoding is 02:08:04:05:98:1F:FA:37:F7:FD)
The reason is that OpenSSL only does the latter if the number fits into a
signed `long` variable, which isn't the case if a positive 64-bit number
has the MSB set (i.e. has a zero prefix) as it would be interpreted as
negative number in two's complement. OpenSSL does print negative serial
numbers (even if it's a violation of the RFC), but only if they were
encoded as such, i.e. if there was no zero prefix:
Serial Number: -5492225205882687294 (-0x4c384db9c7158f3e)
(The encoding is 02:08:b3:c7:b2:46:38:ea:70:c2)
Fixes: e49197f15e ("pki: Don't generate negative random serial numbers in X.509 certificates")
Closesstrongswan/strongswan#631
This is mostly for the non-mmap case as with mmap available, access to the
unmapped memory isn't easily possible (e.g. opening the same area with
MAP_ANONYMOUS | MAP_UNINITIALIZED is usually prevented by the missing
CONFIG_MMAP_ALLOW_UNINITIALIZED option in most kernels).
New versions of Bind limit the maximum UDP message size to 1232 bytes,
which is the same that newer versions of libunbound propose as maximum via
EDNS in requests, so increasing the limit on the server wouldn't help.
Instead we allow DNS via TCP so the client can switch after receiving the
truncated UDP response.
Using the workaround with the EVP interface, which we use to derive shared
keys since 74e02ff5e6 ("openssl: Mainly use EVP interface for ECDH"),
would actually require us to register the OIDs of these curves as NID.
Otherwise, the two EC_GROUPs used by private and public key objects
are not considered the same and the key derivation fails.
Since the curves are supported by OpenSSL since 1.0.2 it's probably rare to
find a version without them nowadays. One exception is the old BoringSSL
version we still use on Android, which defines the NIDs but not the curve
data. However, that version also lacks support to register OIDs as NIDs,
so the only option to support these groups there would be to got back to not
using the EVP interface, which isn't in anyone's interest. If there really
is a need for them there, we could probably patch BoringSSL or use OpenSSL.
The "openssl" alias now defaults to OpenSSL 3.0, which produces a lot of
deprecation warnings. To avoid build failures due to `-Werror`, stay with
OpenSSL 1.1 until we can get rid of these issues.
With the update to Python 3 the encoding of the values in vici messages
changed to bytestrings (the keys are properly decoded). And getting the
first CHILD_SA also needs a change.
The logger is now also initialized after daemonizing to avoid that opened
sockets are closed etc.
If there are many CHILD_SAs, the time between initiating the new IKE_SA
and checking it in might be longer (depending on what else is going on
in the daemon) than the retransmission timeout and no retransmits might
be sent afterwards for this SA (it will just linger around dead).
Calling initiate() last should avoid that (we do this similarly for MBB
reauthentication).
If we are using make-before-break reauthentication, this could lead to
duplicates as the new IKE_SA wouldn't be able to delete the previous
one if it was replaced by a rekeying.
If we initiated a make-before-break reauthentication and the peer
concurrently deletes the IKE_SA (e.g. because it uses break-before-make
reauthentication), we would create a duplicate IKE_SA (the condition forces
a recreation of all existing CHILD_SAs because reestablish() is also called
to complete a break-before-make reauthentication).
Tobias Brunner