gnutls_priority_init: multiple @KEYWORD lookups with fallback
The support for using "@KEYWORD" as a priority string is very
useful to separate selection of priorities from application
specific code or config files. It is, however, not general
enough to fully serve all reasonable use cases.
The system administrator can modify the global priorities
file to change what "@SYSTEM" resolves to for all apps using
GNUTLS. As soon as one application wishes to have a slightly
different configuration from others on the host, you have to
go back and start modifying application specific configuration
files once more. This is bad for the system administrator as
it means there's no longer one single place where they can
see the priority configuration for all apps.
They may try to get around this problem by configuring the
app to use a different keyword, instead of a full priority
string, eg "@LIBVIRT". So the global priorities file can
now define entries for both "SYSTEM" and "LIBVIRT". This
has still placed a burden on the administrator change the
config in two places - both libvirt config files and the
global priorities file.
What is more desirable is if applications were able to provide
a list of keywords that would be tried in order, picking the
first that existed. For example, libvirt could be written to
request the following by default
With this, gnutls would first try to find the "LIBVIRT" keyword
in the global configuration file, and if that is not present,
then it would fallback to trying to find the "SYSTEM" keyword.
This provides nice "out of the box" behaviour for system
administrators, whereby the app would be using "SYSTEM" initially
and if the admin wishes to give the app a custom configuration,
they can simply modify the global priorities file to add in the
application specific keyword "LIBVIRT". There is never a need
for the sysadmin to modify any application specific configuration
files any more. It is exclusively controlled in one place via the
global priorities file.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
priorities: preload the system priorities on library loading time
It is required to restart every application after changing the
system priority file to get changes to take effect.
Further, for applications running in a chroot, it will no longer
honour a system priority file that may exist inside the chroot,
always using the originally cached data from outside the chroot.
This patch changes the caching so that we always try to reload
the cache of system priorities. A mtime check is used to avoid
actually re-reading the file unless its content has obviously
changed. If the file no longer exists, the cache will not be
invalidated. This ensures that the current priority file is
always honoured, whether inside a chroot or not, while at the
same time allowing apps to work in a chroot when no system
priority file is present.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
keylogfile: only consider the SSLKEYLOGFILE variable
In addition do not check the environment in the constructor
but instead use static variables to save the key file name.
The GNUTLS_KEYLOGFILE environment variable is no longer used
since there is no reason to have a separate one.
_gnutls_check_key_purpose: in CA certificates treat the SGC key purpose as GNUTLS_KP_TLS_WWW_SERVER
This is a hack for certain very old CA certificates lurking around which instead
of having the GNUTLS_KP_TLS_WWW_SERVER have some old OIDs for that purpose. Consider
these OIDs equivalent to GNUTLS_KP_TLS_WWW_SERVER in marked as CA certificates.
ocsp: attempt harder to figure an OCSP staple issuer
That is, check initially against the trust list set on the credentials,
and if verification is not possible attempt with all certificates in
the chain as possible issuers. The reason of this enhancement is the
few servers have an OCSP response signed not by their direct CA but
rather by one of the higher level CAs.
tests: added comprehensive OCSP test suite with MUST-staple PKIX extension
This includes the tests:
- Server with valid certificate - no staple
- Server with valid certificate - valid staple
- Server with valid certificate - invalid staple
- Server with valid certificate - unrelated cert staple
- Server with valid certificate - expired staple
- Server with valid certificate - old staple
This verification status flag indicates an OCSP status response
being stapled but it being invalid for some reason (e.g., unable
to parse or doesn't contain the expected certificate).
This replaces the usage of "int" in functions which could only
have accepted an "unsigned" value. Also functions which return
unsigned values are explicitly tagged as such. The ABI remains
the same with these changes.
This allows easier catching of sign/unsigned related errors from
the calling applications.
Tim Kosse [Sun, 20 Dec 2015 14:09:24 +0000 (15:09 +0100)]
Account the TLSFeature certificate extension in certificate verification
That is, account for the OCSP-Must staple extension. If we have sent an OCSP
status request and have not gotten anything, but the certificate has the
Status Request TLSFeature extension present, fail to verify the certificate.
Tim Kosse [Mon, 30 May 2016 07:45:29 +0000 (09:45 +0200)]
Added functions to parse the TLSFeatures X.509 extension.
In addition provide function to enumerate the features it lists,
and output information with the output functions.
This adds:
gnutls_x509_tlsfeatures_init
gnutls_x509_tlsfeatures_deinit
gnutls_x509_tlsfeatures_get
gnutls_x509_ext_import_tlsfeatures
gnutls_x509_crt_get_tlsfeatures
That is we check whether DTLS-1.0 and DTLS-1.2 can be negotiated
using the NORMAL priority string. We also add a custom check for
DTLS-0.9 as this is not fully supported for negotiation.
tests: do not use pkglib to generate libpkcs11mock1.so
This resulted in the test library being installed. Install we use noinst
for the library, but pass -rpath to LDFLAGS as a hack to for libtool
to generate the shared version.
projects / thirdparty / gnutls.git / log
