Chrome SSL Warning: "You cannot proceed because the website operator has requested heightened security for this domain. "

Question

I'm trying to go to the URL below, and Chrome warns me that the wildcard certificate is not valid for this domain.

https://chart.apis.google.com/chart?cht=qr&chs=100x100&chl=otpauth%3A%2F%2Ftotp%2FTest123%204%3Fsecret%3DTKQWCOOJ7KJ4ZIR

At first I thought it was a quirk on how chrome handles URLs with many dots in a wildcard cert, however I see this text in the warning, and am also unable to click through

You cannot proceed because the website operator has requested heightened security for this domain.

Question

• Is this a problem with Chrome's wild card certs and sub domains that are more than 2 layers deep?

• Does the error mean that the website owner has "done something" to make wildcard certificates not work for subdomains?

Answer 1

Please try this Chrome hack: when browser shows the page with the invalid certificate message, type in your keyboard the word "proceed" and then hit Enter.

You should be able to proceed to the requested page.

On newer versions of Chrome, you may have to type "danger" and hit Enter instead.

Answer 2

This is a feature called HTTP Strict Transport Security - see http://dev.chromium.org/sts and http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security.

Sites that send the Strict-Transport-Security header (or are preloaded in Chrome, such as apis.google.com) cannot be accessed when the server SSL cert is invalid.

The certificate sent for chart.apis.google.com is valid for *.google.com, but since the wildcard only matches a single subdomain, chart.apis is invalid.

If apis.google.com were not included in the STS list, Chrome would also show a button to ignore the error and proceed.

--

(The correct HTTPS url for Google Chart API is https://chart.googleapis.com/chart)

Answer 3

This error message triggered by a feature of the web called "HTTP Strict Transport Security" which allows website operators to tell browsers that their site must only be contacted over a secure HTTPS connection. This feature is specified in RFC 6797. In particular, you may want to read section 12.1, which says:

No User Recourse

Failing secure connection establishment on any warnings or errors (per Section 8.4 ("Errors in Secure Transport Establishment")) should be done with "no user recourse". This means that the user should not be presented with a dialog giving her the option to proceed. Rather, it should be treated similarly to a server error where there is nothing further the user can do with respect to interacting with the target web application, other than wait and retry.

Essentially, "any warnings or errors" means anything that would cause the UA implementation to announce to the user that something is not entirely correct with the connection establishment.

Not doing this, i.e., allowing user recourse such as "clicking through warning/error dialogs", is a recipe for a man-in-the-middle attack. If a web application issues an HSTS Policy, then it is implicitly opting into the "no user recourse" approach, whereby all certificate errors or warnings cause a connection termination, with no chance to "fool" users into making the wrong decision and compromising themselves.

So if you are a website user seeing this error message you should just wait; there's nothing you can do about this other than report the problem to the website's owner and wait for them to fix it.

It is, however, worth noting that Chrome is not entirely compliant with this policy, as it does have a way to bypass the error message by entering a certain string of characters on your keyboard when you see the message. This feature is deliberately designed to be obscure to prevent users who don't fully understand what they're doing from harming their own security just to get rid of the error, and out of respect for that goal I will not post the string here, and I encourage others to avoid doing so as well. This page is ranked highly on Google for the query "You cannot proceed because the website operator has requested heightened security for this domain.", so uninformed users searching for the error message will likely end up here.

If you're a developer or security expert and you fully understand the implications of bypassing this warning, you can find the current bypass string (base64-encoded for additional obscurity) in the Chrome source code in the file components/security_interstitials/core/browser/resources/interstitial_large.js. Typing the (decoded) string you find there into Chrome when you see a TLS security error page will bypass that page and force Chrome to load the site. (You can test this on https://subdomain.preloaded-hsts.badssl.com/.) Please use this information responsibly.

Also, since you asked, I should also note that none of this has anything to do with wildcard certificates. Wildcard certificates only match a single level of subdomain, and this is not specific to Chrome. See RFC 6125, section 6.4.3 for details on that.