Don't fail localhost pages with INSECURE

Testing a local site using a self-signed certificate seems pretty reasonable. Wdyt about us allowing localhost in our INSECURE checks?

[connorjclark]

@brendankenny this is not the situation we are in though. IIUC, I think @jimmydief is saying that even though --ignore-certificate-errors is being used and the bad certificate page is not being shown. Lighthouse still throws. This would also explain the explicit workaround behavior in puppeteer.

Example: lighthouse https://expired.badssl.com --chrome-flags="--ignore-certificate-errors" exits immediately with a fatal error.

I confirmed that with and without that flag, the same security states are seen from the protocol.

diff --git a/lighthouse-core/gather/driver.js b/lighthouse-core/gather/driver.js
index 299a8c78..fe2653e9 100644
--- a/lighthouse-core/gather/driver.js
+++ b/lighthouse-core/gather/driver.js
@@ -780,6 +780,7 @@ class Driver {
        * @param {LH.Crdp.Security.SecurityStateChangedEvent} event
        */
       const securityStateChangedListener = ({securityState, explanations}) => {
+        console.log({securityState, explanations});
         if (securityState === 'insecure') {
           cancel();
           const insecureDescriptions = explanations

Seems --ignore-certificate-errors disables interstitials and removes feature gating for things like WebSockets, but does not modify how the protocol sees the security state.

Adding an option to disable that check (so it would hit the timeout instead) seems fine, but I’m loath to have some automated way of circumventing Chrome’s security protections.

This approach would require a flag for the DevTools client too btw. Which would probably lead to checking it for the first time it’s needed, and then never ever unchecking it, which is scary.

People use LH to test sites with authentication, for instance, and I don’t want to be responsible for folks XSSing themselves 😃

I’m wondering if we don’t really need to concern ourselves about that? If a machine is compromised such that a malicious website is being served at localhost, it would seem that the entire machine is compromised anyways. (EDIT: Actually, I’m failing to realize the attack could also come from the network level, if the DNS had been spoofed or something? I have a sketchy understanding of security in regards to this.)

–

I’m leaning towards total disabling of the security check for localhost. A special audit just for localhost seems fine too, although at first glance I’m unsure how that audit would be made with our current setup (how do we move the current code to a gatherer, and still early exit for non-local sites?).

There is another complication for any automated approach, which is that not all local sites use the hostname localhost. What if the local site uses any other hostname? Seem an opt in for “this is a local site” flag would be necessary to handle this completely.

[patrickhulce]

@MichaelJCole the version of Lighthouse in which this has been fixed has not yet been released.