Is there life after the failure of popular browsers to support the architecture of NPAPI
The tasks of strict two-factor authentication and enhanced electronic signature are traditionally solved using the means of cryptographic protection of information made in the form of tokens. To enhance protection against cybercriminals when a user is working in a potentially vulnerable environment, tokens and Trust Screen devices are additionally used.
Default browsers do not provide web page code with access to tokens and Trust Screen devices. To implement such access requires the development of special extensions (plug-ins) for browsers or the use of other technologies. It is also possible to create Java applets and local proxy servers.
Browser extensions are typically developed using the Netscape Plugin Application Programming Interface (NPAPI) architecture. Java applets also worked through NPAPI. For Microsoft Internet Explorer, as a rule, an ActiveX component was developed.
In connection with the identified vulnerabilities and limitations of the NPAPI architecture, browser developers began to refuse to support this architecture in favor of their own solutions. So, Google Chrome proposed using Native Messaging technology, and Mozilla Firefox using WebExtensions technology. Yandex.Browser also announced the rejection of NPAPI. Microsoft announced the creation of its own development platform extensions for the browser Microsoft Edge. Apple, despite all the NPAPI vulnerabilities, has not yet offered any alternative extension technologies for the Safari browser, leaving Mac OS X users potentially vulnerable.
As a result, before the developers of web applications, it became necessary to adapt the applications under the "zoo" of various technologies used by different browsers. This situation has complicated the task of multibrowser support of tokens to implement security functions, increased the developers' costs for embedding and supporting such devices, created a large number of potential points of failure and caused backward compatibility problems. In particular, the NPAPI architecture supports both synchronous and asynchronous methods for working with tokens. Native Messaging technology - only asynchronous.
The question arose - is there an alternative approach that would get rid of the "zoo" of various technologies, provide support for tokens in all popular browsers and allow for the release of solutions that are most compatible with previous ones that used NPAPI. This moment was very important, as many technology partners of Aladdin RD used JC-WebClient 2.4 solution based on NPAPI plug-ins in their web applications, and therefore it was important for us to make it as easy as possible for our partners to migrate to a new version of JC-WebClient. Ideally, I would also like to immediately support the Microsoft Edge browser in Microsoft Windows 10 so that you get something like this:
')
As an alternative technology, common to all browsers, we considered the local proxy server technology.
This architecture allows token support for all popular browsers, but it has certain drawbacks. In particular:
In connection with these shortcomings, such an architecture was recognized by us as not the most optimal. We continued research further.
After analyzing the solution options and performing research and development projects on this topic, they decided to develop an application based on the local web server technology. The main difference between this architecture and the local proxy server technology is that the local web server does not interfere with the transfer of application traffic from the browser to the remote server. The browser accesses the local web server only to access the functions of the token and / or Trust Screen devices. The user, while working with the electronic service, still sees in the address bar of his browser the correct URL of one of the pages of the web application.
The developed prototype for the Microsoft Windows platform proved that this technology works. However, the first version of the prototype had a significant limitation - accessing the local web server was only via HTTP, which did not allow the web application to work over HTTPS with a remote web server due to browser restrictions. We developed the second version of the prototype, implementing TLS support in the local web server so that the browser can establish a connection with both the local and remote web server via HTTPS.
The second version of the prototype successfully worked in all popular browsers, including Microsoft Edge , for which Microsoft has not yet provided the possibility of developing extensions. Based on the second version of the prototype, we developed a new version of the JC-WebClient 3.0 solution, providing support for all popular browsers.
The main components of JC-WebClient 3.0:
The selected local web server technology enabled JC-WebClient 3.0 to support both synchronous and asynchronous methods for working with tokens. Another advantage was the fact that the developers of web services, who previously worked through NPAPI, did not lose the ability to save the session of working with a token when switching from one page to another page of their application within a single browser tab. These two circumstances allowed to maximally facilitate the migration process from version JC-WebClient 2.4 to version 3.0 for technology partners. To switch to the new version, it is enough to add several lines of the same code on each web page that works with the token, without the need to redo the logic of the graphical interface.
The separation of contexts between different browser tabs allowed protecting against malicious scripts trying to access a token from a tab different from the one in which the web application runs.
In a typical scenario, the JC-WebClient 3.0 distribution is downloaded from the web service page and installed on the user's computer once, and then the local web server from the JC-WebClient 3.0 bundle automatically starts immediately after installation. The local web server runs exclusively in the background. It consumes a minimum of resources and does not have any controls. It is also easy to update it when a new version is released.
As a means of strong two-factor authentication and electronic signature, JC-WebClient 3.0 uses USB tokens / smart cards JaCarta and eToken with hardware-implemented Russian cryptoalgorithms. Among them - JaCarta GOST , JaCarta PKI / GOST , eToken GOST . As a trusted Trust Screen-device - Antifrod-terminal , own product of the company "Aladdin RD".
Version JC-WebClient 3.0 supports the Microsoft Windows platform, ranging from Microsoft Windows XP to Microsoft Windows 10. In the near future, release 3.1 is planned, which will support Mac OS X and Linux. Follow our news.
Default browsers do not provide web page code with access to tokens and Trust Screen devices. To implement such access requires the development of special extensions (plug-ins) for browsers or the use of other technologies. It is also possible to create Java applets and local proxy servers.
Browser extensions are typically developed using the Netscape Plugin Application Programming Interface (NPAPI) architecture. Java applets also worked through NPAPI. For Microsoft Internet Explorer, as a rule, an ActiveX component was developed.
The end of the NPAPI era
In connection with the identified vulnerabilities and limitations of the NPAPI architecture, browser developers began to refuse to support this architecture in favor of their own solutions. So, Google Chrome proposed using Native Messaging technology, and Mozilla Firefox using WebExtensions technology. Yandex.Browser also announced the rejection of NPAPI. Microsoft announced the creation of its own development platform extensions for the browser Microsoft Edge. Apple, despite all the NPAPI vulnerabilities, has not yet offered any alternative extension technologies for the Safari browser, leaving Mac OS X users potentially vulnerable.
As a result, before the developers of web applications, it became necessary to adapt the applications under the "zoo" of various technologies used by different browsers. This situation has complicated the task of multibrowser support of tokens to implement security functions, increased the developers' costs for embedding and supporting such devices, created a large number of potential points of failure and caused backward compatibility problems. In particular, the NPAPI architecture supports both synchronous and asynchronous methods for working with tokens. Native Messaging technology - only asynchronous.
The question arose - is there an alternative approach that would get rid of the "zoo" of various technologies, provide support for tokens in all popular browsers and allow for the release of solutions that are most compatible with previous ones that used NPAPI. This moment was very important, as many technology partners of Aladdin RD used JC-WebClient 2.4 solution based on NPAPI plug-ins in their web applications, and therefore it was important for us to make it as easy as possible for our partners to migrate to a new version of JC-WebClient. Ideally, I would also like to immediately support the Microsoft Edge browser in Microsoft Windows 10 so that you get something like this:
')
Local proxy server
As an alternative technology, common to all browsers, we considered the local proxy server technology.
This architecture allows token support for all popular browsers, but it has certain drawbacks. In particular:
- when working through a local proxy server, the user sees in the address bar of the browser not the real URL of the web page on the remote server, but something like 127.0.0.1 : 12345, which makes the user’s work with such a service not quite convenient;
- all application traffic between the browser and the remote server is redirected to the local proxy server, which makes the local proxy server a bottleneck of the entire system;
- Working with each individual web application requires a separate configuration of the local proxy server on the client side.
In connection with these shortcomings, such an architecture was recognized by us as not the most optimal. We continued research further.
Local web server
After analyzing the solution options and performing research and development projects on this topic, they decided to develop an application based on the local web server technology. The main difference between this architecture and the local proxy server technology is that the local web server does not interfere with the transfer of application traffic from the browser to the remote server. The browser accesses the local web server only to access the functions of the token and / or Trust Screen devices. The user, while working with the electronic service, still sees in the address bar of his browser the correct URL of one of the pages of the web application.
The developed prototype for the Microsoft Windows platform proved that this technology works. However, the first version of the prototype had a significant limitation - accessing the local web server was only via HTTP, which did not allow the web application to work over HTTPS with a remote web server due to browser restrictions. We developed the second version of the prototype, implementing TLS support in the local web server so that the browser can establish a connection with both the local and remote web server via HTTPS.
The second version of the prototype successfully worked in all popular browsers, including Microsoft Edge , for which Microsoft has not yet provided the possibility of developing extensions. Based on the second version of the prototype, we developed a new version of the JC-WebClient 3.0 solution, providing support for all popular browsers.
The main components of JC-WebClient 3.0:
- Local web server
- Enables interaction between a web page and a token / Trust screen device over HTTPS
- Provides separation of PC / SC contexts for different browser tabs.
- Enables interaction between a web page and a token / Trust screen device over HTTPS
- JCWebClient.js client script
- Provides web pages with JavaScript APIs for working with JC-WebClient methods.
- Downloaded to a web page from a local web server
- When the methods of the objects implemented in the JCWebClient.js file are called from the context of the web application page, the control is transferred to the local web server and then to the token
- Provides web pages with JavaScript APIs for working with JC-WebClient methods.
- Monitoring service, made in the form of OS service
- Runs a local web server when the OS boots
- Monitors the integrity of the local web server.
- Restarts the local web server in case of abnormal situations / failures in the OS
- Runs a local web server when the OS boots
Benefits
The selected local web server technology enabled JC-WebClient 3.0 to support both synchronous and asynchronous methods for working with tokens. Another advantage was the fact that the developers of web services, who previously worked through NPAPI, did not lose the ability to save the session of working with a token when switching from one page to another page of their application within a single browser tab. These two circumstances allowed to maximally facilitate the migration process from version JC-WebClient 2.4 to version 3.0 for technology partners. To switch to the new version, it is enough to add several lines of the same code on each web page that works with the token, without the need to redo the logic of the graphical interface.
The separation of contexts between different browser tabs allowed protecting against malicious scripts trying to access a token from a tab different from the one in which the web application runs.
Ease of use
In a typical scenario, the JC-WebClient 3.0 distribution is downloaded from the web service page and installed on the user's computer once, and then the local web server from the JC-WebClient 3.0 bundle automatically starts immediately after installation. The local web server runs exclusively in the background. It consumes a minimum of resources and does not have any controls. It is also easy to update it when a new version is released.
Supported hardware devices
As a means of strong two-factor authentication and electronic signature, JC-WebClient 3.0 uses USB tokens / smart cards JaCarta and eToken with hardware-implemented Russian cryptoalgorithms. Among them - JaCarta GOST , JaCarta PKI / GOST , eToken GOST . As a trusted Trust Screen-device - Antifrod-terminal , own product of the company "Aladdin RD".
Supported Operating Systems
Version JC-WebClient 3.0 supports the Microsoft Windows platform, ranging from Microsoft Windows XP to Microsoft Windows 10. In the near future, release 3.1 is planned, which will support Mac OS X and Linux. Follow our news.
Source: https://habr.com/ru/post/306920/
All Articles