Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[PeridexisErrant]

Does the protocol support any sort of authentication / encryption? If it's going to be facing the internet, it really should; maybe using TLS or DTLS. (I don't really know security, but I know you're not supposed to do it yourself )

Currently there's not any, but there will definitely be some authentication. Not sure about any sophisticated encryption - you're not transmitting any sensitive data in game after all. On the other hand, with appropriate modifications, the commands that comprise the protocol can be transmitted over any network protocol.

Encryption is important - it's for:
1. Authentication - important for all packets, not just login,
2. Avoiding man-in-the-middle attacks (ie forged messages),
3. Ensuring your traffic doesn't get hijacked to eg. DDoS someone, and
4. Keeping the messages secret
5. Defeating basic traffic analysis (if you only encrypt secret stuff, and I see you encrypt something...)

Obviously #4 isn't that important here, but given how easy it is to default to good security - just run the protocol over SSL - it's absolutely worth doing.

[Rose]

Also DFHack gives direct memory access to your computer, so it's a pretty big security hole. That's why the default RPC protocol doesn't allow outside connections.

[mifki]

Does the protocol support any sort of authentication / encryption? If it's going to be facing the internet, it really should; maybe using TLS or DTLS. (I don't really know security, but I know you're not supposed to do it yourself )

Currently there's not any, but there will definitely be some authentication. Not sure about any sophisticated encryption - you're not transmitting any sensitive data in game after all. On the other hand, with appropriate modifications, the commands that comprise the protocol can be transmitted over any network protocol.

Encryption is important - it's for:
1. Authentication - important for all packets, not just login,
2. Avoiding man-in-the-middle attacks (ie forged messages),
3. Ensuring your traffic doesn't get hijacked to eg. DDoS someone, and
4. Keeping the messages secret
5. Defeating basic traffic analysis (if you only encrypt secret stuff, and I see you encrypt something...)

Obviously #4 isn't that important here, but given how easy it is to default to good security - just run the protocol over SSL - it's absolutely worth doing.

1. Authentication can be done without encryption
2. Attacks on what? Someone with enough access to perform MiTM will attack your fortress?
3. How?

No, I'm not against encryption, I'm just saying that currently it doesn't have it because there's higher priority stuff. Also, it's not a simple HTTP or something that I can just "run over SSL" with one line of code. On the other hand, I'll consider adding a simple cipher like XTEA. The problem here is that individual messages are very short, while cipher operates on larger input blocks. I can pad data with zeroes but probably this will reduce security, I don't know.

Also DFHack gives direct memory access to your computer, so it's a pretty big security hole. That's why the default RPC protocol doesn't allow outside connections.

Again, this thing does NOT allow to perform arbitrary dfhack/lua commands.
And surely dfhack has access to df process only.

[Kazimuth]

No, I'm not against encryption, I'm just saying that currently it doesn't have it because there's higher priority stuff.

That seems entirely reasonable, given what a big project this is.

Also, it's not a simple HTTP or something that I can just "run over SSL" with one line of code. On the other hand, I'll consider adding a simple cipher like XTEA. The problem here is that individual messages are very short, while cipher operates on larger input blocks. I can pad data with zeroes but probably this will reduce security, I don't know.

LibreSSL actually provides a pretty simple library for using TLS with arbitrary buffers. I haven't actually used it though, so I don't know if it's easy to use.

Again, this thing does NOT allow to perform arbitrary dfhack/lua commands.
And surely dfhack has access to df process only.

Well, it also has access to the filesystem / the ability to run subprocesses. But if the protocol can't access those then things should be fine, barring fancy attacks.

The main reason I was asking about encryption was that people might run public servers, and they don't want to paint targets on themselves saying "use me for bitcoin mining!" But if the set of commands is limited to ingame DF stuff, that shouldn't really be a problem.

Seriously, though, keep up the good work - this project is great

[mifki]

That's it, send me a message with your email address who wants to test the app as it is now (likely not right now, but as soon as I'm ready). You need to have iPhone 5 or later with iOS 8, ideally. 4S will work but couple screens will not fit properly. iPad is OK, but UI elements size and location not optimised for big screens. Probably can support iOS 7 if there will be high demand.

Obviously you'll need a computer to which you will be able to connect - depending on your ISP, your home computer may or may not be accessible from outside (which doesn't prevent from playing on a couch of course). Some NAT configurations are supported but we'll deal with this and required configuration in each case individually.

Just so that you don't expect it to be fully playable, major things still missing: military screen (while squads menu is implemented), workshop profiles, stockpile-workshop links, health overview screen, justice-related stuff, stocks screen, civilizations screen, points/routes/notes, burrows, hauling, world creation/starting a new game, some building actions, nobles requirements/demands/mandates.

[PeridexisErrant]

As exciting as all the recent work is (ie "very exciting"), can I get a lot more detail on this?

Because it looks like the client can trigger a remote download and installation of some software, which is not something I can put in the Starter Pack.  Maybe an incompatibility message, and a chance to visit a link to the updated plugin or email it to yourself?

[mifki]

As exciting as all the recent work is (ie "very exciting"), can I get a lot more detail on this?

Because it looks like the client can trigger a remote download and installation of some software, which is not something I can put in the Starter Pack.  Maybe an incompatibility message, and a chance to visit a link to the updated plugin or email it to yourself?

Unlike the recent discussion about protocol encryption, where I was unsure, these updates are of course signed with an asymmetric key. Of course, you may not trust what I put in the update, but downloading it manually from the same server doesn't change much here.

The reason I believe this is an important feature is that there is a client application that may get updated intentionally by the user, inadvertently, or even automatically. Of course, not every app update will require a server-side update, but if it does, and the user can't update the server at the same time, it won't be good. Automatic updates allow for unattended server installations - install once and forget.

Anyway, if the updater is not installed or disabled or didn't work, it will show manual update instructions.

[PeridexisErrant]

Unlike the recent discussion about protocol encryption, where I was unsure, these updates are of course signed with an asymmetric key. Of course, you may not trust what I put in the update, but downloading it manually from the same server doesn't change much here.

The reason I believe this is an important feature is that there is a client application that may get updated intentionally by the user, inadvertently, or even automatically. Of course, not every app update will require a server-side update, but if it does, and the user can't update the server at the same time, it won't be good. Automatic updates allow for unattended server installations - install once and forget.

Anyway, if the updater is not installed or disabled or didn't work, it will show manual update instructions.

That all sounds good.  I agree on download trust; if someone doesn't want a signed executable built from public source, they shouldn't be using the software at all.  The unattended server argument also makes sense.

At the same time, I also anticipate more local uses such as for Armok Vision or other same-desktop uses, where users may want to freeze on a known-working combination of versions.  Or just avoid autoupdates in general for whatever reason.

It seems to me that an elegant way to do this would be to have a very simple plugin dedicated to updating the main protocol server, which does not run automatically (or a command for the main plugin; it's the interface that matters here).  Those wishing to enable the updater can call it from dfhack.init - or from the console at a time they want to check for updates - and those who don't can simply avoid calling it. 

[mifki]

Yeah, there are options...

Currently I don't know how this will work for other projects at all. I mean, I'll most likely work on the iOS app only and so I'm focused on providing a smooth experience for app users, including the scenario of the app update mentioned before. Also, the protocol (set of commands) is currently tailored for the app needs. Other projects using the server, if any, may require significant modifications, and maybe will just use a separate plugin based on this, that will naturally be untouched by the update mechanism.

[Rose]

Yeah, I'm not currently planning on using the server for Armok Vision, besides just seing how you do things, since the needs are likely quite different, plus I'd rather just have control over it.

[mifki]

Yeah, I'm not currently planning on using the server for Armok Vision, besides just seing how you do things, since the needs are likely quite different, plus I'd rather just have control over it.

But are you planning on developing AV into a complete interface for DF at all?

[Rose]

Yes, though development is slightly slowed because I no longer have a videocard that can handle it easily.

Not sure how I'll do it, but I do want to do it.

[mifki]

Yes, though development is slightly slowed because I no longer have a videocard that can handle it easily.

Not sure how I'll do it, but I do want to do it.

I was thinking about employing one of the gaming frameworks for my project to make it easier to port to other platforms, but none of them (including Unity, as I understand) provide a decent set of easily usable UI controls - and there's a lot of screens in DF to implement.

Hm, but if AV is just a Unity project, it should be possible to build it for iOS and embed into an existing app. What if we....

[Rose]

It would not work well on ios as it is, at least without huge modifications to it, because it uses huge amounts of ram and GPU.

[mifki]

Dashed are not yet implemented.