Hello Thomas and Viktor :) This is an interesting subject!
To get more serious about network connections onto leoservers, some https (ssl) could be setup. (Has to be supported by clients optionally to i guess) Also, like Viktor suggested, some user/password authorisation scheme could be implemented relatively easily on the server in the near future. I've opened and issue for that matter : https://github.com/boltex/leointeg/issues/249 to get things started on my end I really appreciate your input and hope to hear more suggestions, or documentations links like the one Thomas provided from you! Thanks! -- Félix On Monday, March 14, 2022 at 9:01:33 AM UTC-4 [email protected] wrote: > 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/f7accc89-fb86-4443-bdb4-74f5253bb1f4n%40googlegroups.com.
