Security improvements to our services

November 7, 2019 Leave a comment

At Runbox we are continuously working to improve the security of our services. We are now strengthening the security of your web browser’s connection to our servers to ensure that it utilizes modern web security standards.

If you are using an updated version of one of the major web browsers you will probably not notice any effects. You can then continue using our services just like before, while knowing that the strongest encryption protocols are being utilized.

If you’re using a non-standard or not updated web browser, then please read the information below for more details about these changes and how they may affect you.

Those who are interested in the technical details of these changes may also find these details useful.

What we are doing

When you visit our website the connection between your web browser and our web servers is encrypted. This means that no one can intercept your username, password or any other transmitted data including the content of your email messages.

It’s important to use a modern browser that supports modern encryption methods to prevent that encryption from being broken and compromised. This is essential to web security because hackers increasingly use more powerful computers and techniques in their attempts to decrypt data and eavesdrop on unsuspecting users.

In order to ensure that Runbox is providing the latest and most secure encryption between your browser and our service we will therefore end support for outdated encryption methods.

This entails that we will only support the strongest encryption cipher suites that are compatible with most major web browsers.

It also helps us prevent unauthorized access to our servers and helps keep the Runbox services safe for all of our customers.

On December 1, 2019 we will retire some outdated encryption methods and this might affect some older web browsers.

Once these changes are made the TLS protocol version and cipher suites will be the same for all access methods to our email services, including web, POP, IMAP, and SMTP.

The technical details

You don’t need to understand all the technical details, but we know many customers are interested in this and it is useful for everyone to stay educated about web security.

The changes involve retiring support for TLS (Transport Layer Security) version 1.0 and 1.1, and only provide support TLS 1.2 or later. We will also only support a small suite of strong encryption cipher suites that are recommended by the reputable organizations Mozilla and OWASP.

TLS 1.2 has been around for 10 years so there has been a long time for browsers to adopt the use of this type of encryption. However, you don’t need to understand anything about this to make any necessary changes.

All the cipher suites we will be utilizing are of the type Diffie-Hellman Ephemeral (DHE), which means that a unique cryptographic key is generated each time a new connection is made.

This in turn means that even in the unlikely event that one set of keys is compromised it cannot be used for another connection made from another client (“forward secrecy”).

An updated list of cipher suites that are supported currently include the following:

  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-SHA256
  • ECDHE-RSA-AES256-SHA384
  • DHE-RSA-AES128-SHA256
  • DHE-RSA-AES256-SHA256

More information about these cipher suites can be found on Wikipedia: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

How this may affect you

The vast majority of web browsers already support TLS 1.2 and you are only likely to have a problem if you are using an outdated browser and/or an outdated operating system.

We have tested the following browsers and they all work with the modern encryption that we will use:

  • Firefox (Windows, macOS and Linux)
  • Chrome (Windows and macOS
  • Safari (macOS)
  • Opera (Windows and macOS)
  • Edge (Windows)

Many other modern browsers are also likely to work with TLS 1.2 and those listed above are just commonly used ones that we have tested.

Further help

If you need any further information or help on this issue please contact Runbox Support with details of how we can help you.

Continue Reading →

GDPR implementation part 6: Access Control and Permissions

October 24, 2019 Leave a comment

In part 3 of this blog series we described how we mapped the “world” of our operations, including the following components:

  • Server infrastructure, including all servers and other hardware as well as the links between these.
  • Software components that comprise our application stack from the operating system level to the front-end application level.
  • Data networks, including how and where our serves are connected to the Internet, but also the Local Area Network at our premises.
  • Data inventory, i.e. all personal data including customer and employee data, financial records, information about partners/associates, etc.
  • Applications necessary to run the company itself, meaning software that is managerial in nature.

Access control concerns permissions attached to system-related objects. Within each of the components listed above, there may be several sub-objects — servers, software modules, data files, catalogues etc., to which restricted access should be implemented.

Creating an Access Control Table

These objects then form one axis of an Access Control matrix or table (ACT). The other axis of the table include organizational units, broken down into person-related objects, for instance segments or groups, but also individuals, for each unit.

After breaking these objects down to an appropriate level, we attached roles to each of these components. In terms of the GDPR, data processor and data controller are examples of roles to use in this context.

To each of the defined roles, we attached categories of tasks, for instance sysadmin, developer, and support staff tasks.

For our email service systems we found it convenient to structure the system-related objects in 3 main categories:

  • General software.
  • Application software.
  • Personal data.

Within each of these categories there are various numbers of objects, to which access permissions are attached, comprising the Access Control Table for the realm in question. For other realms of our “world” we used a similar approach, resulting in a number of ACTs that implement a principle of least privilege.

With this the groundwork was laid for establishing various mechanisms for implementing the access control regime, in order to secure our most precious pieces of hardware, software, and data.

In our next blog post in this series we will look at Information and Tools for Implementation of Users’ Rights.

Continue Reading →

GDPR implementation part 5: Risk Assessment and Gap Analysis

September 15, 2019 1 Comment

In previous posts in this blog series we have referred to our main planning document, Rules and Regulations for Information Security Management, or RRISM for short, where our road to GDPR compliance started out. In that document we worked out the structure of the project, based on descriptions and definitions of the various components.

Obviously, risk management has to be taken very seriously, and the RRISM lays the groundwork for how we should handle this aspect of information security. The baseline is that risk management is an essential part of the company’s life, and one that comprises all its assets.

Defining and assessing risks

As usual, we first had to agree upon some definitions, and we found the following to be adequate for our purpose — directly from NIST (National Institute of Standards and Technology):

Risk is the net negative impact of the exercise of a vulnerability, considering both the probability and the impact of occurrence. Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level.

Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization.

In order to assess risks, we first have to identify possible threats that may exploit vulnerabilities in our systems or our organization.

In short: Risk management shall first and foremost have as objective to protect assets that are at potential risk.

Analyzing assets

Then we outlined the methodology we adopted:

  1. Identify the assets that could be at risk.
  2. Identify possible threats and vulnerabilities.
  3. Identify the possible consequences of each potential vulnerability.

Each threat was characterized by probability and criticality which together gives one of four risk levels: Very High (red), High (orange), Medium (yellow), and Low (green). This helped us decide what we should prioritize regarding improvements, measures, and other actions.

Analyzing our assets we actually found more of these than anticipated, grouped in 21 different asset types, ranging from our customer base, general software in use and our own key business systems, through hardware and communication lines, and employees and partners – and more.

Threat, vulnerability, and gap analysis

Then we reviewed the vulnerability potentials (what could go wrong) for each asset and created scenarios for possible consequences if something happened that exploited a vulnerability.

The question raised thereafter was: Do we have the necessary measures and remedies in place to eliminate the potential vulnerabilities, or mitigate the consequences if things went wrong — or is there a gap?

The next step was to find out what actions should be taken in order to close the gaps in cases where we were not satisfied with the situation, and this will be the topic of future blog posts in this series.

Conclusion

Our mantra through this process has been: Threats we can imagine will sooner or later be reality, but never as we expect them to happen, and never where we expect them.

We live in an ever-changing environment, which means that risks have to be monitored continuously, and so our risk assessment and gap analysis is continually evolving as well.

Continue Reading →

GDPR implementation part 4: Information Security Policy

July 17, 2019 2 Comments

The groundwork for compliancy

Privacy and security has always been a part of the Runbox culture. However, the GDPR project made it clear to us that we had to systematically work through how to implement the various aspects of data protection and information security.

Let’s start by recalling the meaning of some important terms:

Privacy is about individual’s right to a private life, and the right to control all information about themselves. Grounded in European Convention on Human Rights (1950), the Norwegian Constitution § 102 states that “Everyone has the right to the respect of their privacy and family life, their home and their communication.” followed by “The authorities of the state shall ensure the protection of personal integrity».

Norway’s law on privacy, the Personal Data Act (PDA1), was introduced as early as 1978, so we have tradition for this kind of legislation. That’s why the GDPR2, in principle, didn’t result in significant changes.

In order to protect privacy, Information Security (IS) is crucial. It is mainly about how to prevent personal data from going astray, but we had to go for a more stringent definition: To secure confidentiality, integrity, authenticity, availability (for the approved purpose only), reliability, resilience (the ability to recover), possession (ownership), and utility (readable for the approved purpose) of the data.

With this in mind, we developed our Information Security Policy (ISP) as a documentation of the GDPR compliancy practices, and GDPR requirements to employees and states the company’s commitment to compliance. Article 24 in the GDPR demands controllers (such as Runbox) to implement appropriate data protection policies, and our ISP is an important part of our response to that requirement.

The purpose of Runbox’ Information Security Policy is to provide rules and guidance for Runbox’ employees, Runbox’ contractual employees/consultants, and everyone else working for Runbox, voluntarily or according to contract/agreement, so that they in all respects act

  • to comply with the company’s information security policies,
  • to comply with the company’s Privacy Policy and Terms of Service regarding our obligations to our customers,
  • to ensure that the processing of Personal Data is in accordance with the PDA/GDPR and ensure that appropriate technical and organizational measures are adapted to the purpose, extent and context of the processing, and ensure that such measures are adapted to the risks for the rights and freedoms of natural persons3.

The ISP is a very comprehensive document, stating our commitment to the protection of our customer’s data, and defining technical and organizational measures to fulfill this obligation.

For instance, we will not store customer’s data on any “cloud” (we use our own servers), we shall never disclose account information or email data to authorities (unless presented with a court order from the Norwegian prosecuting authority), and we shall never scan customer’s data to display ads. More information about this can be found on our Privacy Protection page.

An important aspect of the ISP is to define the responsibilities of two roles/positions: The Managing Director is the personified Data Controller, responsible for GDPR compliancy on behalf of the company, and the appointed Data Protection Officer, who is a watchdog regarding the company’s status where GDPR is concerned.

The ISP imposes strict rules for employees, partners, consultants etc. on how to handle systems and data, anchored in a No Disclosure Agreement and Agreement on Protection of Personal Data. This includes rules for how to process and store data and how to protect digital devices.

Finally, let’s mention that the ISP provides rules for contractual agreements with organizations Runbox has partnered with, consultants etc. so that appropriate technical and organizational measures are implemented to ensure GDPR-compliant data processing and systems development.

All together, we have developed two documents that serve as guidance, and control our behavior regarding the GDPR. These are the RRISM (planning document, mentioned in an earlier blog), and the ISP. It is worth mentioning that these documents are continuously updated when new privacy and security issues arise.

1 The Personal Data Act (the PDA) means the regulations that are currently in force in Norway for the protection of individuals in connection with the processing of personal data, which includes the implementation of GDPR in Norway (2018-07-20).

2 The GDPR means Regulation EU 2016/679 of 27 April 2016 on the protection of individuals with regard to the processing of personal data and on the free movement of such data and repealing Directive 95/46 / EC General Data Protection, General Data Processing Regulation. Article refers to Article in the GDPR.

3 See GDPR Article 4(1).

Continue Reading →

POP v IMAP – battle of the protocols

July 14, 2019 Leave a comment

POP (Post Office Protocol) and IMAP (Internet Message Access Protocol) both have their place, but for most customers Runbox recommends that IMAP is used.

POP and IMAP are both ways in which an email program (client) can access your messages on an email service (server). This client-server relationship needs the two systems to communicate with each other and depending on which of these you choose your options for managing your email will be different.

Synchronisation

Generally speaking IMAP can be regarded as synchronising what is on the server (which you can see in the Runbox webmail) and what is on the device or computer that is using IMAP. With the increase in the number of devices we each use if you want your email contents to be the same across all your devices, then IMAP is the best option.

Online v Offline

POP is quite different to IMAP and the basic idea is to allow you to download messages from an Inbox on a server and remove them from the server. The idea behind this was that it would be particularly useful if you have intermittent Internet access and want to manage your email on your device. POP clients also have the option to leave email on the server in case you want to keep it there as a backup or download it to another device later. Some clients also have an option to delete the email after a certain period of time.

However, caching (keeping a copy) of messages in the email program also allows IMAP to provide a way of working without an Internet connection. POP still has the advantage that generally speaking all your email is downloaded and you can be confident it is stored on your machine whereas with IMAP you may need to ensure specifically that the email you want to access offline is downloaded.

Sent messages

Another of the key differences between POP and IMAP is that with IMAP email that is sent from a device is usually copied to the Sent folder on the server. This means if you start using a different IMAP device or access your email via the webmail you can also see your Sent messages sent on all other devices. Sent messages are never copied to the Sent folder when using POP and are stored locally only on the device that sent the message.

Folders

IMAP allows you to structure your email in a variety of folders and these are reflected across your devices. POP only allows access to messages from a particular folder, usually the Inbox (though Runbox has a feature called “POP from folder” that allows you to access a particular folder in your account).

Storage

If you regularly access your email then POP could mean you only need a small amount of server storage and therefore cost you less in hosting charges. For example, if you always download you email and delete it from the server then you won’t need as much storage space compared to someone who leaves all their email on the server using IMAP and may also have a folder structure they need to maintain that wouldn’t be possible with POP.

Of course with IMAP you can also copy messages to a local folder in your email program and then delete them from the server, but this needs a bit more effort whereas with POP it is a feature of this way of accessing messages in the first place.

Backups

Using POP to download all your email and at the same time deleting it from the server does mean that you might want to consider making your own backups of your email. With IMAP your email is stored on the server and this acts as a kind of backup in itself. Runbox also makes backup snapshots of your account (unless you opt out of this), but if you download all your email using POP and leave little on the server, then there might not be anything for us to make a backup snapshot of.

Why we generally recommend IMAP

Generally speaking if a customer asks us whether IMAP or POP is best for them we will recommend IMAP. There are a number of reasons for this, and some are listed below:

  • The experience across devices and between devices and the webmail is consistent.
  • It’s easy to set up two or more devices and know that you will see all the email that is in your account.
  • If you need to remove the account from a device and set it up again you won’t automatically lose your messages (with POP you would need to make a local copy first).
  • It’s easy to change your mind about what email program you want to use because email is stored on the server.

When we would recommend POP

A customer might have a specific reason for not leaving email on the server. They may want to keep their storage plan small so that they don’t need to upgrade over a period of time. They may also want to ensure that data is not stored on our servers for too long, or in our backup system.

They may also need to filter email for different purposes using the filters built in to every Runbox account, and then just access a particular folder as if it was the Inbox using the POP from folder feature mentioned above.

Server details

The server details for POP and IMAP are very similar, except that you use port 995 for POP and 993 for IMAP. You will find the full details on our server details page.

If you need any further information about POP and IMAP just contact Runbox Support.

Continue Reading →

Runbox 7 Calendar now in beta

June 26, 2019 Leave a comment

We are extremely pleased to be able to announce that the Runbox 7 Calendar is now in beta test.

You may be aware that Runbox for a while has provided a calendar (CalDAV) service for calendar clients such as Outlook, Thunderbird Lightning, and macOS Calendar.

If you’ve previously used our CalDAV server you’ll be pleased to be able to finally use it through the web interface, not needing a separate program anymore.

Runbox 7 Calendar

Calendar features

The Runbox 7 Calendar currently offers month, week, and day views, you may add and edit events, and perform other basic actions.

It can also be synchronized with your other programs and devices by setting them up with our CalDAV service.

As this is still a Beta, not everything that your own calendar program can do will be available in the Runbox 7 Calendar quite yet. One notable missing feature is Tasks (TODOs) support – this will be coming later on as a separate feature.

We invite you to try it out by logging into Runbox 7 and clicking Calendar in the main menu.

And let us know what you think over in the Runbox 7 Forum!

Continue Reading →

Introducing Runbox 7 Contacts

June 18, 2019 2 Comments

It is our pleasure to announce that the new Runbox 7 Contacts is available in open beta test!

If you’re already using Runbox 7 you may have noticed them already, and if you aren’t — here’s another reason to try it: Runbox 7 Contacts combines the best of the Runbox 7 web interface with the world of email clients.

Modern user interface

The first thing you’ll notice after clicking Contacts in the main menu in Runbox 7 is the beautiful and smooth user interface.

Runbox 7 Contacts is built with the same Angular framework that powers the Runbox 7 Webmail, and you will recognize its design components and interactive functionality.

Runbox 7 Contacts
Runbox 7 Contacts

New Contacts storage (CardDAV)

One of the key parts of the new Contacts is how we store your contacts on the servers. So far they’ve been stored in a proprietary database, with no other way to access them than through the Runbox 6 web interface.

This has been an annoyance to those of you who would like to use your contacts across many different apps and devices.

From now on in the new Runbox 7, all contacts will be stored on a CardDAV server – an open standard for sharing contacts and address books between different devices.

The advantages of Runbox 7 Contacts

If you know what CardDAV is, chances are you were eagerly awaiting this and need no further encouragement to use it. If you’ve never heard of it before, here are two key benefits it has over the existing system

First of all, Runbox 7 uses the standard vCard for representing the contacts. You may have heard the name before — if you ever sent a contact to someone over an SMS for example, it was a vCard. Using vCards in Runbox 7 Contacts means that much more flexibility when it comes to the information you can store.

vCards in Runbox 7 and CardDAV can store everything Runbox 6 can, and more — as many emails, phones and addresses as you desire, all categorized. Pictures, links to social media accounts, messengers, public keys for encryption; whatever you can think of, it’s probably there.

Second, you can access your Runbox 7 Contacts everywhere. No need to even use the Runbox 7 app — you can use any email client, any contacts app on your computer or your phone, and you’ll have access to the same contacts everywhere.

Add them on your phone, edit them on your laptop, and then they’ll still be available Runbox 7 when you compose a new email. Runbox 7 Contacts contains all the information that you need to set up any other apps that you use.

Using Runbox 7 Contacts

Until you migrate your contacts they will not be available for synchronization yet. Migrating them will move them over to CardDAV and give you all the glorious new features of Runbox 7 Contacts.

2019-04-01-121407_456x120_scrot

Try out the new Runbox 7 Contacts by logging into Runbox 7 and clicking Contacts in the main menu.

And let us know what you think over in the Runbox 7 Forum!

Continue Reading →

GDPR implementation part 3: Mapping our “world”

June 5, 2019 Leave a comment

This is the third post in our series on Runbox’ GDPR implementation.

After having structured our GDPR project, the next piece of necessary groundwork was to map out status on relevant facts about important areas of our business. The reason is that it’s impossible to establish and maintain good security and privacy – and to determine GDPR compliancy — if the “territory” is not clearly described.

The “territory”

The “territory” in question was foremost and first of all,

  • The email service delivery system, that is the Webmail and backend systems and files – the development platform that is used, the components of which the system is built, the dependencies between the components, description of access points etc. – while being well aware of that the GDPR compliancy also includes Privacy of Design requirements.

Other realms that are necessary to describe were for example:

  • The economic system in which the company operates; i.e. mapping out the network of organizations with which our company is involved – including partners, associates, suppliers, financial institutions, government agencies, and so on – in order to serve our customers.
  • Server infrastructure with all physical links and channels, and not the least: All software components.
  • Data networks, including how and where our serves are connected to the Internet, but also the Local Area Network at our premises.
  • Data catalogue, including of course all personal data, that is, what kind of data are registered on customers and also employees and partners/associates as well.
  • Applications of all sorts necessary to run the company – applications that are managerial of nature.

Level of description

One problem encountered is how detailed the descriptions should be. Too many details will make the job unnecessarily big in the first place, followed by a lot of maintenance to keep the documentation current.

We chose to start with a “helicopter view”, to obtain an overview of the different realms with the intention to fine-grain the documentation depending on the requirements of the ultimate goal: To identify areas where privacy and security is of concern, ticking off issues that are well taken care of in light of the GDPR, or followed up with measures to improve the situation to achieve GDPR compliancy.

Of course, the GDPR Implementation Project is not a sequential one, as development projects seldom are. Therefore, from time to time we had to go back and adjust our planning tools when needs arose.

The next blog post in this series will concern our Information Security Policy.

Continue Reading →

Changes to TLS encryption security

May 7, 2019 7 Comments

At Runbox we are pleased to be able to provide you with secure email services. In order to maintain the security of email communications it is necessary to continually review how email systems connect and communicate with each other, and this includes how you connect to our service to send and receive email.

Encryption is important

When you connect to our service using an email program (such as Outlook, Thunderbird, Apple Mail etc.) the connection between the email program and our mail servers is encrypted so that nobody can intercept your username, password or email message content.

It’s important to use updated software that supports modern encryption methods to prevent that encryption from being broken and compromised as hackers increasingly use more and more powerful computers and techniques to decrypt data.

As such we will end support for outdated encryption methods to ensure that we provide the latest and most secure encryption between your email program and our service. This also helps us prevent unauthorised access to our servers and helps keep the Runbox service safe for all customers.

On 1 July 2019 we will retire some very old encryption protocols
and this might affect some older email programs.

The technical details

We will be retiring support for TLS 1.0 and 1.1 and will only support TLS 1.2 or later. TLS 1.2 has been around for 10 years so there has been a long time for email programs to adopt the use of this type of encryption. TLS is Transport Layer Security and is the encryption that protects your data. However, you don’t need to understand much about this to make any necessary changes.

Your email program

Most email programs that were released in the last 5 years will be compatible with the latest encryption. It is important to use the latest versions of email programs as the developers of those programs will have corrected bugs that could be a security issue. Where possible it is also advisable that you use the latest version of your computer’s operating system.

We have tested the email programs below and they all work with the most modern encryption that we use with our servers.

  • Outlook 2010 and later (Windows and macOS) – may require a registry change for Windows 7 customers.
  • Thunderbird (Windows and macOS)
  • Apple Mail (macOS) – High Sierra or later.
  • Windows Mail (Windows)
  • eM Client (Windows and macOS)
  • Gmail app (Android)
  • Mail app (iOS) – requires iOS 10 or later.
  • Maildroid (Android)

Many other email programs will also work with our service and those listed above are just commonly used ones that we have tested.

Further details and help

If you need any help on this issue, or would like us to offer advice on the email program you are using please get in touch with us.

Continue Reading →