Dan Stromberg <[EMAIL PROTECTED]> writes:
> Unless the default for X connections became "encrypt
^^^^^^
Even that would not help *present* X terminal users :-)
You have to modify the X terminal, there is absolutely no other way.
>>> Would this mean a modification to the X server and Xlib?
>>
>> Yes, both, obviously.
>
> I'm not new to programming, but I've never done a project inside of
> X.
The X server listens for incoming connections and handles the display.
Xlib handles (for 99% of all clients) the client side of the
connection: initiating it and requesting graphics etc operations.
Both sides are connection via a byte channel abstraction (pipe, TCP/IP
connection, stream, whatever). If you want to encrypt the data going
over the pipe, you have to change both sides.
> I'd hate to require a proxy. It has to be a total no brainer for
> endusers to make much of a difference.
Ask the lbx people, why they still require a proxy. There may be
technical reasons for it, or maybe it is very hard to change Xlib?
> I'm not that worried about MITM attacks,
You mean you want to allow MITM attacks?
> but might try to guard against them if there's a big howling about
> better security that isn't perfect security.
MITM attacks for Ethernet are extremly simple nowadays, there are even
ready packed toolkit to do them. If you don't guard against them,
the level of security is very low.
>> Actually ssh could be a nice starting point :-)
>
> I have my doubts. But I'm listening.
Well, ssh solves the public/privat two side host authentication
problem with RSA or DSA exchange. Then it checks user authentication
and generates the session key, and finally it includes a couple of
encryption algorithms. It is believed to be secure even against
"timing" attacks.
> I have a suspicion it could be done orthogonally to both xhost and
> xauth, and any other auth system in use.
Yes, but you have to authenticate both sides, and you have to have a
starting point. Xauth could be this starting point, but it does not
have to be.
> This could kill the project. Does everyone agree such an improvement
> couldn't go into the main tree?
AFAIK there is no encryption code in the X three because of the US
export restrictions. They may not be as rediculous as they used to be,
they still divide the world in good and bad, and you are not allowed
to export encryption algorithms to the "bad" side.
The typical solution is to use crypto libraries, which are distributed
separately. Would that help you?
> The other guy had it right - it has to be a no brainer, and work on
> a true X terminal.
Once it is set up properly, ssh is an absolute no brainer (that also
applies to lbx, but setting up is more difficult). Of couse key
management requires permanent storage, if you use key authentication.
> I use ssh for my stuff, but that doesn't help people with real X
> terminals.
What about getting ssh included into the X terminal? I guess there are
problem with xdm, but appart from that I cannot see what you could
gain by including encryption in X.
Thomas <[EMAIL PROTECTED]>
--
Umweltfreundlich, da aus recycleten Buchstaben.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
