EDS in the browser: problems, solutions, personal experience

Those who have ever encountered the need to implement an electronic digital signature in the browser know well what a headache it is for a developer, and especially for a web developer who has managed to get used to open standards, the rule that his software works equally well in all browsers and he doesn’t care what axis the user has, and so on to the other charms of the web.

In fact, today the situation with the EDS in the browser is still not as sad as a few years ago, but it is still far from ideal. This theme also rose several times on Habré, for example, here and here .
')
Under the cut there is a story about the problem itself, about how this problem can be solved, about how I solved it, as well as personal impressions about how things are going with EDS in Belarus.

The essence of the problem and what will happen to it tomorrow

The problem is quite trivial: you want to implement a digital signature on the client in the browser, are you thinking of using your favorite javascript for this? Nothing will work, and all because browsers simply do not provide an API for working with certificates, tokens, signatures, and so on. and etc. ... What should this mechanism look like in the dreams of any web developer? Probably something like this:

//    window.crypto.getCertificates(options); // -  window.crypto.signText(text, options);    ... 

Yes, and it would be great if all this was supported by domestic GOSTs ... well, I was really dreaming about it. Unfortunately, you will not find anything like this in modern browsers. There are, of course, timid attempts to implement something similar in Mozilla , but the warning in the title of the article is very sad:



By the way, if someone tried to use this API, unsubscribe, very interesting.
There is also a mention of Crypto in the W3C repository . Most likely the work started there not long ago, there is little material there now, but the latest update was recently, so the work is on:



Will all this be brought to mind, and most importantly, when this happens, today, probably, no one will tell you. So what is left for developers who need to do here and now?

Crutches

I want to make a reservation right away, EDS in the browser is probably one of the few cases when a developer simply has to use various tricks and crutches, I will list the most popular ones:

• using ActiveX ( CAPICOM )
• use of browser plugins
• use of java applets
• use of the tunnel ( Stunnel )

Let's consider the shortcomings of each of them, I will not describe the merits, IMHO, for all crutches it is one - “well, it works”.

ActiveX

Used in 99% of cases when it is necessary to implement a digital signature in the browser, do not hesitate to use it banks, trading platforms and other serious organizations. In my opinion, now it is the worst of the options, why?
Are you used to using your favorite FF or Chrome for work? - Forget it! ActiveX only works in IE.
Do not like to dig into the browser settings? - And will have to! Before everything works, you pretty much have to delve into the security settings of your IE.
Or maybe you are so advanced that you have Win7, and even x64, and maybe you have also installed IE9-10? - Very vain, most likely you will fail.
Jokes, but Microsoft announced that CAPICOM support was discontinued and the component would not be developed further, and the latest version of CAPICOM, which is officially supported, was in Windows Vista.

Browser Plugins

If something is not in the browser, but you really need it, there is a way out - write your plugin. The main problem here is that if you want it to work in all browsers, you will have to write a plugin for each of them. There is still a problem with support - no one guarantees that your plugin will work in the new version of the browser (or the old one), remember the situation with FF, when Mozilla switched to an accelerated release of versions. Well, another problem with the fact that you at least have to put this plugin. More information about this solution can be found here .

Java applet

Everything seems to be not so bad, and the code is written once, and it works in all browsers, and even nothing needs to be set up. But if you do not have the JRE installed, nothing will happen. Most often works in conjunction with OpenSSL , although using JNI, you can tie a lot of things. Yes, for everything to work, the applet itself must be signed.

Tunnel

A relatively new way, it works according to the proxy principle, the basic idea is that a specially formed POST request passes through a tunnel when sent to the server, it signs data from this request, substitutes the signed data in the request field instead of data and everything is sent further to the server and there already come data from the EDS. The principle is quite simple, but effective. This method has a practical implementation . You can read more here . In order for all this to work, this tunnel must actually be installed on the client, although it can be run from a USB flash drive.

As you can see, there are solutions, although each of them has certain limitations and reservations, I deliberately did not deal with such problems as working in different operating systems, supporting GOSTs, working on mobile platforms - there are more problems here, and this is also very important.

Personal experience

Yes, I was also “lucky” to engage in the implementation of EDS in the browser. I myself work in one of the Minsk software development companies, and once I had to urgently implement support for EDS in a browser on one of the systems. Frankly, I first wanted to do as 99% in this situation and use ActiveX. But, gradually plunging into the problem, I began to realize that this would turn into a headache for users first, and then for me as a developer. There was no time to write plugins for each browser. There remained two solutions: java applet and tunnel. It turned out to be decisive here ... you won't believe it, GOST.

The fact is that in Belarus, as in Russia, our GOST is adopted for the procedures for the development and verification of electronic digital signatures, only here we call it STB RB 1176.2–99 and no RSA to you. Give your GOST to every country! And if for the Russian GOST there are practical implementations of each of the above methods, you can choose any, then Belarusian developers are much less fortunate. On this occasion, even personally talked with representatives of the company that produces cryptographic software for our country. The conversation left a double impression. The people are quite adequate, they understand the problem, but they say that it is not their task, they, they say, wrote a cryptographic provider that satisfies all the guests and has passed the state expertise, and how you are going to use it is not their problem.

- We can only suggest that you use ActiveX.
- Well, what about the problems associated with it?
- We, of course, have certain achievements using java applets, but we cannot offer them as a product yet. Developing this kind of software is not our task.

In my opinion, this is not exactly the right position, because by offering a product, it is commercially beneficial to offer the environment to it.

Well, okay, we work with what is. And what do we have? Earlier our company had already written a desktop application using the functions of EDS, and there was a component working directly with CryptoAPI , it was written in delphi. I really wanted to somehow use this experience of my colleagues and not to waste time on it myself, and most importantly, to do it quickly. But how to do that? To connect component on delphi and web application? Answer on the diagram:



Briefly explain what is happening. When we need to sign something, we call the java applet function using javascript:

  document.CryptoAPI.sign(text); 

The applet, in turn, communicates with the desktop-application through sockets, passes the necessary parameters to it, the application signs what we requested (the previously written component of the colleagues is used for this), and sends the signed data to the applet, which in turn calls the browser function:

  function signResult(params) { //-     } 

For communication between the applet and the application, a simple protocol was invented and implemented; this probably took most of the time, since the rest was quite simple. The disadvantages here are typical: the presence of a JRE and a desktop application that will either be installed or run from somewhere. It will be interesting to hear your comments regarding this method.

I hope that the above information will help to better understand the problem of digital signature in the browser for those who encountered it.