Project

Profile

Help

Issue #7804

closed

Default to enabling HSTS even for self-signed certificates, offer a knob to disable it

Added by spredzy about 4 years ago. Updated almost 4 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
Installer - Moved to GitHub issues
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
OS:
Triaged:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

Currently we only enable HSTS when a user provides a certificate. This is 'technically' the right approach given HSTS aims to prevent a MITM attack.

However some users/customers run security/vuln scan against their deployed tools, and HSTS is one of the item that is often check.

If deployed out-of-the-box, the HSTS check will fail. To offer user/customer a better experience, even if using self-signedd certificate we should default to enabling HSTS (and offer a knob to disable it for valid reasons[1])

[1] https://www.jeffgeerling.com/blog/2018/fixing-safaris-cant-establish-secure-connection-when-updating-self-signed-certificate

Actions #1

Updated by pulpbot about 4 years ago

  • Status changed from NEW to POST

Added by spredzy about 4 years ago

Revision a3992141 | View on GitHub

pulp_webserver: Allow one to decide HSTS enablement via a knob

fixes #7804

Added by spredzy about 4 years ago

Revision a3992141 | View on GitHub

pulp_webserver: Allow one to decide HSTS enablement via a knob

fixes #7804

Actions #2

Updated by spredzy about 4 years ago

  • Status changed from POST to MODIFIED
Actions #3

Updated by dkliban@redhat.com almost 4 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF