Skip to content
Snippets Groups Projects
  1. Jul 12, 2016
  2. Dec 18, 2015
  3. Sep 15, 2015
    • Daniel P. Berrangé's avatar
      ui: convert VNC server to use QCryptoTLSSession · 3e305e4a
      Daniel P. Berrangé authored
      
      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: default avatarDaniel P. Berrange <berrange@redhat.com>
      3e305e4a
  4. Jul 08, 2015
  5. Apr 01, 2015
    • Daniel P. Berrangé's avatar
      CVE-2015-1779: incrementally decode websocket frames · a2bebfd6
      Daniel P. Berrangé authored
      
      The logic for decoding websocket frames wants to fully
      decode the frame header and payload, before allowing the
      VNC server to see any of the payload data. There is no
      size limit on websocket payloads, so this allows a
      malicious network client to consume 2^64 bytes in memory
      in QEMU. It can trigger this denial of service before
      the VNC server even performs any authentication.
      
      The fix is to decode the header, and then incrementally
      decode the payload data as it is needed. With this fix
      the websocket decoder will allow at most 4k of data to
      be buffered before decoding and processing payload.
      
      Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
      
      [ kraxel: fix frequent spurious disconnects, suggested by Peter Maydell ]
      
        @@ -361,7 +361,7 @@ int vncws_decode_frame_payload(Buffer *input,
        -        *payload_size = input->offset;
        +        *payload_size = *payload_remain;
      
      [ kraxel: fix 32bit build ]
      
        @@ -306,7 +306,7 @@ struct VncState
        -    uint64_t ws_payload_remain;
        +    size_t ws_payload_remain;
      
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      a2bebfd6
  6. Mar 18, 2015
    • Daniel P. Berrangé's avatar
      ui: enforce TLS when using websockets server · 51941e46
      Daniel P. Berrangé authored
      
      When TLS is required, the primary VNC server considers it to be
      mandatory. ie the server admin decides whether or not TLS is used,
      and the client has to comply with this decision. The websockets
      server, however, treated it as optional, allowing non-TLS clients
      to connect to a server which had setup TLS. Thus enabling websockets
      lowers the security of the VNC server leaving the admin no way to
      enforce use of TLS.
      
      This removes the code that allows non-TLS fallback in the websockets
      server, so that if TLS is requested for VNC it is now mandatory for
      both the primary VNC server and the websockets VNC server.
      
      Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      51941e46
  7. May 03, 2013
    • Tim Hardeck's avatar
      TLS support for VNC Websockets · 0057a0d5
      Tim Hardeck authored
      
      Added TLS support to the VNC QEMU Websockets implementation.
      VNC-TLS needs to be enabled for this feature to be used.
      
      The required certificates are specified as in case of VNC-TLS
      with the VNC parameter "x509=<path>".
      
      If the server certificate isn't signed by a rooth authority it needs to
      be manually imported in the browser because at least in case of Firefox
      and Chrome there is no user dialog, the connection just gets canceled.
      
      As a side note VEncrypt over Websocket doesn't work atm because TLS can't
      be stacked in the current implementation. (It also didn't work before)
      Nevertheless to my knowledge there is no HTML 5 VNC client which supports
      it and the Websocket connection can be encrypted with regular TLS now so
      it should be fine for most use cases.
      
      Signed-off-by: default avatarTim Hardeck <thardeck@suse.de>
      Reviewed-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      Message-id: 1366727581-5772-1-git-send-email-thardeck@suse.de
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      0057a0d5
  8. Jan 21, 2013
    • Tim Hardeck's avatar
      vnc: added initial websocket protocol support · 7536ee4b
      Tim Hardeck authored
      
      This patch adds basic Websocket Protocol version 13 - RFC 6455 - support
      to QEMU VNC. Binary encoding support on the client side is mandatory.
      
      Because of the GnuTLS requirement the Websockets implementation is
      optional (--enable-vnc-ws).
      
      To activate Websocket support the VNC option "websocket"is used, for
      example "-vnc :0,websocket".
      The listen port for Websocket connections is (5700 + display) so if
      QEMU VNC is started with :0 the Websocket port would be 5700.
      As an alternative the Websocket port could be manually specified by
      using ",websocket=<port>" instead.
      
      Parts of the implementation base on Anthony Liguori's QEMU Websocket
      patch from 2010 and on Joel Martin's LibVNC Websocket implementation.
      
      Signed-off-by: default avatarTim Hardeck <thardeck@suse.de>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      7536ee4b
Loading