HSTS with Apache and Chrome

• HSTS (HTTP Strict Transport Security) prevents your browser from visiting a website over an unencrypted “http://…” url. Instead you have to use the encrypted “https://…” url, otherwise your browser refuses to load the website.
  Either the webserver of the website you are visiting suggests the use of HSTS to your browser by sending an additional HTTP header, or you manually configure a certain website yourself in your browser.
• Apache requires the module mod_headers to make the necessary changes to the HTTP headers.
• Add this to your Apache vhost configuration:
  Header always set Strict-Transport-Security “max-age=15768000; includeSubDomains; preload”
  For a description of all options see RFC: https://tools.ietf.org/html/rfc6797#section-6
  The “preload” option is not part of the RFC. It just signals that you want your site to be added to the browser builtin list of HSTS sites (see below). If you do not plan to get listed, you may omit this option.
• Visit the site at least once using HTTPS in your Chrome browser (“trust on first use”). The HSTS configuration of the site (provided by the Apache STS header) will be added to an internal Chrome list. HSTS really depends on this internal browser list. Webservers only send an additional HTTP header that webbrowsers may or may not honor.
• Add, delete or check websites in your Chrome browser:
  chrome://net-internals/#hsts
  Changes take place immediately without having to restart Chrome.
  You can add sites even if they don’t send the special STS header.
  You can combine those entries with PKP (Public Key Pinning) by providing fingerprints for all accepted public keys of a website.
• Chrome ships with a builtin list of sites that require HSTS. If you run a large public website, you might want to get included in that list: https://hstspreload.appspot.com/
  These builtin sites get listed as “static_…” in your internal Chrome browser list. All other sites (added manually or by honoring the STS header) get listed as “dynamic_…”.
• You cannot delete site entries from the builtin list (assuming that you use the official Chrome browser and that it has not been manipulated).
• This is the message you get in Chrome when HSTS is violated on a website (in this case the certificate of http://www.rolandschnabel.de has expired and therefore Chrome refuses to establish the HTTPS connection):

You cannot visit www.rolandschnabel.de right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.

Important things to note:

• Even for HSTS enabled sites, you may still be able to type in the “http://…” URL in the browser address bar. Chrome automatically recognizes the URL and redirects you to the corresponding “https://…” URL.
  This is different from traditional HTTP redirects, because no unencrypted traffic is sent over the network. The redirection already takes place in the browser.
  The downside of this behaviour is that it makes it hard for people to identify if a website is using HSTS or simply redirects all traffic from HTTP/port 80 to HTTPS/port 443 (HTTP status codes 3xx).
• Many browser plugins now offer the same functionality (redirect some or all website addresses to HTTPS URLs).
• Maybe some day HTTPS URLs become the default in webbrowsers. If you type a URL in the address bar, or select a URL without the leading “http(s)://”, the browser first redirects you automatically to the HTTPS URL. Only if there is no connection possible, you will receive a warning message and get redirected to the HTTP URL. Let’s make HTTPS the default in browsers and accept HTTP only for a small number of exceptions.
  No green lock icon for SSL encrypted websites, just red unlock icons for unencrypted websites.

 

Secure download of Ubuntu ISO installation images

Please follow the instructions on this page:
https://help.ubuntu.com/community/VerifyIsoHowto

There is another website, but it doesn’t use SSL / HTTPS:
http://www.ubuntu.com/download/how-to-verify

The procedure is the same as I have already described for CentOS or Debian in my previous posts:

1. Import the GPG-key and verify its fingerprint.
2. Download the checksum file and verify its signature with the GPG-key.
3. Check the iso file with the checksum file.

Again the fingerprint of the GPG-key is on a SSL encrypted website where you have to check the website certificate and its root CA.

Firefox ships with its own set of root CAs (“Builtin Object Token” as the Security Device in advanced preference settings). Here is a list of all root CAs included in Firefox along with their fingerprints:
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport

Builtin root CAs are hardcoded in /usr/lib/firefox/libnssckbi.so

CAs marked as “Software Security Device” are usually intermediate certificates that are downloaded from websites and stored locally. These CAs that are not builtin are either stored on a PKCS#11 compatible smartcard attached to your PC/laptop or saved to your home directory:
certutil -d ~/.mozilla/firefox/xxx.default -L

Chromium / Google Chrome does not ship with its own CA list but uses the CAs from the underlying operating system:
https://www.chromium.org/Home/chromium-security/root-ca-policy

On Ubuntu 16.04 these CAs are hardcoded in /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so which is part of the package “libnss3”.

Important things to note:

• Verification of ISO images is based on GPG-keys which have to be checked by its fingerprints. You can get that fingerprint from a SSL secured website.
• The security of a website depends on the root CA which is used to sign the website certificate. These CAs are stored locally in different locations based on the browser you are using.
• Neither Firefox nor Chromium / Google Chrome are using CAs from the package “ca-certificates”.