From: Tim Hardeck <thardeck@suse.de>
To: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] VNC Websocket TLS support design decisions
Date: Fri, 12 Apr 2013 11:00:08 +0200 [thread overview]
Message-ID: <5167CD18.20706@suse.de> (raw)
In-Reply-To: <5166BB9F.6060407@suse.de>
Hi,
I have sent in my current implementation some minutes ago.
On 04/11/2013 03:33 PM, Tim Hardeck wrote:
> Websockets over TLS need certificates.
> We already have the "x509" vnc parameter for VNC-TLS to provide the
> certificates but user might have one webserver certificate and one for
> VNC TLS authentication. Of course in this case they could use two vnc
> instances.
> The other issue is that Websockets TLS should work when vnc-tls is
> disabled since GnuTLS is already a requirement for Websockets anyway.
> Should I use this x509 certificate parameter also or add an additional
> parameter like "ws_x509"?
In my current implementation the general "x509" vnc parameter is used to
provide the path for the certificates.
> Should there be an option to only allow Websockets over TLS?
> For example how to react in case of the option "tls=1".
> In my current implementation the Websocket connection is checked during
> initiation for an encryption handshake and and then acted accordingly.
If "tls" is specified Websockets can't be used because VEncrypt is
enforced then which is not supported by noVNC.
In general VNC TLS is decrypted before the Websocket decoding so it
can't be stacked atm. I don't think that it is needed anyway since there
is Websocket TLS support now but there might be HTML 5 clients with
VEncrypt support in the future.
I haven't added any option to only allow encrypted Websockets
connections [yet]. Let me know if this is worth adding another VNC option.
>
> To my knowledge current HTML5 VNC clients do not support another
> authentication then password, so no VEncrypt.
> This means that if I enable tls=1 Websockets connection can't be
> established for this vnc instance.
> Should I add some workaround to use password authentication for
> Websockets or just document it so users could use two vnc instances for
> this use case?
If "tls=1" is specified noVNC shows the message that this security type
is not supported which should be fine I suppose.
> For my implementation I am using many parts of vnc-tls. I am planning to
> make some functions in vnc-tls more flexible or add some checks to allow
> them to be used for Websocket TLS connections.
> Would this be OK or do you have other suggestions.
I got rid of all duplicates except of the functions regarding the TLS
handshake which I imported from vnc-auth-vencrypt.c.
Regards
Tim
--
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
T: +49 (0) 911 74053-0 F: +49 (0) 911 74053-483
http://www.suse.de/
prev parent reply other threads:[~2013-04-12 9:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-11 13:33 [Qemu-devel] VNC Websocket TLS support design decisions Tim Hardeck
2013-04-12 9:00 ` Tim Hardeck [this message]
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=5167CD18.20706@suse.de \
--to=thardeck@suse.de \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).