EDS в браузъра: проблеми, решения, личен опит

Тези, които поне веднъж са се сблъсквали с необходимостта да внедрят електронен цифров подпис в браузър, знаят добре какво главоболие е за разработчика и особено за уеб разработчика, който е свикнал с отворените стандарти, правилото, че неговият софтуер работи еднакво добре във всички браузъри и той не се интересува коя ос има потребителят, както и от други прелести на мрежата.

Всъщност днес ситуацията с цифровия подпис в браузъра все още не е толкова тъжна, както преди няколко години, но все още е далеч от идеалната. Тази тема също беше повдигната няколко пъти върху Хабре, например тук и тук.

Под разрезът е разказ за самия проблем, за това как този проблем може да бъде решен, за това как го реших, както и лични впечатления за това как стоят нещата с EDS в Беларус.

Същността на проблема и какво ще се случи с него утре

Проблемът е доста тривиален: искате ли да внедрите EDS на клиента в браузъра, мислите ли да използвате любимия си javascript за това? Нищо няма да работи и това е така, защото браузърите просто не предоставят API за работа със сертификати, маркери, подписи и т.н. и така нататък ... Как трябва да изглежда този механизъм в мечтите на всеки уеб разработчик? Вероятно нещо подобно:

Да, и също би било чудесно, ако всичко това подкрепи националните ГОСТ ... е, аз просто мечтаех за това. За съжаление няма да намерите подобно нещо в съвременните браузъри. Разбира се, има плахи опити да се приложи нещо подобно в Mozilla, но предупреждението в заглавието на статията е много тъжно:

Между другото, ако някой се опита да използва този API, отпишете се, много интересно.
Има и споменаване на Crypto в хранилището на W3C. Най-вероятно работата там започна не толкова отдавна, там сега няма много материали, но последната актуализация беше наскоро, така че работата продължава:

Дали всичко това ще бъде припомнено и най-важното, кога ще се случи, вероятно никой няма да ви каже днес. И така, какво остава да направим за разработчиците, които се нуждаят тук и сега?

Искам да направя резервация веднага, EDS в браузър е може би един от малкото случаи, когато разработчикът просто е принуден да използва различни трикове и патерици, ще изброя най-популярните от тях:

използване на ActiveX (CAPICOM)
използване на приставки за браузъри
с помощта на Java аплети
използване на тунел (Stunnel)

Нека да разгледаме недостатъците на всеки от тях, няма да описвам предимствата, IMHO, всички патерици имат едно - "ами, работи".

Използва се в 99% от случаите, когато е необходимо да се внедри EDS в браузър, банките, платформите за търговия и други сериозни организации не се колебаят да го използват. Според мен сега това е най-лошият вариант, защо?
Свикнали ли сте да използвате любимите си FF или Chrome за работа? - Забрави! ActiveX работи само в IE.
Не обичате да ровите в настройките на браузъра? - И трябва! Преди всичко да работи, трябва да се впуснете в настройките за сигурност на вашия IE.
Или може би сте толкова напреднали, че имате Win7 и дори x64, или може би сте инсталирали IE9-10 за себе си? - Много напразно, най-вероятно няма да успеете.

Шегите настрана, но Microsoft обяви, че поддръжката за CAPICOM е прекратена и по-нататък компонентът няма да бъде разработен, а последната версия на CAPICOM, която се поддържа официално, е в Windows Vista.

Приставки за браузър

Java аплет

Изглежда, че всичко не е толкова лошо и кодът е написан веднъж и работи във всички браузъри и дори не е необходимо да конфигурирате нищо. Но ако нямате инсталиран JRE, нищо няма да се случи. Най-често работи съвместно с OpenSSL, въпреки че използвайки JNI, можете да прецакате много. Да, за да работи всичко, самият аплет трябва да бъде подписан.

Сравнително нов метод, той работи на принципа на прокси, основната идея е, че специално формирана POST заявка, когато се изпраща до сървъра, преминава през тунел, който подписва данните от тази заявка, замества подписаните данни в поле за заявка вместо данни и всичко се изпраща допълнително към сървъра и вече има получени данни с цифров подпис. Принципът е съвсем прост, но ефективен. Този метод има практическо изпълнение. Можете да прочетете повече тук. За да работи всичко това, този тунел всъщност трябва да бъде инсталиран на клиента, въпреки че можете да го стартирате от флаш устройство.

Както можете да видите, има решения, въпреки че всеки от тях има определени ограничения и резерви, умишлено не съм засегнал такива проблеми като работа в различни операционни системи, поддържане на GOST, работа на мобилни платформи - тук има още повече проблеми и това също е много важно.

Личен опит

Да, имах и „късмет“ да внедря цифровия подпис в браузъра. Аз самият работя в компания за търговия на борси в Минск и веднъж се наложи спешно да внедря EDS поддръжка в браузър в една от системите за търговия. За да бъда честен, първоначално исках да действам като 99% в такава ситуация и да използвам ActiveX. Но постепенно навлизайки в проблема, започнах да осъзнавам, че това първо ще се превърне в главоболие за потребителите, а след това и за мен като разработчик. Нямаше време за писане на приставки за всеки браузър. Оставаха само две решения: java аплет и тунел. Тук се оказа решаващо ... няма да повярвате, ГОСТ.

Факт е, че в Беларус, както и в Русия, е приет собствен ГОСТ за процедурите за разработване и проверка на електронен цифров подпис, само че тук той се нарича STB RB 1176.2–99 и няма RSA за вас. Дайте своя GOST на всяка държава! И ако за руския ГОСТ има практически реализации на всеки от горните методи, можете да изберете всеки, тогава беларуските разработчици имат много по-малко късмет. По този повод дори лично разговарях с представители на компания, която произвежда криптографски софтуер за нашата страна. Разговорът остави смесено впечатление. Хората са съвсем адекватни, разбират проблема, но казват, че това не е тяхната задача, казват, написали са крипто доставчик, който отговаря на всички GOST и е преминал държавния изпит, но как ще го използвате не е техния проблем.

- Можем само да ви предложим да използвате ActiveX.
- Ами какво да кажем за проблемите, свързани с него?
- Разбира се, имаме определени разработки с използването на Java аплети, но като продукт все още не можем да ви ги предложим. Разработването на този вид софтуер не е нашата задача.

Според мен това не е съвсем правилната позиция, тъй като когато се предлага продукт, е икономически изгодно да се предложи средата за него.

Е, добре, работим с това, което имаме. Какво имаме? По-рано нашата компания вече беше написала десктоп приложение, което използва функции EDS, и имаше компонент, работещ директно с CryptoAPI, беше написан в delphi. Наистина исках по някакъв начин да използвам този опит на колеги и да не губя време за него сам и най-важното, да го направя бързо. Но как да го направя? Свържете компонент delphi и уеб приложение? Отговорът е в диаграмата:

Ще обясня накратко какво се случва. Когато трябва да подпишем нещо, извикваме функцията java applet, използвайки javascript:

Аплетът от своя страна комуникира с десктоп приложението чрез сокети, предава му необходимите параметри, приложението подписва това, което сме поискали (за това се използва предварително написаният компонент на колеги), и предава подписаните данни на аплета, който от своя страна към браузъра, извикваща функция:

Надявам се, че горната информация ще помогне на тези, които са се сблъскали с нея, да разберат по-добре проблема с EDS в браузъра.