Phishing message alert 2015.09.02

If you receive messages with the subject “ATTN: RUNBOX ACCOUNT USER” that appears to have been sent from “RUNBOX HELPDESK“, please delete them.

We are deleting all the instances of these messages we can find on the Runbox servers, but we might miss some.

These messages are not sent from Runbox staff and are an attempt to trick Runbox customers into entering their login information at malicious websites.

For more information about phishing, please see the Phishing section of this article.

Continue Reading →

Phishing message alert

If you receive messages with the subject “Pending message” that appears to have been sent from “Runbox Admin” <cusdept@nullrunbox.com>

or

Subject “Account Update” that appears to come from “MEMBERSHIP SERVICE” <membership@nullrbox.com>, please delete them.

We are deleting all the instances of these messages we can find on the Runbox servers, but we might miss some.

These messages are not sent from Runbox staff and are an attempt to trick Runbox customers into entering their login information at malicious websites.

For more information about phishing, please see the Phishing section of this article.

Continue Reading →

Domains and Privacy

From time to time we get asked why Runbox uses runbox.com as our primary email domain rather than our runbox.no domain.

The reason we are asked this is because some people assume that by using a .com domain all the Internet traffic to and from our servers is routed via the Unites States, and could be subject to US government eavesdropping.

(more…)

Continue Reading →

Outlook for iOS – Privacy Issues

Email Apps and Privacy

Back in May 2014 we reported on our investigations in to two smartphone/tablet apps that had been launched. We were worried to find that the apps did not use our outgoing SMTP servers directly, and instead sent email through non-Runbox servers. This made for much easier set up of accounts, but we didn’t like that it wasn’t obvious to the user what was going on.

Those apps were myMail and Evomail (the later is no longer available).

Outlook and Privacy

Outlook now has IMAP compatibility and is able to work with Runbox accounts, however, like myMail and Evomail it doesn’t connect directly to the Runbox SMTP servers for outgoing mail. In fact, we don’t know if it retrieves email directly from our servers either. We do know that it stores some details of your account on servers that are part of Amazon Web Services.

If this doesn’t bother you, then that’s fine as Outlook is turning in to a nice email app that sits nicely alongside the other Microsoft offerings for iOS and Android.

Using Email Apps that Connect Directly to the Runbox Service

We believe that for maximum security and privacy email apps should be connecting directly to the Runbox service and not connecting via other servers, or storing account details anywhere other than in the app on the device.

Usually if you have to enter the server details for incoming and outgoing mail then the app is likely to connect to those services directly. If you have any doubts about an app, please get in touch with Runbox Support and we will investigate how it behaves.

Continue Reading →

SSLv3 disabled on POP connections

For security reasons we have turned off SSLv3 on POP connections (port 995) today. That means we now only allow TLS 1.0, TLS 1.1 and TLS 1.2 on POP connections.

As a Runbox user you should not have to do anything — your email program should already support TLS and use it automatically. If not, please make sure your email program is up-to-date.

Apple Mail users: Please see our notice regarding APOP.

If you do experience any problems, please contact Runbox Support.

Continue Reading →

Email Encryption with Runbox

There has been much talk in the media recently about using email encryption to avoid surveillance and monitoring. In this article we help you understand what email encryption is, how it works, and the options that are available to you as a Runbox customer.

Summary of this Article

  • Email communication involves at least a sending email client, a sending email server, a receiving email server, and a receiving email client.
  • Email communication between client and server is typically encrypted using basic encryption methods such as TLS or SSL.
  • In addition to this, you can use end-to-end encryption with any email service — and we show you how to use encryption with Runbox.

First, the Basics

Email Communication
Email Communication
The client establishes a connection with the sending server, which passes the message on to the receiving server from which the recipient downloads the message.

In order to understand how email encryption works, we need to cover the basics of email communication. Don’t worry, we’ll keep it non-technical and it’s pretty simple.

To send an email to someone, 4 things are usually needed (in addition to the Internet itself):

  1. A sending email client such as Outlook, Apple Mail, and Thunderbird.
    An email client is a program or app, which is running on a computer, tablet, or smart phone. When you use a webmail service such as Runbox Webmail, your browser acts as the email client. Whatever it’s called, it’s the program you use to write your email messages.
  2. A sending email server such as Runbox.
    When you use Runbox your email client connects to our servers, which takes care of figuring out where on the Internet the recipient is located. More correctly, it looks up the domain name part of the recipient’s email address and connects to the servers responsible for that domain name.
  3. A receiving email server such as Gmail.
    The receiving email server accepts the message and stores it until the recipient downloads it to her email client.
  4. A receiving email client such as Outlook, Apple Mail, and Thunderbird.
    Similar to the sending email client, the recipient uses an email program to send and receive email. The email client regularly connects to the receiving email server to check for new email, and usually keeps a copy of the messages on the server so that they are available to other devices the recipient may be using.

Standard Email Encryption

Encrypted Communication
Encrypted Communication
The server presents a valid SSL/TLS certificate and the encrypted connection is indicated by a padlock and green bar in the browser.

The email communication between the client and server (#1 and #2 above) is already encrypted by default if you are using the recommended settings. When using Runbox Webmail encryption is always enabled, which you can tell by the padlock in the address bar and the web address starting with “https” (where the “s” stands for secure).

This type of encryption is called Transport Layer Security or TLS for short (which has succeeded Secure Sockets Layer, SSL) and protects your data from being eavesdropped on its way from your email client to our servers.

After accepting the message for relay, the Runbox outbound email server then looks up the email service responsible for the recipient’s domain name and connects to one of their servers. Runbox always attempts to establish an encrypted connection using TLS, but many services do not support such connections yet.

After connecting to the receiving server (#3 above), Runbox hands over the message for further processing.

The final step (#4 above) between the receiving email server and the recipient is usually encrypted, but it depends on the encryption support of the receiving email service’s servers and the settings in the recipient’s email client. More details: Secure Transfer of Email

Why this type of encryption isn’t sufficient

In other words, there is no way of knowing whether the communication is actually encrypted all the way from you to the recipient. Although some email services provide encrypted email storage, this doesn’t resolve the problem of unencrypted connections further down the message’s path.

In the event that someone was able to eavesdrop on communication encrypted using SSL/TLS, they would in principle not be able to decrypt the contents without somehow accessing the private encryption key which is only stored on the provider’s servers (unless Perfect Forward Secrecy was implemented, which is the case with Runbox).

However, this type of encryption is still theoretically vulnerable to surveillance because the encryption standards used have been developed in cooperation with US intelligence agencies, although any such weakening has been denied by NIST (National Institute of Standards and Technology).

End-to-end encryption of email

End-To-End Encryption
End-To-End Encryption
Sender and recipient have exchanged encryption keys and the communication is encrypted from end to end, in addition to the SSL/TLS encryption which is attempted established by the sending server.

The best solution available is to add another layer of encryption on the email communication all the way from sender to recipient. This is called end-to-end encryption and is already available for use with virtually any email service or provider.

When using end-to-end encryption, the contents of messages will be unreadable to a potential eavesdropper all the way from sender to recipient. It is of course always important that the two parties take great caution to secure their computers or devices to prevent them from being compromised.

Note that the metadata (sender and recipient addresses, subject line, timestamp, etc) of email messages is always unencrypted in order for the message to be routed to its recipient.

There are two main email encryption standards available: PGP and S/MIME. This may look cryptographic in itself, but we will explain both of them. Runbox supports both standards, which can be used with an email client or with Runbox Webmail.

See Encrypting Your Runbox Email for an overview of email clients and their encryption support.

PGP: Pretty Good Privacy

Despite the name, PGP is considered to be cryptographically very strong and is probably the most popular email encryption standard today.

PGP is the easiest encryption standard to get started with because it doesn’t involve anyone but the sender and recipient of a message. It is based on a “web of trust” because it only involves the sender and recipient and assumes that they trust each other.

  • Both parties must have a PGP enabled email client or webmail service.
  • The sender must have generated a private/public encryption key pair using software that is downloaded and installed locally.
  • The recipient must have downloaded the sender’s public key, because the recipient’s public key is used by the sender to encrypt the message. The recipient’s private key is used to decrypt the message.
  • Can be used with webmail services with a web browser.

To get started, see our Encrypting and Securing Email Using OpenPGP help page.

S/MIME: Secure/Multipurpose Internet Mail Extensions

S/MIME is a standard being adopted by the IETF (Internet Engineering Task Force) and requires some more preparation on the part of the email user.

  • S/MIME functionality is built into most major email client programs.
  • Both parties must have an S/MIME enabled email client.
  • A certificate must be obtained from a Certificate Authority and installed in the sender’s email client.
  • Is based on a “chain of trust” because the Certificate Authority validates the sender’s identity and makes the public key available to others.
  • Is not suitable for use with webmail services using a web browser.

We hope this article helped you understand how email encryption works and how to get started using it. And as always, please contact us if you have any questions.

Continue Reading →

New IMAP servers deployed with Perfect Forward Secrecy

Our new IMAP servers were successfully deployed today after upgrading the new ZFS based storage, which resolved an error that had previously caused problems. The technical details of this error can be found in the official bug report from the operating system distributor.

The combination of new, powerful IMAP servers and a modern, ZFS based SAN (Storage Area Network) should significantly improve IMAP performance in the coming days and weeks as we move email accounts to the new storage unit.

Perfect Forward Secrecy support for IMAP

Additionally, the new IMAP servers support Perfect Forward Secrecy on SSL (encrypted) connections, which prevents an unlikely eavesdropper to decrypt the communication between client and server.

You do not have to change anything in your email client to enjoy these new technologies, but do let us know if you experience any problems.

Continue Reading →

[Resolved] “Heartbleed” SSL vulnerability

On April 8, it was revealed in the media that a vulnerability in the internet encryption standard OpenSSL had been discovered. This vulnerability could potentially allow someone to access additional parts of the memory of servers protected by the OpenSSL software.

As stated in the OpenSSL Security Advisory:

A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.

This could potentially compromise sensitive data such as the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of users, and actual content.

Runbox’ servers are secured

Runbox immediately upgraded our installations of OpenSSL on April 8 upon learning about this vulnerability. We have also reissued and reinstalled all our SSL certificates for both Web, POP, IMAP, and SMTP services.

Additionally Runbox web services already supports Perfect Forward Secrecy, which issues unique SSL key pairs for each connection. This prevents an unlikely eavesdropper from retroactively decrypting communications between server and client even if they managed to get the private key.

What you can do

We have no indications that any information has leaked from our systems, and our assessment is that the risk of such leaks is very small. Client computers and software are not affected by this vulnerability.

However, we recommend that you change your Runbox password to be entirely certain that no one else can access your account. It’s a good idea to change your password regularly, and use different passwords for different services. Please see Tips for choosing and protecting passwords for some useful rules about password generation and usage.

More information about Heartbleed from the security company Codenomicon is available at http://heartbleed.com/.

Continue Reading →

Extended Validation SSL certificate installed

In order to further increase the security of our services we have now installed an Extended Validation SSL certificate on our main website https://runbox.com.

The certificate is issued by the WebTrust certified certificate authority GlobalSign and verifies that Runbox Solutions AS owns and operates the website and domain name runbox.com.

What is Extended Validation SSL?

The Extended Validation SSL (Secure Sockets Layer) certificate provides the strong encryption included with regular certificates, and additonally validates our company’s identity by showing our company name and country code in green to the left of the browser address bar:

runbox.com EV SSL

Extended Validation certificates are only issued after rigorous vetting to verify the legal identity and physical presence of the website owner, establish their exclusive control over the domain name, and confirm the identity and authority of the individuals acting for the website owner.

This Extended Validation certificate also covers https://secure.runbox.com and https://www.runbox.com. Other runbox.com subdomains are still using a regular SSL certificate, which has the same encryption level but not the “green bar” identity validation.

Continue Reading →

Runbox now supports Forward Secrecy

In recent weeks there has been some discussion in news outlets about SSL/TLS, which is used by many websites to encrypt the data being transferred between web servers and web browsers.

Since it’s theoretically possible for outsiders to break such encryption, an increasing number of people are requesting improved encryption methods.

What is SSL/TLS?

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are cryptographic methods used to secure communication on the Internet. By using pairs of private and public keys, the web server and the client can securely encrypt and decrypt the data being transferred between two parties.

Gold-padlock.svgWhen a web browser connects to a website protected with SSL or TLS (indicated by a padlock icon in the browser) it receives the public key from the server, which is then used to encrypt the subsequent communication. The data can only be decrypted using the private key, which resides on the server.

The problem with keys

However, if someone was able to break in and copy the private key from a server, they would theoretically be able to decrypt any communication to/from that server — provided that they were also able to eavesdrop on the communication.

The solution: Unique keys

To counter this it’s recently become possible to configure web servers to issue a unique key pair for every single connection, and immediately destroy the keys once the session is complete.

This method is called Forward Secrecy because it prevents anyone from retroactively breaking the encryption.

Forward Secrecy on Runbox

Runbox has now implemented Forward Secrecy in order to further improve the security and privacy of our services. It’s now virtually impossible to eavesdrop on the data being transmitted between your web browser and Runbox’ web servers — and you don’t have to do anything in order to enjoy this new level of security.

For those who are interested in the technical details, here is an analysis of the security provided by https://runbox.com, which is now our main address:

https://www.ssllabs.com/ssltest/analyze.html?d=runbox.com

Continue Reading →