Skip to content

v1.9.0
Compare
Choose a tag to compare
@m-ronnblom m-ronnblom released this 31 Jul 14:43
· 77 commits to master since this release
v1.9.0
9b68249

Release v1.9.0 contains the following improvements:

BTCP Transport

XCM v1.9.0 introduces a new XCM transport BTCP, including the appropriate extensions to <xcm_addr.h>. API-wise, BTCP presents a XCM bytestream type service. On the wire, XCM BTCP is just "raw" TCP, with no XCM-specific wire protocol elements.

There are two primary drivers behind BTCP. One is that it provides a clean and easy way to share TCP/BSD socket-related functionality between XCM BTLS and the XCM TCP transports, and helps assure that TCP-level options and behaviors are the same for both XCM TCP and XCM BTLS/TLS/UTLS.

Already prior to the introduction of BTCP, DNS and BSD sockets-related code was shared between BTLS and TCP (e.g., tcp_attr). The requirement to support RFC 6555-style "Happy Eyeballs" DNS and TCP connection establishment procedures increased the incentive to realize BTCP.

In v1.9.0, XCM BTLS uses the new BTCP transport as mapping layer between OpenSSL and the BSD sockets API. In OpenSSL speak, such a module is referred to as a "BIO". The BTLS transport now has a custom BIO which relays data between OpenSSL and BTCP. An upside of this change is that XCM no longer needs to configure libc to ignore SIGPIPE (which is not something shared libraries should do, generally). Ignoring SIGPIPE was required since the standard OpenSSL BIO previously used by XCM issued the send() syscall without the MSG_NOSIGNAL flag set. Without SIGPIPE filtering, such SIGPIPE UNIX signals would be delivered to the process in case the connection was broken on send(), likely much to the surprise of most applications.

The second reason is for the introduction of BTCP is symmetry (or completeness). XCM BTCP is to XCM TCP what XCM BTLS is to XCM TLS.

Happy Eyeballs

New in v1.9.0 is support for configurable DNS-based TCP connection establishment algorithms.

The DNS resolver (glibc or C-ares) sorts the A and AAA records and returns them to the higher layer in the order of preference. XCM versions prior to v1.9.0 always only attempted to connect to the first, most preferred, address in this list. If that connection attempt failed, an error was returned to the caller.

In v1.9.0, the application may control which algorithm (or mechanism) is used to translate the list of addresses into an established TCP connection using a new XCM socket attribute "dns.algorithm". The default algorithm is "single", which is identical to legacy XCM behavior.

If the "sequential" method is specified, all addresses provided by DNS will be probed, one-by-one, in resolver-controlled priority order.

If the "happy_eyeballs" algorithm is configured, the XCM socket maintains two concurrent tracks, where one attempts to connect to all IPv6 addresses, one-by-one, in priority order, and the other does the same, but for the IPv4 subset. All this pretty much in accordance to RFC 6555.

The "dns.algorithm" attribute is available in all TCP-based transports; UTLS, TLS, BTLS, TCP, and BTCP.

To keep core BTCP transport complexity low, the responsibility for managing BSD socket creation and TCP connection establishment is moved out from xcm_tp_btcp.c to a new module tconnect.c.

v1.9.0 also sports a new "tcp.connect_timeout" socket attribute, which allows the user to specify a TCP connection establishment-specific timeouts. The default is 3 s, which is roughly the same as older XCM versions.

Certificate Revocation Verification

Starting in this release, XCM may optionally be configured to check the remote peer's certificate (and other certificates in the chain of trust) against a set of certificate revocation lists (CRLs). The full chain is checked against the CRLs.

CRL checking is supported in all XCM transports using TLS, including for UTLS connection sockets of the TLS type.

CRL checking is disabled by default. It is enabled by setting the new "tls.check_crl" socket attribute to true.

The actual CRL bundle is supplied by setting one of the new "tls.crl_file" or "tls.crl" socket attributes.

The CRL bundle is cached and re-read/re-parsed on change in the same manner as the cert.pem, key.pem and tc.pem files. Already-established TLS connections will not be torn down.

CRL checking is available on both socket serving in the TLS client and server roles.

Other Improvements

  • Avoid redundant epoll instance updates in the TLS transport, reducing message send and receive overhead with ~5%.
  • Fix DNS-related test failures occuring on non-C-ares builds.
  • Improve API documentation in regards to MT safety.
  • Various minor refactorings.
  • Use SOCK_NONBLOCK to avoid fnctl() calls and reduce overhead for socket creation.
  • Improve "dns.timeout" attribute documentation.
  • Introduce directory subtree under libxcm/, to make navigating the source code easier.
  • Enable the BTLS address parsning test cases.
  • Extend invalid address test cases.
  • Missing SPDX license headers are added to various Python source files.
  • Fix 'xcm' command-line tool floating point attribute bug.

The API/ABI version is bumped to 0.24.

The API documentation and user manual for this release can be found at:
https://ericsson.github.io/xcm/doc/v1.9.0/

Assets 2
Loading