Voor het beveiligen van verbindingen over openbare netwerken kunnen verschillende protocollen worden gebruikt, zoals het veel toegepaste ipsec. StrongSwan is een ipsec-implementatie voor Linux-systemen, waarvan de 5.0-vleugel zich richt op de 2.6- en 3.x-Linux-kernels. Ondersteuning voor ikev1, ikev2 en ipv6 is aanwezig, zoals op deze pagina na te lezen is. De ontwikkelaars hebben strongSwan 5.0.2 uitgebracht en van de volgende lijst met veranderingen voorzien:
- Implemented all IETF Standard PA-TNC attributes and an OS IMC/IMV pair using them to transfer operating system information.
- The new "ipsec listcounters" command prints a list of global counter values about received and sent IKE messages and rekeyings.
- A new lookip plugin can perform fast lookup of tunnel information using a clients virtual IP and can send notifications about established or deleted tunnels. The "ipsec lookip" command can be used to query such information or receive notifications.
- The new error-notify plugin catches some common error conditions and allows an external application to receive notifications for them over a UNIX socket.
- IKE proposals can now use a PRF algorithm different to that defined for integrity protection. If an algorithm with a "prf" prefix is defined explicitly (such as prfsha1 or prfsha256), no implicit PRF algorithm based on the integrity algorithm is added to the proposal.
- The pkcs11 plugin can now load leftcert certificates from a smartcard for a specific ipsec.conf conn section and cacert CA certificates for a specific ca section.
- The load-tester plugin gained additional options for certificate generation and can load keys and multiple CA certificates from external files. It can install a dedicated outer IP address for each tunnel and tunnel initiation batches can be triggered and monitored externally using the "ipsec load-tester" tool.
- PKCS#7 container parsing has been modularized, and the openssl plugin gained an alternative implementation to decrypt and verify such files. In contrast to our own DER parser, OpenSSL can handle BER files, which is required for interoperability of our scepclient with EJBCA.
- Support for the proprietary IKEv1 fragmentation extension has been added. Fragments are always handled on receipt but only sent if supported by the peer and if enabled with the new fragmentation ipsec.conf option.
- IKEv1 in charon can now parse certificates received in PKCS#7 containers and supports NAT traversal as used by Windows clients. Patches courtesy of Volker RĂĽmelin.
- The new rdrand plugin provides a high quality / high performance random source using the Intel rdrand instruction found on Ivy Bridge processors.
- The integration test environment was updated and now uses KVM and reproducible guest images based on Debian.
- Introduced the sending of the standard IETF Assessment Result PA-TNC attribute by all strongSwan Integrity Measurement Verifiers.
- Extended PTS Attestation IMC/IMV pair to provide full evidence of the Linux IMA measurement process. All pertinent file information of a Linux OS can be collected and stored in an SQL database.
- The PA-TNC and PB-TNC protocols can now process huge data payloads >64 kB by distributing PA-TNC attributes over multiple PA-TNC messages and these messages over several PB-TNC batches. As long as no consolidated recommandation from all IMVs can be obtained, the TNC server requests more client data by sending an empty SDATA batch.
- The rightgroups2 ipsec.conf option can require group membership during a second authentication round, for example during XAuth authentication against a RADIUS server.
- The xauth-pam backend can authenticate IKEv1 XAuth and Hybrid authenticated clients against any PAM service. The IKEv2 eap-gtc plugin does not use PAM directly anymore, but can use any XAuth backend to verify credentials, including xauth-pam.
- The new unity plugin brings support for some parts of the IKEv1 Cisco Unity Extension. As client, charon narrows traffic selectors to the received Split-Include attributes and automatically installs IPsec bypass policies for received Local-LAN attributes. As server, charon sends Split-Include attributes for leftsubnet definitions containing multiple subnets to Unity-aware clients.
- An EAP-Nak payload is returned by clients if the gateway requests an EAP method that the client does not support. Clients can also request a specific EAP method by configuring that method with leftauth.
- The eap-dynamic plugin handles EAP-Nak payloads returned by clients and uses these to select a different EAP method supported/requested by the client. The plugin initially requests the first registered method or the first method configured with charon.plugins.eap-dynamic.preferred.
- The new left/rightdns options specify connection specific DNS servers to request/respond in IKEv2 configuration payloads or IKEv2 mode config. leftdns can be any (comma separated) combination of %config4 and %config6 to request multiple servers, both for IPv4 and IPv6. rightdns takes a list of DNS server IP addresses to return.
- The left/rightsourceip options now accept multiple addresses or pools. leftsourceip can be any (comma separated) combination of %config4, %config6 or fixed IP addresses to request. rightsourceip accepts multiple explicitly specified or referenced named pools.
- Multiple connections can now share a single address pool when they use the same definition in one of the rightsourceip pools.
- The options charon.interfaces_ignore and charon.interfaces_use allow one to configure the network interfaces used by the daemon.
- The kernel-netlink plugin supports the charon.install_virtual_ip_on option, which specifies the interface on which virtual IP addresses will be installed. If it is not specified the current behavior of using the outbound interface is preserved.
- The kernel-netlink plugin tries to keep the current source address when looking for valid routes to reach other hosts.
- The autotools build has been migrated to use a config.h header. strongSwan development headers will get installed during "make install" if --with-dev-headers has been passed to ./configure.
- All crypto primitives gained return values for most operations, allowing crypto backends to fail, for example when using hardware accelerators.
- The charon IKE daemon gained experimental support for the IKEv1 protocol. Pluto has been removed from the 5.x series, and unless strongSwan is configured with --disable-ikev1 or --disable-ikev2, charon handles both keying protocols. The feature-set of IKEv1 in charon is almost on par with pluto, but currently does not support AH or bundled AH+ESP SAs. Beside RSA/ECDSA, PSK and XAuth, charon also supports the Hybrid authentication mode. Informations for interoperability and migration is available at http://wiki.strongswan.org/projects/strongswan/wiki/CharonPlutoIKEv1.
- Charon's bus_t has been refactored so that loggers and other listeners are now handled separately. The single lock was previously cause for deadlocks if extensive listeners, such as the one provided by the updown plugin, wanted to acquire locks that were held by other threads which in turn tried to log messages, and thus were waiting to acquire the same lock currently held by the thread calling the listener. The implemented changes also allow the use of a read/write-lock for the loggers which increases performance if multiple loggers are registered. Besides several interface changes this last bit also changes the semantics for loggers as these may now be called by multiple threads at the same time.
- Source routes are reinstalled if interfaces are reactivated or IP addresses reappear.
- The thread pool (processor_t) now has more control over the lifecycle of a job (see job.h for details). In particular, it now controls the destruction of jobs after execution and the cancellation of jobs during shutdown. Due to these changes the requeueing feature, previously available to callback_job_t only, is now available to all jobs (in addition to a new rescheduling feature).
- In addition to trustchain key strength definitions for different public key systems, the rightauth option now takes a list of signature hash algorithms considered save for trustchain validation. For example, the setting rightauth=rsa-2048-ecdsa-256-sha256-sha384-sha512 requires a trustchain that uses at least RSA-2048 or ECDSA-256 keys and certificate signatures using SHA-256 or better.