What does HTTPS protect, and what does it not?

Objectives

By the end of the lesson, you can say what HTTPS protects and what it does not, explain the role of certificate errors, mixed content, and HSTS, and understand why the padlock icon of the browser does not mean a "flawless application".

Why is a separate lesson needed for HTTPS?

HTTPS is the most common protection on the web, so most misconceptions are also connected to it. "There is a padlock, so the page is secure." This is not true, but not false either: the padlock supports one specific, narrow statement. Whoever knows exactly what HTTPS protects does not trust it more than necessary, and does not leave it out where it is needed. In chapter 8 we build on the same knowledge when we discuss the errors of the application.

A protected connection on a public network

HTTPS is the transfer of HTTP messages with TLS protection. A student logs into Kurzuspont on public Wi-Fi. The network in between forwards the traffic, so it is worth asking what it can see or change. If the browser has built a valid HTTPS connection to the desired domain, the content of the request and the response travels under TLS protection: an outsider cannot simply read it, and cannot rewrite it unnoticed either.

flowchart LR
    B[Browser] -->|HTTP protected by TLS| S[Web endpoint]
    K[Network in between] -. forwards, but does not read the content .-> B

The diagram does not promise complete invisibility. The existence, timing, and volume of the connection and some addressing data may be observable. "Encrypted" does not mean that all of the user's activity remains hidden.

Three protection properties

Property	What does it protect against?
Confidentiality	The reading of the transferred content.
Integrity	The message being modified unnoticed on the way.
Authentication	The browser checks that it is talking to the server belonging to the opened domain.

The three together give protection its meaning: authentication without encryption or encryption without authentication is not enough, because an attacker could talk with their own server on an encrypted channel too.

What happens if the certificate is faulty?

If the certificate is not valid for the opened domain, the browser stops before it would send an HTTP request. This is an error of a different type than 404: there an HTTP response already exists. A real example of three typical certificate errors from curl, with the deliberately faulty servers of the test site named badssl.com (which was created for trying out the TLS behavior of browsers, and is also known from the Chromium sources):

$ curl https://expired.badssl.com/
curl: (60) SSL certificate problem: certificate has expired

$ curl https://wrong.host.badssl.com/
curl: (60) SSL: no alternative certificate subject name matches target host name 'wrong.host.badssl.com'

$ curl https://self-signed.badssl.com/
curl: (60) SSL certificate problem: self signed certificate

• expired certificate: the validity period has run out;
• wrong host name: the certificate is not for the name that was reached;
• self-signed certificate: there is no certificate authority known to the browser behind it.

curl gives an error code, and the browser a warning page. On the latter, the "continue" button bypasses the protection: if the user steps through it, the encryption remains, but they no longer know whom they are talking to. This is why ignoring the warning weakens exactly the essence.

The limits of protection

Specifically, HTTPS does not:

• prove that the provider is trustworthy. A deceptive (phishing) page can also get a valid certificate for its own name. The user has to interpret the name in the URL and the context of the service too.
• protect against the errors of the application: a page transferred with HTTPS can also contain an XSS flaw (injected script), bad authorization handling, or a faulty CORS setting (chapter 8). It does not stop injection either: the attacker's data reaches the server over an encrypted channel too.
• protect against the server: the party at the other end of the connection sees the content.
• hide all the metadata (see above).
• protect the section behind the TLS endpoint. If a reverse proxy terminates the TLS (see 4.4), the protection between the browser and the proxy does not automatically extend to the section between the proxy and the application server. The whole path determines where the communication still needs to be protected.

flowchart LR
    B[Browser] -->|HTTPS / TLS| P[TLS endpoint: proxy]
    P -->|internal connection: a question of separate protection| A[Application]
    A --> D[(Database)]

Mixed content

If an HTTPS page tries to load an unprotected (HTTP) resource, mixed content arises. According to MDN, the weak point is that an attacker can see or modify the unprotected resource, and a script is especially dangerous because it can rewrite any part of the page. The current rule distinguishes two categories: upgradable content (for example images, audio, video) is rewritten by the browser to https, while blockable content (for example scripts, style sheets, fetch() calls) is blocked. The fix: every resource should load over HTTPS or by a relative address.

HSTS: preventing downgrade

What happens if the user types only kurzuspont.example? The browser may first turn to an http:// address, from where the server redirects to https://:

$ curl -I http://github.com
HTTP/1.1 301 Moved Permanently
Location: https://github.com/

This first HTTP request is unprotected: an attacker could intercept it on the way and "downgrade" the connection. HSTS (HTTP Strict Transport Security) solves this: the server uses the Strict-Transport-Security header to tell that the host may from then on only be reached over HTTPS.

$ curl -sI https://github.com | grep -i strict
strict-transport-security: max-age=31536000; includeSubdomains; preload

max-age gives in seconds how long the browser should remember the rule (31,536,000 seconds is one year). According to MDN, includeSubDomains extends it to the subdomains; the rule takes effect only after the first HTTPS visit, so the solution of the preload list is that the list of hosts is built into the browsers. With a valid rule, the browser rewrites an http address to https before building the connection, and the user cannot step through a certificate error. A HSTS header received over HTTP is ignored by the browser.

The Secure attribute of the session cookie fits the same thought: it ensures that the browser does not send the cookie over plain HTTP (see 7.2).

Worked example: the HTTPS setup of Kurzuspont

Question	Solution
Login and enrolment should be protected	The whole site runs over HTTPS.
The http:// address should redirect	301 to https.
Downgrade should not be possible	A HSTS header with a long max-age.
No mixed content should remain	The logo, the style sheet, and the script also load over HTTPS or by a relative address.
The internal section should also be protected	The connection between the reverse proxy and the application is also encrypted, or runs on a closed network.
The padlock is not enough	The errors of the application must be prevented with the tools of chapter 8.

Common misconceptions

Statement	Clarification
"An HTTPS page is surely trustworthy."	The protection of the connection does not prove the good intentions of the provider.
"Encryption hides all network data."	Some metadata of the connection may be visible.
"The certificate guarantees the truth of the content."	It helps in checking the connection tied to the name.
"A certificate error is an HTTP 404."	The TLS check can stop the process before the HTTP response.
"TLS automatically protects the internal sections too."	After the TLS endpoint there can be a separate section.

In brief

• HTTPS gives HTTP traffic confidentiality, integrity, and server authentication.
• On a certificate error the browser stops before sending an HTTP request.
• HTTPS does not judge the provider, and does not protect against the errors of the application.
• Mixed content weakens the protection; HSTS prevents downgrade.
• The protection of the whole path is a question behind the TLS endpoint too.

Review questions

1. Why can a phishing page also get a valid certificate?
2. What is the difference between a certificate error and a 404?
3. What is mixed content, and why is it dangerous on an HTTPS page?
4. What does HSTS mean, and why does it not protect on the first visit?

Learning resources

• Transport Layer Security (MDN) — the relation of TLS and HTTPS.
• Mixed content (MDN) — mixed content and how browsers handle it.
• Strict-Transport-Security (MDN) — the details of HSTS.
• badssl.com — test pages with deliberately faulty TLS setups.