[lug] remote xterm question...

[Bear Giles]

Peter Hutnick wrote:
> Bear Giles said:
>>Peter Hutnick wrote:
> 
>>I disagree with describing X terminals as only pieces of hardware.
>>  X defines a wire protocol for use between client and server, and
>>it's the same protocol regardless of whether it goes across your
>>ethernet connection, the loopback device, or a Unix socket.
> 
> I have only seen "X terminal" used for the thingies with a screen and a
> keyboard.  I'm not sure what else you are referring to.  Anything
> displaying an X desktop?  That seems like a uselessly broad definition.

I've worked on some embedded systems where I considered supporting 
the X wire protocol for the graphics-capable LCD display.  The 
reason was that we needed to support *some* protocol, and using X 
would, in theory, allow us to use existing tools during 
development.  (The biggest stumbling block is that the X Window 
System assumes a display, keyboard, and pointing device.  The 
first two were easy to identify, the third was not.)

This might seem unrealistic, but a few years ago the idea that 
network embedded devices would use HTTP servers as their own 
primary way to communicate with administrators was equally 
unrealistic.  "Everybody knew" that you had to find a null modem 
cable and a VT-100 to configure these devices!

>>Does VNC use the X protocol?  Some of the documentation refers to
>>communications occuring over port 5090, not 8000 et seq.

Correction: 5950.

> Not particularly.  For auth the server sends a random plain-text
> challenge.  The client receives this, prompts the user for the password. 
> The password and the challenge grind through some algorithm that creates a
> response, which is transmitted (in the clear) back to the server.  If the
> server comes up with the same response based on the locally stored
> password access is granted.
>
> This is probably sufficient to thwart everybody but the NSA.

It depends on the function used to create the result.  I doubt the 
protocol does something as stupid as XORing each pair of 
characters in challenge and password, but it may still be possible 
to pull the password from the challenge and response.

> If someone was able to interpose themselves on the wire they could quite
> conceivably read the contents of your screen, sniff out your keystrokes
> and, possibly, send keystrokes upstream.

I think that this pretty much covers "insecure." :-)  Sniffing the 
screen and keystrokes is probably a no-brainer.

> I keep hoping for someone to build SSL into the server and the client, but
> it keeps not happening.

Having looked at some of the SSL support out there... adding SSL 
is easy, especially if the code alway has a wrapper around the 
actual reads and writes.  Adding good SSL is apparently not.

(Really good SSL includes stuff like using ephemeral keypairs for 
perfect forward security or resumable sessions.  But many of these 
applications didn't check for error conditions, just closed 
sockets without doing an SSL_shutdown(), etc.  So their crypto 
worked, but wasn't reliable.)