We Asked Countermail Why They are Still Using TLS 1.0

Here is their answer:
Why do you use Java for the email encryption?

You can not (sic) get real end-to-end security in a web browser without a web browser-plugin, like Java, or some other browser plugin.
Anyone working professionally with IT-security and cryptography should know this. Yet, there are many other “secure email providers” which relies only on SSL/TLS (HTTPS)  as protection method between the user (the client) and the email server (you can later read Note:1 about OpenSSL weaknesses).

It’s simple, you must have some local Application, email-client or browser-plugin that handles the most important steps below:

  • Registration: Where the user selects username and password, both must be encrypted locally on thee users computer before sending it to the server, password should only be sent in some form of one-way hashsum, however is should not be the same hashsum which is used to protect the private key. The login name (username) should be encrypted to protect the anonymity.
  • Initial Keypair-generation: This mathematical process should also be done on the client side, one important thing in this step, is that the Private key is strongly encrypted before sending it to the providers server. In our case you can also delete the private key from our server afterwards, or even generate your own keypair and only send us the public key, after the first registration is finished.
  • Login: Username should be sent in encrypted form and the password as a one-way hashsum. the server can then verify the password-hashsum by comparing it with the one stored in the server-side database. If it’s correct, the encrypted user data can be sent to the user, including the encrypted private key- which then will be decrypted locally, and temporarily stored in the computers RAM (memory). Even during Login the username should be encrypted to preserve the anonymity.
  • Create or Read email = Encryption/Decryption, should be done locally, the private key should only be available in unencrypted form inside the local computer memory. All keys should be erased from the computers memory (RAM) when the user logs out.
  • Verifying digital signatures, to do this, you only need the senders Public key, and the signed message itself.
  • Digitally sign a message/file, should be done locally, the signer needs his/her own private key to do this.
  • Password-change, should also be done locally, after a password change the private key protection changes, so the private key should be sent to the server only in encrypted form. And also the new hashsum, which is used to verify the user during Login.

If a provider executes any of these steps on the server-side and not on the client side, they simply don’t have true end-to-end security. See Note:2 for one exception. If a provider don’t have real end-to-end security, emails could be read on the server-side, or wiretapped or exposed to some man-in-the-middle (MITM) attack.

We have selected Java-plugin because it’s already installed on many computers. Read more about Java security here, and how to use it safely.

Even more web browsers support Javascript, and you can do a lot of things with javascript, even strong encryption, locally on the clients computer. But there are some important differences between the Java-plugin and Javascript:

  • Javascript is much slower than Java, generating a good 4096 bits keypair takes time, same with decryption
  • You can’t sign Javascript code as you can do with Java, the Javascript code can be faked much more easily. With Java you can sign the Java-applet with a Digital certificate, a code-signing certitficate, which is verified by a third party. Read more here. If the Java-code certificate changes you will get a warning.
  • You can’t use USB-keyfiles with Javascript
  • You can’t protect against DNS-spoofing with javascript

Some call SSL/TLS half-broken, some even call it “broken by design”, anyway, you should not send any highly sensitive information under the “protection” of SSL/TLS alone.The first problem with SSL/TLS, is that you have to trust 200-300 CA-authorities (companies) in your web browser (or other applications), anyone with a CA-keypair can generate a valid SSL/TLS-certificate, which usually don’t give any warning in the web browser! So an advanced attacker could start an invisible SSL-MITM attack.

Even the latest version of SSL/TLS (OpenSSL) can not protect against this. And a CA-authorithy company can be hacked, so a hacker may steal a valid CA-keypair, or simply create a valid cert for some domain.

That’s why we always had another encryption layer underneath HTTPS (SSL/TLS) to protect against SSL/TLS weaknesses.

Some attacks against OpenSSL (HTTPS/SSL/TLS):

Some other peoples view on OpenSSL:
https://www.youtube.com/watch?v=3jQoAYRKqhg (forward to 41:00)

If incoming emails/or imported emails are sent in unencrypted form to one user, the Public key-encryption can be done on the server-side, the server should then encrypt them to the users own unique public key. This is basically the only time you may allow server-side encryption to occur, because then the users emails will always be stored in encrypted format, which only the user can decrypt and read.

But to get true end-to-end security both the sender and the recipient must encrypt/decrypt messages locally, using OpenPGP, before it leaves their computer. This is how our webmail works: https://countermail.com/?p=server

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s