Add an insecure protocol to world.Export

Page: 1 2
Oct 14 2016, 8:37 pm
In response to MrStonedOne
MrStonedOne wrote:
What they are saying sp. Is rather then do byond:// or http:// just do the IP:port with persist and it should keep it open and not close it, while also sticking to the unencrypted form of the message

Its also encrypted, we had a long chat about it.
What we propose is adding a new protocol, something like byond-unsafe, that when world.Exported it opens an unencrypted channel of communication for use with external applications.
Oct 14 2016, 9:00 pm
Yeah, something definitely changed between when I made my DM <-> Python system years back. I'm guessing we figured out the back and forth needed to make it work at some point and I just blew the details off in the meantime.

A few curious things I found though:

Recompiling the old dmb that worked, made it stop working. The back and forth has been changed since I created it, the reply sent from the Python script is no longer valid to move the process forward.

The process WAS: BYOND sends the packet to the remote server, the remote replies with its own packet that validates and tells the BYOND world it's acceptable, the socket is established and held. If the reply packet doesn't come in a timely manner or it's invalid, the socket is dropped.

I'm guessing at some point between then and now the reply packet needed to validate was changed or the overall process changed.

After a long chat with SP we came to the conclusion that it's probably best not to have the ability to disable the security between BYOND worlds, as it's there for a reason, but to expand on Export().

As it is now, Export() can take byond:// or http:// protocols, which dictate how Export() validates the remote server, http:// is obviously not secured and one-off.

What I suggested to SP to expand on their Feature Request with is a new protocol, that will dictate a new type of connection, it would be unsecure like http:// but allow for persistence like byond://.

world.Export("unsecured://[ip]:[port]?data",1)


Or something along those lines, I'm horrible at naming things.

Since the code already exists on BYOND's end for checking the protocol and differing functionality based on it, this would be the ideal route.

It would require world/Topic() be able to tell whether the incoming packet was from a BYOND world or not, as it stands the Addr argument doesn't include the protocol (never had a reason to), it could either be expanded to include that, or include something unique for non-BYOND packets, or add a new argument to Topic() outright that'd be true for non-BYOND packets.

Seems like that would be the route to take, it would be the easiest for Lummox to deal with, keep compatibility with old code, and provide the developers pure socket connections where they'd be responsible for security.
Oct 14 2016, 9:58 pm
I've updated the OP and topic to reflect the new ideas.
Oct 14 2016, 11:44 pm
I should note, that tobba has already cracked the encryption byond uses, (at least, for client <-> server) and i remember them saying it wasn't hard.
Oct 14 2016, 11:52 pm
It's not really a matter of it being hard or not, it's a matter of providing a way around it without having to actually let the masses know how it's done. That's really the only thing that stops BYOND from dropping the hammer on the people who are smart enough to do these things (violating the 'do not reverse engineer' part of the ToS) is the unspoken 'be smart enough not to tell everyone if you do'.

Somepotato already said he'd have no trouble getting around it, but everyone would prefer if that wasn't required so anything made to utilize it wouldn't have to actively try not to spill the beans.
Oct 15 2016, 12:21 am
Indeed. Its to noones real benefit if something so potentially important is released, BYOND isn't the most secure of platforms and this is one of the few things protecting it (security through obscurity isn't great but when you're a one man team its about all you can afford.)
Oct 15 2016, 1:00 am
Not disclosing the network protocol isn't a courtesy I'd afford a one man team.

Not putting every single exploit i find on a 90 day disclaimer embargo (followed by a post to /r/netsec when they aren't met) is a courtesy (and I do have a few outstanding ones).

I can tell you, that if i had the time or energy to reverse the network encoding I'd sure as hell publicize that, ToS be damned.

If being able to see that causes security issues for byond, maybe they should look at proper encryption, like oh, i don't know, ssl. Or look at closing up the security holes if its something else (like the client getting too much info from the server)

Oct 15 2016, 1:21 am
Yeah, because forcing Lummox to focus on security in a panic that you're going to release things is really an upstanding thing to do.

At the same time you want work done on the engine features, that's a good way to not get that done ever.
Oct 15 2016, 1:30 am
The network protocol being a secret is not something you can rely on, and if it's something byond is relying on, then the sooner byond steps out from that false security blanket, the better.

The fact byond isn't big enough to have 1 black hat security expert attacking it for malicious use only works until it doesn't.

The ToS isn't going to save my server or my players when somebody with the know how decides to start exploiting byond. They aren't going to care.

I'll freely admit that security by obscurity is required in some instances. I know how cids are generated and I know that secret detection metric sticky bans use that evaders don't get around, and I'm not gonna disclose those, but the network protocol isn't one of those necessities.
Oct 15 2016, 1:37 am
It's not really relying on it being secret, it's relying on not having to worry about it urgently. Making the issues known is one thing, forcing Lummox to do something about it is just being an ass.

It's either spend a ton of time worrying about something that could potentially be an issue in the future, or spending that time developing the engine and worrying about the issue when it's not going to eat into time spent on other things. Lummox does have a list, forcing things to the top only forces other things to the bottom.

You're the only person here that's threatening to do any harm.
Oct 16 2016, 5:56 am
The actual "encryption" isn't particularly secret, it's finding the keys that's hard to get info on. I had the "encryption" figured out from reading OpenBYOND code, but I needed a bit of help from Tobba to figure out how the keys were decided on.

Export() with byond:// definitely uses this "encryption", though it's in a different format (0x15 each way for the handshake; client-server handshake is 0x01 each way) and I don't know how the keys are determined.

+1 for an unsecured:// or similar.
Oct 16 2016, 5:57 am
A new protocol like unsecured:// (maybe a shorter name? I dunno) sounds like the best solution here. +1 from me.
Oct 16 2016, 10:22 am
Just on a technical note, such a new protocol wouldn't be done via a URL, since it's a matter of direct connection. Basically what we're talking about here is that users want a way to use something like world.Export() to or from a non-BYOND source. For BYOND using world.Export(), I imagine another argument would be all that was required; coming from a non-BYOND source, they're contacting the server by creating a socket and using the IP and port, handling all the data directly.

To weigh in on the thread, I think something like this is probably a very reasonable idea. I know it'd be very helpful for users maintaining central servers for other purposes. I'm going to put this on my list to look at for 512.
Oct 16 2016, 10:48 am
while adding a unsecured version of Export is useful, This FR really shows the need for a proper socket system accessible to the dev

Especially if we could read data in a binary way, or do things like read as int or read as float.
Oct 16 2016, 11:12 am
In response to Lummox JR
Lummox JR wrote:
Just on a technical note, such a new protocol wouldn't be done via a URL, since it's a matter of direct connection. Basically what we're talking about here is that users want a way to use something like world.Export() to or from a non-BYOND source. For BYOND using world.Export(), I imagine another argument would be all that was required; coming from a non-BYOND source, they're contacting the server by creating a socket and using the IP and port, handling all the data directly.

To weigh in on the thread, I think something like this is probably a very reasonable idea. I know it'd be very helpful for users maintaining central servers for other purposes. I'm going to put this on my list to look at for 512.

Well not necessarily. We could use the other data that world.Export gives and its perhaps quicker to implement than a socket datum. We won't really be able to reliably have binary data reading because of how fickle BYOND is with binary strings (and the special \xFF byte) -- (future BYOND strings to house their length too? hm hm!! more escape codes? the future~)

It is definitely ideal to have a dedicated thing for raw sockets though.
Oct 17 2016, 12:22 am
In response to Nadrew
Nadrew wrote:
I'll get you a test project together next week to demonstrate it, if you haven't figured it out by then.

https://www.youtube.com/watch?v=ypot3CYECwE
Dec 4 2017, 9:05 pm
I'd like to bump this and suggest using the WebSocket protocol, as it's pretty simple and would make this easier to implement on everyone's end.
Page: 1 2