[lug] remote xterm question...
bgiles at coyotesong.com
Sun May 11 10:03:57 MDT 2003
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.
> 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.)
More information about the LUG