CounterMail - protecting your privacy - encrypted pgp email webmail

SSL-MITM protection

The OpenPGP-encryption will always protect the body of your email, but to protect your identity and to protect against MITM-attacks you must have another crypto layer, most providers use SSL for this.

The use of SSL/TLS can lead to a false sense of security, over the last years there have been several successful attacks against SSL, another risk with SSL is the CA-certificates, if some "bad people" use a valid CA-certificate they can decrypt your SSL-traffic in realtime, totally transparent, without any warnings. Read more here.

This means that SSL is not always secure enough. So we added RSA and AES-CBC encryption underneath the standard SSL-protocol to prevent identity leakage and MITM-attacks.

In short, we have four protection layers:
SSL encryption -> Session encryption -> OpenPGP encryption -> Server side disk-encryption. Every layer is based on standard algorithms only, indepedent of each other.

Our Session encryption scheme

1. User starts our Java-applet, either by visiting countermail.com, or even better, by double clicking on Login.html on your own USB-memory.

2. User enters Username and Password, the Password is transformed to an OpenPGP S2K-Hash (using SHA-1, random IV and 262k iterations). The random 128-bit AES-Key and CBC-IV is also generated, using the Java SecureRandom CS-PRNG.

3. The Username, S2K-Hash, AES-Key and CBC-IV is then encrypted with CounterMail's server public RSA-key (stored inside the signed applet). So far, all processing is done inside the User's Java applet. After the RSA encryption, the packet is sent to our web server. Keep in mind that the Password never leaves the Applet, only the hash sum of it.

4. Our web server decrypts the RSA-packet with CounterMail's server private RSA-key and verifies that Username and S2K-Hash combination is correct. If it's correct, our server generates a Session-id and stores the AES-Key and CBC-IV in a temporary Session-file. Since our web server don't have any hard drives the Session-file resides in RAM.

5. Our web server will then read the User-data (email, OpenPGP-keys and Contacts) from our database server, and together with the Session-id, send it back to the User, before the packet is sent it will be encrypted on the server, using the AES-Key and CBC-IV received from the User. If the User have our USB-memory, his/her private OpenPGP-key can be stored on the USB-memory instead.

6. User's Applet receives and decrypts the packet using AES-CBC. The Applet now have the Session-id, Session-AES-Key, and the OpenPGP encrypted User-data, the server and the user can now communicate securely even if someone breaks the SSL. The OpenPGP encrypted User-data will now be decrypted, using the password entered earlier.

As far as we know, we're the only provider that have protection against SSL-Man-In-The-Middle attacks.