qemu-e2k/ui/vnc-auth-vencrypt.c

188 lines
5.9 KiB
C
Raw Normal View History

/*
* QEMU VNC display driver: VeNCrypt authentication setup
*
* Copyright (C) 2006 Anthony Liguori <anthony@codemonkey.ws>
* Copyright (C) 2006 Fabrice Bellard
* Copyright (C) 2009 Red Hat, Inc
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include "vnc.h"
#include "qemu/main-loop.h"
static void start_auth_vencrypt_subauth(VncState *vs)
{
switch (vs->subauth) {
case VNC_AUTH_VENCRYPT_TLSNONE:
case VNC_AUTH_VENCRYPT_X509NONE:
VNC_DEBUG("Accept TLS auth none\n");
vnc_write_u32(vs, 0); /* Accept auth completion */
start_client_init(vs);
break;
case VNC_AUTH_VENCRYPT_TLSVNC:
case VNC_AUTH_VENCRYPT_X509VNC:
VNC_DEBUG("Start TLS auth VNC\n");
start_auth_vnc(vs);
break;
#ifdef CONFIG_VNC_SASL
case VNC_AUTH_VENCRYPT_TLSSASL:
case VNC_AUTH_VENCRYPT_X509SASL:
VNC_DEBUG("Start TLS auth SASL\n");
start_auth_sasl(vs);
break;
#endif /* CONFIG_VNC_SASL */
default: /* Should not be possible, but just in case */
VNC_DEBUG("Reject subauth %d server bug\n", vs->auth);
vnc_write_u8(vs, 1);
if (vs->minor >= 8) {
static const char err[] = "Unsupported authentication type";
vnc_write_u32(vs, sizeof(err));
vnc_write(vs, err, sizeof(err));
}
vnc_client_error(vs);
}
}
static void vnc_tls_handshake_io(void *opaque);
static int vnc_start_vencrypt_handshake(VncState *vs)
{
ui: convert VNC server to use QCryptoTLSSession Switch VNC server over to using the QCryptoTLSSession object for the TLS session. This removes the direct use of gnutls from the VNC server code. It also removes most knowledge about TLS certificate handling from the VNC server code. This has the nice effect that all the CONFIG_VNC_TLS conditionals go away and the user gets an actual error message when requesting TLS instead of it being silently ignored. With this change, the existing configuration options for enabling TLS with -vnc are deprecated. Old syntax for anon-DH credentials: -vnc hostname:0,tls New syntax: -object tls-creds-anon,id=tls0,endpoint=server \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, no client certs: -vnc hostname:0,tls,x509=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, requiring client certs: -vnc hostname:0,tls,x509verify=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \ -vnc hostname:0,tls-creds=tls0 This aligns VNC with the way TLS credentials are to be configured in the future for chardev, nbd and migration backends. It also has the benefit that the same TLS credentials can be shared across multiple VNC server instances, if desired. If someone uses the deprecated syntax, it will internally result in the creation of a 'tls-creds' object with an ID based on the VNC server ID. This allows backwards compat with the CLI syntax, while still deleting all the original TLS code from the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-08-06 15:39:32 +02:00
Error *err = NULL;
if (qcrypto_tls_session_handshake(vs->tls, &err) < 0) {
goto error;
}
ui: convert VNC server to use QCryptoTLSSession Switch VNC server over to using the QCryptoTLSSession object for the TLS session. This removes the direct use of gnutls from the VNC server code. It also removes most knowledge about TLS certificate handling from the VNC server code. This has the nice effect that all the CONFIG_VNC_TLS conditionals go away and the user gets an actual error message when requesting TLS instead of it being silently ignored. With this change, the existing configuration options for enabling TLS with -vnc are deprecated. Old syntax for anon-DH credentials: -vnc hostname:0,tls New syntax: -object tls-creds-anon,id=tls0,endpoint=server \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, no client certs: -vnc hostname:0,tls,x509=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, requiring client certs: -vnc hostname:0,tls,x509verify=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \ -vnc hostname:0,tls-creds=tls0 This aligns VNC with the way TLS credentials are to be configured in the future for chardev, nbd and migration backends. It also has the benefit that the same TLS credentials can be shared across multiple VNC server instances, if desired. If someone uses the deprecated syntax, it will internally result in the creation of a 'tls-creds' object with an ID based on the VNC server ID. This allows backwards compat with the CLI syntax, while still deleting all the original TLS code from the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-08-06 15:39:32 +02:00
switch (qcrypto_tls_session_get_handshake_status(vs->tls)) {
case QCRYPTO_TLS_HANDSHAKE_COMPLETE:
VNC_DEBUG("Handshake done, checking credentials\n");
if (qcrypto_tls_session_check_credentials(vs->tls, &err) < 0) {
goto error;
}
ui: convert VNC server to use QCryptoTLSSession Switch VNC server over to using the QCryptoTLSSession object for the TLS session. This removes the direct use of gnutls from the VNC server code. It also removes most knowledge about TLS certificate handling from the VNC server code. This has the nice effect that all the CONFIG_VNC_TLS conditionals go away and the user gets an actual error message when requesting TLS instead of it being silently ignored. With this change, the existing configuration options for enabling TLS with -vnc are deprecated. Old syntax for anon-DH credentials: -vnc hostname:0,tls New syntax: -object tls-creds-anon,id=tls0,endpoint=server \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, no client certs: -vnc hostname:0,tls,x509=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, requiring client certs: -vnc hostname:0,tls,x509verify=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \ -vnc hostname:0,tls-creds=tls0 This aligns VNC with the way TLS credentials are to be configured in the future for chardev, nbd and migration backends. It also has the benefit that the same TLS credentials can be shared across multiple VNC server instances, if desired. If someone uses the deprecated syntax, it will internally result in the creation of a 'tls-creds' object with an ID based on the VNC server ID. This allows backwards compat with the CLI syntax, while still deleting all the original TLS code from the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-08-06 15:39:32 +02:00
VNC_DEBUG("Client verification passed, starting TLS I/O\n");
qemu_set_fd_handler(vs->csock, vnc_client_read, vnc_client_write, vs);
start_auth_vencrypt_subauth(vs);
break;
ui: convert VNC server to use QCryptoTLSSession Switch VNC server over to using the QCryptoTLSSession object for the TLS session. This removes the direct use of gnutls from the VNC server code. It also removes most knowledge about TLS certificate handling from the VNC server code. This has the nice effect that all the CONFIG_VNC_TLS conditionals go away and the user gets an actual error message when requesting TLS instead of it being silently ignored. With this change, the existing configuration options for enabling TLS with -vnc are deprecated. Old syntax for anon-DH credentials: -vnc hostname:0,tls New syntax: -object tls-creds-anon,id=tls0,endpoint=server \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, no client certs: -vnc hostname:0,tls,x509=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, requiring client certs: -vnc hostname:0,tls,x509verify=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \ -vnc hostname:0,tls-creds=tls0 This aligns VNC with the way TLS credentials are to be configured in the future for chardev, nbd and migration backends. It also has the benefit that the same TLS credentials can be shared across multiple VNC server instances, if desired. If someone uses the deprecated syntax, it will internally result in the creation of a 'tls-creds' object with an ID based on the VNC server ID. This allows backwards compat with the CLI syntax, while still deleting all the original TLS code from the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-08-06 15:39:32 +02:00
case QCRYPTO_TLS_HANDSHAKE_RECVING:
VNC_DEBUG("Handshake interrupted (blocking read)\n");
qemu_set_fd_handler(vs->csock, vnc_tls_handshake_io, NULL, vs);
break;
ui: convert VNC server to use QCryptoTLSSession Switch VNC server over to using the QCryptoTLSSession object for the TLS session. This removes the direct use of gnutls from the VNC server code. It also removes most knowledge about TLS certificate handling from the VNC server code. This has the nice effect that all the CONFIG_VNC_TLS conditionals go away and the user gets an actual error message when requesting TLS instead of it being silently ignored. With this change, the existing configuration options for enabling TLS with -vnc are deprecated. Old syntax for anon-DH credentials: -vnc hostname:0,tls New syntax: -object tls-creds-anon,id=tls0,endpoint=server \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, no client certs: -vnc hostname:0,tls,x509=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, requiring client certs: -vnc hostname:0,tls,x509verify=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \ -vnc hostname:0,tls-creds=tls0 This aligns VNC with the way TLS credentials are to be configured in the future for chardev, nbd and migration backends. It also has the benefit that the same TLS credentials can be shared across multiple VNC server instances, if desired. If someone uses the deprecated syntax, it will internally result in the creation of a 'tls-creds' object with an ID based on the VNC server ID. This allows backwards compat with the CLI syntax, while still deleting all the original TLS code from the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-08-06 15:39:32 +02:00
case QCRYPTO_TLS_HANDSHAKE_SENDING:
VNC_DEBUG("Handshake interrupted (blocking write)\n");
qemu_set_fd_handler(vs->csock, NULL, vnc_tls_handshake_io, vs);
break;
}
return 0;
ui: convert VNC server to use QCryptoTLSSession Switch VNC server over to using the QCryptoTLSSession object for the TLS session. This removes the direct use of gnutls from the VNC server code. It also removes most knowledge about TLS certificate handling from the VNC server code. This has the nice effect that all the CONFIG_VNC_TLS conditionals go away and the user gets an actual error message when requesting TLS instead of it being silently ignored. With this change, the existing configuration options for enabling TLS with -vnc are deprecated. Old syntax for anon-DH credentials: -vnc hostname:0,tls New syntax: -object tls-creds-anon,id=tls0,endpoint=server \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, no client certs: -vnc hostname:0,tls,x509=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, requiring client certs: -vnc hostname:0,tls,x509verify=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \ -vnc hostname:0,tls-creds=tls0 This aligns VNC with the way TLS credentials are to be configured in the future for chardev, nbd and migration backends. It also has the benefit that the same TLS credentials can be shared across multiple VNC server instances, if desired. If someone uses the deprecated syntax, it will internally result in the creation of a 'tls-creds' object with an ID based on the VNC server ID. This allows backwards compat with the CLI syntax, while still deleting all the original TLS code from the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-08-06 15:39:32 +02:00
error:
VNC_DEBUG("Handshake failed %s\n", error_get_pretty(err));
error_free(err);
vnc_client_error(vs);
return -1;
}
static void vnc_tls_handshake_io(void *opaque)
{
VncState *vs = (VncState *)opaque;
VNC_DEBUG("Handshake IO continue\n");
vnc_start_vencrypt_handshake(vs);
}
static int protocol_client_vencrypt_auth(VncState *vs, uint8_t *data, size_t len)
{
int auth = read_u32(data, 0);
if (auth != vs->subauth) {
VNC_DEBUG("Rejecting auth %d\n", auth);
vnc_write_u8(vs, 0); /* Reject auth */
vnc_flush(vs);
vnc_client_error(vs);
} else {
ui: convert VNC server to use QCryptoTLSSession Switch VNC server over to using the QCryptoTLSSession object for the TLS session. This removes the direct use of gnutls from the VNC server code. It also removes most knowledge about TLS certificate handling from the VNC server code. This has the nice effect that all the CONFIG_VNC_TLS conditionals go away and the user gets an actual error message when requesting TLS instead of it being silently ignored. With this change, the existing configuration options for enabling TLS with -vnc are deprecated. Old syntax for anon-DH credentials: -vnc hostname:0,tls New syntax: -object tls-creds-anon,id=tls0,endpoint=server \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, no client certs: -vnc hostname:0,tls,x509=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, requiring client certs: -vnc hostname:0,tls,x509verify=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \ -vnc hostname:0,tls-creds=tls0 This aligns VNC with the way TLS credentials are to be configured in the future for chardev, nbd and migration backends. It also has the benefit that the same TLS credentials can be shared across multiple VNC server instances, if desired. If someone uses the deprecated syntax, it will internally result in the creation of a 'tls-creds' object with an ID based on the VNC server ID. This allows backwards compat with the CLI syntax, while still deleting all the original TLS code from the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-08-06 15:39:32 +02:00
Error *err = NULL;
VNC_DEBUG("Accepting auth %d, setting up TLS for handshake\n", auth);
vnc_write_u8(vs, 1); /* Accept auth */
vnc_flush(vs);
ui: convert VNC server to use QCryptoTLSSession Switch VNC server over to using the QCryptoTLSSession object for the TLS session. This removes the direct use of gnutls from the VNC server code. It also removes most knowledge about TLS certificate handling from the VNC server code. This has the nice effect that all the CONFIG_VNC_TLS conditionals go away and the user gets an actual error message when requesting TLS instead of it being silently ignored. With this change, the existing configuration options for enabling TLS with -vnc are deprecated. Old syntax for anon-DH credentials: -vnc hostname:0,tls New syntax: -object tls-creds-anon,id=tls0,endpoint=server \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, no client certs: -vnc hostname:0,tls,x509=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, requiring client certs: -vnc hostname:0,tls,x509verify=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \ -vnc hostname:0,tls-creds=tls0 This aligns VNC with the way TLS credentials are to be configured in the future for chardev, nbd and migration backends. It also has the benefit that the same TLS credentials can be shared across multiple VNC server instances, if desired. If someone uses the deprecated syntax, it will internally result in the creation of a 'tls-creds' object with an ID based on the VNC server ID. This allows backwards compat with the CLI syntax, while still deleting all the original TLS code from the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-08-06 15:39:32 +02:00
vs->tls = qcrypto_tls_session_new(vs->vd->tlscreds,
NULL,
vs->vd->tlsaclname,
QCRYPTO_TLS_CREDS_ENDPOINT_SERVER,
&err);
if (!vs->tls) {
VNC_DEBUG("Failed to setup TLS %s\n",
error_get_pretty(err));
error_free(err);
vnc_client_error(vs);
return 0;
}
ui: convert VNC server to use QCryptoTLSSession Switch VNC server over to using the QCryptoTLSSession object for the TLS session. This removes the direct use of gnutls from the VNC server code. It also removes most knowledge about TLS certificate handling from the VNC server code. This has the nice effect that all the CONFIG_VNC_TLS conditionals go away and the user gets an actual error message when requesting TLS instead of it being silently ignored. With this change, the existing configuration options for enabling TLS with -vnc are deprecated. Old syntax for anon-DH credentials: -vnc hostname:0,tls New syntax: -object tls-creds-anon,id=tls0,endpoint=server \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, no client certs: -vnc hostname:0,tls,x509=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, requiring client certs: -vnc hostname:0,tls,x509verify=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \ -vnc hostname:0,tls-creds=tls0 This aligns VNC with the way TLS credentials are to be configured in the future for chardev, nbd and migration backends. It also has the benefit that the same TLS credentials can be shared across multiple VNC server instances, if desired. If someone uses the deprecated syntax, it will internally result in the creation of a 'tls-creds' object with an ID based on the VNC server ID. This allows backwards compat with the CLI syntax, while still deleting all the original TLS code from the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-08-06 15:39:32 +02:00
qcrypto_tls_session_set_callbacks(vs->tls,
vnc_tls_push,
vnc_tls_pull,
vs);
VNC_DEBUG("Start TLS VeNCrypt handshake process\n");
if (vnc_start_vencrypt_handshake(vs) < 0) {
VNC_DEBUG("Failed to start TLS handshake\n");
return 0;
}
}
return 0;
}
static int protocol_client_vencrypt_init(VncState *vs, uint8_t *data, size_t len)
{
if (data[0] != 0 ||
data[1] != 2) {
VNC_DEBUG("Unsupported VeNCrypt protocol %d.%d\n", (int)data[0], (int)data[1]);
vnc_write_u8(vs, 1); /* Reject version */
vnc_flush(vs);
vnc_client_error(vs);
} else {
VNC_DEBUG("Sending allowed auth %d\n", vs->subauth);
vnc_write_u8(vs, 0); /* Accept version */
vnc_write_u8(vs, 1); /* Number of sub-auths */
vnc_write_u32(vs, vs->subauth); /* The supported auth */
vnc_flush(vs);
vnc_read_when(vs, protocol_client_vencrypt_auth, 4);
}
return 0;
}
void start_auth_vencrypt(VncState *vs)
{
/* Send VeNCrypt version 0.2 */
vnc_write_u8(vs, 0);
vnc_write_u8(vs, 2);
vnc_read_when(vs, protocol_client_vencrypt_init, 2);
}