User: Password:
|
|
Subscribe / Log in / New account

network-ability Wayland should have: most of those are in xpra

network-ability Wayland should have: most of those are in xpra

Posted Oct 25, 2012 4:08 UTC (Thu) by amtota (subscriber, #4012)
In reply to: Wayland and Weston 0.99.0 snapshots released by drag
Parent article: Wayland and Weston 0.99.0 snapshots released

> 1. Graphic outputs over the network (as discussed above)
See xpra.org
> 2. Audio output over the network (TCP support in Pulseaudio is very effective)
I beg to differ, it is very bandwidth heavy, around 4MBps by default.
xpra supports that (setting up the X11 cookie etc), but it would need audio compression to be really useful. Also, the default pa tcp mode does not support disconnection/re-connection...
> 3. Copy-n-paste over the network. Hopefully some standard for clipboard managers will be implemented. Hopefully HTML-aware in a manner similar to Windows.
xpra does that
> 4. Notifications over the network.
xpra does that - tray icon support is planned
> 5. File transfer support.
Not implemented - not sure we want to either.
> 6. Some sort of thing for supporting weird input devices. Like USB support for generic devices.. things for special input support like game devices or accessability devices. I don't know.
On the todo list so we can support things like pressure sensitive devices over the network (ie: android clients)
> 7. Some lovely way to securely tunnel it all. SSH would be great I expect.
xpra supports ssh and will have an AES/SPEKE secure tcp mode in the next release (probably)


(Log in to post comments)

network-ability Wayland should have: most of those are in xpra

Posted Oct 25, 2012 13:34 UTC (Thu) by njs (guest, #40338) [Link]

> I beg to differ, it is very bandwidth heavy, around 4MBps by default. xpra supports that (setting up the X11 cookie etc), but it would need audio compression to be really useful. Also, the default pa tcp mode does not support disconnection/re-connection...

In principle even this would be fixable with some work (either by fixing the PA TCP mode or by running a PA daemon on the server and loading some custom 'xpra sink'), but the real problem is multiplexing latency-sensitive audio + screen updates over an SSH channel over TCP while avoiding audio dropouts. Maybe once bufferbloat is fixed this will be more doable, but for now it's a very difficult bit of network engineering.

> xpra supports ssh and will have an AES/SPEKE secure tcp mode in the next release (probably)

While I am sort of amused to see my predictions from years ago coming true[1], it's still true that ROLLING YOUR OWN TRANSPORT CRYPTO IS A STUPID IDIOTIC IDEA AND YOU SHOULD NOT DO IT. Sorry for shouting, but it is important that you NOT DO THIS IT WILL NOT BE SECURE I PROMISE YOU WILL BE LYING TO YOUR USERS. I know SSH and TLS are both obnoxious to work with but EVERYTHING ELSE IS SNAKE OIL THERE IS NO-ONE ALIVE WHO IS SMART ENOUGH TO DO WHAT YOU ARE DOING SO STOP IT.

...goodness sakes, 2 minutes of googling suggests that TLS-SRP is even reasonably well supported these days. Use that. Please.

[1] "how do I know that the next person won't want even more assurances, like encryption or MITM protection or whatever? That will *definitely* spiral out of our ability to get right." - http://lists.partiwm.org/pipermail/parti-discuss/2009-Jun...

network-ability Wayland should have: most of those are in xpra

Posted Oct 26, 2012 3:50 UTC (Fri) by amtota (subscriber, #4012) [Link]

> In principle even this would be fixable with some work (either by fixing the PA TCP mode or by running a PA daemon on the server and loading some custom 'xpra sink'), but the real problem is multiplexing latency-sensitive audio + screen updates over an SSH channel over TCP while avoiding audio dropouts. Maybe once bufferbloat is fixed this will be more doable, but for now it's a very difficult bit of network engineering.
In winswitch, I've solved this by doing pretty much that: starting a decicated PA server per session (which is not trivial if you launch more than one per user) and then compressing the stream over TCP sockets (yikes) via gstreamer pipelines (with buffering and all)
The problem with xpra is that I see this as being out of scope: do one thing and do it well.

> ROLLING YOUR OWN TRANSPORT CRYPTO IS A STUPID IDIOTIC IDEA AND YOU SHOULD NOT DO IT. Sorry for shouting (...)
Please feel free to review the code once it is finished (it isn't), some already have already provided comments:
https://www.xpra.org/trac/ticket/198

> I know SSH and TLS are both obnoxious to work with (...)
Indeed. And more importantly, it is a different security model altogether: one where you trust an authority (or just inspect manually) to verify the authenticity of the host. We aren't interested in that. If that is what you want, stick with SSH, or use OpenVPN.

> EVERYTHING ELSE IS SNAKE OIL (...)
I think the authors of SPEKE would beg to differ...

> That will *definitely* spiral out of our ability to get right."
Well, let's agree to disagree. Secure key exchange is not rocket science, it was quite a new thing 15 years ago, but things have moved on.
Please do consider the differences between the ssh/tls model and speke.. these do not address the same concerns. (and I'll admit there may well be difficulties in explaining those differences to users)

network-ability Wayland should have: most of those are in xpra

Posted Oct 26, 2012 14:17 UTC (Fri) by njs (guest, #40338) [Link]

> Please feel free to review the code once it is finished (it isn't), some already have already provided comments:

This is only useful if you can convince as many people to review your code as have reviewed SSH/TLS. Those protocols both contained bugs which survived dozens of man-years of review. You are not smarter than the entire cryptographic community. Have you read your Ferguson & Schneier (& Kohno)? What's your rekeying time? Do you know what that is and why it matters? Now that I've said that you can look it up and patch one obvious hole, but there will still be a dozen more.

> I think the authors of SPEKE would beg to differ...

WTF, do you not even understand the difference between a crypto primitive and a crypto protocol? SPEKE is a fine primitive (well, there are better ones, but that's actually besides the point). But it doesn't matter if you choose good primitives. If design your own protocol YOU WILL FUCK IT UP AND CHALLENGING PEOPLE TO REVIEW IT WILL NOT SAVE YOU.

Most snake oil vendors honestly believe that their code is great! And advertise them by boasting about using cool primitives (AES! SPEKE! XX-bits! never mind that they're used insecurely!). And then when someone point this out, the snake oil vendor always responds by challenging them to review the code and point out specific problems. Srsly you're exhibiting the classic symptoms. Stop and think about it. Spreading bad crypto is a sin.

> Please do consider the differences between the ssh/tls model and speke

Please read my fucking message. I said you should use TLS-SRP. That has the same model as the protocol you are ineptly trying to design. Yes, it requires you to deal with the gnutls api instead of playing around with fun maths, but on the other hand IT IS DESIGNED AND IMPLEMENTED BY PEOPLE WHO KNOW WHAT THEY ARE DOING AND IT WILL ACTUALLY FUCKING WORK.

(Just one example - SPEKE requires the server store passwords in plain text, which we've had *plenty* of evidence lately is a terrible idea. SRP avoids this problem.)

network-ability Wayland should have: most of those are in xpra

Posted Oct 27, 2012 1:45 UTC (Sat) by amtota (subscriber, #4012) [Link]

> Please read my fucking message
Sorry, after all the shouting and swearing, I stopped. Maybe some other time.

network-ability Wayland should have: most of those are in xpra

Posted Oct 27, 2012 10:11 UTC (Sat) by njs (guest, #40338) [Link]

Heh. I swear because I care... and because every time I've explained this before, you've just ignored the main points completely. So I was hoping that might get you to pay attention.

Obviously though if you are determined not to listen when people warn you that you are making a serious mistake, then that's ultimately your decision.

network-ability Wayland should have: most of those are in xpra

Posted Oct 28, 2012 17:31 UTC (Sun) by nix (subscriber, #2304) [Link]

Srsly, he's right. This way lies disaster, no matter how smart you are. Programming Satan's computer, and all that. It's ever so much better an idea to use someone else's code for this, and gnutls does work and does get review.

TLS-SRP (as opposed to plain TLS) is suitable?

Posted Feb 19, 2015 1:34 UTC (Thu) by gmatht (subscriber, #58961) [Link]

Minus the shouting the concern seems to be that your security model sounds a lot like that of the already existing TLS-SRP (as opposed to plain TLS). For example:
TLS-SRP provides mutual authentication (the client and server both authenticate each other), while TLS with server certificates only authenticates the server to the client. Client certificates can authenticate the client to the server, but it may be easier for a user to remember a password than to install a certificate. -- Wikipedia
Any comments on the difference between your security model and that of TLS-SRP?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds