The security dashboard of the world’s most popular sites, SecureTheWeb.info, uses data collected by a Python script that visits the sites. This Python script in turn relies on the underlying OpenSSL implementation on the computer where it is running. This is a limitation because the script cannot check for protocols that Python or OpenSSL don’t support, but which would be necessary information to web users. For example, some Python builds don’t know about SSLv3 while others don’t know about TLSv1.2:

Therefore I decided to look for a lower-level evaluation framework, like Mozilla’s TLS Observatory. On the site, I was entering the domains of various reference sites that I use for testing, and this is where I discovered an anomaly.

One of my reference sites is the online banking portal for the State Bank of India, onlinesbi.com. When I ran this through Observatory, it displayed the following results.

The two red bands at the top say that the SSL certificate returned by the site will distrusted in future versions of Chrome and Firefox, for reasons that are not germane here. This move has been coming for a while.

While I knew that SBI’s certificate was slated for blacklisting from when I last checked in January, I was surprised that the bank still hadn’t taken any action. I also didn’t recall seeing any issues in my browsers although I visit the site regularly.

So I pulled up the site in Chrome (version 66) and sure enough, it showed a green “All-OK” lock in the address bar.

What’s more, the certificate that the site sent wasn’t issued by Symantec, but rather by Digicert, and it looked like it may have been issued in January 2018 (at least, that’s when it’s validity starts).

After double-checking that the Observatory’s results were fresh and not cached, it was clear that SBI’s server was using two different certificates.

Up to now, any time I specified the SBI server’s address, I’d just entered “onlinesbi.com”. But the address that Chrome was displaying was www.onlinesbi.com, even though that’s not what I had entered. So it looked like there was a browser redirection taking place. The network results in Chrome confirmed that there was indeed a HTTP 307 directive from the server.

However, while I had confirmed that Observatory’s results weren’t cached, I wasn’t sure whether Chrome wasn’t doing the redirect based on some caching logic, similar to what it does for HSTS. This wasn’t a case of HSTS, but I didn’t know yet that it was a redirect coming from the server and not some local browser logic. So I pulled the site via the command line using curl. And to be doubly sure that my local machine wasn’t impacting the results somehow, I ran the command on an EC2 instance.

As expected, the server returned an HTTP 307 response for the URL http://onlinesbi.com, redirecting to https://www.onlinesbi.com, which has a valid Digicert certificate. SSL/TLS validation tools such as Observatory, SSL Labs and others, however, evaluate the certificate that’s returned with the server’s response and don’t follow redirect prompts. The sites do however, upgrade, or rather form the request, for the HTTPS URL of the site. So when I type in “onlinesbi.com” in Observatory, it actually checks https://onlinesbi.com. It now made sense that Observatory was getting a different certificate at https://onlinesbi.com than Chrome was at https://www.onlinesbi.com.

I wondered what the server response was for https://onlinesbi.com. I dropped it into Chrome and saw the following:

This URL too was redirected to https://www.onlinesbi.com. It looked like the people who configured SBI’s server had installed the new certificate on https://www.onlinesbi.com and redirected plain http://onlinesbi.com to the secure https://www.onlinesbi.com, but they didn’t replace the certificate on soon-to-be-distrusted https://onlinesbi.com, which still had the Symantec certificate.

To be consistent I pulled up the URL https://onlinesbi.com in curl, and I was surprised to see following warning message:

When I reran the command with the option to turn off certificate verification, instead of receiving an HTTP 302 response as in Chrome, curl received an HTTP 200 response and  the page contents. This result didn’t make sense, because curl doesn’t automatically follow redirects. I verified that against another server that I knew returned an HTTP 302 response, and in fact curl displayed an HTTP 302 response.

So why is curl displaying the redirected-to page results when the ignore-warning flag is set? Is it loading the redirected page, or is the SBI server returning the page contents? This is a mystery that I am not able to solve. As a film noir fan, I’m going to leave that thread dangling and move on.

At this point, Chrome, and Firefox, behavior is consistent with their schedules for distrusting Symantec certificate, because this one was issued to SBI sometime in November 2017. By then Google had already announced its plans, so it’s unfortunate that SBI still got a Symantec certificate rather than switching to another provider. On the other hand, the curl (and wget, I checked) developers (or the maintainers of the Ubuntu certificate stores, I suspect, because curl on Mac OS doesn’t complain about this Symantec certificate) seem to have gone ahead and blacklisted all Symantec certificates.

It seems to be an oversight, but SBI needs to fix their certificate for https://onlinesbi.com. Otherwise visitors using Chrome (the most popular browser in India) and Firefox will see a warning like the one above.