Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/safe-webdrop/safewebdrop

Secure https-based encrypted message exchange mechanism
https://github.com/safe-webdrop/safewebdrop

aes-encryption communication-protocol file-transfer https-request https-server openpgp openssl organisation-management rsa-signature secure-communication

Last synced: 18 days ago
JSON representation

Secure https-based encrypted message exchange mechanism

Awesome Lists containing this project

README 

          
# safewebdrop

## Secure https-based encrypted message exchange mechanism



Originally developed for the Crypto Bone, 

the SafeWebdrop message exchange mechanism

can be adapted for a large number of projects that require secure, ie encrypted and

authenticated, message and file exchange.



It is a foundation for internal communication demands within an organisation that can be

established with a minimal invasive software product on a server, that is already up and running

and can be accessed via HTTPS.



To ensure true end-to-end encryption, it is absolutely necessary to start a secure message

exchange with a shared initial secret that has been agreed on by two people in a personal contact.

Once two people have decided on such an initial secret, this initial secret must be protected

on their endpoint devices which is not easy to achieve.



But the exchange of AES encrypted messages and files must also be secured to make sure

that only the two legitimate people (sender and recipient) can access the encrypted data.



This secure message exchange is provided by the SafeWebdrop software in a specific way.



## Principles of Secure Message Exchange 



*  Providing the SafeWebdrop service on a https-enabled server should be non-invasive.

   That means, it must not be necessary to have people, using the service, introduced as users on the server.

   Unlike ssh the SafeWebdrop service creates only a single directory /var/safewebdrop/username,

   nothing else.



*  Every user is enabled only if an administrator accepts a user's public RSA key that

   the registration software on the user's endpoint device produces. For this to 

   happen, one personal contact between the user and the server administrator is required

   in which the user presents a registration code to the administrator that is stored together

   with his public key on the server.

   The administrator will then run a script that creates the user's directory and copies

   the public RSA key into it.

   The administrator's involvement ends with the registration, everything else is done by

   the server scripts.

   

   Once registered, the user can avail of the SafeWebdrop service as long as the admin

   does not delete their directory or RSA public key.



*  Registered users receive a SafeWebdrop address consisting of their user name and the

   server's domain name (or IP address) separated with a %-sign. Those addresses look similar to

   email addresses, (Alice.Johnson%example.com) but they are used over HTTPS to send

   encrypted messages and files to other users on the same (local) server.

   This https-based message exchange reduces the meta data that would be visible with an

   ordinary encrypted email exchange.



*  All interactions with the server (reading, writing, deleting) require that the requests

   being sent to the server are signed with the user's corresponding RSA private key,

   which is stored (and protected) on the user's endpoint device. The SafeWebdrop

   client scripts 

   take care of this.



*  If (and only if) the administrator of a SafeWebdrop service allows message exchange

   to users on a different SafeWebdrop server, then the process of accepting a remote user's

   public key is safeguarded by the initial secret, these two users have agreed on.

   And on the fact that the remote administrator has accepted the other user's RSA

   public key on his server.



   Note, that no contact between the two administrators nor the use of any

   PKI is involved to establish cross-server message exchange. 

   The conclusion of acceptance of a certain cross-server contact relies 

   entirely on the initial secret, both users have agreed on, which is part of the hash value

   that triggers the storage of the remote user's public key by the server scripts.



## Testing the Server-Side Software



The six server-side scripts are all coded in pure bash and won't interfere with the 

server's orginal functionality. All messages that are stored and retrieved by users live under

a single directory /home/safewebdrop.



You can test whether or not all necessary server-side commands are already in place

with the test program check-server-utils on your server. And you'll find examples

and advice how to test the functionality of the server-side code on your own server 

with these test scripts. 



## Using SafeWebdrop Exchange for Your Own Project



Of course, the SafeWebdrop exchange mechanism can also be used as a foundation for your

own projects. The server-side scripts need not be changed at all. 



But you have to be extremely cautious when you are developing your own client-side code.

If you don't avail of the CryptoBone daemon to secure access to the message encryption keys,

you have to think hard how to safeguard the encryption keys that are used in your own code.

The secret, that protects the user's RSA private key must also be protected as much as 

possible, as every request is signed using this private RSA key. 



In the client-side code you'll find lines like this

```

PASS=$(/usr/bin/echo "get-element webdropsecret" | /usr/bin/socat -t15 - UNIX-connect:$SOCK 

```

that retrieve secret information from the cryptobone daemon. If you don't want to use

this daemon in your own code,

you need to take extra care to safeguard these secrets.

For details see the project's security page.



## Code Review



Every code review is most welcome, however in order to maintain the stability and reliability

of the code base I will carefully vet any contribution and I may chose to rewrite it,

add comments and documentation, rather than taking it as is. 

Needless to say that code changes will happen only after conclusion of extensive tests.