Jump to content

[1.8.x to 1.12.x] kRPC: Remote Procedure Call Server (v0.5.1, 2nd March 2023)


djungelorm

Recommended Posts

This is the development thread for kRPC.

For discussion of using the plugin, see the release thread

JUYhVrt.png

kRPC allows you to control Kerbal Space Program from scripts running outside of the game, and includes client libraries for many popular languages.

See the release thread for more information and download links

Source code on github (Several licenses including LGPL, GPL and MIT. See here for details)

Documentation

sXYTMJw.png

Edited by djungelorm
v0.5.0
Link to comment
Share on other sites

Ooo nifty. Does it accept only connections from the local machine, or could I run a script on another computer on my LAN (or presumably anywhere on the 'net, if I expose/forward the right port on my firewall)?

Link to comment
Share on other sites

May you provide some information about the security with this plugin? Anything that allows to read data from my computers and fetch them to the outside, can be considered a potential security breach. The big software houses make a lot of efforts to check that their products are secure, and sometimes fail. Now, I am not suggesting you bring this to an independent certified security lab to have it evaluated and classified according to ITSEC/CC. But I would like to know if you took any steps to avoid potential breaches, as e.g. those that may come from a malformed RPC command. There is some literature around the net, about RPC intrinsic insecurity in some situations, but I believe you already know and probably have dealt with those issues.

Link to comment
Share on other sites

Valid concerns! I've updated the default configuration to make it more secure. It now only accepts connections from the local machine, and uses port 50000 by default.

With these settings the outside world shouldn't be able to connect to the server. (I'm not a network security expert, but I'm fairly certain about this!)

Assuming you have a standard home network setup (a router that does NAT to connect to the internet) the outside world will only be able to connect if both of the following are true:

1) your router is configured to "port forward" the port that the server listens on (home routers usually come preconfigured not to do this anyway)

2) the server is configured to accept connections from any IP address

Also, port 50000 is within the range of port numbers used for private/temporary use. If you're really worried, you can change this to anything in the range of 1024-65535 for a bit of security through obscurity :P

Enforcement of these settings for incoming connections (if they do get through the port forwarding on your router) is done using C#'s System.Net.Sockets.TcpListener class. So I'm relying on the security of Microsoft's implementation of the C# libraries rather than any of my code ;)

If you do decide to use it over the wider internet, I don't think doing so is particularly dangerous. All the data received over the connection is passed through this protocol buffers library. If any malformed messages are received, an exception is generated, and the RPC server returns an error message. Although, of course, use it over the internet at your own risk!

Link to comment
Share on other sites

Valid concerns! I've updated the default configuration to make it more secure. It now only accepts connections from the local machine, and uses port 50000 by default.

With these settings the outside world shouldn't be able to connect to the server. (I'm not a network security expert, but I'm fairly certain about this!)

....

Thank you for that. I believe the above is a valid improvement, but even more important is to know what this allows or not (and I am thinking more about users who don't know what computer security really is, and delegate everything to a security suite - if they even do - but then open the floodgates allowing any connection through their firewall). I am sure you will agree, knowing what dangers exist is the most important step with security, as no valid protection can be raised against the unknown.

About NAT, there is some misconception about the protection it offers. The protection comes from the firewall, that with the average home netwrok setup also has NAT service. But NAT doesn't make any filtering, any incoming traffic for a valid port will find the target machine: I don't have to find the correct internal address of that machine in its private network, if the NAT service itself provides a way to get to that machine by calling the router address.

I am no "network" security expert, either. And I actually know much more about other fields of IT than networking (I will never be able to program a RPC handler). But I had, among other tasks, responsibility for overall security of the IT department of a large organization, therefore my instinct to immediately look for possible issues with this kind of tools.

To improve further on this aspect of security, I would ask the following:

1) Is there any authentication mechanism of the client calling the RPC server? In case not, it means that anybody, without effort, will get a valid answer just by sending a call to the correct address:port. It doesn't take much, with a scanner, to find what ports are open on any machine, so if there is no verification mechanism, it takes very little to make a valid connection - without the owner of that machine knowing.

2) Is there any logging of the exchange? So that, at least, it could be possible to find when and how data were moved?

3) Protocols (I may find this by checking through your code, but I'm lazy, sorry). Which ones are used to control and actually make the data transfer, perhaps HTTP? TCP? Each of the above has specific weaknesses that allow unwanted connections to be established. Moreover:

4) Data encryption. Does this use any protocol that include a data-encryption/decryption mechanism? So that nobody else than the client that originated a valid request, can decrypt data (that would otherwise be flowing in clear through the net, for anybody along the way to read).

About the last points, I would consider what Microsoft does for RPC security, as in this page.

Link to comment
Share on other sites

NAT (actually, we are talking about Port Address Translation, but lets keep calling it NAT for simplicity) does offer quite a lot of protection to the common folk. It was invented so multiple clients can use the same external IP. For that, ports have to be dynamically assigned. If you send a web request for lets say port 12345 to google (port 80), another client does the same and google would respond to port 12345 for both requests, your router wouldn't know to what internal IP he should send the data to. Because of that he maps the sending port to some other available port that is reserve for you only and that google can respond to. Any response to that for you reserved port will be forwarded to your PC and port 12345. But your client has to start the communication to the outside to create such a port mapping, otherwise there is no way for your router to know what local client he should send the data to. You cannot really portscan a PC that is behind a NAT (*). And since blocking port is one of the primary things firewalls do (especially older ones), NAT has taken away a lot of their job, especially for security products that are/were targeted to non mobile home PCs.

Also i don't get why you are fixated on security. Yes, with this stuff someone sending commands can do pretty much everything a mod can do, what is basically everything it wants. But this is something people will set up in their home LAN, hell i guess most of the time it will be on the local PC and not go via network at all. Yes, i would highly advise against using something like that via the internet or on a public network / wlan. And yes, authentication, encryption and stuff like that would be good. But is "implementing state of the art security" really what the projects current focus should be? Its good enough to use for someone who kinda knows what he is doing, IMO.

Edited by Faark
Link to comment
Share on other sites

All valid Dio, and who knows what kinds of hacks and vulnerabilities can come up through a game not designed for network traffic as of yet. The encryption thing, we're not talking about banking information, so I'm thinking that putting encryption load is going to be quite the bit overkill considering what you're trying to protect versus the speed of an already overburdened game.

The basic authentication system I could accept would be KSP throwing up something on the screen stating that a particular machine wants to establish a connection and "do" something, which would require at least a basic HELO introduction. Unless this HELO introduction isn't sent within a period of time, the connection is dropped. If the proper introductory statement is sent, KSP asks the player if the connection is valid and desired. If so, accept and do whatever is needed. If not, then close the port. The other thing that could be done is just add a white list of IPs to a text file and only allow connections from those IPs.

Link to comment
Share on other sites

All valid Dio, and who knows what kinds of hacks and vulnerabilities can come up through a game not designed for network traffic as of yet. The encryption thing, we're not talking about banking information, so I'm thinking that putting encryption load is going to be quite the bit overkill considering what you're trying to protect versus the speed of an already overburdened game.

The basic authentication system I could accept would be KSP throwing up something on the screen stating that a particular machine wants to establish a connection and "do" something, which would require at least a basic HELO introduction. Unless this HELO introduction isn't sent within a period of time, the connection is dropped. If the proper introductory statement is sent, KSP asks the player if the connection is valid and desired. If so, accept and do whatever is needed. If not, then close the port. The other thing that could be done is just add a white list of IPs to a text file and only allow connections from those IPs.

I like this way for a basic authentication. That would work.

About encryption, don't think it overburdens anything. Your browser can do it all the time, without you ever noticing. It is just a choice of using an already developed and recognized protocol to establish the connection, and is something done at a level lower than running the application (that burdens CPU and GPU - where really goes the load of runnning KSP). What load may come from encryption/decryption of a few data packets, anyway?

About the motives for data encryption, it is because I can't think security when leaving clear data in the open. It is not something only banks or governmental organizations should be concerned with, either. As most other people here (including, it is evident, someone who doesn't understand security and has no idea of how NAT works, but likes to write on this thread), it may be you are considering that what you have to protect are only a few data about KSP. Not at all. This kRPC plugin has the ability to query KSP for any data it has available. But, KSP is NOT sandboxed (and I really hope you all can understand what it means). KSP has itself the ability to read information from within our machines. Without, theoretically, any limit. It is only KSP, then, to limit what are the data that can be retrieved; but nobody can see (as the KSP sourcecode is not public) what it really can do. So, allowing a non-secure connection via KSP and kRPC, is potentially giving away whatever you may have on that machine you are running KSP on. Oh, don't think anybody would ask kRPC to provide your passwords directly. But when KSP can find and retrieve files in your machine, and kRPC can transmit them to the outside, it is just a minor step for anybody to ask for *that* systemfile that holds users credentials. And the next step, that file may be updated with a new account... (this is just one of several possibilities)

Link to comment
Share on other sites

@ Faark. What you wrote is fine only when thinking about the usual way to establish a connection. I thought to have written (but was probably on the previous post) that you may start the connection otherwise, using a well recognized port. Start there, get an answer, modify the address:port and resend the query, then see. If there is a port open listening...(exactly what an RPC server does. A server does not initiate a call, it answers that).

So, in case still that isn't clear: when you start a server on your machine, you want to allow it to establish connections with clients calling from the outside. So it is the server itself wanting to open a port , and even if address:port are scrambled by NAT, there will be one port open and valid that allows incoming connections. Your NAT will not filter such connections (it will be the firewall, if so instructed), but instead will translate for the correct machine and port in your private network to be reached.

Portscanning is often inhibited by a firewall (absolutely not by NAT), but then it depends on how the firewall rules are set, and you can't say it won't work altogether if not on your own installment (where you are in control of that firewall).

Edited by diomedea
Link to comment
Share on other sites

i think most network hardware these days has hardware encryption built in. no need to do it in software or put any burden on the cpu. your firewall will likely prompt you to set up rules for a new connection as soon as its detected. its pretty much the same for any network enabled application. if you want to leave your local network, you will likely need to set up your router to do that. im not really that concerned, my network fu is strong (and i have an degree in that field).

Link to comment
Share on other sites

i think most network hardware these days has hardware encryption built in. no need to do it in software or put any burden on the cpu. your firewall will likely prompt you to set up rules for a new connection as soon as its detected. its pretty much the same for any network enabled application. if you want to leave your local network, you will likely need to set up your router to do that. im not really that concerned, my network fu is strong (and i have an degree in that field).

That above is exactly my understanding. Thanks for confirming, data encryption nowadays does not put any burden on the CPU, it is all done by the firmware behind the Ethernet port (that everybody already has). Or, by other highly sophisticathed encryption devices used in secured networks.

And yes, you are right also about the firewall and router, one needs to set up rules to allow new connections (unless somebody has actually turned all filtering off). If anybody wants to use kRPC only within his network, before the external firewall/router, that would not be a problem. The problem comes from the prospect that kRPC will allow to connect via Internet, and people already planning to actually do that. Therefore, going to set those rules allowing such connections through their router.

Link to comment
Share on other sites

So, in case still that isn't clear: when you start a server on your machine, you want to allow it to establish connections with clients calling from the outside. So it is the server itself wanting to open a port , and even if address:port are scrambled by NAT, there will be one port open and valid that allows incoming connections. Your NAT will not filter such connections (it will be the firewall, if so instructed), but instead will translate for the correct machine and port in your private network to be reached.

... which it cannot do, unless the client inside your private network initiated the connection. If the connection is coming from the outside, with no information about which internal IP address it wants to connect to, there's no way for the NAT device to figure out which of the possibly many machines on the internal network you want to connect to. NAT does filter such connections, not as a matter of security, but simply by virtue of the fact that it cannot resolve them if you haven't explicitly provided the NAT with information on how to route them. Without port forwarding explicitly enabled, NAT cannot do what you appear to be claiming it will do above.

Link to comment
Share on other sites

About the motives for data encryption, it is because I can't think security when leaving clear data in the open. It is not something only banks or governmental organizations should be concerned with, either. As most other people here (including, it is evident, someone who doesn't understand security and has no idea of how NAT works, but likes to write on this thread), it may be you are considering that what you have to protect are only a few data about KSP. Not at all. This kRPC plugin has the ability to query KSP for any data it has available. But, KSP is NOT sandboxed (and I really hope you all can understand what it means). KSP has itself the ability to read information from within our machines. Without, theoretically, any limit. It is only KSP, then, to limit what are the data that can be retrieved; but nobody can see (as the KSP sourcecode is not public) what it really can do. So, allowing a non-secure connection via KSP and kRPC, is potentially giving away whatever you may have on that machine you are running KSP on. Oh, don't think anybody would ask kRPC to provide your passwords directly. But when KSP can find and retrieve files in your machine, and kRPC can transmit them to the outside, it is just a minor step for anybody to ask for *that* systemfile that holds users credentials. And the next step, that file may be updated with a new account... (this is just one of several possibilities)

TL;DR: You're looking at the wrong end of the telescope for system security. Encryption isn't going to solve the payload problem.

TL;DR#2: Default to listening on the LOCALHOST/127.0.0.1 interface only. ZERO physical network activity will happen.

Full-on text, and its one hell of a wall:

The thing is, once the connection is made, via encryption or not, you're in. Once you're passed my proposed HELO, you're in. Beyond that, you're at the mercy of whatever can be done, desired or undesired, based on what SQUAD has permitted the application to do TO or WITH the filesystem, or what the mod is permitted to do. I know sandboxing, I know encapsulation, I know user virtualization, I know home directory isolation, and I know a few other techniques of hiding and protecting information, but none of that has *ANYTHING* to do with encryption (Well, you can encrypt files at the platter level, but we're not talking that here). Encryption has NOTHING to do with what the contents of the payload is. Encryption CAN defer things like "Man in the middle" or whatever, but, beyond that, once a valid connection is made, you're at the mercy of what is being communicated, and what the communication is between the two end points are is entirely subject to what the software handling the eventual unencrypted communication can do, again desired or undesired. That encrypted information has to be decrypted for the program to do something valuable, which is what the payload is. Basically, if I've somehow allowed myself to get onto your computer, via encrypted methods or not, "yer skrewed", and I can do whatever I want within the confines of what the software and OS is going to let me do, exploits or not. Is sandboxing going to help? Yeah, of course. Whatever the software is asking the OS to do is going to be accepted or denied based on what the contents of the sandbox has or allows, but, it this isn't encryption. Does KSP act as a sandbox? Nope, but encryption has nothing to do with that either.

Looking at this from a coders point of view, and this gives me the biggest knot in my stomach (And no its not the Tuna), with encryption turned on, now every future tool out there has to start laying down their own security models within their application which is going to become a burden on the developer, both for this mod and me who wants to turn his tablet into a flight tracking device, a MechJeb controller, or a web interface, etc. Crap-tonnes of code out there to get it done in whatever language you want, but its an extra layer of complication and additional requirements that need to be supported, and for those that want the simple stuff (Me being one of them), this is just way over the top. The encryption is going to do well to hide the in-transit package details from point A to point B at the communication layer (Specifically layers 1-4 of the OSI model), and no one is going to be able to sniff up (with ease anyways) what you're two end points are talking about, but once the application gets the information decrypted, and starts ACTING on it, communication back for whatever the payload is requesting is STILL going to be encrypted on its way back to the origin, with whatever information was supposed to go back. Is unencrypted information between two devices a private affair? Depends on your network setup, first off. With a network hub, absolutely not. EVERY packet is broadcast to EVERY port on the device. Network Switch? Depends, but probably not, and it depends on how many switches you have between point A and B. I have two GigE switches between my main desktop and my router, three between my main rig and wifes machines on another level in the house, and four switches between my rig and the kids machine[1].

As for the browser thing, yeah, it does it all the time, but not as quickly as you'd think. Any data being transmitted from, say, your bank site, is only a few hundred kilobytes of information at most. MAYBE a megabyte if you're looking at a years worth of transactions. The point is, you as the user, see the data show up "relatively" quickly. But I'd bet my last dollar that sitting on that servers LAN with browsing my 20+year bank history, comparing speed differences between the HTTP protocol and HTTPS, HTTP would be easily 25-50% faster.) But what happens is, your computer does its handshake and dance (CPU time) and encrypts the request. The request is sent down through the OSI levels, out the pipe to your provider, out to the net, out to your bank site, to which then the bank server has to decrypt that information based on another key. (Lets not forget that some points between you and the bank re-encrypt your encrypted data, so more CPU time, but, not included in my thoughts since its out of this mods control). So more handshakes and dances (More CPU time) is spent handling the encrypted data before the request can be worked on. The decrypted request gets completed, yet ANOTHER dance happens (More CPU time) to encrypt the data, which is then transmitted and sent down the wire, then decrypted (More CPU time) to get the job done.

My big issue is on the CPU side of things. Encryption HAS come a long way, and HAS become more efficient. The biggest issue I've got is that in an already overburdened single-threaded game that deals with physics, graphics, and other processing, you're introducing just another thing to be handled, but instead of a short blurb of a request and answer session, you're now potentially STREAMING this encrypted data back and forth, and depending on the events, every physics iteration, or screen refresh, or if you're going to get smart, delay the transaction for a few frames or a full second or whatever. This, of course, depends entirely on what the application in question is supposed to do with what KSP is providing the outside device. We also shouldn't forget that people are playing this game on low end machines and barely surviving as is. Myself, I've got a quad-core (8-thread) first get i7 (960) with a 12gig of DDR3, and running my OS off of a pair of 256meg SATA-3 SSD drives in RAID-0 and a GTX570 running along side a GTX8800 as a secondary card for my quad-monitor setup. My system is not a slouch, but there are times this game already burdened with my near 700 part station. If I start throwing a lot of data at compression algos, I might as well just down the station and do something else.

I'm no where *NEAR* saying that encryption isn't important. It absolutely, without a question, has its place. I'm just very against taxing the game for something that has little benefit. Considering that I doubt anyone is going to open up their router to play KSP on a machine remotely via a web interface without being able to keep score on how many Kerbals got killed, or, can't see what is on the screen, etc. I feel that this kind of mod is going to rely purely on a LAN style of configuration instead of an internet based configuration.

That all said, there ARE OPTIONS. Move the encrypting calculations somewhere else. Another CPU thread, another machine, a router, or whatever. Keep it out of the mod. If you're hard set on external connections, get a VPN going. You remove encryption calculations from the mod and your system. The external device/software will still need to do the proper calculations if running on the same machine, BUT, it isn't in the game causing speed issues.

---

*1

- I have an insane network setup. Literally two wireless routers (One wireless disabled due to old speed) and an access point. My machine plugs directly into a 5-port wired switch, which then connects to another switch which sits about 10 feet away from my router/server. The switch from my desk to the second switch is about 15 feet away. The second switch is an 8-port GigE with a few broken ports due to storms. From the second switch, I run a very long wire up to the wifes office which hooks into another GigE switch (8 port) which then feeds her 2 computers, as well as a line out to the living room to a 5 port switch which feeds my PS3, TV, and Wii. From the wifes 8-port switch, I feed the first wireless router (Demoted to a switch) and it acts as an access point for the living room and upstairs bedrooms, as well as wires to two network printers. From the same wired network switch in the wifes room, I run yet another long wire into the kitchen into a 5-port switch, which feeds the kids computer and a notebook that is being used as a "home resource center". The last access point that allows us to use our phones, tablets, and notebooks (Yes, all plural) out on our front yard. All this said, from my basement computer, I won't see traffic from my kids machine on the switch on my desk while they watch YouTube. So I cannot sniff their traffic unless I'm between the router and the switch directly connected.

[[after staring at this for about 3 hours (I'm at work) I give up on this wall. ;) ]]

Link to comment
Share on other sites

Just to add, if encryption is desired for the connection for some reason, this can be done at the firewall level via VPN or something similar. This particular library/mod itself is precisely the wrong place to attempt to implement encryption. Insofar as it is desirable, it should be done on a different level, and where it is desirable, having it properly at the level it should be and in this library too would be taxing and overkill -- right idea, but wrong place for it. Not every single library should attempt to solve every security issue on its own -- that's precisely the kind of piecemeal approach that leads to bugs that cause security breaches, as every program relies on its own possibly buggy ad hoc methods, rather than having a specific purpose-built library or piece of hardware doing the one job its designed to do well.

Edited by Gaius
Link to comment
Share on other sites

... which it cannot do, unless the client inside your private network initiated the connection. If the connection is coming from the outside, with no information about which internal IP address it wants to connect to, there's no way for the NAT device to figure out which of the possibly many machines on the internal network you want to connect to. NAT does filter such connections, not as a matter of security, but simply by virtue of the fact that it cannot resolve them if you haven't explicitly provided the NAT with information on how to route them. Without port forwarding explicitly enabled, NAT cannot do what you appear to be claiming it will do above.

Look, you are right, in that NAT can't resolve the internal address for a generic connection (then it is seen as filtering, though it is a very different thing).

But the issue here is, if this kRPC works across the internet (as it is stated in the OP) it has to establish a port and listen there. And, for it to work, that port will be translated by NAT into another, valid port, at the router level. The outside client will not have to look for the specific machine at all, the internal IP address is not its business. It will ask for a connection with the router, and then that connection is internally routed to the correct machine. That, or the whole client-server model won't work anymore.

Also, about the encryption. Sorry if, because of other discussions on this, it has gone out of where I actually suggested. But if you check back, I suggested to use an already existent protocol to allow for encryption. And, a protocol that is very widely used. Not that this application should directly deal with encryption itself.

Link to comment
Share on other sites

@ Pontiac.

Your post is really too long, sorry you had to write all that. There is one flaw that inficiates how you start: thinking encryption has no value cause one may establish a connection. The very first of my proposals was about authentication of the client. Security without that is null.

About the rest, you put a lot of very valuable concepts. Very long read, will try to when I have time.

Link to comment
Share on other sites

this thing is all in the application layer of the osi model. encryption and most of the other security features you need are usually handled further down.

http://en.wikipedia.org/wiki/Osi_model

Be sure, I know about ISO/OSI.

But again, this all started with a set of questions, all of them connected, about how security would be managed. Others have pointed to specific aspects, but looking at those in isolation, the whole issue was lost (though, on themselves, the specific issues like validity of encryption or firewalling rules they have considered have a lot of importance). One question of mine was about the set of protocols this application was to use, but that doesn't mean it has to handle them directly. Rather, it was to mean what were those that would support it (I even hinted at the possibility some were TCP/HTTP, but as you certainly know, there are other possibilities, and some are better then others). Though the protocols stack is handled by the system, it is in the end the application to make the call for the system to provide a service through those protocols. Hope to have made my intention a bit more clear, sorry if it wasn't before (or if it still is).

Link to comment
Share on other sites

@ Pontiac.

Your post is really too long, sorry you had to write all that. There is one flaw that inficiates how you start: thinking encryption has no value cause one may establish a connection. The very first of my proposals was about authentication of the client. Security without that is null.

About the rest, you put a lot of very valuable concepts. Very long read, will try to when I have time.

Meh. Don't be sorry. I put off a few customers to write that. Wuz fun. ;)

Look forward to reading your reply, or, if the OP wants to boot this, we could possibly move the convo over to another forum.

Link to comment
Share on other sites

Meh. Don't be sorry. I put off a few customers to write that. Wuz fun. ;)

Look forward to reading your reply, or, if the OP wants to boot this, we could possibly move the convo over to another forum.

Pontiac, it was a very good read. Interesting setup you have at home. Not going here to give details on mine, as my posts have already derailed this thread too much.

On the important points, I can confirm the first impression I had. There was that start about thinking encryption on itself (if that was the case, I would totally agree), but hope to have made clear encryption was only the last of four questions about security - the first and most important the client authentication, that I believe is exactly what you also were considering. Those concepts you show about what may happen once an unauthorized client got access are exactly what I was meaning on other posts (but it seems others did not want to believe). I wrote kRPC may allow to send out any data that KSP has access to, and that is exactly the same concept from you.

You make a point about the complication security will add to plugin makers. Sure it will, I am not denying. But, there are plugins inherently more secure than others. I really love a lot of those, and feel secure (though I am obsessed with security). Fact is, no plugin to KSP (or any other) can establish a connection if I deny it. I have only two that actually want to connect to the outside world, and both I have checked the sourcecode, and compiled them myself. I check everything for malware behaviour, but then it is enough. So, I don't ask, nor want, other plugins to deal with these complications of security. What is different here, is this application will actually open a port to the outside with the promise to deliver any data from KSP. So, this is a very different business. I can't check what kind of data it will deliver looking at its code (as that is in KSP realm), so I am left with the only option of using security measures. That, I strongly believe, I quite know about, therefore I am suggesting. I may even leave it as is, as I don't really need kRPC. And nobody, who only wants to run kRPC on its internal and well protected network (!), will need all of that added security, either. But other users should at least know what may happen (and you provided very good explanation about) when they think about internet connections thanks to RPC (and I already saw a few jumping for that possibility). After all, what I learned and teached, the first and foremost security dangers come not from technological shortcomings, but human behaviour (both admin and users).

Another point of yours is about speed. Certainly, data encryption makes for slower connections (I was at a time in a project about very fast cryptologic machines, then to be used for overall protection of a very large extranet, so I have an idea of what you mean). And again, on the technical side, I concur with you. But there are two or three concepts here I have to make:

- data encryption is not a burden for the CPU; it is noticeable slower but at a lower level, that the system delegates to (as I understand) the firmware on the Ethernet port (or, to other firmware on encryption modules, if you use those on your machine). So, KSP will not experience framerate losses as both CPU and GPU will keep going only about their usual business.

- It is the remote client (asking for KSP data) that will feel a slower connection and reduced data rate, but here we have not even begun to consider amount and frequency of the data needed to run anything on the client side. Not really the business of kRPC, in my view.

- even if it was the CPU to directly handle encryption, it would do in a different thread than KSP. My KSP machine is pretty good (pretty on par with yours), but when KSP really chokes, it is only at 25% load (the biggest load is with the GPU, but still very much lower than max). The problem is with KSP, of course, and multithreading, so that not all the resources of my CPU are used. Unless of some very inappropriate load-sharing method (that system should actually optimize), I can't see why KSP and data encryption would hurt each other.

Then, you recommend to avoid burdening the mod with data encryption. And I concur, because what I want is for this mod to use (if that is the choice) data encryption provided by the system. This mod will only have to use the correct calls (something I saw is available, according to some Microsoft papers) and data encryption will be in.

Link to comment
Share on other sites

I've made a bunch of changes to the protocol and updated the OP with details.

@Pontiac Love the HELO message idea. And phew what a long post! Will have a read tomorrow.

@diomedea to answer your questions from post #7:

1) Before tonight, there wasn't any client authentication (see updated OP for details)

2) Requests and client connections (along with IP addresses) are logged (although the content of the messages are not). Incorrect HELO messages are also logged.

3) It uses raw TCP streams for communication.

4) Nope, no encryption yet! Although if people want to use this over a network where security matters - then I'll look into including an SSL layer or similar.

I've added a little summary of how the protocol works to the OP which hopefully makes it clear what the server is up to.

The main use case I had in mind for the plugin was for use just on the local machine. However, TCP sockets happened to be the simplest cross-platform and language-agnostic way of doing interprocess communication - but appear to have opened a can of worms! Ideally (for local use) it should use something like unix pipes (for performance reasons as well as security!) although I'm not sure what the Windows equivalent would be. Anyone know?

Edited by djungelorm
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...