Clouds, responsibility and unexpected situations with SSL certificates

When discussing cloud platforms, the question naturally arises about the reliability of the platform and the responsibility of the provider for its problems. At the same time, users have the highest expectations - everything should work perfectly 25 hours a day, 9 days a week and all days of the year. In the real world, all kinds of problems arise - either when switching off the external power supply, the transition to the reserve one does not work , then there will be condensate (water) at the bottom of the tank with diesel fuel , then on February 29 “in a year” it will be calculated by an increase of one year .

Not the last place in the list of problems is occupied by certificates for SSL. For example, a certificate of a cloud service may expire completely unexpectedly.

Who is to blame and what to do?

You don’t need to go far for examples - this can happen to everyone. At the end of February 2013, three certificates of the Windows Azure Storage service expired at once. Chaos and a series of destruction followed; English-language sites wrote a lot about this. In general, the replacement of certificates was planned in advance and almost completely completed. Here it is described why the replacement was not carried out to the end and at the same time no one noticed anything until the moment when it was already too late. It is highly recommended to read at least as a scenario of the epic trilogy and be sure to read before leaving comments on the radius of curvature of the hands.

Let's take a closer look at this situation. Soon after hour X, these two posts appeared: one and two. They have a certain screenshot that shows the URL for which the certificate is intended, and the certificate validity period. Something like this (only here is a newer certificate and a screenshot from another program):



Where did this screenshot come from? Maybe this is a screenshot of the Enterprise version of some superprogram, available only to administrators starting at level 80, with a license for 100,500 money?

Let's try the following experiment. What is described below seems trivial to many (and quite rightly), but it turns out that so many experts were not even aware of such transcendent possibilities of software. So ...

Take the most common browser. Ognelis 20 is suitable, only the location of controls will depend on the choice of browser. Create an empty tab and type in the address bar, for example,github.com After the GitHub main page opens, the address bar looks like this:



You see, there is an image of the castle and the inscription “GitHub, Inc. (US). ” You can poke this inscription with the mouse, this form with a button will appear.



After clicking on the button, a form appears with details and, among other things, the View Certificate button.



Click on this button ... VERY UNEXPECTED ...



... exactly the same form as in the very first screenshot, adjusted for a specific certificate.

So, at a completely arbitrary point in time, we found out that the github.com certificate is valid until the end of July 2013. We did not need any special privileges or any special software. And most importantly, all the necessary information constantly - every day and around the clock - was in plain sight.

Now the reader is already eager for comments to sarcastically ask, “why should we check the validity period of the certificate of someone else’s service”. In fact, why, because "this is not our certificate"?

Let's see what exactly happens when a certificate expires. Some site had a certificate valid until, for example, February 30th. All browsers and other programs are happy to establish a secure connection to this site. Suddenly came February 31 and the certificate has expired. What changed? Cryptographic keys are still keys, and the signature on the certificate still matches the certificate. What is the point of validity?

Formally, the meaning is very simple - after the certificate expires, it becomes impossible to verify whether the certificate has been revoked. Accordingly, you can still establish a connection to the server, but there is some chance that its certificate has been revoked, and it is impossible to verify this. There is one more reason - the certificate is usually issued by a third-party company and it wants to receive money for issuing a new certificate, but we will pretend that it is secondary.

Accordingly, the client has three options: either hope for the best and establish a connection, or warn the user (the warning will probably be ignored) and establish a connection, or refuse to establish a connection and give an error message.

A significant proportion of software, including Microsoft .NET Framework, by default, goes the third way. Accordingly, if, for example, our ABBYY Cloud OCR SDK service expires a certificate, many of our users will not be able to work with us through a secure connection, because their software will simply refuse to establish a connection.

This is exactly what happened with Azure Storage in February. On Windows Azure, some services depend on Azure Storage. Therefore, when the certificate expired at Azure Storage, they refused to work with it and not only third-party user services, but also part of the Windows Azure services, interrupted the deployment of changes and the creation of new services .

So, it turns out that if our certificate expires, our users have problems. And if not our certificate expires, our users still have problems because our service will fail.

You have not changed your mind asking why we should check a certificate of a third-party service?

It is not particularly difficult. The code for accessing the certificate in C # takes up to 10 lines - you need to create a WebRequest, send an HTTP request to the server, then access the ServicePoint.Certificate property of the request. Like that:

var request = (HttpWebRequest)(WebRequest.Create(uri));
using(var response = request.GetResponse()) {
}
var serverCertificate = request.ServicePoint.Certificate;

A simple programming exercise for morning workout interns. Then it remains to make this code called once every couple of days automatically for the URL of each of the services on which our service depends. At the same time, it is not harmful to check your own certificate. If a certificate expires in less than, say, two weeks, we send ourselves a notification. Yes, it would be nice if these notifications were read by someone who can respond to them.

Now, when they forget to renew the certificate two weeks before the deadline, it will no longer be SUDDENLY, you can contact the service provider in advance, leave a message on the support forum , chat with the service reseller company - in general, there is much more room for action.

Or you can simply believe in the provider, and then explain to your users that "it's all their fault." They are to blame, but whose users will suffer?

Dmitry Meshcheryakov,
product department for developers