All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Vladimir Sementsov-Ogievskiy" <vsementsov@virtuozzo.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-block@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"Hanna Reitz" <hreitz@redhat.com>,
	"Eric Blake" <eblake@redhat.com>
Subject: [PATCH 01/12] crypto: mandate a hostname when checking x509 creds on a client
Date: Thu,  3 Mar 2022 16:03:19 +0000	[thread overview]
Message-ID: <20220303160330.2979753-2-berrange@redhat.com> (raw)
In-Reply-To: <20220303160330.2979753-1-berrange@redhat.com>

Currently the TLS session object assumes that the caller will always
provide a hostname when using x509 creds on a client endpoint. This
relies on the caller to detect and report an error if the user has
configured QEMU with x509 credentials on a UNIX socket. The migration
code has such a check, but it is too broad, reporting an error when
the user has configured QEMU with PSK credentials on a UNIX socket,
where hostnames are irrelevant.

Putting the check into the TLS session object credentials validation
code ensures we report errors in only the scenario that matters.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 crypto/tlssession.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/crypto/tlssession.c b/crypto/tlssession.c
index a8db8c76d1..b302d835d2 100644
--- a/crypto/tlssession.c
+++ b/crypto/tlssession.c
@@ -373,6 +373,12 @@ qcrypto_tls_session_check_certificate(QCryptoTLSSession *session,
                                session->hostname);
                     goto error;
                 }
+            } else {
+                if (session->creds->endpoint ==
+                    QCRYPTO_TLS_CREDS_ENDPOINT_CLIENT) {
+                    error_setg(errp, "No hostname for certificate validation");
+                    goto error;
+                }
             }
         }
 
-- 
2.34.1



  reply	other threads:[~2022-03-03 16:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-03 16:03 [PATCH 00/12] nbd: enable use of TLS on non-TCP transports and other TLS improvements Daniel P. Berrangé
2022-03-03 16:03 ` Daniel P. Berrangé [this message]
2022-03-03 20:10   ` [PATCH 01/12] crypto: mandate a hostname when checking x509 creds on a client Eric Blake
2022-03-03 16:03 ` [PATCH 02/12] block: pass desired TLS hostname through from block driver client Daniel P. Berrangé
2022-03-03 20:14   ` Eric Blake
2022-03-04 19:19     ` Daniel P. Berrangé
2022-03-03 16:03 ` [PATCH 03/12] block/nbd: support override of hostname for TLS certificate validation Daniel P. Berrangé
2022-03-03 21:46   ` Eric Blake
2022-03-03 16:03 ` [PATCH 04/12] qemu-nbd: add --tls-hostname option " Daniel P. Berrangé
2022-03-03 22:47   ` Eric Blake
2022-03-03 16:03 ` [PATCH 05/12] block/nbd: don't restrict TLS usage to IP sockets Daniel P. Berrangé
2022-03-04 15:54   ` Eric Blake
2022-03-03 16:03 ` [PATCH 06/12] tests/qemu-iotests: add QEMU_IOTESTS_REGEN=1 to update reference file Daniel P. Berrangé
2022-03-04 16:36   ` Eric Blake
2022-03-03 16:03 ` [PATCH 07/12] tests/qemu-iotests: expand _filter_nbd rules Daniel P. Berrangé
2022-03-04 16:41   ` Eric Blake
2022-03-03 16:03 ` [PATCH 08/12] tests/qemu-iotests: introduce filter for qemu-nbd export list Daniel P. Berrangé
2022-03-04 16:43   ` Eric Blake
2022-03-04 19:32     ` Daniel P. Berrangé
2022-03-03 16:03 ` [PATCH 09/12] tests/qemu-iotests: convert NBD TLS test to use standard filters Daniel P. Berrangé
2022-03-04 16:45   ` Eric Blake
2022-03-03 16:03 ` [PATCH 10/12] tests/qemu-iotests: validate NBD TLS with hostname mismatch Daniel P. Berrangé
2022-03-04 16:49   ` Eric Blake
2022-03-03 16:03 ` [PATCH 11/12] tests/qemu-iotests: validate NBD TLS with UNIX sockets Daniel P. Berrangé
2022-03-04 16:50   ` Eric Blake
2022-03-03 16:03 ` [PATCH 12/12] tests/qemu-iotests: validate NBD TLS with UNIX sockets and PSK Daniel P. Berrangé
2022-03-04 16:51   ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220303160330.2979753-2-berrange@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.