Fortinet Document Library

Version:

Version:


Table of Contents

Handbook

Download PDF
Copy Link

HSTS and HPKP support

Starting from its 4.8.1 release, FortiADC supports HSTS and HPKP to offer enhanced web security to its users.

HSTS

HSTS, or HTTP Strict Transport Security, is a web security mechanism used to guard websites against malicious attacks, such as protocol downgrading and cookie hijacking. Once implemented, HSTS enables the web server to force web browsers to use secure HTTPS connections when interacting with it, and prohibit the use of insecure HTTP connections.

An HSTS-enabled web application server communicates its HSTS policy to web browsers via an HTTPS header field called "Strict-Transport-Security". The policy dictates that web browsers should only connect to the server via a secure connection during the period of time (i.e., max-age) specified in the policy. Based on the HSTS policy, compliant web browsers either automatically convert insecure (i.e., HTTP) connections to secure (i.e., HTTPS) ones or show an error message and bar the user from accessing the server if it cannot ensure the security of the connection.

HSTS is used to address SSL/TSL-stripping attacks and prevent hackers from stealing your cookie-based web login credentials.

HSTS syntax:

  • Strict-Transport-Security: max-age=<expire-time> [; includeSubDomains][; preload]
  • Preload validation and registration:
  • https://www.chromium.org/hsts
  • https://hstspreload.org

HPKP

HPKP, or HTTP Public Key Pinning, is a web security mechanism used to prevent HTTPS websites from impersonation via mis-issued or fraudulent security certificates.

The first time a client browser accesses an HTTPS web application server, the server sends to the client a set of public keys, which are the only ones that should be trusted for connections to the domain. This list of "pinned" public key hashes are used for subsequent connections between the client and the server, and are valid only for the period of time that is specified in the HPKP policy.

HPKP syntax

  • Public-Key-Pins: pin-sha256="<pin-value>"; pin-sha256=“<backup-pin-value>”; max-age=expireTime [; includeSubDomains][; report-uri="reportURI"]
  • Public-Key-Pins-Report-Only: pin-sha256="<pin-value>"; pin-sha256=“<backup-pin-value>”; max-age=<expire-time> [; includeSubDomains][; report-uri="<uri>“]

HPKP note and validation

  • Note a host as the known pinned host:
  • Identified only by its domain name, but never IP
  • Three conditions:
    • PKP received over an error-free TLS, including possible HPKP validation
    • At least one intersection
    • The host must set a backup pin.
  • Pin Validation:
  • Ignore superfluous certificates
  • Check intersection, at least one
  • Can be disabled for some hosts according to local policy

Good HPKP practices

  • If used incorrectly, HPKP could lock out users for a long period of time. Using backup certificates and/or pinning the CA certificate is recommended.
  • Use small value for max-age.
  • When a certificate expires, generate a new certificate using the old key if pinning is done on the server certificate.

HPKP calculation

Use the following OpenSSL commands to calculate HPKP fingerprints:

  • openssl rsa -in my-rsa-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
  • openssl ec -in my-ecc-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
  • openssl req -in my-signing-request.csr -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
  • openssl x509 -in my-certificate.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
  • openssl s_client -servername www.example.com -connect www.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

Implementation of HSTS/HPKP

Support for HSTS and HPKP can be implemented for both SSL offloading and forward proxy.

SSL offloading

On the Server Load Balance>Virtual Server>Content Rewriting page, do the following:

  1. (Optional) Add a content rewriting rule to delete the HSTS or HPKP header received from the real server. Skip this step if the real server did not send any HSTS or HPKP header. See Delete HTTP header (optional).
  2. Add one content rewriting to add an HSTS or HPKP header, customize the max-age and other optional fields. See Add HTTP header.

Delete HTTP header (optional)

Add HTTP header

Forward proxy

On the Server Load Balance>Virtual Server>Content Rewriting page, do the following:

  1. (Optional) Add a content rewriting rule to delete the HSTS or HPKP header received from the real server. Skip this step if the real server did not send any HSTS or HPKP header.
  2. Do nothing to HSTS header (let it pass through).

HSTS and HPKP support

Starting from its 4.8.1 release, FortiADC supports HSTS and HPKP to offer enhanced web security to its users.

HSTS

HSTS, or HTTP Strict Transport Security, is a web security mechanism used to guard websites against malicious attacks, such as protocol downgrading and cookie hijacking. Once implemented, HSTS enables the web server to force web browsers to use secure HTTPS connections when interacting with it, and prohibit the use of insecure HTTP connections.

An HSTS-enabled web application server communicates its HSTS policy to web browsers via an HTTPS header field called "Strict-Transport-Security". The policy dictates that web browsers should only connect to the server via a secure connection during the period of time (i.e., max-age) specified in the policy. Based on the HSTS policy, compliant web browsers either automatically convert insecure (i.e., HTTP) connections to secure (i.e., HTTPS) ones or show an error message and bar the user from accessing the server if it cannot ensure the security of the connection.

HSTS is used to address SSL/TSL-stripping attacks and prevent hackers from stealing your cookie-based web login credentials.

HSTS syntax:

  • Strict-Transport-Security: max-age=<expire-time> [; includeSubDomains][; preload]
  • Preload validation and registration:
  • https://www.chromium.org/hsts
  • https://hstspreload.org

HPKP

HPKP, or HTTP Public Key Pinning, is a web security mechanism used to prevent HTTPS websites from impersonation via mis-issued or fraudulent security certificates.

The first time a client browser accesses an HTTPS web application server, the server sends to the client a set of public keys, which are the only ones that should be trusted for connections to the domain. This list of "pinned" public key hashes are used for subsequent connections between the client and the server, and are valid only for the period of time that is specified in the HPKP policy.

HPKP syntax

  • Public-Key-Pins: pin-sha256="<pin-value>"; pin-sha256=“<backup-pin-value>”; max-age=expireTime [; includeSubDomains][; report-uri="reportURI"]
  • Public-Key-Pins-Report-Only: pin-sha256="<pin-value>"; pin-sha256=“<backup-pin-value>”; max-age=<expire-time> [; includeSubDomains][; report-uri="<uri>“]

HPKP note and validation

  • Note a host as the known pinned host:
  • Identified only by its domain name, but never IP
  • Three conditions:
    • PKP received over an error-free TLS, including possible HPKP validation
    • At least one intersection
    • The host must set a backup pin.
  • Pin Validation:
  • Ignore superfluous certificates
  • Check intersection, at least one
  • Can be disabled for some hosts according to local policy

Good HPKP practices

  • If used incorrectly, HPKP could lock out users for a long period of time. Using backup certificates and/or pinning the CA certificate is recommended.
  • Use small value for max-age.
  • When a certificate expires, generate a new certificate using the old key if pinning is done on the server certificate.

HPKP calculation

Use the following OpenSSL commands to calculate HPKP fingerprints:

  • openssl rsa -in my-rsa-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
  • openssl ec -in my-ecc-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
  • openssl req -in my-signing-request.csr -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
  • openssl x509 -in my-certificate.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
  • openssl s_client -servername www.example.com -connect www.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

Implementation of HSTS/HPKP

Support for HSTS and HPKP can be implemented for both SSL offloading and forward proxy.

SSL offloading

On the Server Load Balance>Virtual Server>Content Rewriting page, do the following:

  1. (Optional) Add a content rewriting rule to delete the HSTS or HPKP header received from the real server. Skip this step if the real server did not send any HSTS or HPKP header. See Delete HTTP header (optional).
  2. Add one content rewriting to add an HSTS or HPKP header, customize the max-age and other optional fields. See Add HTTP header.

Delete HTTP header (optional)

Add HTTP header

Forward proxy

On the Server Load Balance>Virtual Server>Content Rewriting page, do the following:

  1. (Optional) Add a content rewriting rule to delete the HSTS or HPKP header received from the real server. Skip this step if the real server did not send any HSTS or HPKP header.
  2. Do nothing to HSTS header (let it pass through).