« back to all changes in this revision
Viewing changes to docs/remote-desktop.txt
- browse files at revision 1
- compare with another revision
- download diff
- download tarball
- view history from revision 1
- Committer: Bazaar Package Importer
- Author(s): Sebastien Bacher
- Date: 2004-10-12 19:36:40 UTC
- Revision ID: james.westby@ubuntu.com-20041012193640-ybetkwuqt7e04dke
Tags: upstream-2.8.1
Import upstream version 2.8.1
- files added:
- capplet
- docs
- icons
- po
- server
- server/libvncserver
- server/libvncserver/rfb
- session
added
removed
docs/remote-desktop.txt
1
Remote Desktop Project
2
======================
3
(Work In Progress)
4
5
Mark McLoughlin (mark@skynet.ie)
6
December 1st, 2003
7
8
1. Problem Description
9
======================
10
11
In enterprise installations system administrators typically
12
have to deal with a large number of pretty basic problems on users'
13
machines. Remotely taking control of a user's desktop to fix the
14
problem while at the same time training the user as to how to resolve
15
the problem for themselves is an effective and simple way to handle
16
these types of support scenarios.
17
18
Currently there is no way to do this with GNOME.
19
20
2. Overview
21
===========
22
23
The basic requirement for such a tool is some method of
24
sharing a desktop session between multiple users. The sysadmin sees
25
what the user sees and the user sees what the sysadmin sees.
26
27
However, the technology behind this is obviously useful in
28
other ways. Here in Sun, for example, we make widespread use of VNC
29
for some basic collaboration. Targetting this project purely at the
30
Remote Assistance use case will leave some users wondering "why
31
... why on earth did you make it impossible for us to use this like
32
VNC?".
33
34
This project, therefore, also encompasses the use case of
35
a simple form of collaboration by sharing access to a desktop
36
session.
37
38
There are various existing technologies in this area which all
39
work in very similar ways. This project will follow those same basic
40
architectural principals.
41
42
The core part of such a system is a protocol by which
43
information about what is happening on the screen of the "host"
44
machine (in this case, the user's machine) is sent to the "client"
45
machine (the sysadmin's machine). The client also needs to be able to
46
relay back key presses and pointer manipulation information to the
47
host.
48
49
There are several existing such protocols available - the RFB
50
(Remote FrameBuffer) protocol used by VNC, RDP (Remote Desktop
51
Protocol) used by Window's Remote Desktop and the Sun Ray protocol.
52
53
On the host machine a mechanism is needed by which all drawing
54
primitives are proxied via the protocol to the client machine as well
55
as a mechanism by which key/pointer events from the client are passed
56
to the windowing system. Also needed is an authentication mechanism by
57
which access to the host system can be restricted.
58
59
On the client machine an application which allows the user to
60
connect to the host machine, authenticate, display the contents of the
61
host display and forward input events to the host is required.
62
63
3. Task List, by Commonality and Frequency
64
==========================================
65
66
Below, each of the user tasks the project aims to facilitate
67
is listed, grouped by the proportion of users who will perform the
68
task and how often it will be performed. In the absence of personas to
69
encapsulate our target user base, the groupings are judgement based.
70
71
Each task also has (C), (I) or (NTH) depicting whether support
72
for that task is core, important or nice to have functionality.
73
74
75
First lets take a look at the "Remote Assistance" use case on
76
the host side and then on the client side.
77
78
=> Host
79
80
* Frequent by Many:
81
82
1. Verify/approve a connection before it can be
83
established. (C)
84
85
* Frequent by Few:
86
87
1. Request assistance from a colleague or system
88
administrator. (I)
89
90
=> Client
91
92
* Frequent by Many:
93
94
1. View a desktop remotely. (C)
95
2. Interact with a remote desktop. (C)
96
3. Browse the network for a machine to connect to. (I)
97
4. Make the remote desktop occupy the entire local screen
98
i.e. a fullscreen option. (NTH)
99
100
* Occasional by Many:
101
102
1. Open a connection to a user's desktop given only the
103
hostname of the user's machine (C)
104
2. Open a connection to a user's desktop without having the
105
user be aware of your connection. (I)
106
3. Receive a remote assitance request and open a connection to
107
that user's desktop. (I)
108
109
110
Now, lets take a look at the additional tasks with a simple
111
VNC-like collaboration tool.
112
113
=> Host
114
115
* Frequent by Many:
116
117
1. Inform others how to connect to your desktop. (I)
118
119
* Frequent by Few:
120
121
1. View the number of and the details of established
122
connections. (I)
123
2. Close established connections. (I)
124
3. Toggle established connections between interactive and
125
non-interactive. (NTH)
126
127
* Occasional by Many:
128
129
1. Allow/dis-allow remote connections to the desktop. (C)
130
2. Allow/dis-allow interactive connections. (C)
131
2. Restrict remote access to your desktop in some way
132
(e.g. set a password, specify specific users ...) (C)
133
134
=> Client
135
136
* Frequent by Many:
137
138
1. Open a connection to a remote desktop given some details
139
from the host user (C)
140
141
4. Functional Requirements
142
==========================
143
144
=> Host
145
146
1. Ability to approve or reject a request to remotely connect to
147
the desktop. (C)
148
149
2. Ability to request assistance from a pre-defined source. (I)
150
3. Ability to request assistance from a colleague. (I)
151
152
4. Ability to allow/dis-allow remote connections to the desktop. (C)
153
5. Ability to allow/dis-allow interactive connections. (C)
154
6. Ability to restrict access to the desktop in some way
155
(e.g. assign a password) (C)
156
157
7. Ability to give, to another user, enough details for that user
158
to connect to your desktop. (I)
159
160
8. A list of currently open connections, including details of
161
the other endpoint of the connection and whether or not the
162
connection is interactive. (I)
163
9. Ability to close a connection. (I)
164
10. Ability to toggle a connection between interactive and
165
non-interactive. (I)
166
167
=> Client
168
169
1. Ability to view a desktop remotely. (C)
170
2. Ability to interact with a desktop remotely. (C)
171
172
3. Ability (for a user with sufficient priviledges) to connect to
173
a given user's desktop on a given host. (C)
174
4. Ability to browse the network for hosts which you can then connect
175
to. (I)
176
5. Ability (for a system administrator) to connect to a given user's
177
desktop without the user being aware of the connection. (I)
178
179
6. Ability to view the remote desktop in fullscreen mode. (NTH)
180
181
7. Ability to connect to a desktop given a remote assitance
182
request. (I)
183
8. Ability to connect to a desktop given some details from the
184
host user. (I)
185
186
5. Notes/Design Constraints/Caveats
187
===================================
188
189
* I don't think the "Request Assistance" task is a very important
190
one. In most cases where a user has support personnel available I
191
think picking up the phone will be a much more common way of
192
requesting assistance rather than clicking a button and twidling
193
your thumbs waiting for someone to respond.
194
195
6. Review of Existing Technologies
196
==================================
197
198
6.1. Existing Products - VNC/RFB
199
================================
200
201
RFB[1] (Remote FrameBuffer) is the protocol used by VNC. The
202
emphasis in the design of the protocol was to make very few
203
requirements of the client. The client has no need to maintain
204
explicit state and clients are able to disconnect and re-connect to
205
the server while preserving the state of the user interface.
206
207
The dislay part of the protocol is based around a single
208
simple graphics primitive "put a rectangle of pixel data at a given
209
position". Each rectangle may be encoded in any one of a number of
210
encodings allowing for compression or usage of parts of the client's
211
existing copy of the framebuffer. Updates are requested by the client
212
rather than pushed out by the server allowing the protcol to adapt to
213
slower networks and/or clients - i.e. with a slow network or client
214
the rate of updates are greatly reduced and the client ignores the
215
transient state of the framebuffer.
216
217
The protocol is quite extensible. Extra encodings can be
218
advertised by the server and used if the client supports the
219
encoding. Use of encodings are not only limited to how frame buffer
220
updates are encoded on the wire, but also extra psuedo-encodings may
221
be added which can do anything from inform the client of a change in
222
cursor shape, a change in the size of the screen or even things like
223
extra in-band communication between the server and client.
224
225
There seems to be many different implementations of VNC
226
available. Available RFB server implementations include:
227
228
* libvncserver[2]: a "library" for implementing VNC
229
servers. It basically just seems to be a hacked up version of an
230
existing VNC server in an archive with some header files. Not a very
231
nice API, but quite a few projects are using it successfully.
232
233
* xf4vnc[3]: a controlled fork of XFree86 which allows you to
234
run an Xserver which doubles as a VNC server or export your local
235
framebuffer through a loadable module.
236
237
* realVNC[4]: seems to be a continuation of the original VNC
238
project which has an Xserver which doubles as a VNC server. Thus,
239
there is no method by which you can remote the local framebuffer.
240
241
* x0rfbserver: an X11 client which acts as an RFB server and
242
exports the local display by polling the display for updates using X
243
and pushing the updates out to clients using RFB.
244
245
* krfb[5]: a pretty nice looking VNC server for KDE which is
246
based on the same concept (and indeed uses some of the code of)
247
x0rfbserver. It also uses libvncserver.
248
249
I won't list the VNC client's available, there seem to be
250
many, but suffice to say there are X11, Windows and OS X clients
251
available along with, interestingly, several implementations of a Java
252
client which can be run embedded in the browser as an applet.
253
254
Tim Waugh has written a nice article[6] on VNC and the many
255
projects around the technology.
256
257
In summary, the RFB protocol has a number of advantages:
258
259
1) Simple and open protocol.
260
2) Rate-limited by the client, pretty low bandwidth/latency
261
requirements.
262
3) Extensible.
263
4) Several open source implementations available.
264
5) Many existing clients available for different platforms.
265
266
6.2. Existing Protocols - Remote Desktop/RDP
267
============================================
268
269
"Remote Desktop"[7,8,9] is Microsoft's technology in this
270
area. The RDP protocol itself is essentially an extension of the
271
ITU-T T.128 (aka T.SHARE) application sharing protocol[10].
272
273
The protocol is a good deal more complex than the RFB protocol
274
and the protocol supports a very much larger set of functionality than
275
the RFB protocol e.g.
276
277
* Printer re-direction - you can print something on the host
278
machine to a printer local to the remote desktop client.
279
280
* Sound re-direction - sounds from the host can be heard at
281
the client.
282
283
* Multi-point sharing - the remote desktop session does not
284
neccessarily consist of only windows/applications on a single
285
host. Multiple hosts can share applications to the session.
286
287
None of these features are needed here given the functional
288
requirements above.
289
290
Also, the protocol has been further extended by Microsoft to
291
such an extent that it hardly be considered an "open" protocol.
292
293
Another problem with Window's Remote Desktop compared to VNC
294
is the limited client availability. On Linux, the rdesktop[11] project
295
provides a Remote Desktop client (tsclient[12] is a GNOME-like frontend
296
for it) but on Windows, the only client I know of is the Window's
297
Remote Desktop client.
298
299
6.3. Existing Protocols - Sun Ray
300
=================================
301
302
There's not a lot of information out there on SLIM, the
303
protocol behind Sun Ray. About the only details available are from a
304
paper[13] investigating the performace of the protocol.
305
306
SLIM, like RDP, is designed to immediately push all frame
307
buffer updates to the client. Therefore, on low bandwidth connections
308
the updates would just pile up. One would assume this is the reason
309
Sun Ray requires a dedicated network.
310
311
Also, Sun Ray has no client implementation available apart
312
from the Sun Ray Enterprise Appliance itself.
313
314
7. System Design
315
================
316
317
7.1. Overview
318
=============
319
320
The host side is to be implemented as a VNC server using the
321
libvncserver library. The VNC server will act as an X client and poll
322
the local X display for the contents of the framebuffer and notify the
323
VNC clients if there have been any changes. Input events coming from
324
the clients will be injected into the X display using the XTEST[14,15]
325
extension.
326
327
The VNC client we will most likely be a modified version of
328
an existing Java client. The advantage of having a Java client is that
329
it may be used to connect to the host from any platform.
330
331
7.2. Monitoring The Local Display
332
=================================
333
334
To implement a VNC server you need to know the contents of the
335
local framebuffer in order to pass this information onto the VNC
336
clients.
337
338
Currently, as an X client, there is only one way to do this
339
and that is by doing a GetImage on the root window which basically
340
copies the entire framebuffer from the X server to the X client. The
341
main problem with this approach is that without knowing what parts of
342
the framebuffer has actually changed since the last time you updated,
343
you are wasting an enormous amount of resources copying the entire
344
framebuffer each time.
345
346
There are a number of possiblities to lessen the inefficiency
347
here. The first is to limit the amount of polling you do per update of
348
the framebuffer. For example, every update you could just check a
349
certain number of scanlines against your local copy of the frame
350
buffer and if parts of the scanline differ, then do a GetImage on a
351
number of tiles which capture those changes to the scanline. This is
352
the approach taken by krfb and x0rfbserver.
353
354
Another possibility is an X extension to notify the X client
355
of changes to the framebuffer, thereby negating the need for
356
continually polling the X server. When the client receives the
357
notification it can do a GetImage to update its copy of the
358
framebuffer with the latest changes. Keith Packard is currently
359
working on an extension to do exactly this called XDAMAGE[16].
360
361
Initially we will use the x0rfbserver approach of polling the
362
screen, but will later implement support for the XDAMAGE extension
363
when it becomes available.
364
365
7.3. Input Event Handling
366
=========================
367
368
The VNC server will need to handle two types of input events
369
coming from VNC clients - keyboard and pointer events. These events
370
will be injected into the Xserver using the XTEST extension.
371
372
To inject a keyboard event into the X server you invoke
373
XTestFakeKeyEvent with the appropriate keycode. The X server then maps
374
this keycode, according to the current modifier state, to a keysym. We
375
need to make sure that they keycode we pass to the X server maps to
376
the same keysym as the keysym we received from the VNC client. We can
377
reverse map a keysym to a keycode, but we also need to make sure the
378
modifier state is such that the keycode will map back to that
379
keycode. Both krfb and x11vnc use the same code for ensuring this and
380
we can just copy that.
381
382
You can inject into the X server button presses/releases using
383
XTestFakeButtonEvent() and pointer movement using
384
XTestFakeMotionEvent(). The PointerEvent you receive from the client
385
contains information on the state of each button and the current
386
pointer location. The only slightly difficult part here is translating
387
the button state information to button presses/releases, but it merely
388
involves keeping track of the previous button state.
389
390
7.4. Cursor Handling
391
====================
392
393
The basic problem here is how to allow the VNC client to see
394
the cursor. There are several possible approaches:
395
396
1. Draw the cursor directly to the VNC server's copy of the
397
framebuffer and send framebuffer updates as the cursor is moved
398
around. The client will see the cursor being moved in all cases.
399
400
2. Provide the cursor image to the client using the RichCursor or
401
XCursor psuedo encoding and let the client draw the cursor
402
locally. The client only sees cursor movement when that client is
403
the one moving the cursor.
404
405
3. Again provide the cursor image to the client, but also send the
406
client updates on the pointer position using the PointerPos
407
pseudo-encoding which the client can use to update the position
408
of its locally drawn cursor. Again, the client will see the
409
cursor movement no matter who is moving it.
410
411
Approach (2) isn't very useful - the client needs to be able to
412
see cursor movement on the host. For that reason, we will not
413
advertise the cursor image to the client unless it supports *both*
414
cursor position and cursor shape updates. If the client only supports
415
one or the other, we ignore the support for that encoding and always
416
draw the cursor to the framebuffer.
417
418
One problem here is that, in the screen polling case, because
419
we will be comparing the local copy of the framebuffer (which may,
420
with approach (1) above, have the cursor drawn in it) to the actual
421
framebuffer (which will not contain the cursor image) we will need to
422
undraw the cursor before doing any comparison. Instead of complicating
423
the screen polling code with this detail we will draw the cursor image
424
to the framebuffer just before sending a frame buffer update to the
425
client and then immediately undraw it.
426
427
Of course, with either approach (1) or (2) we need some
428
mechanism by which we can determine the current cursor position and
429
shape. The only way to determine the current cursor position is by
430
regularily polling using XQueryPointer(). Determining the current
431
cursor shape is not possible but such support is to be added to the
432
XFIXES extension. [FIXME: more details on this].
433
434
7.5. libvncserver Work
435
======================
436
437
libvncserver contains lots of code from different VNC server
438
implementations. The intent is to bring all that code together under
439
one API which makes it easy to write VNC servers. However, rather than
440
being a library, it seems more like a full VNC server implementation
441
around which you can wrap a main function.
442
443
There are a number of problems with the library which can be
444
fixed in a fairly straightforward manner, by extending the API
445
slightly and cleaning bits up.
446
447
Other concerns around the library containing way more
448
implementation that we would like/need, many private functions exposed
449
in the API, structures that will likely need to be expanded being
450
exposed in the API and a general feeling that the library cannot
451
hope to maintain ABI compatibility are much harder to address. We have
452
the option of just statically linking to the library, and so, the
453
project will not be held up by these problems, but we should continue
454
to consider coming up with a plan to fix these problems.
455
456
Initially, the project will contain a copy of libvncserver
457
with the following changes:
458
459
+ API to allow glib mainloop integration.
460
+ Support for version 3.7 of the RFB protocol - this adds security
461
type negotiation.
462
+ A hook so that we can allow the user to decide whether or not an
463
authenticated client should be allowed to connect.
464
+ Re-worked cursor handling so that the cursor remains drawn to the
465
server's copy of the framebuffer only for the duration of
466
rfbSendFrameBufferUpdate().
467
+ API to set the current cursor postion.
468
+ Only send cursor shape updates when the client also has support
469
for cursor position updates and vice versa.
470
+ Removed default implementations of hooks and make that the default
471
action when the hook isn't implemented.
472
+ TRUE == 1 instead of -1 to match glib.
473
+ Warnings fixes.
474
+ LIBVNCSERVER prefix removed from the #ifdefs so that we can use a
475
normal config.h. libvncserver really shouldn't have platform
476
dependant defines in its header anyway.
477
+ Threading support disabled but not removed.
478
+ Lots of code which we don't need removed:
479
- UDP support
480
- Vestiges of CORBA support
481
- Back channel support
482
- setTranslateFunction(), getCursorPtr and displayHook hooks
483
- HTTP server implementation
484
- Support for drawing GUIs to the framebuffer on the server
485
side.
486
- Command line argument processing.
487
488
7.6. Service Discovery
489
======================
490
491
In order to implement the ability to browse the network for
492
available remote desktop servers there must be some way to enumerate
493
the available servers. One possible mechanism for doing this is DNS
494
Based Service Discovery[17], a draft of which is currently on the IETF
495
standards track.
496
497
DNS-SD is a convention for naming and structuring DNS resource
498
records such that a client can query the DNS for a list of named
499
instances of a particular service. The client can then resolve one of
500
these named instances to an address and port number via a SRV[18]
501
record.
502
503
In the remote desktop case, a client could query the DNS for
504
PTR records of _rfb._tcp.<domain> and would be returned a list of
505
named instances of RFB servers, using TCP, on the domain. For example:
506
507
PTR:_rfb._tcp.ireland.sun.com -> SRV:Mark's Desktop._rfb._tcp.ireland.sun.com
508
SRV:Gman's Desktop._rfb._tcp.ireland.sun.com
509
510
(Note the way the Service Instance Name is a user-friendly
511
name containing arbitrary UTF-8 encoded text. It is not a host name.)
512
513
The client would then display the list of available remote
514
desktop servers - i.e. "Mark's Desktop" and "Gman's Desktop" - and
515
allow the user to choose one. If the user chooses "Mark's Desktop" the
516
client can then resolve that SRV record associated with the remote
517
desktop instance.
518
519
SRV:Mark's Desktop._rfb._tcp.ireland.sun.com -> markmc-box.ireland.sun.com:5900
520
521
The client can then resolve the "markmc-box.ireland.sun.com"
522
hostname and using the resulting ip address connect to the remote
523
desktop server on port 5900.
524
525
526
While DNS-SD seems like a perfect mechanism by which remote
527
desktop instances may be queried for, there remains the problem of how
528
the DNS is populated with the details of these services to begin with.
529
530
A related draft proposal on the IETF standards track is
531
Multicast DNS[19]. The idea behind Multicast DNS is to allow a group
532
of hosts on a local link, in the absence of a convetionally managed
533
DNS server, to co-operatively manage a collection of DNS records and
534
allow clients on that same local link query those records.
535
536
The scheme works by each client connecting to the mDNS
537
multicast IPv4 address and sending/receiving DNS-like queries/answers
538
to port 5353. Between them, the clients manage the top-level ".local."
539
domain and negotiate any conflicts that arise. So, for example, the
540
host referenced by "markmc-box.ireland.sun.com" in the above example
541
could also be resolved using the host name "markmc-box.local" by other
542
Multicast DNS clients on the same link.
543
544
In order to be queriable by Multicast DNS, our remote desktop
545
server could act as a Multicast DNS Responder and Querier and register
546
the remote desktop service there. Here's how the example above would
547
look like if we were using mDNS:
548
549
Client queries the local link for remote desktop servers ...
550
551
PTR:_rfb._tcp.local
552
553
... and receives a reply first from markmc-box ...
554
555
-> SRV:Mark's Desktop._rfb._tcp.local
556
557
... and then a reply from gman-box:
558
559
-> SRV:Gman's Desktop._rfb._tcp.local
560
561
Once the user has selected "Mark's Desktop" from the displayed
562
list, the client resolves that service and receives a reply once again
563
from markmc-box:
564
565
SRV:Mark's Desktop._rfb._tcp.ireland.sun.com -> markmc-box.local:5900
566
567
The client then resolves "markmc-box.local" to an ip address
568
(still using Multicast DNS) and connects to that address on port 5900.
569
570
Luckily, implementing this won't require writing an mDNS
571
implementation from scratch. There is an existing implementation in
572
GNOME CVS which integrates nicely with glib's main loop and there are
573
plans to centralise this in a desktop service advertisement and
574
discovery daemon.
575
576
577
Another possible mechanism for making remote desktop service
578
information available via DNS is to use Dynamic DNS Updates[20] to add
579
DNS-SD records to a conventional DNS server. However, the majority of
580
DNS server deployments restrict (for obvious security reasons) the
581
ability to update DNS records completely or to only a few known
582
hosts. Because using this mechanism would require installation sites
583
to change their DNS administration policies, this is obviously not an
584
attractive option.
585
586
7.7. Security Considerations
587
============================
588
589
7.7.1. VNC Authentication
590
=========================
591
592
VNC uses a simple DES based challenge-response authentication
593
scheme. In order to authenticate the client, the server sends a random
594
16 byte challenge and the client then encrypts the challenge with DES
595
using the user supplied password as a key. If the response matches the
596
expected result, the client is authenticated. Otherwise, the server
597
closes the connection. There are a number of possible vulnerabilities
598
with this mechanism.
599
600
Firstly, the password, being limited to 8 characters, could be
601
brute force guessed by an attacker who continually tries to
602
authenticate using different passwords[21]. The standard way of
603
making such attacks unfeasible is to enforce a delay between failed
604
authentication attempts - i.e. if there has been a failed
605
authentication attempt, delay sending the challenge to the next client
606
who connects for a number of seconds.
607
608
Another possible vulnerability is the predictability of the
609
random challenge sent by the server. If the server, under any
610
circumstances, sends a challenge which has previously been used in a
611
successful authentication attempt there is the possibility that an
612
attacker may use the previously observered valid response again. An
613
example[22] of such is if the server re-seeds the random number
614
generator used to produce the challenge with the current time on each
615
connection attempt. In this case, if an attacker connects to the VNC
616
server within the same one second window as a valid client, then the
617
attacker will receive the same challenge as the valid client and use
618
the response from that client to authenticate. To avoid such a
619
vulnerability the server should produce highly unpredictable
620
challenges using the cryptographically strong random number generator
621
providied with the GNU TLS library.
622
623
Challenge-response authentication schemes are inherently
624
susceptible to man-in-the-middle attacks. The basic idea is that
625
attacker uses a client to generate a valid response for a given
626
challenge. One way[23] of carrying out such an attack is if the attack
627
can intercept and modify the packets flowing between the client and
628
the server. The attacker can then replace the challenge from the
629
server with a challenge the attacker has received in a pending
630
authentication attempt. The client then returns a valid response for
631
that challenge with which the attacker can use to complete its
632
authentication.
633
634
Given that this tool is aimed mainly at system administrators
635
administering a network of many desktop machines, and given that an
636
administrator would likely set the same password for the remote
637
desktop server on each of these machines, a more worrying
638
man-in-the-middle attack is:
639
640
("C" is the administrator using a VNC client, "S" is the VNC
641
server under attack and "M" is the attacker.)
642
643
1. M starts a modified VNC server which advertises itself on
644
the local link using mDNS and DNS-SD (see the "Service
645
Discovery" above)
646
2. C connects to M's modified VNC server by selecting it from
647
the list of available VNC servers
648
3. M then connects to S and receives a challenge
649
4. M sends this challenge to C
650
5. C sends back a valid response to M
651
6. M sends a failed authentication message to C.
652
7. M uses this response to authenticate against S and is
653
granted access.
654
655
There is no way to protect VNC's challenge response
656
authentication mechanism from such an attack.
657
658
DES[24], by today's standards, is quite a weak encryption
659
mechanism. Given that in this case that both plaintext and ciphertext
660
(the challenge and response) are both available a brute force attack
661
to find the key (the password in the VNC case) is possible. Brute
662
force cracking of DES is a much discussed[25]. A large amount of
663
computing power would be required for such an attack and given that
664
this tool would only deployed on private networks, it is perhaps not
665
an immediate concern. However, in the years to come it is to be
666
expected that such attacks would beome much more common and easy to
667
perform.
668
669
7.7.2. Encryption
670
=================
671
672
RFB protocol messages are sent across the network
673
unencrypted. This is an obvious security concern because an attacker
674
may snoop the protocol packets and, using a modified VNC viewer,
675
observe a VNC session in progress. Even more worrying, is that all key
676
presses are sent in the open and may be snooped. Considering that
677
system administrators are the primary target audience and that they
678
are likely to enter the root password when running some system
679
utility, the password could be snooped and used to gain root-level
680
access to the machine.
681
682
In order to protect the VNC session from such attacks, the
683
protocol should be extended to allow the stream to be
684
encrypted. Luckily, the RFB protocol was designed to allow such
685
extensions while maintaining compatibility.
686
687
The encryption of the RFB stream will be implemented with
688
TLS/SSL[26] using the gnutls[27] library and, for the Java client, the
689
Java Secure Socket Extension (JSSE)[28].
690
691
TLS is a protocol designed to provide privacy, data integrity,
692
compression and, optionally, peer authentication using public key
693
cryptography. The protocol mainly consists of two parts - the Record
694
Protocol and the Handshake Protocol. The Record Protocol is
695
responsible for fragmenting, compressing, hashing and encrypting the
696
data to be transmitted. The Handshake Protocol involves the peers
697
agreeing on a protocol version, cipher suite and compression method,
698
generating a shared secret and, optionally, exchanging certificates to
699
allow the peers to authenticate one another (either or both peers may
700
be authenticated).
701
702
New security types will be added (see below) which will cause
703
the client and server to begin the TLS handshaking protocol
704
immediately after one of those security types has been agreed upon. If
705
VNC authentication is required, that challenge-response exchange will
706
happen immediately after the TLS handshake has completed.
707
708
The peer authentication which may take place as part of the
709
TLS handshake involves the peers exchanging certificates (currently
710
only X.509[29] certificates are supported by the protocol but support
711
for OpenPGP[30] certificates has been proposed[31]) and verifying
712
their identity. In order to support server certificate authentication
713
the VNC client will need have some sort of certificate store which
714
contains the server certificates the client trusts - this is useful
715
because it prevents a man-in-the middle attack. To support client
716
certificate authentication, the VNC server will also require a
717
certificate store listing the clients who are authorised to connect -
718
this is useful because the password is no longer a weak point, but
719
also that it would be generally more convenient for a system
720
administrator to distribute his certicate to each of the desktop
721
systems he administers and never have to type in a password.
722
723
If certificate based peer authentication is not used the
724
client and server agree on a secret using anonymous Diffie-Hellman key
725
exchange.
726
727
TLS supports compression of the communication stream. Some
728
investigation should be carried out to see if using this compression
729
mechanism is with uncompressed RFB tiles results in better bandwidth
730
usage than no TLS compression and compressed RFB tiles.
731
732
7.7.3. New RFB Security Types
733
=============================
734
735
The negotiated security-type in the RFB protocol is an 8 bit
736
unsigned integer. Currently there are only two possible values:
737
"None"(1) to indicate no authentication is needed and "VNC
738
authentication"(2) to indicate that the client is to be authenticated
739
using the challenge-response scheme detailed above. 0 indicates and
740
error condition.
741
742
We will add a further four security types:
743
744
+ Anonymous TLS (3)
745
+ TLS With VNC Authentication (4)
746
+ TLS With Server Certificate and VNC Authentication (5)
747
+ TLS With Server and Client Certificate Authentication (6)
748
749
In order to ensure interoperability with other
750
implementations, these security types must be registered with RealVNC
751
who maintain the RFB protocol specification.
752
753
7.7.4. Security Related Preferences
754
===================================
755
756
A number of preferences will be provided which will have a
757
direct impact of the security of the system. Their meaning and
758
rationale for their existance is detailed below:
759
760
/desktop/gnome/remote_access/enabled (boolean, default=false)
761
762
If false, the Remote Desktop server will not be started at
763
login time and if running will not allow any new remote
764
connections, put all existing clients on hold and exit after a 30
765
second timeout.
766
767
The rationale for the preference is that unless Remote Desktop
768
access is to actually be used, it is much more preferable to not
769
have the server running for both resource consumption and security
770
reasons.
771
772
The default for the preference is false under the assumption
773
that Remote Desktop access will not be used by the majority of the
774
user base.
775
776
777
/desktop/gnome/remote_access/prompt_enabled (boolean, default=true)
778
779
If true, once a client has connected and been authenticated the
780
user is prompted on whether the client connection should be
781
allowed to be completed.
782
783
The rationale here is that in the majority of scenarios, the
784
user on the host machine should be in control of whether or not
785
remote users are allowed to connect to their desktop. Even if the
786
host user has enabled remote access, set a password and informed
787
some other user of that password, the host user may still want to
788
both be aware of another user connecting and also decide whether
789
that particular time is suitable for the remote user to connect.
790
791
The default is true for two reasons. Firstly, it is assumed that
792
most users will want to vet new connections and, secondly, because
793
by default there is no authentication required to connect this
794
prompt will provide some level of manual authentication.
795
796
797
/desktop/gnome/remote_access/view_only (boolean, default=false)
798
799
If true, remote users will only be allowed to view the remote
800
desktop and all keyboard, pointer and clipboard events from the
801
remote user will be ignored.
802
803
The view only preference is intended to support the simple
804
collaboration scenario where a number of remote users will connect
805
to a single host to observe something happening on the host
806
machine. In this scenario the host will no want any of the remote
807
users to use the pointer or keyboard on the host.
808
809
The default is false because this is not the primary scenario we
810
are expecting to target.
811
812
813
/desktop/gnome/remote_access/require_encryption (bool, default=true)
814
815
If true, the host requires that all connecting client use TLS
816
encryption. Any clients attempting to use the "None" and "VNC
817
Authentication" security types will be refused. This will only have
818
affect the cases where the VNC viewer being used by remote user
819
does not have support for TLS encryption. If the viewer does have
820
support, it will always be used.
821
822
The preferences is provided so that the host may make the policy
823
decision on whether unencrypted connections should be allowed.
824
825
However, in most cases it is expected that the host will require
826
that only encrypted connections be allowed so as to not allow any
827
information on the host to be compromised. For this reason, the
828
default value for the preference is true.
829
830
831
/desktop/gnome/remote_access/authentication_methods (list, default=[none])
832
833
The list of authentication which the server will
834
advertise. Currently the supported values are "none" and "vnc",
835
but when certificate based authentication is implemented
836
"server-cert-with-vnc" and "server-cert-with-client-cert" will
837
also be supported.
838
839
The preference is provided so as to allow the host user decide
840
on how remote users should be authenticated. The host may decide
841
that no authentication is required, that password or certificate
842
based authentication should be used.
843
844
The default value is "none" because there is no point in having
845
the default value be "vnc" because no password would be set.
846
847
848
/desktop/gnome/remote_access/vnc_password (base64 encoded string, default=<unset>)
849
850
The password used to authenticate the remote user when VNC
851
authentication is being used. The password is stored in GConf
852
base64 encoded to provide an extra level of secrecy. However, the
853
secrecy of the password is guaranteed by the fact that the files
854
which GConf stores preference values in are only readable by the
855
user in question.
856
857
858
7.7.5. Summary of Security Considerations
859
=========================================
860
861
(
862
How to put this ? There must be some standard methodology to lay
863
out the specific types of attacks you are and are not protecting
864
against with different configurations e.g. given the following
865
configuration:
866
867
+ allowed = true
868
+ require_encryption = true
869
+ authentication_methods = [vnc]
870
+ vnc_password = strong-password
871
872
and based on the following assumptions about potential attackers:
873
874
+ Has the ability to snoop the intervening network stream.
875
- Does not have the ability to modify the intervening network
876
stream.
877
- Does not have the ability to brute force crack the DES key
878
given the challenge and response.
879
- Does not have the ability to spoof an IP address.
880
+ Does not have access to the host machine as either root or the
881
user who is running the server.
882
+ Does not have any prior knowledge of what the password may be.
883
+ Does not have access to the user's X display.
884
+ Does not have access to the user's GConf daemon.
885
886
then no attacker should be able to:
887
888
+ Snoop the host's screen contents from the VNC session.
889
+ Snoop keyboard/pointer/clipboard events from the client.
890
+ Obtain access to the VNC session.
891
+ Obtain shell access to the host machine as root or the user
892
who is running the server.
893
894
But you are also making assumptions about the behaviour of the
895
user on both sides - e.g. that the remote user has the correct IP
896
address and port number for the host she wishes to connect to, and
897
not the IP address and port number of an attacker.
898
)
899
900
What problems remain ?
901
902
+ No peer authentication - possibility of man-in-the-middle attacks.
903
904
905
8. Host User Interface
906
======================
907
908
8.1. Preferences Dialog
909
=======================
910
911
Menu Entry:
912
Name = Remote Desktop
913
Comment = Set your remote desktop access preferences
914
Categories = GNOME;Application;Settings;
915
916
+-+-------------------------------------------------------+-+-+
917
|#| Remote Desktop Preferences |_|X|
918
+-+-------------------------------------------------------+-+-+
919
| |
920
| ! Some of these preferences are locked down |
921
| |
922
| Sharing |
923
| ------- |
924
| [ ] Allow other users to view my desktop on their computer |
925
| [ ] Also allow other users to control my desktop |
926
| |
927
| Security |
928
| -------- |
929
| When a user tries to view or control my desktop: |
930
| [ ] Ask me for confirmation |
931
| [ ] Ensure they are using encryption |
932
| [ ] Require them to enter this password: |
933
| Password: ________ |
934
| |
935
+-------------------------------------------------------------+
936
| <Help> <Close> |
937
+-------------------------------------------------------------+
938
939
Notes:
940
o The "locked down" warning is only displayed if one of the GConf
941
keys associated with the preferences isn't writable. Each such
942
non-writable key also causes the appropriate control to be made
943
insensitive.
944
o When "Enable remote desktop access" is inactive, the rest of the
945
controls are insensitive.
946
o When "Require password for remote access" is inactive, the
947
"Password" entry is insensitive.
948
949
8.2. Connection Query Dialog
950
============================
951
952
This dialog appears when the "Prompt me before allowing
953
access" preference is set and a remote user connects to the server and
954
is authenticated.
955
956
+-+----------------------------------------------------------+-+-+
957
|#| Question |_|X|
958
+-+----------------------------------------------------------+-+-+
959
| |
960
| ??? An attempt is being made to access your deskop remotely |
961
| ??? from '<hostname>' |
962
| ??? |
963
| Allow this connection to be completed? |
964
| |
965
+----------------------------------------------------------------+
966
| <Refuse> <Allow> |
967
+----------------------------------------------------------------+
968
969
8.3. Notification Area Icon
970
===========================
971
972
Icon which will appear in the notification area when there are
973
any remote users connected. Clicking on the icon will show the
974
connections details dialog.
975
976
8.4. Connection Details Dialog
977
==============================
978
979
Dialog will show the list of remote desktop users, the host
980
they are connected from and how long they have been connected. You
981
will be able to disconnect a given user using the dialog.
982
983
9. Client User Interface
984
========================
985
986
+ Initially a patched version of RealVNC's Java vncviewer.
987
+ Later possibly a integrated into a lockhart type GUI.
988
989
10. See Also
990
============
991
992
[1] - The RFB Protocol Specification
993
http://www.uk.research.att.com/vnc/rfbproto.pdf
994
995
[2] - libvncserver:
996
http://libvncserver.sourceforge.net/
997
998
[3] - xf4vnc:
999
http://xf4vnc.sourceforge.net/
1000
1001
[4] - realVNC:
1002
http://www.realvnc.com/
1003
1004
[5] - krfb:
1005
http://www.tjansen.de/krfb/
1006
1007
[6] - VNC: Where it came from, where it's going:
1008
http://cyberelk.net/tim/articles/VNC/
1009
1010
[7] - Using Remote Desktop:
1011
https://www.microsoft.com/windowsxp/pro/using/howto/gomobile/remotedesktop/default.asp
1012
1013
[8] - Using Remote Assitance:
1014
https://www.microsoft.com/windowsxp/pro/using/howto/gethelp/remoteassist/default.asp
1015
1016
[9] - FAQ on Remote Desktop:
1017
https://www.microsoft.com/windowsxp/remotedesktop/faq.asp
1018
1019
[10] - ITU-T T.128 Application Sharing Protocol:
1020
http://www.rdesktop.org/docs/t128.zip
1021
1022
[11] - rdesktop: A Remote Desktop Protocol Client:
1023
http://www.rdesktop.org/
1024
1025
[12] - tsclient: A Frontend for rdesktop:
1026
http://www.gnomepro.com/tsclient/
1027
1028
[13] - The Interactive Performace of SLIM: A Stateless, Thin-Client
1029
Architecture:
1030
http://research.sun.com/research/features/tenyears/volcd/papers/nrthcutt.htm
1031
1032
[14] - XTEST Extension Protocol:
1033
http://www.x.org/pub/R6.6/xc/doc/hardcopy/Xext/xtest.PS.gz
1034
1035
[15] - XTEST Extension Library:
1036
http://www.x.org/pub/R6.6/xc/doc/hardcopy/Xext/xtestlib.PS.gz
1037
1038
[16] - XDAMAGE Extension Wiki
1039
http://xlibs.freedesktop.org/Software/DamageExt
1040
1041
[17] - DNS-Based Service Discovery:
1042
http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt
1043
1044
[18] - A DNS RR for specifying the location of services (DNS SRV):
1045
http://www.ietf.org/rfc/rfc2782.txt
1046
1047
[19] - Performing DNS Queries via IP Multicast:
1048
http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
1049
1050
[20] - Dynamic Updates in the Domain Name System (DNS UPDATE):
1051
http://www.ietf.org/rfc/rfc2136.txt
1052
1053
[21] - Example of a brute force VNC passwords cracking tool:
1054
http://www.securiteam.com/tools/Brute_forcing_VNC_passwords.html
1055
1056
[22] - Example of VNC challenge predictability vulnerability:
1057
http://www.securityfocus.com/archive/1/284064/2003-09-02/2003-09-08/2
1058
1059
[23] - Details of how a man-in-the-middle attack on VNC might be
1060
performed:
1061
http://www1.corest.com/common/showdoc.php?idx=117&idxseccion=10
1062
1063
[24] - A nice overview of DES encryption:
1064
http://www.tropsoft.com/strongenc/des.htm
1065
1066
[25] - Cracking DES: Secrets of Encryption Research, Wiretap Politics
1067
& Chip Design
1068
http://cryptome.org/cracking-des.htm
1069
1070
[26] - Transport Layer Security (TLS) - IETF standardisation of SSL
1071
http://www.ietf.org/html.charters/tls-charter.html
1072
1073
[27] - The GNU Transport Layer Security Library (gnutls)
1074
http://www.gnu.org/software/gnutls/
1075
1076
[28] - Java Secure Sockets Extension
1077
http://java.sun.com/products/jsse/index-14.html
1078
1079
[29] - Public-Key Infrastructure (X.509) (pkix)
1080
http://www.ietf.org/html.charters/pkix-charter.html
1081
1082
[30] - OpenPGP Message Format (rfc2440)
1083
http://www.ietf.org/rfc/rfc2440.txt
1084
1085
[31] - Using OpenPGP keys for TLS authentication
1086
http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-03.txt
Loggerhead is a web-based interface for Breezy
Version: 2.0.1