Thanks for the helpful thoughts, @viktor. Here is a StackOverFlow page I found that seems useful for getting wss working in Python:
How to create Python secure websocket client request? <https://stackoverflow.com/questions/46852066/how-to-create-python-secure-websocket-client-request> I'd forgotten about the need to generate a self-signed certificate. I've only done that a few times, using java tools IIRC. It was a pain, and learning what to do was even more so. For use on a (my) my LAN, I don't think I want to get into authentication. I suppose that if one were ever going to allow communications from outside the LAN that would be a different story. If the ws(s) server is able to discover the IP address of a request, it could be configured to disallow any connections apart from specific ones. That would probably be a good move. Or one could just leave that to the system firewall. On Monday, March 14, 2022 at 1:14:02 AM UTC-4 [email protected] wrote: > Hello Thomas, > > [email protected] schrieb am Samstag, 12. März 2022 um 23:00:34 UTC+1: > >> Since we are looking at getting Leo to work with files on a remote >> computer, we should discuss the security aspect. I think there are >> basically two kinds of things we'd like to prevent. My terminology here is >> that the "host" computer is the one that contains a Leo file that we'd like >> to work on in an instance of Leo running on a different computer; The >> "remote" computer is the one where we want to be able have Leo open that >> host file. >> >> 1) Exfiltration of arbitrary files from the host computer. We don't want >> someone to use our host's leoserver to retrieve any arbitrary file by >> pretending to be a remote Leo instance. >> >> 2) Replacement or corruption of arbitrary files - or even just Leo files >> - on the host computer. >> >> Now, I realize that I've been picturing this remote usage as being >> entirely within the local LAN, and even then you'd have to get the firewall >> on the host machine to let our webchannel connections through. Even so, I >> think we should be thinking about the issues. >> > > Definitely it should be done now / in parallel - and - not as an > afterthought. > > >> >> I don't have a general solution to suggest here. And I don't know much >> about how the Windows firewall can be configured (not for Linux, either, >> but I think at least there one can do almost anything). But here are some >> measures that could be done, probably for not too much effort: >> >> a. Get the firewall to only allow connections from the one specific >> IP:port combination you want to use for the remote computer; >> b. Have leoserver only send and receive Leo outlines; >> b1. Have leoserver validate that a file really is a proper Leo file; >> c. Have leoserver only save files from the remote that it had previously >> sent to the remote. >> d. Have leoserver only send and receive files that have been specified in >> a config file. >> > > I think those are the bare minimal measures to get the implementation > started - and - are needed as soon as leo-client 'leaves' localhost in real > life usage. > > I believe that transport layer security (e.g. support & usage of wss:// > instead of only ws://) - as well as - proper authentication (e.g. login (w/ > 2FA?)) should be taken into account as well. > > IMO both authentication & encryption should be made available, at least as > opt-in extensions, for the leo-server environment on the host machine. > > >> Yes, it's true, someone could modify the leoserver python file to get >> around these kinds of restrictions. But to do that, they would have to >> have local access already, and if that is the case they would already be >> able to drop or retrieve any files they want anywhere on the machine. So I >> don't think we need to worry much about this particular possibility. >> > > Agreed. > > Looking forward to hear what Edward & Felix think about this topic. > > With kind regards, > > Viktor > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/5c1b25b6-d440-4c4f-8396-6ba2f34c4ee0n%40googlegroups.com.
