4 ms·

This nicely solves a problem I've been asked about: how to share a screen securely (read-only). VNC protocol and implementations are too complex/sloppy so I don

by arde 13y ago

This nicely solves a problem I've been asked about: how to share a screen securely (read-only). VNC protocol and implementations are too complex/sloppy so I don't trust them. An endless GIF, on the other hand...

Falling3 13y ago
What about a service like join.me or gotomeeting?
- arde 13y ago
  For this use case I don't trust implementations that I have source code for, due to their complexity. This is intended to share screens that lie behind a firewall. It wouldn't make sense to trust third-party code with closed source code and a similarly complex protocol (and undocumented). Neither would be logical to add this third party, the middle-man, as a point of failure and attack.
zanny 13y ago
> VNC protocol and implementations are too complex/sloppy so I don't trust them. The protocol is 50 pages long with pretty reasonable margins and it even has pictures: http://www.realvnc.com/docs/rfbproto.pdf http://www.realvnc.com/docs/rfbproto.pdf It is an afternoon read. Most desktop environments in Linux implement their own VNC server just because it isn't that complex and you can implement a subset of the protocol for a server anyway. I imagine if there was a protocol flaw revealed (or even in the many implementations like libvncserver) it would be patched overnight. All of them support viewer-only mode. I like krfb, because by default it only uses access passes rather than a global password, so unless you give someone credentials of an access ticket nobody can login. I bet an exploitation in the way gifs download and how http resolves file transfers in the dozens of implementations of both is much more likely to have an exploitable man in the middle or other mechanism to eavesdrop, if not take remote control.
- sidorares 13y ago
  +1 rfb protocol is not complex and properly documented
  - arde 13y ago
    It depends on what you compare it to. I meant complex in the context of the use case I have in mind. It certainly IS much more complex (and powerful) than a simple GIF creator. But if you only need a one-way, low quality stream, RFB is overkill.
- arde 13y ago
  For my use case I'm not worried about the client's security (in fact, he's the one I'm interested in protecting the server from). We probably are assuming very different tolerance thresholds on security. But even so, I don't think you can argue for any security advantages of typical implementations for a 50-page protocol when comparing them to a one-way simple GIF sender.

by arde 13y ago

Falling3 13y ago

What about a service like join.me or gotomeeting?

arde 13y ago
For this use case I don't trust implementations that I have source code for, due to their complexity. This is intended to share screens that lie behind a firewall. It wouldn't make sense to trust third-party code with closed source code and a similarly complex protocol (and undocumented). Neither would be logical to add this third party, the middle-man, as a point of failure and attack.

zanny 13y ago

> VNC protocol and implementations are too complex/sloppy so I don't trust them. The protocol is 50 pages long with pretty reasonable margins and it even has pictures: http://www.realvnc.com/docs/rfbproto.pdf http://www.realvnc.com/docs/rfbproto.pdf It is an afternoon read. Most desktop environments in Linux implement their own VNC server just because it isn't that complex and you can implement a subset of the protocol for a server anyway. I imagine if there was a protocol flaw revealed (or even in the many implementations like libvncserver) it would be patched overnight. All of them support viewer-only mode. I like krfb, because by default it only uses access passes rather than a global password, so unless you give someone credentials of an access ticket nobody can login. I bet an exploitation in the way gifs download and how http resolves file transfers in the dozens of implementations of both is much more likely to have an exploitable man in the middle or other mechanism to eavesdrop, if not take remote control.

sidorares 13y ago
+1 rfb protocol is not complex and properly documented
- arde 13y ago
  It depends on what you compare it to. I meant complex in the context of the use case I have in mind. It certainly IS much more complex (and powerful) than a simple GIF creator. But if you only need a one-way, low quality stream, RFB is overkill.
arde 13y ago
For my use case I'm not worried about the client's security (in fact, he's the one I'm interested in protecting the server from). We probably are assuming very different tolerance thresholds on security. But even so, I don't think you can argue for any security advantages of typical implementations for a 50-page protocol when comparing them to a one-way simple GIF sender.