Security improvements to our services

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

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

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

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 →

Runbox 7 Calendar now in beta

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

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”

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 →

GDPR implementation part 2: Structuring our GDPR project

As mentioned in our previous blog post about our GDPR project plan, we structured our implementation plan in 14 sub-projects.

In this blog post we’ll take a look at the first of these sub-projects.

Mapping status compared to the Regulation

The foundation for the sub-projects was (of course) the requirements in the GDPR Regulation, which we had mapped in subproject # 1: Compliancy Status Tables mapping Runbox’ status compared to regulations.

In order to prepare ourselves, we did that before the final regulation was decided. We also did this for the requirements from the Norwegian Personal Data Regulation at that point in time.

Of course, the mapping had to be made compliant with the final version of the GDPR after the EU decision in 2016 – and so we did.

Controller and processor

At that point in time, we had our project nicely structured in the 14 sub-projects mentioned above. That was pretty easy, because of the mapping we had done. An important fact in this context, is that Runbox is a controller and a processor as well, depending on the circumstances, according to the GDPR definitions. It was important to be exact about where and when.

Subprojects definitions and delimitations

In the GDPR we found some important points that we had to consider:

  • Our agreement with our main processor, Copyleft Solutions – and what about the agreements with our affiliates, partners and the like? Are confidentiality clauses regarding protection of personal data adequate any longer?
  • Do our Terms of Service and Privacy Policy correspond to the new requirements?
  • What changes have to be done in our systems to fulfill GPDRs requirement regarding customers’ rights?
  • Do we have a systematic documentation of our systems, and what about access control?
  • Does our information security policy cover the necessary elements, and is our risk analysis up to date?
  • What about the processing of personal data we do for internal processing? Obviously it was necessary to take a look into the agreements we have with internal and external personnel.
  • What about the internal control mechanism we have – do they comply?

Those points (and some more) made the foundation for establishing delimitations between each sub-project, which we will continue blogging about in the weeks to come.

Continue Reading →

Runbox 7 Feature and Bug Bounty Program

The Runbox 7 project represents an ambitious plan to revolutionize the world of webmail services, and with the Runbox 7 open source launch on https://github.com/runbox/runbox7 we have invited skilled developers to join us in this quest.

Now we are excited to announce a bounty program to accelerate development further. The program is two-fold and introduces bounties for both features and bugs.


Feature bounties

We encourage you to contribute to Runbox 7 with your skill and talent by adding new functionality that all Runbox 7 users can enjoy.

All contributions must include tests and documentation in order to be accepted.

Gold – $1,000 reward

Gold bounties are rewarded for contributing major new features that involve substantial additions to the Runbox 7 code base.

Examples of such features can be found on the Runbox 7 Roadmap and include complete, new screens for Account, Files, or Manager with REST endpoint specifications.

Other examples are significant optimizations of the code that improve performance or substantially restructures or refactors the code base.

Silver – $500 reward

Silver bounties are given for contributions of medium-sized new features or additions of new functionality that improves existing features.

Examples of such features can be found on the Runbox 7 Roadmap and include new screens for sections under Account, Files, or Manager with REST endpoint specifications.

Bronze – $100 reward

Smaller features or functionality that extends or improves existing features.

Examples include those listed on Github as Runbox 7 enhancement issues (urgent and critical).

Iron – $10 reward

Minor features or functionality that extends or improves existing features.

Examples include those listed on Github as Runbox 7 enhancement issues (trivial, low, and medium).

Bug bounties

Integrity and reliability is paramount to our operations and although we take all reasonable precautions to prevent bugs, all open source software benefits from thorough reviews from the community.

Therefore we provide bug bounties with an emphasis on problems that could impact the integrity of our services.

High – $1,000 reward

Reporting severe errors that could lead to elevated privileges, significant data compromise, or service downtime.

To be eligible for this bounty:

  • You must not publicly disclose your finding.
  • You must never exploit any found vulnerability.
  • You must send a detailed explanation with steps to reproduce the bug.
  • You may submit a patch that fixes the issue for a double bounty!

Examples include issues listed on Github as Runbox 7 bug issues (critical).

Medium – $500 reward

Reporting vulnerabilities that provide limited access and that could result in denial of service, manipulation of individual accounts, or temporary problems that affect limited data sets.

To be eligible for this bounty:

  • You must not publicly disclose your finding.
  • You must never exploit any found vulnerability.
  • You must send a detailed explanation with steps to reproduce the bug.
  • You may submit a patch that fixes the issue for a double bounty!

Examples include issues listed on Github as Runbox 7 bug issues (critical).

Low – $100 reward

Vulnerabilities that have a low impact on our operations or that require significant knowledge about our systems.

Examples include issues listed on Github as Runbox 7 bug issues (urgent).

Trivial – $10 reward

Minor bugs that are annoyances rather than vulnerabilities, and that don’t affect the integrity or reliability of our services.

Examples include those listed on Github as Runbox 7 bug issues (trivial, low, and medium).

How to get started

To get started with our bounty program, have a look at our Runbox 7 GitHub repository at https://github.com/runbox/runbox7.

We are marking issues that are suitable for new contributors with “good first issue“.

Then review our contribution guidelines and follow the instructions there: https://github.com/runbox/runbox7/blob/master/CONTRIBUTING.md


Continue Reading →