Luckily, the type is only used once when generating payloads and there it
doesn't matter because the encoding rules are the same.
Closesstrongswan/strongswan#135.
The main fixes are
* the generation of fingerprints for RSA, ECDSA, and EdDSA
* the encoding of ECDSA private keys
* calculating p and q for RSA private keys
* deriving the public key for raw Ed25519 private keys
Also, instead of numeric literals for buffer lengths ASN.1 related
constants are used.
Instead of assuming passwords are simply ASCII-encoded we now assume they are
provided UTF-8-encoded, which is quite likely nowadays. The UTF-8 byte
sequences are not validated, however, only valid code points are encoded
as UTF-16LE.
Fixes#3014.
Previously, the initiator would install the SA in transport mode if the
peer sent back the USE_TRANSPORT_MODE notify, even if that was not
requested originally.
The only messages that are generally sent encrypted but could be sent
unencrypted are INFORMATIONALs (currently only used for IKEv1 and ME
connectivity checks). This should prevent issues if the keymat_t behaves
incorrectly and does not return an aead_t when it actually should.
Might be useful for users of other daemons too. Note that compared to the
previous implementation in charon-tkm, the mask/label are applied in
network order.
Closesstrongswan/strongswan#134.
Previously, attributes in an incorrectly sent CFG_REPLY would still be passed
to attribute handlers. This does not prevent handlers from receiving
unrequested attributes if they requested at least one other.
This is mainly to see what's necessary to create them (in case we
integrate this into the daemon) and to experiment in our testing
environment without having to add a patched version of iproute2 (the
4.20.0 version in stretch-backports doesn't support XFRM interfaces
yet). The regular version of iproute2 can be used for other operations
with these interfaces (delete, up, addrs etc.).
The PB-TNC finite state machine according to section 3.2 of RFC 5793
was not correctly implemented when sending either a CRETRY or SRETRY
batch. These batches can only be sent in the "Decided" state and a
CRETRY batch can immediately carry all messages usually transported
by a CDATA batch. strongSwan currently is not able to send a SRETRY
batch since full-duplex mode for PT-TLS isn't supported yet.
The bits not written to are marked tainted by valgrind, don't print
them in the debug messages. Also use more specific printf-specifiers
for other values.
There was a race condition between install() and uninstall()
where one thread was in the process of installing a trap
entry, and had destroyed the child_sa, while the other
thread was uninstalling the same trap entry and ended up
trying to destroy the already destroyed child_sa, resulting
in a segmentation fault in the destroy_entry() function.
The uninstall() function needs to wait until all the threads
are done with the installing before proceeding to uninstall
a trap entry.
Closesstrongswan/strongswan#131.
This can be the case for IKEv1 since 419ae9a20a ("ikev1: Default remote
identity to %any for PSK lookup if not configured").
Closesstrongswan/strongswan#128.
Tobias Brunner