If I set the types as you describe below, it doesn't work how I would
expect. The client will always use VncAuth if the server supports it,
regardless of the preferred order on the server. That's not what I
want. I want the client to take the first security type from the server
as its default.
Leaving the security types as-is on the client (with X509Plain first and
VncAuth second to last) doesn't do what I expect either. In this case,
the client will always try to use an encrypted type, even if the server
prefers VncAuth over TLS.
In other words, it seems like the client's security type order is being
honored, not the server's. IMHO, the security types on the client
should mean "this is what I support", whereas the server security types
should determine the actual preference order.
On 2/17/11 3:17 AM, Adam Tkac wrote:
> On Thu, Feb 17, 2011 at 02:48:54AM -0600, DRC wrote:
>> Since Martin has confirmed that the GnuTLS slow-down is not
>> system-specific, I propose to move forward with changing the default
>> server security types such that VncAuth is first and VeNCrypt is implicit.
>
> Ok, ack.
>
> I propose this list for server built with GNUTLS:
>
> VeNCrypt,VncAuth,TLSVnc
>
> and this list for GNUTLS-capable client:
>
> VeNCrypt,VncAuth,X509Plain,TLSPlain,X509Vnc,TLSVnc,X509None,TLSNone,None
>
> Is it acceptable for you? I'm not sure if we should enable "Plain"
> sectype (i.e. user + plain password without encryption) because it is
> quite insecure.
>
> Regards, Adam
Index: common/rfb/Security.cxx
===================================================================
--- common/rfb/Security.cxx (revision 4292)
+++ common/rfb/Security.cxx (working copy)
@@ -67,6 +67,7 @@
list<rdr::U8> result;
list<U32>::iterator i;
+ result.push_back(secTypeVeNCrypt);
for (i = enabledSecTypes.begin(); i != enabledSecTypes.end(); i++)
if (*i < 0x100)
result.push_back(*i);
@@ -104,6 +105,8 @@
for (i = enabledSecTypes.begin(); i != enabledSecTypes.end(); i++)
if (*i == secType)
return true;
+ if (secType == secTypeVeNCrypt)
+ return true;
return false;
}
Index: common/rfb/SecurityClient.cxx
===================================================================
--- common/rfb/SecurityClient.cxx (revision 4292)
+++ common/rfb/SecurityClient.cxx (working copy)
@@ -45,7 +45,7 @@
("SecurityTypes",
"Specify which security scheme to use (None, VncAuth)",
#ifdef HAVE_GNUTLS
- "VeNCrypt,X509Plain,TLSPlain,X509Vnc,TLSVnc,X509None,TLSNone,VncAuth,None",
+ "VncAuth,X509Plain,TLSPlain,X509Vnc,TLSVnc,X509None,TLSNone,None",
#else
"VncAuth,None",
#endif
Index: common/rfb/SecurityServer.cxx
===================================================================
--- common/rfb/SecurityServer.cxx (revision 4292)
+++ common/rfb/SecurityServer.cxx (working copy)
@@ -39,7 +39,7 @@
("SecurityTypes",
"Specify which security scheme to use (None, VncAuth)",
#ifdef HAVE_GNUTLS
- "VeNCrypt,TLSVnc,VncAuth",
+ "VncAuth,TLSVnc",
#else
"VncAuth",
#endif
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
