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.