[wp-trac] [WordPress Trac] #47577: Streamline detecting and enabling HTTPS

[WordPress Trac]

#47577: Streamline detecting and enabling HTTPS
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Administration                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion needs-unit-tests has-    |     Focuses:
  patch                                          |
-------------------------------------------------+-------------------------

Comment (by miinasikk):

 Replying to [comment:12 flixos90]:
 > How about we also issue a request to a random media file, and
 potentially even a core asset, to make the same check (only if the root
 URL is different, e.g. when using a CDN)? Only if all of them support
 HTTPS, we'll tell the user that their site supports HTTPS. It is
 admittedly a special case, but probably enough people are using a CDN (and
 hopefully they're all good enough to support HTTPS) to make this worth
 having.

 Are you suggesting that we should check if a random media file that's
 already on the site supports HTTPS and if it doesn't then consider the
 site not supporting HTTPS?

 Some concerns with that:
 - We would check just one random media file. This would mean that it could
 happen that the chosen file is from CDN but it could also be from some
 other random source / be a leftover or irrelevant and not accurately
 reflect the site being ready for HTTPS.
 - How would you choose the random media file, could it differ at different
 times and have different results?
 - This wouldn't really reflect accurately if the site supports HTTPS,
 having external resources not supporting HTTPS means that the external
 site isn't supporting HTTPS, not the local.

 If the CDN doesn't support HTTPS then maybe it would be good to change the
 service, too.

 Also, the sites that aren't already supporting HTTPS aren't going to have
 the CSP header anyway -- these sites would actually need to take steps to
 convert the site to HTTPS where some issues can be expected. It would
 probably be unexpected for the sites already supporting HTTPS when the
 resources suddenly display broken, for those, however, the information
 about being or not being HTTPS ready wouldn't be relevant anymore. WDYT?

 > I'd prefer to not expose this to the user, at least not in here - it's
 very technical information and most folks will have no idea what it is.
 ''If'' we want to expose it, then I'd prefer just doing it in the Info
 part of Site Health, with all the other technical data.

 Fair point that it's very technical information and out of the place. The
 technical information does make sense under Info more, however, we should
 first actually check if the header hasn't been overwritten by a filter
 before displaying the information about it. Also, if we already display
 the CSP header information then should others be displayed as well?
 Perhaps you're right and it's not that important to display it in such
 detail.

 It would be good to have information under the Status with the HTTPS
 information though, however, not sure what would be a good way to tell
 that "External resources that don't support HTTPS might break after
 switching to HTTPS -- make sure that you don't have those!". Do you think
 it'd be unnecessary information for the user and we could just skip all
 the information part? Perhaps I'm overthinking.

 > After reading the previous discussion and reviewing the patch, I'd
 prefer if we just set the `upgrade-insecure-requests` value in the filter
 and not bothered about the very specific `report-only` cases. You'd need
 to use a filter to modify the behavior anyway, and you could just as well
 remove our filter if you wanted to do so.

 That's true, however, I think that the report-only case would be helpful
 for transitioning, we could document the filter better to make it more
 clear what's it for, it's very likely that the report-only header is not
 something that everyone is aware of and the header would be just removed
 instead of trying to transition. So having that filter could help.


 > What we should probably do though is check, if the `Content-Security-
 Policy` header is already set, and if so append our value (maybe we should
 even check whether it's not already set). We don't wanna override other
 CSP headers people may be using already.

 It wouldn't make sense to just append our value without knowing what's
 there before, that would cause duplicate directives and not really work
 (e.g. having default-src twice). Checking first if it already exists and
 adding the header only then is a good point, no need to overwrite the
 exising efforts.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47577#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform