Upstream/SubServers-2
1
0
Fork 0
mirror of https://github.com/ME1312/SubServers-2.git synced 2024-11-28 21:26:01 +01:00
Code Issues Projects Releases Wiki Activity

Updated SubData (markdown)

ME1312 2021-04-10 00:08:48 -04:00
parent 68f6a8ab23
commit 592d9a5e17
1 changed files with 40 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
SubData.md

@ -1,9 +1,43 @@
SubData, in a similar fashion to the [Plugin Messaging Channel (PMC)](https://www.spigotmc.org/wiki/bukkit-bungee-plugin-messaging-channel/), allows for the various components in your SubServers network to communicate with each other. However, unlike the PMC, it doesn't rely on a player's connection to send and receive data. This ultimately makes it a better choice to use if you need to send data which is unrelated to players. SubData, in a similar fashion to the [Plugin Messaging Channel (PMC)](https://www.spigotmc.org/wiki/bukkit-bungee-plugin-messaging-channel/), allows for the various components in your SubServers network to communicate with each other. However, unlike the PMC, it doesn't rely on a player's connection to send and receive data. This ultimately makes it a better choice to use if you need to send data which is unrelated to players.
# SubData 2 # Connecting to SubData
This is the latest edition of SubData. SubServers.Bungee will open port 4391 (by default) so that all the SubServers apps can communicate with each other. SubServers.Bungee opens port 4391 (by default) so that SubServers apps can communicate with each-other. To connect a SubServers app to SubServers.Bungee, open its main config file and enter the address needed to connect. Depending on your encryption type, you may need to take an additional step listed below.
## Usage ## No Encryption
**Encryption:** `None`<br>
**How to Connect:** `No additional action is required`<br>
<br>
This one simply sends the data as-is, with no encryption applied. This is SubData's fastest and most insecure mode.<br>
## AES Encryption
**Encryption:** `AES`, `AES-128`, `AES-192`, `AES-256`<br>
**How to Connect:** `Copy the password field in config.yml to the app you're trying to connect`<br>
<br>
SubData natively supports AES 128, 192, and 256 bit password-based encryption if you need to turn up the security. It does this by turning packets into AES encrypted binary data and sending that instead.<br><br>
For some java installations, AES 192 and/or 256 bit encryption has been disabled. You can download a fix for this [here](http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html). For more information, [click here](https://crypto.stackexchange.com/questions/20524/why-there-are-limitations-on-using-encryption-with-keys-beyond-certain-length).<br>
## RSA/AES Encryption
**Encryption:** `RSA/AES`, `RSA-2048/AES-128`, `RSA-3072/AES-192`, `RSA-4096/AES-256`<br>
**How to Connect:** `Copy subdata.rsa.key to the config folder of the app you're trying to connect`<br>
<br>
So, what's better than some good ol' password-based encryption? How about a system where we login using a signature file, send over a completely randomized password that was encrypted using that signature, and then start encrypting using that randomized password. Yeah, sounds better to me, too.<br><br>
In this mode, each SubData connection uses its own randomized password to AES encrypt and decrypt data after login. Even though you may be sending the same data, no two connections are the same. This can be considered the most secure mode of SubData.<br>
## DHE/AES Encryption
**Encryption:** `DHE/AES`, `DHE-128/AES-128`, `DHE-192/AES-192`, `DHE-256/AES-256`<br>
**How to Connect:** `No additional action is required`<br>
<br>
If you don't feel like fumbling around with passwords and key files just to get some encryption, then this one's for you. By using the Diffie-Hellman Exchange, both ends of the connection can agree on a completely randomized password to encrypt with automatically.<br><br>
As you may have noticed, this mode is similar in nature to `RSA/AES`. The main difference is the lack of key files. What you're giving up on for this ease of use, however, is the simple fact that only *you* have *your* key files. Being keyless, the Diffie-Hellman Exchange doesn't care who's on the other end when negotiating a password.<br>
# Communicating with SubData
SubData has grown beyond SubServers into [its very own project](https://github.com/ME1312/SubData-2). This means that some things, like the API and Protocol Formatting, have been moved to more appropriate locations on [its new wiki](https://github.com/ME1312/SubData-2/wiki). Here are some additional topics you may be interested in: SubData has grown beyond SubServers into [its very own project](https://github.com/ME1312/SubData-2). This means that some things, like the API and Protocol Formatting, have been moved to more appropriate locations on [its new wiki](https://github.com/ME1312/SubData-2/wiki). Here are some additional topics you may be interested in:
> [Sending and Receiving Custom Messages](https://github.com/ME1312/SubData-2/wiki/Usage#working-with-packets-and-messages)<br> > [Sending and Receiving Custom Messages](https://github.com/ME1312/SubData-2/wiki/Usage#working-with-packets-and-messages)<br>
> Working with Multiple Data Channels<br> > Working with Multiple Data Channels<br>
@ -15,35 +49,11 @@ SubData has grown beyond SubServers into [its very own project](https://github.c
SubServers allows multiple SubData channels to be opened from the same source at one time. As a result, the way SubData channels are tracked within SubServers has gotten a little complex. If you're a developer, you may have noticed that when you get the linked client for a server (for example), it now returns an array. SubServers allows multiple SubData channels to be opened from the same source at one time. As a result, the way SubData channels are tracked within SubServers has gotten a little complex. If you're a developer, you may have noticed that when you get the linked client for a server (for example), it now returns an array.
**The Master Channel**<br> **The Master Channel**<br>
The first item in the array `client[0]` is always guaranteed be the master channel; it's id of `0` will never change. The master channel is the initial channel opened by SubServers itself. Additionally, it is always present in the array, even if unavailable. If it does happen to be unavailable it will just simply return a null value, but it shouldn't be that way for long, since SubServers will reconnect this channel automatically. The first item in the array `client[0]` is always guaranteed be the master channel; its id of `0` will never change. The master channel is the initial channel opened by SubServers itself. Additionally, it is always present in the array, even if unavailable. If it does happen to be unavailable it will just simply return a null value, but it shouldn't be that way for long, since SubServers will reconnect this channel automatically.
**SubChannels**<br> **SubChannels**<br>
Everything else in the array is a subchannel. Each subchannel is dynamically registered with a positive id number. However, this can come with it's own set of problems. Everything else in the array is a subchannel. Each subchannel is dynamically registered with a positive id number. However, this can come with its own set of problems.
Let's say we have 2 subchannels connected. If `client[1]` disconnects, this means the next connection to identify itself as a subchannel will get id `1` because that id is no longer in use. However, if you tried to access `client[2]` during the time subchannel `1` was disconnected, you would have been met with an `ArrayIndexOutOfBoundsException` because the position was not the same as the id number. Let's say we have 2 subchannels connected. If `client[1]` disconnects, this means the next connection to identify itself as a subchannel will get id `1` because that id is no longer in use. However, if you tried to access `client[2]` during the time subchannel `1` was disconnected, you would have been met with an `ArrayIndexOutOfBoundsException` because the position was not the same as the id number.
Since this method of tracking is clearly unreliable for use cases other than simple listing and iteration, we recommend for the opener of the channel to keep track of it's own subchannel(s).<br> Since this method of tracking is clearly unreliable for use cases other than simple listing and iteration, we recommend for the opener of the channel to keep track of its own subchannel(s).<br>
## Encryption
SubServers allows SubData packets to be encrypted with the cipher you choose via the configuration. To disable encryption, go to your SubData settings and set `Encryption` to `None`.
### AES
`Encryption`: `AES`, `AES-128`, `AES-192`, `AES-256`<br>
<br>
SubData natively supports AES 128, 192, and 256 bit password-based encryption if you need to turn up the security. It does this by turning those previously mentioned packets into AES encrypted binary data and sending that instead.
For some java installations, AES 192 and/or 256 bit encryption has been disabled. You can download a fix for this [here](http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html). For more information, [click here](https://crypto.stackexchange.com/questions/20524/why-there-are-limitations-on-using-encryption-with-keys-beyond-certain-length).<br>
### RSA + AES
`Encryption`: `RSA/AES`, `RSA-2048/AES-128`, `RSA-3072/AES-192`, `RSA-4096/AES-256`<br>
<br>
So, what's better than some good ol' password-based encryption? How about a system where we login using a signature file, send over a completely randomized password that was encrypted using that signature, and then start encrypting using that randomized password. Yeah, sounds better to me, too.
In this mode, each SubData connection uses it's own randomized password to AES encrypt and decrypt data after login. Even though you may be sending the same data, no two connections are the same. This can be considered the most secure mode of SubData.<br>
### DHE + AES
`Encryption`: `DHE/AES`, `DHE-128/AES-128`, `DHE-192/AES-192`, `DHE-256/AES-256`<br>
<br>
If you don't feel like fumbling around with passwords and key files just to get some encryption, then this one's for you. By using the Diffie-Hellman Exchange, both ends of the connection can agree on a completely randomized password to encrypt with automatically.
As you may have noticed, this mode is similar in nature to `RSA/AES`. The main difference is the lack of key files. What you're giving up on for this ease of use, however, is the simple fact that only *you* have *your* key files. Being keyless, the Diffie-Hellman Exchange doesn't care who's on the other end when negotiating a password.<br>