HTTP Public Key Pinning about eotk HOT 5 CLOSED

If I understand your issue correctly, it sounds like this is because the public-key-pins header is being forwarded to the client by eotk when it might be more useful to avoid doing that.

Looks to me like adding either:

proxy_hide_header public-key-pins;

or

more_clear_headers "public-key-pins";

to the server{ } directive of the nginx.conf template should fix the issue as then the HPKP header won't be forwarded to users arriving via .onion

There's probably a good argument for masking the Strict-Transport-Security header in the same way too, but I'll see what @alecmuffett thinks.

from eotk.

@sainslie I think this is a pointer to me needing to write actual documentation; I already have a couple of switchables:

• set header_csp_suppress 1
• set header_hsts_suppress 1

...but maybe the HSTS one (at least) should be default-on, and @ajhaydock has (I think) spotted a deficiency in the existing code, re the *pins headers

Also, maybe CSP should be rewritten using Lua, not nuked?

from eotk.

CSP is an interesting one. I probably wouldn't nuke it completely like the HSTS/HPKP headers, but rewriting it might be a good idea.

Letting CSP headers pass through unedited might cause issues if we want to present the client with an onion served over regular HTTP, and the site admin has decided to use something like img-src https: in the CSP, which would allow for the loading of image content from any domain, but only over HTTPS.

I don't know how common that sort of policy is, but I've used that particular directive myself before to allow for image embedding and hyperlink thumbnails on a forum-style site (but without allowing the site to serve mixed-content which would result in a yellow HTTPS warning triangle in the client's browser).

from eotk.

@sainslie - check the new code :-)

from eotk.

Bump? I plan to close this tomorrow if no further input?

from eotk.