From nobody Fri May 3 10:05:30 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 15230217980241007.7145059176482; Fri, 6 Apr 2018 06:36:38 -0700 (PDT) Received: from localhost ([::1]:56124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4RXh-0002Zn-2G for importer@patchew.org; Fri, 06 Apr 2018 09:36:37 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4RSF-0006IZ-0e for qemu-devel@nongnu.org; Fri, 06 Apr 2018 09:31:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4RSB-00036P-2h for qemu-devel@nongnu.org; Fri, 06 Apr 2018 09:30:59 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:55148 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f4RSA-00035n-TK for qemu-devel@nongnu.org; Fri, 06 Apr 2018 09:30:55 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 71280406E9B2 for ; Fri, 6 Apr 2018 13:30:52 +0000 (UTC) Received: from t460.redhat.com (unknown [10.33.36.63]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3B9498444F; Fri, 6 Apr 2018 13:30:50 +0000 (UTC) From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Date: Fri, 6 Apr 2018 14:30:44 +0100 Message-Id: <20180406133046.5682-2-berrange@redhat.com> In-Reply-To: <20180406133046.5682-1-berrange@redhat.com> References: <20180406133046.5682-1-berrange@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 06 Apr 2018 13:30:52 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 06 Apr 2018 13:30:52 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'berrange@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PULL 1/3] docs: update information for TLS certificate management X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: "Daniel P. Berrange" The current docs for TLS assume only VNC is using TLS. Some of the informat= ion is also outdated (ie lacking subject alt name info for certs). Rewrite it to more accurately reflect the current situation. Reviewed-by: Eric Blake Reviewed-by: Kashyap Chamarthy Signed-off-by: Daniel P. Berrange --- qemu-doc.texi | 364 +++++++++++++++++++++++++++++++++++++++++++-----------= ---- 1 file changed, 272 insertions(+), 92 deletions(-) diff --git a/qemu-doc.texi b/qemu-doc.texi index 89fa80518a..5813d27615 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -140,6 +140,7 @@ accelerator is required to use more than one host CPU f= or emulation. * direct_linux_boot:: Direct Linux Boot * pcsys_usb:: USB emulation * vnc_security:: VNC security +* network_tls:: TLS setup for network services * gdb_usage:: GDB usage * pcsys_os_specific:: Target OS specific information @end menu @@ -1041,7 +1042,6 @@ considerations depending on the deployment scenarios. * vnc_sec_certificate_pw:: * vnc_sec_sasl:: * vnc_sec_certificate_sasl:: -* vnc_generate_cert:: * vnc_setup_sasl:: @end menu @node vnc_sec_none @@ -1161,25 +1161,105 @@ with the aforementioned TLS + x509 options: qemu-system-i386 [...OPTIONS...] -vnc :1,tls,x509,sasl -monitor stdio @end example =20 +@node vnc_setup_sasl =20 -@node vnc_generate_cert -@subsection Generating certificates for VNC +@subsection Configuring SASL mechanisms =20 -The GNU TLS packages provides a command called @code{certtool} which can -be used to generate certificates and keys in PEM format. At a minimum it -is necessary to setup a certificate authority, and issue certificates to -each server. If using certificates for authentication, then each client -will also need to be issued a certificate. The recommendation is for the -server to keep its certificates in either @code{/etc/pki/qemu} or for -unprivileged users in @code{$HOME/.pki/qemu}. +The following documentation assumes use of the Cyrus SASL implementation o= n a +Linux host, but the principles should apply to any other SASL implementati= on +or host. When SASL is enabled, the mechanism configuration will be loaded = from +system default SASL service config /etc/sasl2/qemu.conf. If running QEMU a= s an +unprivileged user, an environment variable SASL_CONF_PATH can be used to m= ake +it search alternate locations for the service config file. + +If the TLS option is enabled for VNC, then it will provide session encrypt= ion, +otherwise the SASL mechanism will have to provide encryption. In the latter +case the list of possible plugins that can be used is drastically reduced.= In +fact only the GSSAPI SASL mechanism provides an acceptable level of securi= ty +by modern standards. Previous versions of QEMU referred to the DIGEST-MD5 +mechanism, however, it has multiple serious flaws described in detail in +RFC 6331 and thus should never be used any more. The SCRAM-SHA-1 mechanism +provides a simple username/password auth facility similar to DIGEST-MD5, b= ut +does not support session encryption, so can only be used in combination wi= th +TLS. + +When not using TLS the recommended configuration is + +@example +mech_list: gssapi +keytab: /etc/qemu/krb5.tab +@end example + +This says to use the 'GSSAPI' mechanism with the Kerberos v5 protocol, with +the server principal stored in /etc/qemu/krb5.tab. For this to work the +administrator of your KDC must generate a Kerberos principal for the serve= r, +with a name of 'qemu/somehost.example.com@@EXAMPLE.COM' replacing +'somehost.example.com' with the fully qualified host name of the machine +running QEMU, and 'EXAMPLE.COM' with the Kerberos Realm. + +When using TLS, if username+password authentication is desired, then a +reasonable configuration is + +@example +mech_list: scram-sha-1 +sasldb_path: /etc/qemu/passwd.db +@end example + +The @code{saslpasswd2} program can be used to populate the @code{passwd.db} +file with accounts. + +Other SASL configurations will be left as an exercise for the reader. Note= that +all mechanisms, except GSSAPI, should be combined with use of TLS to ensur= e a +secure data channel. + + +@node network_tls +@section TLS setup for network services + +Almost all network services in QEMU have the ability to use TLS for +session data encryption, along with x509 certificates for simple +client authentication. What follows is a description of how to +generate certificates suitable for usage with QEMU, and applies to +the VNC server, character devices with the TCP backend, NBD server +and client, and migration server and client. + +At a high level, QEMU requires certificates and private keys to be +provided in PEM format. Aside from the core fields, the certificates +should include various extension data sets, including v3 basic +constraints data, key purpose, key usage and subject alt name. + +The GnuTLS package includes a command called @code{certtool} which can +be used to easily generate certificates and keys in the required format +with expected data present. Alternatively a certificate management +service may be used. + +At a minimum it is necessary to setup a certificate authority, and +issue certificates to each server. If using x509 certificates for +authentication, then each client will also need to be issued a +certificate. + +Assuming that the QEMU network services will only ever be exposed to +clients on a private intranet, there is no need to use a commercial +certificate authority to create certificates. A self-signed CA is +sufficient, and in fact likely to be more secure since it removes +the ability of malicious 3rd parties to trick the CA into mis-issuing +certs for impersonating your services. The only likely exception +where a commercial CA might be desirable is if enabling the VNC +websockets server and exposing it directly to remote browser clients. +In such a case it might be useful to use a commercial CA to avoid +needing to install custom CA certs in the web browsers. + +The recommendation is for the server to keep its certificates in either +@code{/etc/pki/qemu} or for unprivileged users in @code{$HOME/.pki/qemu}. =20 @menu -* vnc_generate_ca:: -* vnc_generate_server:: -* vnc_generate_client:: +* tls_generate_ca:: +* tls_generate_server:: +* tls_generate_client:: +* tls_creds_setup:: @end menu -@node vnc_generate_ca -@subsubsection Setup the Certificate Authority +@node tls_generate_ca +@subsection Setup the Certificate Authority =20 This step only needs to be performed once per organization / organizational unit. First the CA needs a private key. This key must be kept VERY secret @@ -1190,11 +1270,10 @@ issued with it is lost. # certtool --generate-privkey > ca-key.pem @end example =20 -A CA needs to have a public certificate. For simplicity it can be a self-s= igned -certificate, or one issue by a commercial certificate issuing authority. To -generate a self-signed certificate requires one core piece of information,= the -name of the organization. - +To generate a self-signed certificate requires one core piece of informati= on, +the name of the organization. A template file @code{ca.info} should be +populated with the desired data to avoid having to deal with interactive +prompts from certtool: @example # cat > ca.info < server.info < server-hostNNN.info < server-key.pem +# certtool --generate-privkey > server-hostNNN-key.pem # certtool --generate-certificate \ --load-ca-certificate ca-cert.pem \ --load-ca-privkey ca-key.pem \ - --load-privkey server-key.pem \ - --template server.info \ - --outfile server-cert.pem + --load-privkey server-hostNNN-key.pem \ + --template server-hostNNN.info \ + --outfile server-hostNNN-cert.pem @end example =20 -The @code{server-key.pem} and @code{server-cert.pem} files should now be s= ecurely copied -to the server for which they were generated. The @code{server-key.pem} is = security -sensitive and should be kept protected with file mode 0600 to prevent disc= losure. +The @code{dns_name} and @code{ip_address} fields in the template are setti= ng +the subject alt name extension data. The @code{tls_www_server} keyword is = the +key purpose extension to indicate this certificate is intended for usage in +a web server. Although QEMU network services are not in fact HTTP servers +(except for VNC websockets), setting this key purpose is still recommended. +The @code{encryption_key} and @code{signing_key} keyword is the key usage +extension to indicate this certificate is intended for usage in the data +session. =20 -@node vnc_generate_client -@subsubsection Issuing client certificates +The @code{server-hostNNN-key.pem} and @code{server-hostNNN-cert.pem} files +should now be securely copied to the server for which they were generated, +and renamed to @code{server-key.pem} and @code{server-cert.pem} when added +to the @code{/etc/pki/qemu} directory on the target host. The @code{server= -key.pem} +file is security sensitive and should be kept protected with file mode 0600 +to prevent disclosure. + +@node tls_generate_client +@subsection Issuing client certificates + +The QEMU x509 TLS credential setup defaults to enabling client verification +using certificates, providing a simple authentication mechanism. If this +default is used, each client also needs to be issued a certificate. The cl= ient +certificate contains enough metadata to uniquely identify the client with = the +scope of the certificate authority. The client certificate would typically +include fields for organization, state, city, building, etc. + +Once again on the host holding the CA, create template files containing the +information for each client, and use it to issue client certificates. =20 -If the QEMU VNC server is to use the @code{x509verify} option to validate = client -certificates as its authentication mechanism, each client also needs to be= issued -a certificate. The client certificate contains enough metadata to uniquely= identify -the client, typically organization, state, city, building, etc. On the hos= t holding -the secure CA private key: =20 @example -# cat > client.info < client-hostNNN.info < client-key.pem +# certtool --generate-privkey > client-hostNNN-key.pem # certtool --generate-certificate \ --load-ca-certificate ca-cert.pem \ --load-ca-privkey ca-key.pem \ - --load-privkey client-key.pem \ - --template client.info \ - --outfile client-cert.pem + --load-privkey client-hostNNN-key.pem \ + --template client-hostNNN.info \ + --outfile client-hostNNN-cert.pem +@end example + +The subject alt name extension data is not required for clients, so the +the @code{dns_name} and @code{ip_address} fields are not included. +The @code{tls_www_client} keyword is the key purpose extension to indicate +this certificate is intended for usage in a web client. Although QEMU +network clients are not in fact HTTP clients, setting this key purpose is +still recommended. The @code{encryption_key} and @code{signing_key} keyword +is the key usage extension to indicate this certificate is intended for +usage in the data session. + +The @code{client-hostNNN-key.pem} and @code{client-hostNNN-cert.pem} files +should now be securely copied to the client for which they were generated, +and renamed to @code{client-key.pem} and @code{client-cert.pem} when added +to the @code{/etc/pki/qemu} directory on the target host. The @code{client= -key.pem} +file is security sensitive and should be kept protected with file mode 0600 +to prevent disclosure. + +If a single host is going to be using TLS in both a client and server +role, it is possible to create a single certificate to cover both roles. +This would be quite common for the migration and NBD services, where a +QEMU process will be started by accepting a TLS protected incoming migrati= on, +and later itself be migrated out to another host. To generate a single +certificate, simply include the template data from both the client and ser= ver +instructions in one. + +@example +# cat > both-hostNNN.info < both-hostNNN-key.pem +# certtool --generate-certificate \ + --load-ca-certificate ca-cert.pem \ + --load-ca-privkey ca-key.pem \ + --load-privkey both-hostNNN-key.pem \ + --template both-hostNNN.info \ + --outfile both-hostNNN-cert.pem @end example =20 -The @code{client-key.pem} and @code{client-cert.pem} files should now be s= ecurely -copied to the client for which they were generated. +When copying the PEM files to the target host, save them twice, +once as @code{server-cert.pem} and @code{server-key.pem}, and +again as @code{client-cert.pem} and @code{client-key.pem}. =20 +@node tls_creds_setup +@subsection TLS x509 credential configuration =20 -@node vnc_setup_sasl +QEMU has a standard mechanism for loading x509 credentials that will be +used for network services and clients. It requires specifying the +@code{tls-creds-x509} class name to the @code{--object} command line +argument for the system emulators. Each set of credentials loaded should +be given a unique string identifier via the @code{id} parameter. A single +set of TLS credentials can be used for multiple network backends, so VNC, +migration, NBD, character devices can all share the same credentials. Note, +however, that credentials for use in a client endpoint must be loaded +separately from those used in a server endpoint. =20 -@subsection Configuring SASL mechanisms +When specifying the object, the @code{dir} parameters specifies which +directory contains the credential files. This directory is expected to +contain files with the names mentioned previously, @code{ca-cert.pem}, +@code{server-key.pem}, @code{server-cert.pem}, @code{client-key.pem} +and @code{client-cert.pem} as appropriate. It is also possible to +include a set of pre-generated Diffie-Hellman (DH) parameters in a file +@code{dh-params.pem}, which can be created using the +@code{certtool --generate-dh-params} command. If omitted, QEMU will +dynamically generate DH parameters when loading the credentials. =20 -The following documentation assumes use of the Cyrus SASL implementation o= n a -Linux host, but the principals should apply to any other SASL impl. When S= ASL -is enabled, the mechanism configuration will be loaded from system default -SASL service config /etc/sasl2/qemu.conf. If running QEMU as an -unprivileged user, an environment variable SASL_CONF_PATH can be used -to make it search alternate locations for the service config. +The @code{endpoint} parameter indicates whether the credentials will +be used for a network client or server, and determines which PEM +files are loaded. =20 -If the TLS option is enabled for VNC, then it will provide session encrypt= ion, -otherwise the SASL mechanism will have to provide encryption. In the latter -case the list of possible plugins that can be used is drastically reduced.= In -fact only the GSSAPI SASL mechanism provides an acceptable level of securi= ty -by modern standards. Previous versions of QEMU referred to the DIGEST-MD5 -mechanism, however, it has multiple serious flaws described in detail in -RFC 6331 and thus should never be used any more. The SCRAM-SHA-1 mechanism -provides a simple username/password auth facility similar to DIGEST-MD5, b= ut -does not support session encryption, so can only be used in combination wi= th -TLS. +The @code{verify} parameter determines whether x509 certificate +validation should be performed. This defaults to enabled, meaning +clients will always validate the server hostname against the +certificate subject alt name fields and/or CN field. It also +means that servers will request that clients provide a certificate +and validate them. Verification should never be turned off for +client endpoints, however, it may be turned off for server endpoints +if an alternative mechanism is used to authenticate clients. For +example, the VNC server can use SASL to authenticate clients +instead. =20 -When not using TLS the recommended configuration is +To load server credentials with client certificate validation +enabled =20 @example -mech_list: gssapi -keytab: /etc/qemu/krb5.tab +$QEMU -object tls-creds-x509,id=3Dtls0,dir=3D/etc/pki/qemu,endpoint=3Dserv= er @end example =20 -This says to use the 'GSSAPI' mechanism with the Kerberos v5 protocol, with -the server principal stored in /etc/qemu/krb5.tab. For this to work the -administrator of your KDC must generate a Kerberos principal for the serve= r, -with a name of 'qemu/somehost.example.com@@EXAMPLE.COM' replacing -'somehost.example.com' with the fully qualified host name of the machine -running QEMU, and 'EXAMPLE.COM' with the Kerberos Realm. - -When using TLS, if username+password authentication is desired, then a -reasonable configuration is +while to load client credentials use =20 @example -mech_list: scram-sha-1 -sasldb_path: /etc/qemu/passwd.db +$QEMU -object tls-creds-x509,id=3Dtls0,dir=3D/etc/pki/qemu,endpoint=3Dclie= nt @end example =20 -The saslpasswd2 program can be used to populate the passwd.db file with -accounts. +Network services which support TLS will all have a @code{tls-creds} +parameter which expects the ID of the TLS credentials object. For +example with VNC: =20 -Other SASL configurations will be left as an exercise for the reader. Note= that -all mechanisms except GSSAPI, should be combined with use of TLS to ensure= a -secure data channel. +@example +$QEMU -vnc 0.0.0.0:0,tls-creds=3Dtls0 +@end example =20 @node gdb_usage @section GDB usage --=20 2.14.3 From nobody Fri May 3 10:05:30 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1523021610116666.8552450613458; Fri, 6 Apr 2018 06:33:30 -0700 (PDT) Received: from localhost ([::1]:56035 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4RUf-0007gX-An for importer@patchew.org; Fri, 06 Apr 2018 09:33:29 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4RSF-0006IY-0J for qemu-devel@nongnu.org; Fri, 06 Apr 2018 09:31:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4RSB-00036F-1u for qemu-devel@nongnu.org; Fri, 06 Apr 2018 09:30:59 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:35740 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f4RSA-00035p-Tw for qemu-devel@nongnu.org; Fri, 06 Apr 2018 09:30:54 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 29BFF77067 for ; Fri, 6 Apr 2018 13:30:54 +0000 (UTC) Received: from t460.redhat.com (unknown [10.33.36.63]) by smtp.corp.redhat.com (Postfix) with ESMTP id E20B88444F; Fri, 6 Apr 2018 13:30:52 +0000 (UTC) From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Date: Fri, 6 Apr 2018 14:30:45 +0100 Message-Id: <20180406133046.5682-3-berrange@redhat.com> In-Reply-To: <20180406133046.5682-1-berrange@redhat.com> References: <20180406133046.5682-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 06 Apr 2018 13:30:54 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 06 Apr 2018 13:30:54 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'berrange@redhat.com' RCPT:'' Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PULL 2/3] docs: Document -object tls-creds-x509 priority=xxx X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Christophe Fergeau Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" From: Christophe Fergeau This was added in 13f1243, but is missing from qemu-options.hx Signed-off-by: Christophe Fergeau Signed-off-by: Daniel P. Berrang=C3=A9 --- qemu-options.hx | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/qemu-options.hx b/qemu-options.hx index 3ece30d216..ca4e412f2f 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -4112,7 +4112,7 @@ expensive operation that consumes random pool entropy= , so it is recommended that a persistent set of parameters be generated upfront and saved. =20 -@item -object tls-creds-x509,id=3D@var{id},endpoint=3D@var{endpoint},dir= =3D@var{/path/to/cred/dir},verify-peer=3D@var{on|off},passwordid=3D@var{id} +@item -object tls-creds-x509,id=3D@var{id},endpoint=3D@var{endpoint},dir= =3D@var{/path/to/cred/dir},priority=3D@var{priority},verify-peer=3D@var{on|= off},passwordid=3D@var{id} =20 Creates a TLS anonymous credentials object, which can be used to provide TLS support on network backends. The @option{id} parameter is a unique @@ -4145,6 +4145,15 @@ version by providing the @var{passwordid} parameter.= This provides the ID of a previously created @code{secret} object containing the password for decryption. =20 +The @var{priority} parameter allows to override the global default +priority used by gnutls. This can be useful if the system administrator +needs to use a weaker set of crypto priorities for QEMU without +potentially forcing the weakness onto all applications. Or conversely +if one wants wants a stronger default for QEMU than for all other +applications, they can do this through this parameter. Its format is +a gnutls priority string as described at +@url{https://gnutls.org/manual/html_node/Priority-Strings.html}. + @item -object filter-buffer,id=3D@var{id},netdev=3D@var{netdevid},interval= =3D@var{t}[,queue=3D@var{all|rx|tx}][,status=3D@var{on|off}] =20 Interval @var{t} can't be 0, this filter batches the packet delivery: all --=20 2.14.3 From nobody Fri May 3 10:05:30 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1523021610645300.82352191180655; Fri, 6 Apr 2018 06:33:30 -0700 (PDT) Received: from localhost ([::1]:56036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4RUf-0007gc-J9 for importer@patchew.org; Fri, 06 Apr 2018 09:33:29 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4RSF-0006IW-0G for qemu-devel@nongnu.org; Fri, 06 Apr 2018 09:30:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4RSC-00037G-DL for qemu-devel@nongnu.org; Fri, 06 Apr 2018 09:30:59 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:57808 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f4RSC-00036w-6B for qemu-devel@nongnu.org; Fri, 06 Apr 2018 09:30:56 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B0756818B126 for ; Fri, 6 Apr 2018 13:30:55 +0000 (UTC) Received: from t460.redhat.com (unknown [10.33.36.63]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9B4D7AFD5C; Fri, 6 Apr 2018 13:30:54 +0000 (UTC) From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Date: Fri, 6 Apr 2018 14:30:46 +0100 Message-Id: <20180406133046.5682-4-berrange@redhat.com> In-Reply-To: <20180406133046.5682-1-berrange@redhat.com> References: <20180406133046.5682-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 06 Apr 2018 13:30:55 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 06 Apr 2018 13:30:55 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'berrange@redhat.com' RCPT:'' Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PULL 3/3] crypto: ensure we use a predictable TLS priority setting X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" The TLS test cert generation relies on a fixed set of algorithms that are only usable under GNUTLS' default priority setting. When building QEMU with a custom distro specific priority setting, this can cause the TLS tests to fail. By forcing the tests to always use "NORMAL" priority we can make them more robust. Reviewed-by: Eric Blake Signed-off-by: Daniel P. Berrang=C3=A9 --- tests/test-crypto-tlssession.c | 1 + tests/test-io-channel-tls.c | 1 + 2 files changed, 2 insertions(+) diff --git a/tests/test-crypto-tlssession.c b/tests/test-crypto-tlssession.c index 1a4a066d76..82f21c27f2 100644 --- a/tests/test-crypto-tlssession.c +++ b/tests/test-crypto-tlssession.c @@ -75,6 +75,7 @@ static QCryptoTLSCreds *test_tls_creds_create(QCryptoTLSC= redsEndpoint endpoint, "server" : "client"), "dir", certdir, "verify-peer", "yes", + "priority", "NORMAL", /* We skip initial sanity checks here because we * want to make sure that problems are being * detected at the TLS session validation stage, diff --git a/tests/test-io-channel-tls.c b/tests/test-io-channel-tls.c index 32743b2c96..bb88ee870f 100644 --- a/tests/test-io-channel-tls.c +++ b/tests/test-io-channel-tls.c @@ -78,6 +78,7 @@ static QCryptoTLSCreds *test_tls_creds_create(QCryptoTLSC= redsEndpoint endpoint, "server" : "client"), "dir", certdir, "verify-peer", "yes", + "priority", "NORMAL", /* We skip initial sanity checks here because we * want to make sure that problems are being * detected at the TLS session validation stage, --=20 2.14.3