Protected social networks - myth or reality?
In this article I want to tell you how I came up with the idea of a secure social network web service. How to implement it and on what technologies. I will share technological solutions to problems during the development of the service.
The idea of this project came to me after I got acquainted with the current state of affairs in the field of encryption. I ran into two problems.
')
On the one hand, it is the complete insecurity of users from information leaks from social networks, instant messengers, and so on. For example, Skype or Telegram stores all correspondence on their servers and, at the request of the government, provide any data from these correspondence. I also recall the recent hacking of a dating site for adultery Ashley Madison, where user data floated.
On the other hand, we all know that the higher the level of protection, the less pleasant it is to use such a product. For example, to sign and encrypt emails using PGP requires special software and skills. Using Telegram, you are obliged to install their messenger and shine your SIM card and, besides, the secret chat mode, with only one user, there is no group mode. Also, changing the device, you do not see what you chatted earlier in a secret chat.
Quite an interesting solution offers Bitmessage. As Wikipedia says, “it donates some convenience for the sake of security and decentralization” is in my opinion the key drawback of this solution.
On the Internet, I met a service that allows you to encrypt text notes and store them in the clouds. Access was through a regular browser and you had to know the password from your notes. The trick was that the service itself guaranteed that it could not peek at what you had in the notes, since the encryption took place in your browser with your password. And on the server everything is transmitted already in encrypted form. Symmetric encryption algorithm was used. In other words, if someone gets access to your notes, then there is no point in this, since they are encrypted.
I have adopted these two concepts. We store on our servers user data already encrypted. The process of encryption and decryption goes on the side of the user's browser with his password. My task is complicated by the fact that I need to send a message from one user to another. They will not be encrypted with the same password. For this, I used an asymmetric encryption algorithm. To do this, each user must have a public and private key.
When one user sends a message to another, he must take the public key of the second user and encrypt the message with it. The second user receiving the message uses his private key to decrypt. This is where the password symmetric encryption approach came in handy. Public keys can be handed out openly, but it is not convenient to force a user to drag on a flash drive or store his private key on a screw. For this, I made that the public and private key were generated in the user's browser and transmitted to the server. Public in open form, and private private password that is set by the user.
Next, I had to somehow understand that the message being sent or the requested list of messages come from such and such a user. To do this, all requests from the user are signed by his private key, and my servers keep his public key in clear text with which I check this request or message whether it is true from this user or not.
When there was a question about the choice of technology, I thought for a long time whether to do everything quickly and on the old proven things. Or maybe try what is new and what the future stands for. As a result, I wrote the server part on Scala running the Play Framework on the Cassandra database. Client part on CoffeeScript under control of AngularJS. Design taken from Bootstrap. Encryption was done using Forge library in javascript. Unfortunately, HTML5 has no built-in encryption mechanisms.
Architecturally, it looks like a JavaScript client that goes through Rest to the server. WebSocket is also used to receive notifications about new messages from the server. Each WebSocket connection generates an Actor, which subscribes to the Akka event bus, and if an event is associated with its user, then sends it to the browser.
Separately, I want to mention the experience of using the database Cassandra. This is somewhat unusual. When you work with a regular database, you throw in tables, fields, and you can use them for any queries. If it slows down, then you add indexes. Cassandra is the opposite. Each table is essentially one main query that quickly follows the specified keys in the table. If you decide to somehow extract data from it differently with different sampling conditions, you will have to do one more table and other keys to it and in essence duplicate data. This approach hinders the rapid development, as it makes you think everything optimally at once. But on the production you do not roll out the brake poop :)
The source code of the project can be found here: github.com/evgenyigumnov/protectednet I made the project Open Source and the service itself free.
The idea of this project came to me after I got acquainted with the current state of affairs in the field of encryption. I ran into two problems.
')
On the one hand, it is the complete insecurity of users from information leaks from social networks, instant messengers, and so on. For example, Skype or Telegram stores all correspondence on their servers and, at the request of the government, provide any data from these correspondence. I also recall the recent hacking of a dating site for adultery Ashley Madison, where user data floated.
On the other hand, we all know that the higher the level of protection, the less pleasant it is to use such a product. For example, to sign and encrypt emails using PGP requires special software and skills. Using Telegram, you are obliged to install their messenger and shine your SIM card and, besides, the secret chat mode, with only one user, there is no group mode. Also, changing the device, you do not see what you chatted earlier in a secret chat.
Quite an interesting solution offers Bitmessage. As Wikipedia says, “it donates some convenience for the sake of security and decentralization” is in my opinion the key drawback of this solution.
On the Internet, I met a service that allows you to encrypt text notes and store them in the clouds. Access was through a regular browser and you had to know the password from your notes. The trick was that the service itself guaranteed that it could not peek at what you had in the notes, since the encryption took place in your browser with your password. And on the server everything is transmitted already in encrypted form. Symmetric encryption algorithm was used. In other words, if someone gets access to your notes, then there is no point in this, since they are encrypted.
I have adopted these two concepts. We store on our servers user data already encrypted. The process of encryption and decryption goes on the side of the user's browser with his password. My task is complicated by the fact that I need to send a message from one user to another. They will not be encrypted with the same password. For this, I used an asymmetric encryption algorithm. To do this, each user must have a public and private key.
When one user sends a message to another, he must take the public key of the second user and encrypt the message with it. The second user receiving the message uses his private key to decrypt. This is where the password symmetric encryption approach came in handy. Public keys can be handed out openly, but it is not convenient to force a user to drag on a flash drive or store his private key on a screw. For this, I made that the public and private key were generated in the user's browser and transmitted to the server. Public in open form, and private private password that is set by the user.
Next, I had to somehow understand that the message being sent or the requested list of messages come from such and such a user. To do this, all requests from the user are signed by his private key, and my servers keep his public key in clear text with which I check this request or message whether it is true from this user or not.
When there was a question about the choice of technology, I thought for a long time whether to do everything quickly and on the old proven things. Or maybe try what is new and what the future stands for. As a result, I wrote the server part on Scala running the Play Framework on the Cassandra database. Client part on CoffeeScript under control of AngularJS. Design taken from Bootstrap. Encryption was done using Forge library in javascript. Unfortunately, HTML5 has no built-in encryption mechanisms.
Architecturally, it looks like a JavaScript client that goes through Rest to the server. WebSocket is also used to receive notifications about new messages from the server. Each WebSocket connection generates an Actor, which subscribes to the Akka event bus, and if an event is associated with its user, then sends it to the browser.
Separately, I want to mention the experience of using the database Cassandra. This is somewhat unusual. When you work with a regular database, you throw in tables, fields, and you can use them for any queries. If it slows down, then you add indexes. Cassandra is the opposite. Each table is essentially one main query that quickly follows the specified keys in the table. If you decide to somehow extract data from it differently with different sampling conditions, you will have to do one more table and other keys to it and in essence duplicate data. This approach hinders the rapid development, as it makes you think everything optimally at once. But on the production you do not roll out the brake poop :)
The source code of the project can be found here: github.com/evgenyigumnov/protectednet I made the project Open Source and the service itself free.
Source: https://habr.com/ru/post/271215/
All Articles