Once you've found a server administrator who provides the SafeWebdrop service all requests to the server rely on a https-based exchange of data to that server. Plain unencrypted (and unauthenticated) http cannot be used with SafeWebdrop.

Registration

The primary goal of registration is to have a user's RSA public key being accepted by the server administrator. The only reliable means to ensure that the user's public key is authentic is the first-hand contact to the server's administrator in which the registration code is presented. If the administrator checks this registration code before accepting a user's public key, no-one else is able to smuggle a different key onto the server to overwrite the authentic one.

It should be said, that receiving the registration code first-hand is essential and must not be bypassed with any more convenient means of proof.

Even if an attacker tries to overwrite a user's registration with his own RSA public key in order to deny the legitimate user a registration, it is not possible to replace a public key that has already been accepted. Only the server administrator has write permissions on all accepted public keys. The SafeWebdrop code has read permissions to a public key only.

An attacker will never succeed to register a false ID unless the attacker is able to impersonate the user in a personal contact to the administrator using social engineering tricks or worse. The legitimate user is asked to repeat his registration process until a valid request with the registration code conveyed first-hand is visible to the administrator.

From that point onwards, all requests being sent to the server comprise of a unique challenge that is digitally signed with the legitimate user's RSA private key. The server-generated challenge (a 256 bit random number) must be provided in a signed message for every request that needs to be completed by the server. Replay attacks are prevented by generating a fresh challenge at the start of every new request.

As an additional means, no message or attachment file will ever be stored on the server that is not AES encrypted.

So what can go wrong, once the user's public key is accepted?

If an attacker can utilize some other rogue software on the server to execute code as the https process owner, it is possible for the attacker to copy messages and files that are encrypted and whose decryption key reside only on the sender's and the recipient's own local devices in protected form. The attacker will not find any information on the server that enables a decryption of any message or attachment file. But the attacker would get access to some metadata by reading the logs in a user's home directory, using the rogue webserver code.

Cross Server Contacts

If the config file permits, the SafeWebdrop server code allows two users that have been registered on different servers (by different administrators) to exchange information securely. In order to enable such cross-server communication between users, the public key of a user that has not been registered by the server admin needs to be accepted on his server.

If the admin allows cross-server communication at all, the acceptance of a foreign RSA public key happens without his involvement. A legitimate user (Alice) on the server can send a message (an allow information) to her server that contains a hash value of her own and her foreign contact's full SafeWebdrop addresses together with the initial secret that both users have agreed. Once her foreign contact (bob) sends a similar message (a request information and his RSA public key) and both hash values match, the SafeWebdrop code stores Bob's public key in Alice's contacts directory to allow the use of a Bob's public key on her own server.

Note, that no contact between the two administrators nor the use of any PKI is involved. The conclusion of acceptance of a certain contact relies entirely on the secret, both users have agreed on, which is part of the hash value that triggers the storage of the public key.

Though an attacker can send a false request together with his illegitimate public key to Alice, but the attacker will not be able to produce the necessary hash value as he does not know the initial shared secret (ideally 20 random characters) between the two users. So the fake contact request will never conclude.

Both users have to make sure that the secret they agree on personally is not guessable or known to the attacker. The security of the CryptoBone's message exchange relies entirely on this initial secret agreement. It cannot be skipped or simplified. Once both users have produced the same hash value (including their shared secret) and have provided it to the server, the contact's public key is stored and an attacker won't be able to overwrite it. Needless to say that all this is done automatically when Alice enters the initial shared secret with Bob into her CryptoBone GUI to enable Bob as a recipient.

Given the fact, that the attacker can execute his own rogue webserver code on the server, the attacker might be able to replace a foreign RSA public key that has been accepted and stored in the past with his own fake public key, because the webserver code has write permission on all keys stored in "contacts" directories used for cross server communication. This is the trade-off you have to accept, when the establishment of cross-server public keys shall happen based on the actions of two SafeWebdrop users on different servers without the involvement of both server administrators. But the server admin has full control over the use of all RSA public keys (for verification of signed message requests) on his server as he can deliberately disable the x-permission on any user's "contacts" directory to switch off cross-server communication for this particular user any time.

Client-side Attacks

If an attacker can run code on a user's device under the user's UID, the CryptoBone GUI can be used to initiate a new registration request (see above) so the attacker can destroy the user's ability to read his messages. The attacker's code will also be able to access currently stored messages and files on the device's RAM-disk through the GUI that have arrived recently and have been decrypted successfully. But this code cannot access the decryption keys that change with each message, because the key database is accessible by the CryptoBone daemon only, so that forward secrecy is assured. The decryption keys that have already been used are discarded by the CryptoBone reliably. Details can be checked with the cryptobone daemon source code here.

Using the SafeWebdrop Exchange for your own Code

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 key.

Given the vulnerabilities of certain popular Operating Systems this may not be an easy task.

To give you an idea of how the CryptoBone daemon protects the database of secrets, I will briefly outline its functionality.

The cryptoboned process is started during the boot process by systemd (UID=0) and has access to the file system, in which the master key is stored. In a fraction of a second the cryptobone daemon has read the master key to decrypt the database of secrets and stores the clear text database in memory and discards the master key in memory. The process then mounts a different filesystem onto the directory in which the master key is stored making access to the master key impossible unless you can unmount this file system as root.

An attacker who has access to the client device during the boot process over a network connection has a very limited unpredictable time window in which the master key is visible at all. And even then root permissions protect the master key.

It is a very different story if an attacker can mount your primary OS partition because of physical access to your device. In this case you have to assume that your device is compromised entirely, so that access to the database of secrets will reveal current decryption keys only but not already used ones.

During normal operation the cryptobone daemon answers requests to secrets stored in the database in memory over a UNIX socket that can only be read by a process running under UID=0. So the GUI needs to selectively ask the daemon to perform actions in which encryption keys are needed.

As you can see, this mode of protection makes heavy use of UNIX capabilities and is not easily adaptable to other operating systems. That is the reason why I don't even think of trying to do that.