With increased, more frequent cyber attacks against public and private websites , more and more sites choose site-wide HTTPS. HTTPS, a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encryption and secure identification of the server, provides three main features: content encryption, authentication, and data integrity, therefore to prevent eavesdropping and tampering, as well as protect the site against man in the middle attack. Below I want to share some practical experience on how to implement HTTPS, especially on how HTTPS can work with new security standards and protocols.

Understand Mixed Content

By definition, when a user access a page over encrypted HTTPS connection, if the HTTPS page includes cleartext HTTP contents, such as images, this is called mixed content. Different browsers handle mixed content differently.

Early IE

When early version of IE discovers mixed content request, it will popup a warning message for "Do you want to view only the webpage content that was delivered securely?" If the user clicks "Yes", all mixed content resources will not be loaded; if "No" is clicked, all the resources will be loaded.

Modern IE

The newer versions of IE (9, 10, 11) will display a short message in the yellow notification bar (see below). By default it will load the image type Mixed Content, but for the others, such as JavaScript and CSS, user can decide whether to load the content.

Modern browsers

The other modern browsers (Chrome, Firefox, Safari, Microsoft Edge), basically are compliance with W3C's Mixed Content standard, to classify the Mixed Content into two categories: Optionally-blockable and Blockable. Optionally-blockable Mixed Content category contains those information is less risky. By default the browser will load these resources, and it will display a warning message on the console. Such Optional-blockable mixed content resources include:

• Images loaded via img

*Note: This includes SVG documents loaded as images

• By <video> / <audio> and <source> tag loaded video or audio
• Prefetched resources

All content that is not optionally-blockable is considered blockable, and is blocked by the browser. So HTTPS page for JavaScript, CSS and other HTTP resources, will not be loaded.

Mobile Browser

Compared to desktop browsers, mobile browser is more complicated. Most of the current mobile browsers by default will allow loading Mixed Content. In other words, for mobile browsers, both HTTPS and HTTP resources, whether it is image or JavaScript, or CSS, will be loaded.

Generally speaking once the site-wide HTTPS is chosen, we need to avoid Mixed Content; to use HTTPS to ensure end to end secure communication.

Use of CSP

CSP, stands for Content Security Policy, is a computer security standard to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in trusted web page context.

• block-all-mixed-content

 As mentioned above, for HTTPS Optionally-blockable class HTTP resources, such as images, modern browsers will load the content. In general, if image resources are hijacked, it will not cause much damage,  but there are some risks, for example, many user interfaces embedded images for buttons, if these user buttons were compromised or altered by man in the middle, there will be impacts to user.

 By using CSP block-all-mixed-content feature, we can enable “Strict Mixed Content Checking” mode. In this mode, all non-HTTPS resources are not allowed to load. As with all other CSP rules, we can enable this restrict mode in two ways:

• HTTP response header:

Content-Security-Policy: block-all-mixed-content

• <Meta> tag mode:

<meta http-equiv="Content-Security-Policy"
  content="block-all-mixed-content">

• upgrade-insecure-requests

 Migration from HTTP to HTTPS is complicated. To re-write the code and to add “s” at the end of each HTTP is very time and resource consuming.  CSP “upgrade-insecure-requests” feature allows browser to automate this conversion. After you enable this policy, there are two changes:

1. All HTTP resource page will be replaced with HTTPS address;
2. All outbound links within a page, when clicked, will be replaced by HTTPS address.

HTTP Strict Transport Security (HSTS)

After the implementation of the site-wide HTTPS, if the user manually typing the site's HTTP address, or from elsewhere clicked the site’s HTTP link, 301/302 redirect on the server side will enable HTTPS service. However If the first HTTP request is hijacked, a request will not reach the server - this is call protocol downgrade attack.

• HSTS basic feature

 This problem can be solved by HSTS (HTTP Strict Transport Security, RFC6797). HSTS is a response header in the following format:

Strict-Transport-Security: max-age = expireTime [; includeSubDomains] [; preload]

max-age, in seconds, is used to tell the browser within the specified time, the site must be accessed with HTTPS. If HTTP address is used, the browser needs to replace with HTTPS before request is sent.

• HSTS Preload List

Browser vendors also built a list of domains, even if the user has not visited before, will use the HTTPS protocol; the list can be updated regularly. Currently the Preload List maintained by Google Chrome, Chrome, Firefox, Safari, IE 11 and Microsoft Edge. If you want to add your domain to this list, you first need to meet the following conditions:

• Have a valid certificate (which must expire before 2016 if it uses SHA-1).
• Redirect all HTTP traffic to HTTPS.
• Serve all subdomains over HTTPS.
• Serve an HSTS header on the base domain for HTTPS requests:
• Expiry must be at least eighteen weeks (10886400 seconds).
• The includeSubdomains token must be specified.
• The preload token must be specified.

CDN security

For large heavy traffic website, after the migration to site-wide HTTPS, CDN (Content Delivery Network) is still required. However CDN needs to support HTTPS. If a third-party CDN is used, CDN over HTTPS or SSL is required.

• Use of SRI

 HTTPS can prevent data from being hijacked, and legitimate certificate to authenticate the server can also secure the site, but if the CDN server is hacked, and if files on the server has been compromised, HTTPS can not do anything.

W3C's SRI (Subresource Integrity) can be used to solve this problem. SRI, specifically, validates assets served by a third party, such as a content delivery network. This ensures these assets have not been compromised.

• Keyless SSL

Another problem is that when using a third-party CDN's HTTPS service, if you want to use your own domain name, you need to provide third party with your private key. This is very risky. Keyless SSL technology can be used to solve this problem. In this case, you don’t have to give the private key to third party, instead just provide a key server that can calculate a key in real time. Throughout the process, the private key is kept in the Key Server, and will not be exposed to third parties.

To sum up, the paper tried to provide some advice on the HTTPS implementation. It should be noted that above mentioned CSP, HSTS and SRI and other strategies are only supported by the latest browsers. Moreover after the migration to HTTPS, the performance optimization needs to be addressed.