travis: Use amalgamation build for Botan and build outside our source tree
This merges all source files into botan_all.cpp, which reduces the build
time by almost 50%. Building outside the strongSwan tree avoids analyzing
Botan with sonarqube.
Tobias Brunner [Wed, 8 Aug 2018 09:41:36 +0000 (11:41 +0200)]
leak-detective: Whitelist some Botan functions
Due to the mangled C++ function names it's tricky to be more specific. The
"leaked" allocations are from a static hashtable containing EC groups.
There is another leak caused by the locking allocator singleton
(triggered by the first function that uses it, usually initialization of
a cipher, but could be a hasher in other test runners), but we can avoid
that with a Botan config option.
Tobias Brunner [Thu, 9 Aug 2018 11:00:50 +0000 (13:00 +0200)]
botan: Load public/private keys generically
Simplifies public key loading and this way unencrypted PKCS#8-encoded
keys can be loaded directly without pkcs8 plugin (code for encrypted
keys could probably later be added, if necessary).
It also simplifies the implementation of private_key_t::get_public_key()
a lot.
Tobias Brunner [Wed, 8 Aug 2018 16:23:11 +0000 (18:23 +0200)]
botan: Encode curve OID and public key in EC private key
Without OID we can't generate an algorithmIdentifier when loading the
key again. And older versions of OpenSSL insist on a public key when
e.g. converting a key to PKCS#8.
Simply unwrapping the ECPrivateKey structure avoids log messages when
parsing other keys in the KEY_ANY case.
René Korthaus [Fri, 27 Jul 2018 07:33:39 +0000 (09:33 +0200)]
botan: Add MD5 support to Botan hasher
Support MD5 in the Botan plugin if supported by Botan.
MD5 is required for RADIUS and obviously EAP-MD5,
and also for non-PKCS#8 encoded, encrypted private keys.
René Korthaus [Thu, 26 Jul 2018 09:17:07 +0000 (11:17 +0200)]
unit-tests: Remove 768 bits RSA gen test
Botan only allows RSA generating keys >= 1,024 bits, which makes
the RSA test suite fail. It is questionable whether it makes
sense to test 768 bit RSA keys anymore. They are too weak
from today's perspective anyway.
Tobias Brunner [Thu, 31 May 2018 09:46:29 +0000 (11:46 +0200)]
settings: Don't allow dots in section/key names anymore
This requires config changes if filelog is used with a path that
contains dots. This path must now be defined in the `path` setting of an
arbitrarily named subsection of `filelog`. Without that change the
whole strongswan.conf file will fail to load, which some users might
not notice immediately.
Tobias Brunner [Fri, 31 Aug 2018 10:27:40 +0000 (12:27 +0200)]
Merge branch 'xfrm-set-mark'
This adds the ability to configure marks the in- and/or outbound SA
should apply to packets after processing on Linux. Configuring such a mark
for outbound SAs requires at least a 4.14 kernel. The ability to set a mask
and configuring a mark/mask for inbound SAs will be added with the upcoming
4.19 kernel.
Martin Willi [Wed, 9 May 2018 11:40:36 +0000 (13:40 +0200)]
child-sa: Use SA matching mark as SA set mark if the latter is %same
For inbound processing, it can be rather useful to apply the mark to the
packet in the SA, so the associated policy with that mark implicitly matches.
When using %unique as match mark, we don't know the mark beforehand, so
we most likely want to set the mark we match against.
Martin Willi [Mon, 14 May 2018 11:42:53 +0000 (13:42 +0200)]
ipsec-types: Restrict the use of %unique and other keywords when parsing marks
%unique (and the upcoming %same key) are usable in specific contexts only.
To restrict the user from using it in other places where it does not get the
expected results, reject such keywords unless explicitly allowed.
Tobias Brunner [Mon, 6 Aug 2018 15:01:20 +0000 (17:01 +0200)]
ikev1: Increase DPD sequence number only after receiving a response
We don't retransmit DPD requests like we do requests for proper exchanges,
so increasing the number with each sent DPD could result in the peer's state
getting out of sync if DPDs are lost. Because according to RFC 3706, DPDs
with an unexpected sequence number SHOULD be rejected (it does mention the
possibility of maintaining a window of acceptable numbers, but we currently
don't implement that). We partially ignore such messages (i.e. we don't
update the expected sequence number and the inbound message stats, so we
might send a DPD when none is required). However, we always send a response,
so a peer won't really notice this (it also ensures a reply for "retransmits"
caused by this change, i.e. multiple DPDs with the same number - hopefully,
other implementations behave similarly when receiving such messages).