Re: [Tigervnc-devel] Security for multiple client types
On Tue, Nov 22, 2011 at 04:26:44PM -0600, DRC wrote: Android would be an easier target. I don't think it already has GnuTLS, so it would probably be necessary to build those libraries and statically link against them, but the Android Market does allow GPL'ed software, so it would be theoretically possible to extend one of the existing Android VNC clients. Most of the adroid code is a modifed java, so he should look at our java viewer. Andorid will likely include a TLS implementation, which can be used instead of the JDK supplied variants. The message parsing/ creating code should be reusable too. Regards, Martin -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Security for multiple client types
Hi, I'm still in the process of developing an integrated remote desktop system for a specialist user base, and am using TigerVNC to great effect so far. I would like to enable client connections from standard Win/Mac/Lin desktops (using the Tiger VncViewer) and ALSO client connections from mobile devices such as iOS / Android etc. The problem being, there are no free/open mobile (iOS/Android) VNC clients which implement encryption - yet. If I run the Xvnc server with SecurityType=None (which I would need to do to allow these mobile clients to connect), HOW can I make it more secure? Obviously, the password is still sent encrypted (I believe) but the RFB communication is open and in the clear (albeit using TightVNC encoding). Is this a big problem? Can I make it better somehow, perhaps by creating a dynamic firewall rule that only allows VNC client access from the IP address given during a previous HTTPS authentication? Any thoughts welcome. Thanks, Dan G -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Security for multiple client types
On Tue, Nov 22, 2011 at 05:39:54PM +, Dan Garton wrote: I'm still in the process of developing an integrated remote desktop system for a specialist user base, and am using TigerVNC to great effect so far. I would like to enable client connections from standard Win/Mac/Lin desktops (using the Tiger VncViewer) and ALSO client connections from mobile devices such as iOS / Android etc. The problem being, there are no free/open mobile (iOS/Android) VNC clients which implement encryption - yet. If I run the Xvnc server with SecurityType=None (which I would need to do to allow these mobile clients to connect), HOW can I make it more secure? Obviously, the password is still sent encrypted (I believe) but the RFB communication is open and in the clear (albeit using TightVNC encoding). Is this a big problem? Can I make it better somehow, perhaps by creating a dynamic firewall rule that only allows VNC client access from the IP address given during a previous HTTPS authentication? You will not get any security this way. Without encryption, all keyboard input is sent unencrypted. Please don't waste your time with such pseudo security solutions - you should better invest them into implementing encryption in mobile clients. Regards, Martin -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Security for multiple client types
On 11/22/11 3:07 PM, Martin Koegler wrote: On Tue, Nov 22, 2011 at 05:39:54PM +, Dan Garton wrote: I'm still in the process of developing an integrated remote desktop system for a specialist user base, and am using TigerVNC to great effect so far. I would like to enable client connections from standard Win/Mac/Lin desktops (using the Tiger VncViewer) and ALSO client connections from mobile devices such as iOS / Android etc. The problem being, there are no free/open mobile (iOS/Android) VNC clients which implement encryption - yet. If I run the Xvnc server with SecurityType=None (which I would need to do to allow these mobile clients to connect), HOW can I make it more secure? Obviously, the password is still sent encrypted (I believe) but the RFB communication is open and in the clear (albeit using TightVNC encoding). To expand upon what Martin said, SecurityType=VncAuth (VNC Password Authentication) is the classic way of authenticating with VNC servers, and every mobile VNC client I've seen supports that. However, it's not really secure. The password is sent using DES3, so it can't be casually sniffed, but the session is not encrypted at all once the password is transmitted, so any other passwords you type while connected will be completely readable. Probably not a big deal if you're running within a secure corporate network without root access, but outside of a firewall, it's an issue. The issue with VNC on iOS is that Apple won't allow any GPL-licensed apps in the App Store, so that effectively eliminates one's ability to leverage code from TigerVNC (or most other VNC code bases) in an iPhone app. It probably prevents one from using LGPL-licensed libraries such as GnuTLS as well (TigerVNC uses GnuTLS to implement its built-in encryption.) The terms of the LGPL are such that you would have to provide source for the library as well as object files for the rest of the VNC viewer, and my understanding is that any such viral provisions are incompatible with the App Store. Android would be an easier target. I don't think it already has GnuTLS, so it would probably be necessary to build those libraries and statically link against them, but the Android Market does allow GPL'ed software, so it would be theoretically possible to extend one of the existing Android VNC clients. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
