Clouds, liability and unexpected situations with SSL certificates

When discussing cloud platforms, it is quite natural to ask a question about the reliability of the platform and the responsibility of the provider for its problems. At the same time, user expectations are highest - everything should work perfectly 25 hours a day, 9 days a week and all the days of the year. In the real world, all sorts of problems arise - if the external power supply is disconnected, the transition to the reserve one will not work , then condensate (water) will appear at the bottom of the tank with diesel fuel , then February 29 will be calculated a year by one in a year .

Not least in the list of problems are certificates for SSL. For example, completely unexpectedly, a certificate of a cloud service may expire.

Who is to blame and what to do?

There is no need to go far for examples - it can happen to anyone. 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 websites wrote a lot about it. In general, the replacement of certificates was planned in advance and carried out almost completely. Here it is described why the replacement was not carried out to the end and at the same time no one noticed anything until it was too late. It is highly recommended to read at least as an epic trilogy script and be sure to read before leaving comments about the radius of curvature of the hands.
')
Let's take a closer look at this situation. Shortly after hour X, these two posts appeared: one and two . They have a screenshot that shows the URL for which the certificate is intended, and the validity period of the certificate. 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 super program that is available only to single members starting at level 80, with a license for 100,500 money?

Let's try the next experiment. What is described below will seem trivial (and quite rightly) to many, but it turns out that many experts did not even know about such extreme software capabilities. So…

Take the most common browser. Firestone 20 will do; only the location of the controls will depend on the choice of the 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 a picture of the castle and the inscription “GitHub, Inc. (US) ". In this inscription, you can poke the mouse, this form will appear with a button.



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



We press on this button ... EXTREMELY 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 certificate github.com is valid until the end of July 2013. We did not need any special privileges and no 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 torn in the comments, to maliciously ask, “why should we check the validity of the certificate of someone else’s service”. In fact, why, because “this is not our certificate”?

Let's see what happens when a certificate expires. Some site had a certificate valid until, well, for example, February 30th. All browsers and other programs gladly established a secure connection to this site. Suddenly, February 31 came and the certificate expired. What changed? The 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. 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 pretend that it is secondary.

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

A significant proportion of software, incl. Microsoft .NET Framework, the default is the third way. Accordingly, if, for example, our ABBYY Cloud OCR SDK service expires on 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. In Windows Azure, some of the services depend on Azure Storage. Therefore, when the certificate expired for Azure Storage, not only third-party user services, but also part of Windows Azure services, refused to work with it, including 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 the validity of our certificate does not expire, our users still have problems, because our service fails.

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

This is not particularly difficult. The code for accessing the certificate in C # is within 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 the morning trainee warm-up. It remains to make sure that this code is called every two 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 any certificate expires in less than, say, two weeks, send a notification. Yes, it would be good if someone would be able to read these notifications.

Now, when they forget to renew the certificate two weeks before the deadline, it won't be EXTREMELY possible, you can contact the service provider in advance, leave a message on the support forum , talk with the service reseller - 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." Blame "they", but whose users will suffer?

Dmitry Mescheryakov,
product department for developers