[Libwebsockets] using unix or tcp sockets?
andy at warmcat.com
Tue Aug 29 04:38:41 CEST 2017
On 08/29/2017 08:50 AM, Per Bothner wrote:
> I'm looking into integrating session management (as in GNU screen or tmux)
> into DomTerm (http://domterm.org). This seems to imply a separate
> server process that manages the various processes and ptys.
> Short-running clients
> would send requests (such as "create a new session" or "list sessions")
> to the server.
It sounds like it needs a really good security story.
> It seems to make sense to use Unix domain sockets for communication
> between the
> clients and the server, for at least two reasons:
> (1) discoverability: the socket can be bound to a standard (per-user) place
> in the file system
> (2) security: by default the socket has the same ownership and permissions
> as the user running the server, so a client belonging to one user can't
> communicate with the server belonging to another user.
> On the other hand, it's not clear to me how to mix unix and tcp sockets
> with libwebsockets,
The unix sockets support was contributed.
At the moment it's all or nothing (it's enabled in the context options
not the vhost options)... it needs improving.
> and communicating between the server and the display front-ends
> (which are web browsers, possibly embedded, like Electron, but not always)
> would seem to require tcp sockets.
> Using http over tcp sockets would make for a simpler server.
> Discoverability can be handled by writing the listening port to a file
> in the fire system, where the client can read it. Security is harder,
> but as long we're just working locally simple authentication may be
> enough: The server can generate a key, write it to a user-only-readable
> which the client can read and present to the server.
Unless you know it can never split across the network, you at least want
it to be able to use tcp sockets. That also lets you consider TLS certs
/ crypto as the security story throughout (ie, clients have to present a
client cert before allowed to even set up the TLS tunnel).
> (Later, I want to figure out a good way to handle remote sessions,
> where the client and front-end are on one machine, and the server
> is on a different machine (and the connection between them might be
> or intermittent), as well as shared sessions (multiple users each with
> their own front-ends sharing access to a single remote sessions).
> It seems plausible to use ssh for this. However, for now I just want to
> get local sessions working simply, securely, and reliably.)
I actually have an SSH server implementation done as an lws protocol
plugin. But at the moment it's not FOSS. You can read what I found
about ssh / scp protocol while doing it, plus a little about the
It runs over WIFI on ESP32, so it is very lightweight. But it still
supports 4Kbit RSA keys, curve25519-sha256 key exchange and chacha
In my implementation you can teach the ESP32 your ssh public key over
https, and then ssh into it, or send files to it via scp... the
"terminal" ends is a multistandard, galvanically isolated UART. There's
also a https / js terminal.
> If we use http, I know how to write the server part, but I need to
> figure out how to write the client. It needs to package up a request
> (based on the command line, and also env/pwd), create a GET, send it to
> the server, and wait for a response. Nothing fancy. I can puzzle
> my way through test-server/test-client.c, but it does an awful lot.
> Do you have a simpler example?
A guy on github pointed out this
however this is "simpler" in the sense of removing TLS support and all
comments... I am still thinking about how to balance the "minimal code"
part of the test apps and the "testing stuff" part of the test apps.
I would recommend testing the test client as is (you can point it at,
eg, https://warmcat.com from the commandline which will do the GET) and
then chop out everything not involved in your successful test.
> Any advice otherwise?
Since people will ultimately have authenticated sessions in their
terminals they are likely to be paranoid about security, and it's
difficult to make some value of "secure" after the fact. Especially if
there's some central terminal server scheme potentially with
authenticated sessions to all your boxes it would be the end of
everything if someone malicious could get into it. So I would
definitely think about a strong security story (eg, TLS client certs, or
ssh keys) alongside the basic architecture at the first step.
If you design it for paranoid security by default you can easily relax
aspects of the security for people who don't care. But if it wasn't
really thinking about security from the start adding paranoid security
on top successfully is much harder.
The kind of people most concerned about that will not really trust
browsers (rightly or wrongly) and providing for ssh and being able to
disable browser access would probably go down well.
More information about the Libwebsockets