Dealing with HSTS and Charles and Chrome in the same room

If you’re a front-end developer, you should be aware of Charles. If you think of Charles as a Ming Vase, and not as the Emperor of Austria, feel free to skip this paragraph. Charles is a local proxy application, that enables you to monitor, edit, replace http/https traffic on your machine. This is epic, because you can replace the build on your website to your local one without deploying, and you can rewrite specific back end responses to help testing edge cases.

This is clearly a zone of danger

Method 1: type in "thisisunsafe" to the error window.

So when using Charles, it need to bypass security configs, as obviously it stands as a man in the middle. And this is all well known, nowadays both Chrome and Safari lets you accept the fact that it’s risky. If you see this image, 2 years ago you could type in ‘danger’ (or as I always preferred, ‘dangerzone’) to the window, and it let you bypass this screen. Nowadays it changed to ‘badidea’ ** update: now it’s changed again, to ‘thisisunsafe‘ **

** update 2: I’ve found that wireless keyboard might have troubles with the code below

function handleKeypress(e) {
  var BYPASS_SEQUENCE = 'thisisunsafe';
  if (BYPASS_SEQUENCE.charCodeAt(keyPressState) == e.keyCode) {
    keyPressState++;
    if (keyPressState == BYPASS_SEQUENCE.length) {
      sendCommand(CMD_PROCEED);
      keyPressState = 0;
    }
  } else {
    keyPressState = 0;
  }
}

I’ve been using this, and worked quite well, until I found a new type of NET::ERR_CERT_AUTHORITY_INVALID message, where the website uses HSTS.

No “Continue to website” button at the error page

So, what is HSTS? HTTP Strict Transport Security enforces to use Transport Layer securely. More on this at Scott Helme’s website.

Method 2: delete domain from net-internals

The point is, typing ‘badidea’ often fixes the problem. But what if not? Turns out, Chrome has a built-in cache for the HSTS failed websites, and will block it for you without even trying the connection again. In this case, you’ll have to visit chrome://net-internals/#hsts and you’ll see this beautiful console:

net-internals console in Chrome

Once you’ve opened this, you should try to load the blocked page once again (to be sure), and you can query for HSTS info by the domain (top level worked for me). After query, you’ll see some nice data, that’s causing the issue. So all you have to do now is delete the domain from the HSTS set of Chrome. Once thats done, it will allow you to let you accept the danger of the website, and continue developing. I’ve used this solution on my Mac.

Remember to Follow!

I really hope you liked this article, please comment, clap, subscribe for more!