Libvirt has long supported use of TLS for its remote API service, using the gnutls library as its backend. When negotiating a TLS session, there are a huge number of possible algorithms that could be used and the client & server need to decide on the best one, where “best” is commonly some notion of “most secure”. The preference for negotiation is expressed by simply having an list of possible algorithms, sorted best to worst, and the client & server choose the first matching entry in their respective lists. Historically libvirt has not expressed any interest in the handshake priority configuration, simply delegating the decision to the gnutls library on that basis that its developers knew better than libvirt developers which are best. In gnutls terminology, this means that libvirt has historically used the “
DEFAULT” priority string.
The past year or two has seen a seemingly never ending stream of CVEs related to TLS, some of them particular to specific algorithms. The only way some of these flaws can be addressed is by discontinuing use of the affected algorithm. The TLS library implementations have to be fairly conservative in dropping algorithms, because this has an effect on consumers of the library in question. There is also potentially a significant delay between a decision to discontinue support for an algorithm, and updated libraries being deployed to hosts. To address this Fedora 21 introduced the ability to define the algorithm priority strings in host configuration files, outside of the library code. This system administrators can edit a file
/etc/crypto-policies/config to change the algorithm priority for all apps using TLS on the host. After editting this file, the
update-crypto-policies command is run to generate the library specific configuration files. For example, it populates
/etc/crypto-policies/back-ends/gnutls.config In gnutls use of this file is enabled by specifying that an application wants to use the “
@SYSTEM” priority string.
This is a good step forward, as it takes the configuration out of source code and into data files, but it has limited flexibility because it applies to all apps on the host. There can be two apps on a host which have mutually incompatible views about what the best algorithm priority is. For example, a web browser will want to be fairly conservative in dropping algorithms to avoid breaking access to countless websites. An application like libvirtd though, where there is a well known set of servers and clients to connect in any site, can be fairly aggressive in only supporting the very best algorithms. What is desired is a way to override the algorithm priorty per application. Now of course this can easily be done via the application’s own configuration file, and so libvirt has added a new parameter “
The downside of using the application’s own configuration, is that the system administrator has to go hunting through many different files to update each application. It is much nicer to have a central location where the TLS priority settings for all applications can be controlled. What is desired is a way for libvirt to be built such that it can tell gnutls to first look for a libvirt specific priority string, and then fallback to the global priority string. To address this patches were written for GNUTLS to extend its priority string syntax. It is now possible to for libvirt to pass “
@LIBVIRT,SYSTEM” to gnutls as the priority. It will thus read
/etc/crypto-policies/back-ends/gnutls.config first looking for an entry matching “
LIBVIRT” and then looking for an entry matching “
SYSTEM“. To go along with the gnutls change, there is also an enhancement to the update-crypto-policies tool to allow application specific entries to be included when generating the
/etc/crypto-policies/back-ends/gnutls.config file. It is thus possible to configure the libvirt priority string by simply creating a file
/etc/crypto-policies/local.d/gnutls-libvirt.config containing the desired string and re-running
In summary, the libvirt default priority settings are now:
- RHEL-6/7 –
NORMAL– a string hard coded in gnutls at build time
- Fedora < 25 -
@SYSTEM– a priority level defined by sysadmin based on
- Fedora >= 25 –
@LIBVIRT,SYSTEM– a raw priority string defined in
/etc/crypto-policies/local.d/gnutls-libvirt.config, falling back to
/etc/crypto-policies/configif not present.
In all cases it is still possible to customize in
/etc/libvirt/libvirtd.conf via the
tls_priority setting, but it is is recommended to use the global system
/etc/crypto-policies facility where possible.