Page MenuHomePhabricator

Description for "security.strict-transport-security" is incorrect
Closed, WontfixPublic


The "security.strict-transport-security" option does not behave as documented. When this option is turned off, Phabricator sends a Strict-Transport-Security header with a max-age of 0:

Strict-Transport-Security: max-age=0; includeSubdomains; preload

When turned on, it simply toggles the max-age:

Strict-Transport-Security: max-age=31536000; includeSubdomains; preload

This doesn't match the option documentation, which says: "Enable HTTP Strict Transport Security (HSTS)." Clicking on it, you see "HTTP Strict Transport Security (HSTS) sends a header..."

Therefore, if the HSTS option is turned off, you would expect that header to *not* be sent...because turning it on "sends a header".

The description of the option (both in the short-text and the longer description) should make it clear that the header is *always* sent and the option simply controls the set max-age.

Event Timeline

jefferai raised the priority of this task from to Needs Triage.
jefferai updated the task description. (Show Details)
jefferai added a subscriber: jefferai.
epriestley claimed this task.
epriestley added a subscriber: epriestley.

This is behaving as expected. We send the header with "max-age=0" in order to overwrite older settings user agents may have cached.

In that case, please add an option to turn this off. This plays havoc with systems that are setting that header elsewhere (such as on a reverse proxy to php-fpm) because you get conflicting headers, which leads to unexpected behavior.

The much better approach would be to allow the administrator to configure the age. If they wanted to overwrite older settings, they could turn on the header and set max-age to 0 on their own. Blindly sending it when the option that claims to control whether it's sent is set to false is misleading and problematic.

We're satisfied with the current behavior. If you're rewriting responses in a proxy, you should overwrite the header.

I *could* overwrite the header, if I knew it was being set in the first place.

The current behavior does *not* match what's documented.

jefferai renamed this task from Strict-Transport-Security option not honored to Description for "security.strict-transport-security" is incorrect.Apr 8 2015, 12:20 AM
jefferai reopened this task as Open.
jefferai updated the task description. (Show Details)

I've updated the description to document the issue of the option description being incorrect.

epriestley removed a subscriber: epriestley.
chad added a subscriber: chad.
chad removed a subscriber: chad.
epriestley claimed this task.

@jefferai how did you overwrite the headers? I'm encountering this exact same issue.

For reference, even though this isn't right. I figured I'd put my notes here for someone else to find and help me out:

location / {
    client_max_body_size 32M;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;
    proxy_set_header        X-Frame-Options DENY;
    proxy_set_header        X-XSS-Protection "1; mode=block";
    proxy_set_header        Referrer-Policy no-referrer-when-downgrade;

    proxy_redirect		    off;