table1.cc Blog

Reproducible and Efficient Creation of ‘Table 1’ Summary Tables for Research Papers

Ensuring Effective Encryption on table1.cc

Ensuring effective encryption is a central design requirement for the confidential handling of potentially sensitive research data. Enforcing encryption of transmitted content is therefore a key priority in table1cc's design.

Figure 1. Table1.cc uses the https protocol exclusively

Figure 1. Table1.cc uses the https protocol exclusively

This post is to highlight the journey taken to enforce encryption on the table1.cc website. It serves to highlight our security efforts and ensure transparency, as well as help other website owners wanting to achieve enforced encryption when using Heroku and Flask.

How websites communicate with your web browser:

There are at least four ways to access any given website, here using “example.org” as a generic example.

  1. http://www.example.org
  2. https://www.example.org
  3. http://example.org
  4. https://example.org

As web users, we expect any of these addresses to “just work” at any time we type them into a browser and hit ENTER. Yet, on a technical level, these are four distinct web addresses that require individual routing and resolution.

The significance of https for website security

The main distinction from a security standpoint for the user is as follows:

  • Only the two https addresses provide an encrypted protocol and therefore enhance safety
  • The http (without s) addresses are un-encrypted.

This means as a website user, the use of https is clearly superior and should be used whenever possible.

How to ensure that https is used

Fortunately, a website owner has at least three ways potential methods to ensure that all traffic is routed via https via any of the following three layers.

  1. Redirection on the DNS (so called Domain Name Server) (This is the server provider)
  2. The web server that is responsible for serving the website (such as Apache or nginx) can initiate the redirect to https
  3. The web application

Limitations of DNS (1. Layer) and web server (2. Layer) approaches

It is generally recommended to use either the DNS server or web server layer should be used to ensure https redirects. However these two options come with limitations that ultimately did not make them a viable option for table1.cc:

This is an increasingly relevant topic as the importance of https has been rising in recent years.

The table1.cc app runs on a web platform called Heroku a service platform that enables rapid development and improvement. Heroku is a Platform-as-a-service and comes with security enhancements out of the box. Despite these benefits, one challenge in enforcing encryption was of the virtual nature of this platform that limits the ability to access redirection. Heroku documentation for details

To make matters even more complex, in 2017/2018 Heroku implemented changes to its infrastructure that simplified enabling encryption but rendered previous redirect methods ineffective. A large number of and search hits on Google, StackOverflow, and many other knowledge bases are unfortunately no longer applicable.

To summarize:

  1. To redirect traffic from one https to another https domain consistently, the DNS server would require access to a separate https certificate for the address (given that all addresses are handled separately) Since DNS servers do not usually have access to a given website’s encryption certificate, the redirect attempt fails.
  2. The web server level requires access to the web server. However, Heroku utilizes an ‘ephemeral’ file system and other restrictions, that while generally advantageous preclude this option limits the ability to

How to ensure consistent https encryption with Heroku and Flask in 2020

Ultimately, the solution involved rerouting all web traffic on the application level (3rd layer). While this is somewhat more computationally intensive (and therefore more costly), this was ultimately the preferred because it is the safest method for our users.

Here is how the implementation works in case this is useful for other Heroku and Flask users:

Based on a StackOverflow post by user Danilo Bargen here. The code was updated to reflect changes in Python3:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
from urllib.parse import urlparse, urlunparse

@app.before_request
def redirect_nonwww():
    """Redirect non-www requests to www."""
    urlparts = urlparse(request.url)
    if urlparts.netloc == 'example.com':
        urlparts_list = list(urlparts)
        urlparts_list[1] = 'www.example.com'
        return redirect(urlunparse(urlparts_list), code=301)

Redirection scheme on table1.cc

This table shows the current routing scheme for the four possible combinations of https and www / non-www URLs.

Entered address Redirects to
http://table1.cc https://www.table1.cc
http://www.table.cc https://www.table1.cc
https://www.table1.cc https://www.table1.cc
https://table1.cc https://www.table1.cc

Table 1: How redirects on table1.cc enforce reliable encryption

Bottom line

No matter which of the four addresses is entered when using table1.cc: All traffic to and from table1.cc is encrypted via https/SSL so you can rest assured your data is safe. To verify that encryption is active, you can look for the “lock” symbol in the taskbar of your web browser as seen in Fig 1.

Expect more updates on new table1.cc features in the near future.

If you are curious, give it a try here and follow us on Twitter here.