Blog

MakeSends: secure file transfer right in your web browser

We have taken swi5t to a new level. Based on the same technology used by swi5t, we have launched MakeSends, a secure file transfer service.

It's simple: You pick a file to transmit, type the recipients' email addresses, and an encryption password.

MakeSends then encrypts the file for you using your password, uploads the encrypted file onto the internet, and notifies the recipients by email. The recipients click on the link in the email, and type the password you share with them.

Files are encrypted before being uploaded, and decrypted in your friend's web browser after being downloaded. The confidentiality of your documents is therefore guaranteed even if hackers intercept the email, or the encrypted document.

As opposed to swi5t, you do not need to install any software on your computer. Try it for free at www.makesends.com.

Does swi5t access the internet?

When starting swi5t for the first time, you may see a message from your firewall or internet security suite asking you if you want to allow swi5t to access the internet. You are seeing this message when swi5t checks for new versions.

With version 1.7, we added an automatic update check to swi5t to keep you posted when new versions appear. We recommend you to allow swi5t to do this check, and to update swi5t whenever a new version appears. New versions not only add features, but may also improve the security or fix bugs.

For the techies among us: when starting swi5t, it makes a request to

http://swi5t.com/news/windows/1.8/

to check for news and updates. If that page has changed, it is displayed on the screen.

Swi5t never transmits your passwords or documents to the internet, and works fine without internet access.

Announcing swi5t 1.8

The new swi5t 1.8 is online. Besides bug fixes and small improvements, we have added the possibility to upload the encrypted HTML file directly onto a FTP server. This comes in handy for users who want to share their documents through an FTP drive.

Do you like the new version? Are you awaiting more features? Share your feedback with us.

End-to-end encryption

We are putting our files and data, sometimes private and confidential, on the internet via emails, websites, and cloud services. Our data is being surveyed by governments or businesses or even by individuals with malicious intent.

Encrypting our data is perhaps the safest way to protect it from unwanted access. But encryption only provides the desired safety if it is used correctly:

• An encryption service should offer about 256 bits of security. Anything below 60 bits can be broken quite easily with a powerful computers, and even 128 bit algorithms are within reach. 256 bits provides us with healthy margin against brute force attacks.
• The encryption scheme should be based on well-known and tested algorithms (e.g. AES). Ideally, the source code should be open source so that cryptographers can check and test it.
• Finally, encryption should be end-to-end. This means that data is encrypted on the sender's computer, and decrypted on the receiver's computer only. The password (or key) is thereby known to the sender and receiver only, and not to the server(s) over which the encrypted data is transferred.

Using HTTPS, the data is encrypted between your web browser and the server only. The server decrypts the data to store or process it. This leaves plenty of possibilities for potential hackers.

In some cases, the data is re-encrypted by the server for storage. That does not add a lot of security, since the encryption keys are stored on the server (or unfar from it) as well. This is akin to locking a door but leaving the keys behind. The protection is minimal and cannot be verified by the user.

End-to-end encryption therefore remains the only secure option.

Hacking HTTPS

HTTPS is widely used across the internet, and touted as the secure version of HTTP. In contrast to HTTP, data remains encrypted for the transmission between server and client. However, HTTPS has several weaknesses, allowing surveillance agencies to readily decrypt your HTTPS transmissions.

First, HTTPS allows for different encryption algorithms, some of which are outdated and known to be weak. Which algorithm is being used is negociated between your web browser and the server when a connection is established. Web browsers are pretty lean about that: if the server does not support any of the strong algorithms, they content themselves with a weak encryption algorithm - without asking or telling you. While most servers nowadays are configured to use strong algorithms, it is not easy for you to check (or enforce) that.

Weak encryption can be broken in real-time with readily available tools.

Second, HTTPS relies on a hierarchic certificate scheme. Certificates are issued by VeriSign, StartSSL, and many others, and used to check the identity of the server. Whenever you connect to DropBox, for instance, you want to make sure that you are talking to a DropBox server, and not to a hacker pretending to be DropBox. To prove that, the server signs his reply with a (private) key, and sends the corresponding certificate to your browser, which then checks the signature, as well as the validity and trustworthyness of the certificate.

That scheme is simple and strong – technically. In practice, however, there are two severe issues:

• Most people don't check the name on the certificate. Whenever it says "https" in a green URL box, they believe the connection is secure. However, somebody may be listening as a man-in-the-middle, and present his own certificate (with a different name) to the user.
• Some governments (or their security agencies) can secretly force certificate issuers (such as VeriSign) to create certificates with the name of some company for them. In this case, even checking the name is not sufficient. In other words, even if it says "DropBox, Inc." on the certificate, you may not be talking to a DropBox server.

According to a recent study¹ by Facebook, about 0.2 % of all HTTPS connections use a forged certificates.