As part of my general 'web infosec' reading habit, I recently wound up going through Scott Helme's Using security features to do bad things (via). This discusses a number of ways to use HSTS and HPKP for evil, both for sniffing out what sites people have visited and for damaging sites that you've compromised. It's neat work and I like keeping up on this sort of stuff in general, but initially I didn't think it had any particular relevance to us. Then a little light went on in my mind: user CGI scripts can add HTTP headers to their responses, as can the user run web servers we use to solve the multiuser PHP problem.

We have innocently, ignorantly, and accidentally given everyone on our primary web server the ability to inflict a certain amount of what I'll call 'TLS suicide' on us. With no work at all they can use HSTS to force all future access to any part of our web server to be over TLS for some time (which isn't too big a problem, as we're not likely to drop TLS on the server). With work they can probably inflict some degree of HPKP suicide on us, although this mostly isn't something they could do by accident.

(There doesn't even have to be any malign intent, just people's ignorance or default software configurations. I can easily see someone simply following directions on how to increase the security of their site, directions that include 'add HSTS headers', and not realizing that this affects our entire site instead of just their URLs. HPKP would be harder to do this way, but it might be possible; I'm sure there are going to be canned directions on how to set up HPKP for a site that uses Let's Encrypt certificates.)

Fortunately I think the fix is simple; we just need to specifically configure Apache to strip out any (user-added) Strict-Transport-Security, Public-Key-Pins, or Public-Key-Pins-Report-Only headers in responses. The standard Apache mod_headers module will do this for you if configured appropriately, and I think the appropriate configuration is just:

Header unset Strict-Transport-Security
Header unset Public-Key-Pins
Header unset Public-Key-Pins-Report-Only

This prevents accidents, but the bad news is that people can add their own Header directives if you allow FileInfo overrides for .htaccess files. Unfortunately a ton of important Apache options are all under FileInfo; if you turn off allowing FileInfo in .htaccess, you disable things like Redirect and RewriteRule. Not to mention that there are entirely legitimate reasons to add headers in .htaccess files. Based on carefully reading the Apache documentation on configuration sections, I think we can do what we want here by putting these Header directives inside a <Location> directive, because that will be applied last. In order to be sure, I'm going to have to test this (carefully and probably on a test server, just in case).

(I suppose I can test the behavior here using a harmless X-something header instead of one of the dangerous TLS ones.)