You can subscribe to this list here.
2002 |
Jan
(8) |
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Joe A. <jo...@py...> - 2003-04-11 14:27:17
|
On Wed, 2003-04-09 at 18:37, Constantin Kaplinsky wrote: Hi Const > TJ> Do you have any code/documentation for this? That would be great, > TJ> since exactly this is on my feature list for KDE's Desktop > TJ> Sharing. > > And in my feature list (for TightVNC), too. :-) > > I've started to work on OpenSSL integration, however, I'm rather > interested in encryption than in certificate-based authentication. > > By the way, I also have implemented protocol extensions to negotiate > protocol options such as tunneling/encryption methods, additional > authentication schemes, non-standard normal messages and extra > encodings. The sources are available in the CVS, in both Unix and > Win32 parts. Just looked at your changes in CVS. I could see that the protocol extension are much more general than mine, and I can easily integrate my requirements into this. Am I right in finding that your CVS does not yet contain any actual OpenSSL integration? If yes, would my changes maybe fit your requirements? As said in my previous mail, my "public" changes to not contain (yet) any certificate stuff. Just using anon DH keyexchange (ADH-RC4-MD5) then provides "pure" encryption, without any cert stuff. But that of course also means that they don't provide any means against man-in-the-middle attacks. If you really decide to go down this way, we might want to implement something like the "host key feature" of SSH to reduce the need for trust to the very first connection establishment. Of course, this then raises questions like where to store the known server keys etc. Anyway, you might find it helpful looking into my sources. Although they are based against Tight 1.2.6 (with some non-encrytpion related changes), they should be easily integratable. I implemented encryption by subclassing the connection classes on both client and server side. This allowed me to keep encryption related code in one .h/.cpp file on each client and server. Also, I '#ifdef OPENSSL' all other required changes (in some places, they were needed). Forget about the '#ifdef UBS' stuff, those are really related to cert auth stuff (or other weird things). Also, I had to make some member function virtual/protected to be able to override them in the subclasses. CU, Joe |
From: Joe A. <jo...@py...> - 2003-04-11 13:55:20
|
On Wed, 2003-04-09 at 18:37, Constantin Kaplinsky wrote: > Hello Tim, Joe, > > >>>>> "TJ" == Tim Jansen <ml...@tj...> writes: > > >> Currently it does X.509 certificate auth and "regular" VNC auth. > >> Also, I've extenden initial RFB client/server handshake so that the > >> authtype could be negotiated (and then accepted or not by either > >> party depending on configurable policies). > > TJ> Do you have any code/documentation for this? That would be great, > TJ> since exactly this is on my feature list for KDE's Desktop > TJ> Sharing. > > And in my feature list (for TightVNC), too. :-) > > I've started to work on OpenSSL integration, however, I'm rather > interested in encryption than in certificate-based authentication. I've also implemented this in 2 ways: 1) Just use SSL with anonymous DiffieHellman Keyexchange to get encryption 2) My "private" extension of this also does cert base authentication. > By the way, I also have implemented protocol extensions to negotiate > protocol options such as tunneling/encryption methods, additional > authentication schemes, non-standard normal messages and extra > encodings. The sources are available in the CVS, in both Unix and > Win32 parts. Probably much the same I did :-) I'll check that out. Probably, I can base my future release on this. > Joe, could you please send me your changes? Sinse I've already > implemented a subset of similar functionality, I won't include your > changes as is, but I think your work can save some time and prevent > some duplication of efforts. I have put up my changes (Win only) to http://www.pyx.ch/joe/vnc/. It's quite old and not tidied up. CU, Joe |
From: Smith, T. <Tod...@ca...> - 2003-04-09 17:02:53
|
Hello, I don't really have much to contribute other then joy that this list and the wonderful capabilities of RFB are not going to die. Todd Smith <tod...@ca...> -----Original Message----- From: Constantin Kaplinsky [mailto:co...@ce...] Sent: Wednesday, April 09, 2003 12:38 PM To: ti...@tj... Cc: Joe Ammann; sec...@li... Subject: Re: [rfbhackers] is anybody working on sercureVNC? Hello Tim, Joe, >>>>> "TJ" == Tim Jansen <ml...@tj...> writes: >> Currently it does X.509 certificate auth and "regular" VNC auth. >> Also, I've extenden initial RFB client/server handshake so that the >> authtype could be negotiated (and then accepted or not by either >> party depending on configurable policies). TJ> Do you have any code/documentation for this? That would be great, TJ> since exactly this is on my feature list for KDE's Desktop TJ> Sharing. And in my feature list (for TightVNC), too. :-) I've started to work on OpenSSL integration, however, I'm rather interested in encryption than in certificate-based authentication. By the way, I also have implemented protocol extensions to negotiate protocol options such as tunneling/encryption methods, additional authentication schemes, non-standard normal messages and extra encodings. The sources are available in the CVS, in both Unix and Win32 parts. Joe, could you please send me your changes? Sinse I've already implemented a subset of similar functionality, I won't include your changes as is, but I think your work can save some time and prevent some duplication of efforts. -- With Best Wishes, Constantin |
From: Constantin K. <co...@ce...> - 2003-04-09 16:39:34
|
Hello Tim, Joe, >>>>> "TJ" == Tim Jansen <ml...@tj...> writes: >> Currently it does X.509 certificate auth and "regular" VNC auth. >> Also, I've extenden initial RFB client/server handshake so that the >> authtype could be negotiated (and then accepted or not by either >> party depending on configurable policies). TJ> Do you have any code/documentation for this? That would be great, TJ> since exactly this is on my feature list for KDE's Desktop TJ> Sharing. And in my feature list (for TightVNC), too. :-) I've started to work on OpenSSL integration, however, I'm rather interested in encryption than in certificate-based authentication. By the way, I also have implemented protocol extensions to negotiate protocol options such as tunneling/encryption methods, additional authentication schemes, non-standard normal messages and extra encodings. The sources are available in the CVS, in both Unix and Win32 parts. Joe, could you please send me your changes? Sinse I've already implemented a subset of similar functionality, I won't include your changes as is, but I think your work can save some time and prevent some duplication of efforts. -- With Best Wishes, Constantin |
From: Tim J. <ml...@tj...> - 2003-04-07 22:17:32
|
On Monday 07 April 2003 22:15, Joe Ammann wrote: > I'll have to do some porting to Linux/Solaris anyway, and that seems > also to be a very nice opportunity to dive into the KDE X.509 handling > stuff. I presume you're talking about something like integration with > the Sphinx framework, aren't you? No, the Sphinx framework is only for groupware. Desktop Sharing allows a administrator to join a user's desktop using VNC. For this use case VNC's password authentication is very bad. The Desktop Sharing server runs with user permissions. Thus every user can replace the original server with a trojan horse that captures the administrators password (or at least gets the right token for a single challenge-response) and use it to access somebody else's desktop. The other problem is that it would be desirable if administrators could authenticate using their regular account, not with a password that is shared among administrators. So the part that I am most interested in is the handshake to negotiate the authentication. My primary focus is Kerberos, as it allows administrators to authenticate using their regular accounts even on an untrusted machine. That's why I have planned to extend the protocol with a SASL mechanism. I did not start coding on this. The timeframe is KDE 3.2, which will probably be released in late summer or fall, but there is no schedule yet. Authentication using public-key certificates would be a bonus that I have also considered (as a solution for small companies and home users who don't have Kerberos servers), but not for the next KDE version. KDE has KSSL which can be used for managing certicficates and other things, but I am not familar with it. bye... |
From: Joe A. <jo...@py...> - 2003-04-07 20:16:45
|
On Mon, 2003-04-07 at 19:35, Tim Jansen wrote: > On Monday 07 April 2003 12:19, Joe Ammann wrote: > > Currently it does X.509 certificate auth and "regular" VNC auth. Also, > > I've extenden initial RFB client/server handshake so that the authtype > > could be negotiated (and then accepted or not by either party depending > > on configurable policies). > > Do you have any code/documentation for this? That would be great, since > exactly this is on my feature list for KDE's Desktop Sharing. Yes. Unfinished, unclean, and mostly Windows code (that was what my customer wanted). It's based on the TightVNC source, but the part with changes is just about the same in any VNC variant. I guess I can grab together my bits tomorrow. I'd be grateful to be able to discuss this with people, because I feel somewhat "unreflected" until now..... I'll have to do some porting to Linux/Solaris anyway, and that seems also to be a very nice opportunity to dive into the KDE X.509 handling stuff. I presume you're talking about something like integration with the Sphinx framework, aren't you? CU, Joe |
From: Tim J. <ml...@tj...> - 2003-04-07 17:34:52
|
On Monday 07 April 2003 12:19, Joe Ammann wrote: > Currently it does X.509 certificate auth and "regular" VNC auth. Also, > I've extenden initial RFB client/server handshake so that the authtype > could be negotiated (and then accepted or not by either party depending > on configurable policies). Do you have any code/documentation for this? That would be great, since exactly this is on my feature list for KDE's Desktop Sharing. bye... |
From: Joe A. <jo...@py...> - 2003-04-07 10:19:58
|
On Mon, 2003-04-07 at 01:28, Andrew van der Stock wrote: > I've fallen off the edge of the planet. > > Anyone who wants to take it over, feel free to do so. > I'd be interested to contribute. I've developed for a customer a "RFB over SSL" solution with a (somewhat - needs improvement) pluggable authentication mechanism. Currently it does X.509 certificate auth and "regular" VNC auth. Also, I've extenden initial RFB client/server handshake so that the authtype could be negotiated (and then accepted or not by either party depending on configurable policies). Something like a basis is laid, but I'd need further contributors to make it generally usable. CU, JOe |
From: Andrew v. d. S. <aj...@gr...> - 2003-04-06 23:28:42
|
I've fallen off the edge of the planet. Anyone who wants to take it over, feel free to do so. Andrew -----Original Message----- From: sec...@li... [mailto:sec...@li...] On Behalf Of oliver thuns Sent: Monday, 7 April 2003 1:05 AM To: sec...@li... Subject: [rfbhackers] is anybody working on sercureVNC? please cc to my private mail address, because i'm not subribed to the list (seems the project is dead) ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Securevnc-rfbhackers mailing list Sec...@li... https://lists.sourceforge.net/lists/listinfo/securevnc-rfbhackers |
From: oliver t. <sm...@gm...> - 2003-04-06 15:05:54
|
please cc to my private mail address, because i'm not subribed to the list (seems the project is dead) |
From: Andrew v. d. S. <aj...@gr...> - 2002-07-17 00:19:19
|
Please ignore my thing about BEEP. It fails my "no redundant crap" test. Yet another sorta-XML over TCP protocol suite. If I wanted that, I'd have used SOAP. Andrew -----Original Message----- From: sec...@li... [mailto:sec...@li...] On Behalf Of Andrew van der Stock Sent: Wednesday, 17 July 2002 10:04 AM To: 'Smith, Todd' Cc: sec...@li... Subject: RE: [rfbhackers] Auditing Capabilities Todd, [snip] Did anyone see the BEEP (block extensible exchange protocol) discussion on Slashdot yesterday? Who thinks moving to Beep as the underlying protocol? This would seriously cut down the time it takes to migrate to RFB 4.x as you'd only need to map BEEP messages to RFB capabilities. Andrew |
From: Andrew v. d. S. <aj...@gr...> - 2002-07-17 00:04:22
|
Todd, The protocol per se doesn't have any auditing features. The major thing from my point of view is that it is easily verifiable, and nearly all channels completely optional. If the client or server implementers wish to include auditing features (and I think this is a good idea), then they should do so based upon the grammar of the protocol. Did anyone see the BEEP (block extensible exchange protocol) discussion on Slashdot yesterday? Who thinks moving to Beep as the underlying protocol? This would seriously cut down the time it takes to migrate to RFB 4.x as you'd only need to map BEEP messages to RFB capabilities. Andrew -----Original Message----- From: sec...@li... [mailto:sec...@li...] On Behalf Of Smith, Todd Sent: Wednesday, 17 July 2002 6:10 AM To: 'sec...@li...' Subject: [rfbhackers] Auditing Capabilities I hope that this is on-topic but I don't see within the protocol specs or within any of the clients and servers the ability to audit connection information from a VNC server. Have I missed something? Todd Smith <tod...@ca...> ------------------------------------------------------- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim _______________________________________________ Securevnc-rfbhackers mailing list Sec...@li... https://lists.sourceforge.net/lists/listinfo/securevnc-rfbhackers |
From: Smith, T. <Tod...@ca...> - 2002-07-16 20:10:58
|
I hope that this is on-topic but I don't see within the protocol specs or within any of the clients and servers the ability to audit connection information from a VNC server. Have I missed something? Todd Smith <tod...@ca...> |
From: Andrew v. d. S. <aj...@gr...> - 2002-06-16 05:29:34
|
Okay, I've been working on the draft in my hotel room (not much else to do), and I want to make the following simplifications: Only two encodings: . Hextile with optional zlib compression . Tight-1.2.x encoding (I'm using 1.2.4 as my guide) I'd like to drop the "text" encoding as Eric Hill pointed out that in many circumstances, the cache encoding I've proposed will be even more efficient than a text encoding. So I will talk to Constantin about the possibilities of adding the cache tile encoder to the Tight encoding. The reasons for dropping older encoders is to help small footprint platforms. Remember, in RFB 4.x nearly everything is optional, so it is possible to make a very small server and viewer. Only one bi-directional transfer mechanism. This will have extensions to cope with files and printing, but essentially, it's a "bag o' bits" approach. I don't want the protocol to get too tied up with platform-specific intricacies. Andrew |
From: Andrew v. d. S. <aj...@gr...> - 2002-03-22 14:04:47
|
Hi there, I've started an acceptance test area on my VNC pages. I'll be adding to them as time goes on. I see the acceptance tests as being one small SQA tool in the effort to reduce the number of outstanding VNC security bugs. However, they will also be useful to test the new protocol and to ensure great interop for those clients and servers that wish to retain RFB 3.3 capabilities. http://www.evilsecurity.com/vnc/ Click on the acceptance test for an example of four tests. More to come. Feel free to submit more to me. Andrew |
From: Tim J. <ti...@tj...> - 2002-02-21 00:12:02
|
On Thursday 21 February 2002 00:13, Andrew van der Stock wrote: > our encryption. However, many embedded / PDA platforms don't have an SSL > library, which is why secsh is sort of nice as it provides three > functions: authentication, transport (it supports channels), and strong > encryption. SSL only provides encryption. IMHO the question is what the minimum requirements for the target system are. Today even PDAs come with SSL (at least the PocketPCs), and Palms will do so sooner or later, too. Is encryption on Palms really a critical feature? > There's still a potential for namespace clashes with a URI style. Whether a > name is represented by 16 bits or 16 bytes, it's still possible to use the > same values. Not if you use the DNS namespace. BTW have you looked at BEEP (RFC 3080). It is also relatively complex, but resembles the whole channel mechanism of the RFB 4.0 draft (with URIs for channels and TLS for security features). If you use BEEP all you have to define is a profile for the encodings and the events. It is XML-based though. bye... |
From: Andrew v. d. S. <aj...@gr...> - 2002-02-20 23:22:00
|
Actually SSL can also provide moderately strong authentication via the use of X.509 certificates, but getting a cert onto devices without filesystems (Palm's and WinCE 1.0, for example) would be a nightmare. Andrew * (Yes, PalmOS has "records" and there are various third party tools to get around the lack of direct file storage, but it'll be just simpler to discount the certificate stuff in this context.) -----Original Message----- From: sec...@li... [mailto:sec...@li...] On Behalf Of Andrew van der Stock Sent: Thursday, 21 February 2002 10:13 AM To: ti...@tj... Cc: sec...@li... Subject: RE: [rfbhackers] Comments on RFB 4.0 draft ... SSL only provides encryption. ... |
From: Andrew v. d. S. <aj...@gr...> - 2002-02-20 23:13:20
|
Tim, Thanks for the feedback - some good ideas here. SSL versus secsh (the other current alternative). Most platforms have the equivalent of openssl or CryptoAPI, so we could leverage that for our encryption. However, many embedded / PDA platforms don't have an SSL library, which is why secsh is sort of nice as it provides three functions: authentication, transport (it supports channels), and strong encryption. SSL only provides encryption. I'm hearing you on the vendorID front; the issue for me is to keep the size of the protocol down and reduce complexity and reduce the ability for the protocol to be exploited. There's still a potential for namespace clashes with a URI style. Whether a name is represented by 16 bits or 16 bytes, it's still possible to use the same values. I just wanted to make room for a sound channel. It's a common feature request. I don't necessarily see it happening anytime soon. SIP is huge, and not simple at all. SIP suffers from having to interpret UTF-8 strings as meaningful data. The other issue is that SIP, although feature rich, is too verbose. Even if we cut down on the amount of verbs all implementations must implement, we're looking at SIP on top of what amounts to about 80% of a web server as well as VNC code. http://www.ietf.org/rfc/rfc2543.txt We could allow the use of SIP discovery - but I think SIP is just too big for VNC. SDP is interesting, but the fact that clients and servers will have to interpret text buffers and make them into machine representations doesn't gel with the binary protocol that RFB 3.x is, and 4.x should be. From a security standpoint dealing with arbitrary length Unicode UTF-8 strings to start a session is complex and fills me with fear. http://www.ietf.org/rfc/rfc2327.txt Compared to SIP, secsh's channel architecture is the very essence of simplicity and more to the point, we can leverage libraries of secsh code that already exist, thus reducing the amount of time it takes to get the first implementation working. If we go to secsh, I propose that we just utilize the "scp" file transfer, and potentially allow the transport of IPP or lpr across the transport. Please let me know if I'm way out of line here, but I think we need to keep the protocol as simple as possible, binary, and cope with the few extra things that are currently missing. All of the strings in the current protocol draft are for human consumption, and are easily ignored by clients and servers alike. Andrew -----Original Message----- From: sec...@li... [mailto:sec...@li...] On Behalf Of Tim Jansen Sent: Friday, 1 February 2002 8:12 AM To: sec...@li... Subject: [rfbhackers] Comments on RFB 4.0 draft Hi... A few comments on the RFB 4.0 draft: - is there a good reason not to use SSL/TLS for encryption and possibly also as an authentication option? The SSL handshake could take place after the authentication mechanism has been negotiated. - instead of using VendorIDs I would propose to use URIs, similar to the use in XML DTDs or Java package names. This would prevent the possibility of name clashes. - IMHO transmitting real-time sound over TCP is not a good idea, especially with lower bandwidth. Skips in audio data are very unpleasant for the user and getting audio right over TCP can be very difficult. RTP is already there and could be used as well. - I think RFB should be seen in context of SIP. SIP/SDP can establish connections and negotiate protocols (like having RFB and RTP in a single session). Microsoft seems to use it for audio (and a few other things like video) with RDP as well, at least for VoIP. - several of the other channel types duplicate the functionality of existing RFCs. If you initiate the session using SIP and SDP printers could be accessed using IPP, files using HTTP/WebDAV. There is no need to create subprotocols in RFB for that. When SSL/TLS is used all these protocols (except RTP) could use the same security layer. - the text encoding sounds somewhat dangerous to me as there may be different font renders on the system (for example one that supports kerning and one that doesnt) or fonts with the same name but slightly different outlines. IMHO caching of bitmaps/glyphs should be sufficient. bye... _______________________________________________ Securevnc-rfbhackers mailing list Sec...@li... https://lists.sourceforge.net/lists/listinfo/securevnc-rfbhackers |
From: Tim J. <ml...@tj...> - 2002-01-31 21:07:08
|
Hi... A few comments on the RFB 4.0 draft: - is there a good reason not to use SSL/TLS for encryption and possibly also as an authentication option? The SSL handshake could take place after the authentication mechanism has been negotiated. - instead of using VendorIDs I would propose to use URIs, similar to the use in XML DTDs or Java package names. This would prevent the possibility of name clashes. - IMHO transmitting real-time sound over TCP is not a good idea, especially with lower bandwidth. Skips in audio data are very unpleasant for the user and getting audio right over TCP can be very difficult. RTP is already there and could be used as well. - I think RFB should be seen in context of SIP. SIP/SDP can establish connections and negotiate protocols (like having RFB and RTP in a single session). Microsoft seems to use it for audio (and a few other things like video) with RDP as well, at least for VoIP. - several of the other channel types duplicate the functionality of existing RFCs. If you initiate the session using SIP and SDP printers could be accessed using IPP, files using HTTP/WebDAV. There is no need to create subprotocols in RFB for that. When SSL/TLS is used all these protocols (except RTP) could use the same security layer. - the text encoding sounds somewhat dangerous to me as there may be different font renders on the system (for example one that supports kerning and one that doesnt) or fonts with the same name but slightly different outlines. IMHO caching of bitmaps/glyphs should be sufficient. bye... |
From: Andrew v. d. S. <aj...@gr...> - 2002-01-17 21:52:40
|
My personal interest is that RFB 3.x is not securable, but if you look at the draft, it adds a whole raft of things that needed to be added for the longest time. It's basically a NG discussion list, not just about security. Andrew -----Original Message----- From: sec...@li... [mailto:sec...@li...] On Behalf Of Michael Ossmann Sent: Friday, 18 January 2002 5:44 AM To: sec...@li... Subject: Re: [rfbhackers] Protocol Hackers On Thu, Jan 17, 2002 at 11:27:29AM +0200, Erlichmen, Shay wrote: > > Is this list will be oriented on securing the RFB protocol only?, or > for general purpose design of the TNG protocol. Andrew's primary focus happens to be on security, but the list is dedicated to the future of the protocol as a whole and the eventual standardization of RFB 4.0. Please join us if you have an interest in RFB. The more, the merrier! -- Mike Ossmann, Tarantella/UNIX Engineer/Instructor Alternative Technology, Inc. http://www.alttech.com/ _______________________________________________ Securevnc-rfbhackers mailing list Sec...@li... https://lists.sourceforge.net/lists/listinfo/securevnc-rfbhackers |
From: Michael O. <mic...@al...> - 2002-01-17 18:42:30
|
On Thu, Jan 17, 2002 at 11:27:29AM +0200, Erlichmen, Shay wrote: > > Is this list will be oriented on securing the RFB protocol only?, or for > general purpose design of the TNG protocol. Andrew's primary focus happens to be on security, but the list is dedicated to the future of the protocol as a whole and the eventual standardization of RFB 4.0. Please join us if you have an interest in RFB. The more, the merrier! -- Mike Ossmann, Tarantella/UNIX Engineer/Instructor Alternative Technology, Inc. http://www.alttech.com/ |
From: Erlichmen, S. <Sha...@ic...> - 2002-01-17 09:28:12
|
Hi, Is this list will be oriented on securing the RFB protocol only?, or for general purpose design of the TNG protocol. -Shay. |
From: Michael O. <mic...@al...> - 2002-01-17 01:00:20
|
On Thu, Jan 17, 2002 at 10:40:41AM +1100, Andrew van der Stock wrote: > It'd be better if we tracked IETF's secsh rather than ssh2 per se. Yeah, the secsh group work is actually what I meant by SSH2. > Also, secsh/ssh2 is fairly large, which is a consideration for smaller > clients. Have you taken a look at the size of a minimal secsh client? The only required algorithms are 3des-cbc, hmac-sha1, diffie-hellman-group1-sha1, and publickey/dss authentication. There are no required compression algorithms, and I don't think there are any required channel types on the client side. I think it could be pretty small. There is a good argument about packet size in the Architecture draft. > However, you are right, if we go to secsh for the transport (and I like the > idea of using its channels), we can't be on port 5900 and allow RFB 3.x > clients to connect as the server gets to talk first. We'd have to choose > another port. We could have a fall through that starts the negotiation after > RFB 4.x is selected, like we do at the moment, to fix that, but we wouldn't > be a pure secsh enabled protocol. We could define a new port, encourage 3.x compatibility on the old ports (and over tunnels), and forget about fall-through. I don't know how strongly people feel about this issue. > Prioritization is a method of fixing interactivity problems. I wanted to > ensure that all packets are not too large, and that things like file > transfers were done when literally nothing else was happening so as to not > freeze the interface. That would definitely be a good thing. It seems like we should be able to build this on top of secsh channels. By the way, have you been in contact with the ORL people at all? I noticed the draft mentions an internal version (and I've seen their web page about it), but I was wondering if they have had any input or made any statements for or against an open protocol discussion (and the potential hijacking of their protocol name :-) -- Mike Ossmann, Tarantella/UNIX Engineer/Instructor Alternative Technology, Inc. http://www.alttech.com/ |
From: Andrew v. d. S. <aj...@gr...> - 2002-01-16 23:40:56
|
It'd be better if we tracked IETF's secsh rather than ssh2 per se. secsh is shaking out the protocol bugs of the ssh2 protocol, and will be a better target as it matures. Also, secsh/ssh2 is fairly large, which is a consideration for smaller clients. I wanted something small, like AES for inbuilt encryption and SRP for authentication so that the smallest clients wouldn't overly suffer from huge library imports and associated licensing issues. Saying that however, secsh has extreme merit for the purposes that I wanted SRP and AES and channels. Realistically, RFB 4.0 requires a new decoder, so the compatibility issue is somewhat moot. I was hoping that RFB 3.x code, once triggered by the RFB 4.x would remain interoperable. I have tried where I can to not change the semantics of the message, only the way it is delivered. However, you are right, if we go to secsh for the transport (and I like the idea of using its channels), we can't be on port 5900 and allow RFB 3.x clients to connect as the server gets to talk first. We'd have to choose another port. We could have a fall through that starts the negotiation after RFB 4.x is selected, like we do at the moment, to fix that, but we wouldn't be a pure secsh enabled protocol. Prioritization is a method of fixing interactivity problems. I wanted to ensure that all packets are not too large, and that things like file transfers were done when literally nothing else was happening so as to not freeze the interface. We could just make it part of the protocol that requires clients and servers to play well, just as in the cooperative multi-tasking days. I'd prefer prioritization to be left in or added somehow. Andrew ----- Original Message ----- From: "Michael Ossmann" <mic...@al...> To: <sec...@li...> Sent: Thursday, January 17, 2002 10:27 AM Subject: [rfbhackers] using SSH2 > I'd like to discuss the possibility of using SSH2 as the lower layers of > RFB4. I wouldn't be surprised if this has been discussed already, but, > if so, I'd like to hear the reasons that this direction has not been > pursued. > > SSH2 is an extensible protocol which includes authentication, > encryption, and channel multiplexing, all features which are essential > parts of the RFB4 draft. SSH1 and SSH2 are already popular tools among > VNC integrators for these very capabilities but are generally integrated > with VNC by using SSH's TCP port forwarding capabilities. It is also > possible to use SSH2 channels directly, avoiding the security and > administration problems inherent in port forwarding. > > The pros that I see are: > - The design work of these layers is already done. > - SSH2 is further along the standards track. > - We gain the benefit of the many eyeballs that are looking at SSH2. > - RFB4 protocol implementation becomes easier because we can reuse > existing open source SSH2 code or even integrate with complete SSH2 > products (such as OpenSSH's subsystem feature). > > The cons: > - Backwards compatibility with RFB3 becomes more difficult. > - I haven't looked into channel prioritization, but it might be a > problem. > > Thoughts? > > By the way, I'm currently making my way through the draft and so far I'm > very impressed. It is exactly the direction that I had hoped RFB would > go. |
From: Michael O. <mic...@al...> - 2002-01-16 23:25:56
|
I'd like to discuss the possibility of using SSH2 as the lower layers of RFB4. I wouldn't be surprised if this has been discussed already, but, if so, I'd like to hear the reasons that this direction has not been pursued. SSH2 is an extensible protocol which includes authentication, encryption, and channel multiplexing, all features which are essential parts of the RFB4 draft. SSH1 and SSH2 are already popular tools among VNC integrators for these very capabilities but are generally integrated with VNC by using SSH's TCP port forwarding capabilities. It is also possible to use SSH2 channels directly, avoiding the security and administration problems inherent in port forwarding. The pros that I see are: - The design work of these layers is already done. - SSH2 is further along the standards track. - We gain the benefit of the many eyeballs that are looking at SSH2. - RFB4 protocol implementation becomes easier because we can reuse existing open source SSH2 code or even integrate with complete SSH2 products (such as OpenSSH's subsystem feature). The cons: - Backwards compatibility with RFB3 becomes more difficult. - I haven't looked into channel prioritization, but it might be a problem. Thoughts? By the way, I'm currently making my way through the draft and so far I'm very impressed. It is exactly the direction that I had hoped RFB would go. -- Mike Ossmann, Tarantella/UNIX Engineer/Instructor Alternative Technology, Inc. http://www.alttech.com/ |