Bug 1430035 - Support HTTP Strict Transport Security (HSTS) policy
Summary: Support HTTP Strict Transport Security (HSTS) policy
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.7.0
Assignee: Phil Cameron
QA Contact: zhaozhanqi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-07 17:22 UTC by Marc Nozell
Modified: 2022-08-04 22:20 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: See docs PR 5365 Reason: Result:
Clone Of:
Environment:
Last Closed: 2017-12-18 13:22:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Origin (Github) 16544 0 None None None 2017-09-25 18:27:45 UTC
Red Hat Product Errata RHBA-2017:3464 0 normal SHIPPED_LIVE Red Hat OpenShift Container Platform 3.7 bug fix and enhancement update 2017-12-18 18:22:05 UTC

Comment 2 Phil Cameron 2017-09-26 13:36:09 UTC
origin PR 16544
openshift-docs PR 5365

Comment 3 openshift-github-bot 2017-09-28 17:37:31 UTC
Commits pushed to master at https://github.com/openshift/origin

https://github.com/openshift/origin/commit/9ebaefce365aaa449088cbe3758fe6c1d4a08b04
Router support for Strict-Transport-Security (hsts)

Strict-Transport-Security (hsts) policy (RFC 6797) is a way that the
host can tell clients to always use https requests to the host. It is
controlled by adding the haproxy.router.openshift.io/hsts_header annotation
to the route. When the Strict-Transport-Security response is received
by a client, it observes the policy until:
1) It is updated by another response from the host, or
2) the max-age decrements to 0

The max-age is only updated when the client receives a response
that contains the Strict-Transport-Security header. Otherwise
that the client just decrements max-age to 0.  When hsts policy is
no longer desired for a host set max-age=0 in the annotation rather
than deleting the annotation. When a client makes another request
the response will cause the policy to be discarded.

In the route add the annotation:
metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains

Where max-age=<seconds> is required and
includeSubDomains and
preload
are optional.

When the annotation is present for a route https responses will
include the Strict-Transport-Security header with the annotation's
value. The annotation value must contain max-age=<seconds> and it
may contain either or both of: includeSubDomains and preload.

max-age sets the length of time the client should force requests
to the host to be https.  max-age=31536000 is one year.

includeSubDomains requests all subdomains of the host should
observe the max-age of the host.

preload tells the client to include this host in its host preload list.

Bug: 1430035
https://bugzilla.redhat.com/show_bug.cgi?id=1430035

Trello:
https://trello.com/c/H1FhCI1I/452-3-sccfsi-support-hsts-policy

https://github.com/openshift/origin/commit/621b7e3cf0d6bd7fe80615240def5b32de2bcdb9
Merge pull request #16544 from pecameron/bz1430035

Automatic merge from submit-queue (batch tested with PRs 14558, 16544).

Router support for Strict-Transport-Security (hsts)

Strict-Transport-Security (hsts) support (RFC 6797) is a way that the
host can tell clients to always use https requests to the host. It is
controlled by adding the haproxy.router.openshift.io/hsts_header annotation
to the route. When the Strict-Transport-Security response is received
by a client, it respects the request until:
1) It is updated by the response from the host to another request.
2) the max-age decrements to 0

The max-age is only updated when the client receives a response
that contains the Strict-Transport-Security header. Other than
that the client just decrements max-age to 0.  When hsts is no longer
desired for a host set max-age=0 in the annotation rather than
deleting the annotation.  There is no telling when a client will 
make a request to the host.

In the route add the annotation:
metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains

Where max-age=<seconds> is required and
includeSubDomains and
preload
are optional.

When the annotation is present for a route https responses will
include the Strict-Transport-Security header with the annotation's
value. The annotation value must contain max-age=<seconds> and it
may contain either or both of: includeSubDomains and preload.

max-age sets the length of time the client should force requests
to the host to be https.  max-age=31536000 is one year.

includeSubDomains requests all subdomains of the host should
observe the max-age of the host.

preload tells the client to include this host in its host preload list.

Bug: 1430035
https://bugzilla.redhat.com/show_bug.cgi?id=1430035

Trello:
https://trello.com/c/H1FhCI1I/452-3-sccfsi-support-hsts-policy

Comment 9 Phil Cameron 2017-11-10 14:17:47 UTC
This is in 3.7, why is it still in MODIFIED state?

Comment 12 zhaozhanqi 2017-11-14 03:06:35 UTC
Verified this issue on v3.7.7

we can set the hsts policy in CLI, steps

1. Create pod/svc
2. Create edge/reencrypt route
3. Set hsts for the route, eg:
   oc annotate route myroute haproxy.router.openshift.io/hsts_header=max-age=100;includeSubDomains;preload
4. Check the route response header
  curl --head https://$route -k
  
  the result should contain 'strict-transport-security=max-age=100;includeSubDomains;preload'

Since this issue still need to fix in web console. So file another bug 1512759 to trace.

Comment 15 errata-xmlrpc 2017-12-18 13:22:48 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:3464


Note You need to log in before you can comment on or make changes to this bug.