Chrome, Chromium, and Certificate Caching

June 18, 2015

Just like a good System Administrator, I set on one day to replace the current certificate for the main site that’s used for HTTPS. I issue a new CSR, I send it to the Certificate Authority, I get the Signed Certificate, Revoke the old one and after a total of 5-10 minutes I have the web server serving the new certificate to all connecting clients.

Of course, I need to verify that I do indeed serve the new certificate and everything went correctly. I had the website open in Google Chrome on Mac OS X and I had not refresh it yet after the certificate change. I click the https:// before the URL and I examine the certificate. Everything is fine, since the certificate is the old one. I press ⌘+R, which is refresh for all you Windows / Linux / BSD users to refresh the page, I click the certificate and I still see the old version. I ssh into the web server again, reload the configuration, refresh again, and still it shows the old certificate. I even try restarting the entire web server, still nothing. I go to Chrome, press ⌘+Shift+R, which is Force Refresh (purge cache), and I still see the same certificate. I type the URL again, press Enter, still the same. I open a new Tab, a new Window, still the old certificate. Every other browser could perfectly see the new certificate so it must be something with caching.

I open a new Bug Report in Chromium Issue Tracker and soon I am told that this “cannot be exploited” since Google Chrome does not refresh the UI only when the certificate changes from a trusted state to another trusted state. After a bit of discussion, I mention Domain Validation and Extended Validation certificates, as well as their differences in the UI representation. The guys let me know that by the time the user is shown the visual difference, her cookies are already sent to the attacker server and therefore she has already been compromised.

However, what if the user accesses a service like PayPal for example that logs out the user after every session? What if the attacker wants to trick the user into logging in? Let’s assume that somehow he managed to get a DV Certificate and is sitting in the middle of PayPal and the User. He intercepts the original connection, he presents a PayPal clone but the user notices she doesn’t see the PayPal, Inc. [US] in the address bar and doesn’t login.

Now what if the attacker exploits this bug? What if Google Chrome or Chromium never shows the user a simple https:// and instead shows PayPal, Inc. [US]? She will have no way of knowing and telling the two sites apart. This is the impact of the bug. Since both DV and EV certificates use the same protocol (HTTPS), but have different visual warnings, and that’s the only way to distinguish the difference, forcing the browser not to show even that can have an impact in the user decision on whether to enter that e-mail and that password or not.