I'm a real n00b when it comes to programing, just know the basics in HTML5, PHP, Java, jQuery, Python and Ruby. I have an idea that I would like to try, but i don't know where to begin so here is one thing I could not find an good answer for. I'm also not that great when it comes to explaining stuff and my english is not the best.
I've been looking for a way to send encrypted data between servers, like links if you will, that enables the user of one server to view a specific file from another server without downloading it, using a web interface.
E.g. if the user of server 1 uploads a picure, then server 2 automatically gets a "link" to that picture so the user of server 2 can view the picture using a web interface. Thus only the two users can see the picture even if there are more servers that can connect to server 1.
I've been thinking the best way to make that happen is to use Python or Ruby on both servers, but i can't figure out where to begin. Should i create a back-end program that handles the encryption and whos servers should get the link? The easiest way to setup the servers would then be to install the same program on all servers and adding the other servers to a list?
I also want the code to be open source so anyone can use the same server setup and access the other servers that it have access to thrugh the "links".
So, is this posible?
I apologize if this is the wrong forum, I'm new to hanging out on forums, and for the confusing explanation of my question.
Best regards and keep up the Tek awesomeness! / tInc
FTPS? Something to look at, but that's more a server to client setup.
You could use something simple such as a password secured index system that's accessed through HTTPS. The password portion makes sure that only authenticated clients can connect and see the correct index. Again though a very much server-client setup.
Unless you use a pre-shared key to encrypt data between servers and send automated index updates when a new file is added. So rather than checking a new file is available, it is told a new file is available.
Some brief ideas, give me sometime and I might come up with something better.
Yeah, I've seen some server-client solutions and in a way I'd like for the servers to be both servers and clients. One possibility would be to have the servers act like a client when reciving the data from another server but it may be better to make the server encrypt the data and than send to the other server that is in a "reciver list" and the reciving server can only decrypt the data using a pre-shared key, possibly stored in a "incoming list" so that the reciving server could add the content on its web interface?
Also, the file itself should not be copied to another server just a "link" to the file to keep the amount of data traffic down.
In this case, how secure would the transfer be? If I have https from the webinterface to the server and encrypted data between the servers.
Also, the file itself should not be copied to another server just a "link" to the file to keep the amount of data traffic down.
That's what I mean by an index file. Not the file itself, just info on the file. Eg. Name, Size, location etc.
Using HTTPS, the initial connection (establishment of connection) is the only time data is not encrypted. Anything after that the data is encrypted, but the sender and receiver are still known. (For obvious routing purposes) If you are sending an encrypted file within an encrypted tunnel, its going to require someone to be actively watching for a transfer to snipe the HTTPS encryption key and then they are left with an encrypted file. Which depending on the level of tin foil hat, could be a stupidly long and complex encryption key. (Think of the HTTPS as a deterrent and the encrypted data as the real protection.)
As long as the pre-shared keys never get transferred through an un-encrypted form, or if they are transferred via offline means and then kept secure from possible intruders. I imagine the system will be pretty secure.
You could further enhance encryption by using a rotating encryption key (one that changes after a set time to another key) and also making sure each server uses a separate key so that if one is compromised, the whole lot is not. Obviously to get a proof of concept off of the ground, I'd stick to a single key just to prevent development being too complex early on.
Oh, of course... I didn't get that becauce it was way late and I had a bit of brain-meltdown. Thank you for being patient with me, and for all the good tips!
I have a way to generate a pre-shared key on defferent servers without sending data... should be secure enough for starters, there is always the possibility to add a rotating encryption key later. And use HTTPS for the connection between client/server and server/server with different pre-shared keys to make it a bit more secure?
What programming language would be easiest to use to generate a database that stores the encryption keys? Is PHP a good choise?
Well using HTTPS should be fine, providing its kept up to data. Also providing its not using the OpenSSL library of a certain version. LINK
I think seeing as this is a web based application of sorts. Something like PHP maybe best. For databases, you could use SQL, although that does open up some other possible security issues. I'd have a look around, work with something you know or it might be beneficial to learn something that you think could be better.
Yeah, that heartbleed made me put on an extra layer on my tinfoil-hat...
Encrypt the data using PHP, then place in a encrypted SQL or similar database using Python and transmit the data between servers using HTTPS? That would be like sending an encrypted encryption of the encrypted index-file so the weak point would be on the user end and/or layout of the servers. 3¹²⁸-bits encryption on the server and only requires 128-bit to be transmitted... the sent data will probably be a bit more, but that would work.
I think I have a decent idea how to get this done now, going to be alot of coding and testing from now on... I'll get back and update my progress when near done if anyone is interested.