Bug 84796 - RFE: Add support for HSTS to Web UI
Summary: RFE: Add support for HSTS to Web UI
Status: VERIFIED FIXED
Alias: None
Product: ZCS
Classification: Unclassified
Component: Mail - Web Client (show other bugs)
Version: 8.0.5_ZCS_IronMaiden
Hardware: All Browsers All
: P4 enhancement
Target Milestone: JudasPriest
Assignee: Phil Pearl
QA Contact: Girish Bhamare
URL: http://tools.ietf.org/html/rfc6797
Keywords: 8_7_0, DOC_REQ, Security
Depends on:
Blocks: 60404
  Show dependency treegraph
 
Reported: 2013-11-05 11:43 EST by Malte Stretz
Modified: 2015-09-16 08:40 EDT (History)
7 users (show)

See Also:
Feature Notes:
Eng Days:
QA Days:
Root Cause: ---
Fix Type: ---
QA Analysis: ---
CVE Number:
CVSS Score:
CVE Reporter:
ZCO Subcategory:
Queue Position:
Test Stories:
User Stories:
UX:
Developer:
PM:
QA:
Docs:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Malte Stretz 2013-11-05 11:43:25 EST
If zimbraMailMode is set to redirect or https it would be great if there was an option to enable HSTS (HTTP Strict Transport Security) and set the max-age.

The simplest solution would be an LDAP attribute like zimbraMailSSLPolicyMaxAge which if missing disables the feature and if set (zero is a valid option) a header with the given value is sent, ie:
  Strict-Transport-Security: max-age=${zimbraMailSSLPolicyMaxAge}
Comment 1 Malte Stretz 2014-02-19 09:48:26 EST
Current workaround:

zmprov mcf +zimbraResponseHeader "Strict-Transport-Security: max-age=31536000"
Comment 4 Phil Pearl 2015-04-23 15:36:21 EDT
Malte (or anyone else interested) would you be willing to comment on if you feel there is a need to do something different than simply utilizing zimbraResponseHeader as you mentioned in comment #1?

I realize that my not be the most elegant solution, but at the same time it isn't clear that there's a great benefit from doing something more elegant either (e.g. setting the header only upon accessing specific endpoints).  Thoughts?

Note, we also have bug 98938 not where we're considering having the equivalent of zimbraResponseHeader for the proxy.
Comment 5 Malte Stretz 2015-04-24 05:01:26 EDT
You mean apart from the fact that setting zimbraResponseHeaders is broken right now (cf. bug 98495)? :-)

Setting the headers manually is definitely doable;  if there was a GUI to add headers (is there?).
Comment 6 Phil Pearl 2015-05-12 14:25:43 EDT
Marking this as fixed for 8.7 release.  The official solution is to use zimbraResponseHeader (broken in 8.5 and 8.6) in a manner similar to comment #1.

If desired, a separate bug will be necessary to capture the desire to be able to set zimbraResponseHeader via the Admin [web] Console.  (I'm not sure if that was the original intent of this bug or not, sorry if I misinterpreted this)

To verify this bug:
- ideally we would have QA automation set and check that zimbraResponseHeader gets set and passed appropriately when accessing ZWC.

Another option would be to mark this bug as a duplicate of bug 98495 I suppose since that bug was blocking of using zimbraResponseHeader as desired.
Comment 7 Girish Bhamare 2015-05-20 02:33:04 EDT
(In reply to Phil Pearl from comment #6)
> Marking this as fixed for 8.7 release.  The official solution is to use
> zimbraResponseHeader (broken in 8.5 and 8.6) in a manner similar to comment
> #1.
> 
> If desired, a separate bug will be necessary to capture the desire to be
> able to set zimbraResponseHeader via the Admin [web] Console.  (I'm not sure
> if that was the original intent of this bug or not, sorry if I
> misinterpreted this)
> 
> To verify this bug:
> - ideally we would have QA automation set and check that
> zimbraResponseHeader gets set and passed appropriately when accessing ZWC.
> 
> Another option would be to mark this bug as a duplicate of bug 98495 I
> suppose since that bug was blocking of using zimbraResponseHeader as desired.


Added separate bug 99547 for the above issue  and marking this as verified as it working fine from back end.