ब्राउज़र में ईडीएस: समस्याएं, समाधान, व्यक्तिगत अनुभव

जिन लोगों ने कम से कम एक बार एक ब्राउज़र में इलेक्ट्रॉनिक डिजिटल हस्ताक्षर को लागू करने की आवश्यकता का सामना किया है, वे अच्छी तरह से जानते हैं कि एक डेवलपर के लिए यह सिरदर्द क्या है, और विशेष रूप से एक वेब डेवलपर के लिए जो खुले मानकों के आदी हो गए हैं, यह नियम कि उनका सॉफ्टवेयर सभी ब्राउज़रों में समान रूप से अच्छी तरह से काम करता है। और वह इस बात की परवाह नहीं करता कि उपयोगकर्ता के पास कौन सा अक्ष है, ठीक है, और वेब के अन्य सुख।

वास्तव में, आज ब्राउज़र में ईडीएस के साथ स्थिति अभी भी कुछ साल पहले की तरह उदास नहीं है, लेकिन यह अभी भी आदर्श से बहुत दूर है। इस विषय को भी कई बार हैबे पर उठाया गया था, उदाहरण के लिए, यहाँ और यहाँ ।

कट के तहत खुद समस्या के बारे में एक कहानी है, इस समस्या को कैसे हल किया जा सकता है, इसके बारे में मैंने इसे कैसे हल किया, साथ ही व्यक्तिगत छापें कि बेलारूस में ईडीएस के साथ चीजें कैसे होती हैं।

समस्या का सार और कल इसका क्या होगा

समस्या काफी तुच्छ है: क्या आप ब्राउज़र में क्लाइंट पर डिजिटल हस्ताक्षर लागू करना चाहते हैं, इसके लिए अपनी पसंदीदा जावास्क्रिप्ट का उपयोग करने के बारे में सोचें? इससे कुछ भी नहीं होगा, और सभी क्योंकि ब्राउज़र केवल प्रमाण पत्र, टोकन, हस्ताक्षर आदि के साथ काम करने के लिए एक एपीआई प्रदान नहीं करते हैं। और इतने पर ... किसी भी वेब डेवलपर के सपनों में यह तंत्र कैसा दिखना चाहिए? शायद कुछ इस तरह:

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

हां, और यह बहुत अच्छा होगा अगर यह सब घरेलू GOSTs का समर्थन करेगा ... ठीक है, मैं वास्तव में इसके बारे में सपना देखा था। दुर्भाग्य से, आपको आधुनिक ब्राउज़रों में ऐसा कुछ नहीं मिलेगा। बेशक, मोज़िला में कुछ समान लागू करने के लिए डरपोक प्रयास हैं, लेकिन लेख के शीर्षक में चेतावनी बहुत दुखद है:



वैसे, अगर किसी ने इस एपीआई का उपयोग करने की कोशिश की, तो सदस्यता समाप्त करना बहुत दिलचस्प है।
W3C रिपॉजिटरी में क्रिप्टो का भी उल्लेख है । सबसे अधिक संभावना है कि वहां काम बहुत पहले शुरू हुआ था, वहां अब बहुत अधिक सामग्री नहीं है, लेकिन अंतिम अपडेट हाल ही में हुआ था, इसलिए यह काम हो रहा है:



क्या यह सब ध्यान में लाया जाएगा, और सबसे महत्वपूर्ण बात, जब यह होता है, तो आज, शायद, कोई भी आपको नहीं बताएगा। तो उन डेवलपर्स के लिए क्या बचा है जिन्हें यहां और अभी की जरूरत है?

बैसाखी

मैं तुरंत आरक्षण करना चाहता हूं, ब्राउज़र में ईडीएस शायद कुछ मामलों में से एक है जब एक डेवलपर को बस विभिन्न ट्रिक्स और बैसाखी का उपयोग करने के लिए मजबूर किया जाता है, मैं उनमें से सबसे लोकप्रिय को सूचीबद्ध करूंगा:

• ActiveX ( CAPICOM ) का उपयोग करना
• ब्राउज़र प्लगइन्स का उपयोग करना
• जावा एप्लेट का उपयोग करना
• सुरंग का उपयोग ( स्टनेल )

आइए उनमें से प्रत्येक की कमियों को देखें, मैं सभी बैसाखी के लिए फायदे, आईएमएचओ का वर्णन नहीं करूंगा, इसमें एक बात है - "ठीक है, यह काम करता है।"

ActiveX

99% मामलों में इसका उपयोग तब किया जाता है जब किसी ब्राउज़र में इलेक्ट्रॉनिक डिजिटल हस्ताक्षर को लागू करना आवश्यक होता है, बैंक, ट्रेडिंग फ़्लोर और अन्य गंभीर संगठन इसका उपयोग करने में शर्माते नहीं हैं। मेरी राय में, अब यह सबसे खराब विकल्प है, क्यों?
क्या आप काम करने के लिए अपने पसंदीदा FF या Chrome का उपयोग कर रहे हैं? - इसे भूल जाओ! ActiveX केवल IE में काम करता है।
अपनी ब्राउज़र सेटिंग्स में तल्लीन करना पसंद नहीं है? - और आपको करना है! सब कुछ काम करने से पहले, आपको अपने IE की सुरक्षा सेटिंग्स में गहरी खुदाई करनी होगी।
या हो सकता है कि आप इतने उन्नत हैं कि आपके पास Win7, और यहां तक ​​कि x64 है, या शायद आपने अपने लिए IE9-10 भी स्थापित किया है? - बहुत व्यर्थ, सबसे अधिक संभावना है कि आप सफल नहीं होंगे।
कोई मजाक नहीं है, लेकिन माइक्रोसॉफ्ट ने घोषणा की कि CAPICOM के लिए समर्थन बंद कर दिया गया है और घटक का कोई और विकास नहीं होगा, और CAPICOM का नवीनतम संस्करण, जो आधिकारिक तौर पर समर्थित है, विंडोज विस्टा में था।

ब्राउज़र प्लगइन्स

यदि कुछ ब्राउज़र में नहीं है, लेकिन आपको वास्तव में इसकी आवश्यकता है, तो एक तरीका है - अपना प्लगइन लिखें। यहां मुख्य समस्या यह है कि यदि आप चाहते हैं कि यह सभी ब्राउज़रों में काम करे, तो आपको उनमें से प्रत्येक के लिए एक प्लगइन लिखना होगा। अभी भी एक समर्थन समस्या है - कोई भी गारंटी नहीं देता है कि आपका प्लग-इन नए ब्राउज़र संस्करण (या पुराने) में काम करेगा, एफएफ के साथ स्थिति को याद रखें जब मोज़िला त्वरित संस्करण रिलीज़ पर स्विच हो गया। खैर, इस तथ्य के साथ एक और समस्या है कि आपको इस प्लगइन को कम से कम स्थापित करना होगा। इस समाधान के बारे में अधिक विवरण यहां पाया जा सकता है ।

जावा एप्लेट

लगता है कि सब कुछ इतना बुरा नहीं है, और कोड एक बार लिखा गया है, और सभी ब्राउज़रों में काम करता है, और आपको कुछ भी कॉन्फ़िगर करने की आवश्यकता नहीं है। लेकिन अगर आपके पास JRE इंस्टॉल नहीं है, तो कुछ भी नहीं होगा। ज्यादातर यह ओपनएसएसएल के साथ मिलकर काम करता है, हालांकि, जेएनआई का उपयोग करके, आप बहुत सी चीजों को पेंच कर सकते हैं। हां, सब कुछ काम करने के लिए, एप्लेट को स्वयं हस्ताक्षरित करना होगा।

सुरंग

एक अपेक्षाकृत नई विधि जो प्रॉक्सी सिद्धांत के आधार पर काम करती है, मुख्य विचार यह है कि जब सुरंग के माध्यम से सर्वर पर एक विशेष रूप से उत्पन्न POST अनुरोध भेजा जाता है, तो यह इस अनुरोध से डेटा पर हस्ताक्षर करता है, डेटा के बजाय अनुरोध फ़ील्ड में हस्ताक्षरित डेटा को प्रतिस्थापित करता है और सब कुछ सर्वर को आगे भेजा जाता है। और डिजिटल हस्ताक्षर से पहले से ही डेटा आ रहा है। सिद्धांत काफी सरल है, लेकिन प्रभावी है। इस पद्धति का व्यावहारिक कार्यान्वयन है । यहाँ और पढ़ें यह सब काम करने के लिए, सुरंग को ग्राहक पर ही स्थापित किया जाना चाहिए, हालांकि इसे फ्लैश ड्राइव से भी शुरू किया जा सकता है।

जैसा कि आप देख सकते हैं, समाधान हैं, हालांकि उनमें से प्रत्येक की कुछ सीमाएं और आरक्षण हैं, मैंने जानबूझकर विभिन्न ऑपरेटिंग सिस्टम में काम करने, GOSTs का समर्थन करने, मोबाइल प्लेटफॉर्म पर काम करने जैसी समस्याओं पर ध्यान नहीं दिया - यहां और भी समस्याएं हैं, और यह भी महत्वपूर्ण है।

व्यक्तिगत अनुभव

हां, I, भी, ब्राउज़र में EDS के कार्यान्वयन में संलग्न होने के लिए "भाग्यशाली" था। मैं खुद सॉफ्टवेयर विकास में शामिल मिन्स्क कंपनियों में से एक में काम करता हूं, और एक बार सिस्टम में एक ब्राउज़र में डिजिटल हस्ताक्षर के लिए समर्थन को तत्काल लागू करना आवश्यक था। सच कहूं, तो सबसे पहले मैं इस स्थिति में 99% की तरह काम करना चाहता था और ActiveX का उपयोग करना चाहता था। लेकिन, धीरे-धीरे समस्या में घिरते हुए, मुझे एहसास हुआ कि यह पहले उपयोगकर्ताओं के लिए सिरदर्द बन जाएगा, और फिर एक डेवलपर के रूप में मेरे लिए होगा। प्रत्येक ब्राउज़र के लिए प्लगइन्स लिखने का समय नहीं था। दो समाधान बने रहे: जावा एप्लेट और सुरंग। यह निर्णायक हो गया ... आपको विश्वास नहीं होगा, GOST।

तथ्य यह है कि बेलारूस में, रूस की तरह, इसने इलेक्ट्रॉनिक डिजिटल हस्ताक्षर बनाने और सत्यापित करने की प्रक्रियाओं के लिए अपना GOST अपनाया है, केवल हमारे देश में इसे STB RB 1176.299 कहा जाता है और आपके लिए कोई RSAs नहीं हैं। हर देश को अपना GOST दो! और अगर रूसी GOST के लिए उपरोक्त विधियों में से प्रत्येक के व्यावहारिक कार्यान्वयन हैं, तो आप कोई भी चुन सकते हैं, फिर बेलारूसी डेवलपर्स बहुत कम भाग्यशाली थे। इस अवसर पर, मैंने व्यक्तिगत रूप से एक कंपनी के प्रतिनिधियों के साथ भी बात की, जो हमारे देश के लिए क्रिप्टोग्राफ़िक सॉफ़्टवेयर का उत्पादन करती है। बातचीत ने दोहरी छाप छोड़ी। लोग काफी पर्याप्त हैं, वे समस्या को समझते हैं, लेकिन वे कहते हैं कि यह उनका काम नहीं है, उन्होंने माना कि एक क्रिप्टोग्राफिक प्रदाता लिखा है जो सभी राज्य मानकों को पूरा करता है और राज्य विशेषज्ञता से गुजरता है, और आप इसे कैसे उपयोग करना चाहते हैं यह उनकी समस्या नहीं है।

- हम केवल आपको ActiveX का उपयोग करने की पेशकश कर सकते हैं।
"ठीक है, उसके साथ जुड़ी समस्याओं के बारे में क्या?"
- बेशक, हमारे पास जावा एप्लेट्स का उपयोग करने के लिए कुछ विकास हैं, लेकिन हम उन्हें अभी तक आपको एक उत्पाद के रूप में पेश नहीं कर सकते हैं। इस तरह के सॉफ्टवेयर का विकास हमारा काम नहीं है।

मेरी राय में, यह बिल्कुल सही स्थिति नहीं है, क्योंकि किसी उत्पाद की पेशकश करते समय, इसके लिए पर्यावरण की पेशकश करना व्यावसायिक रूप से लाभदायक है।

ठीक है, ठीक है, हमारे पास जो है उसके साथ हम काम करते हैं। हमारे पास क्या है? इससे पहले, हमारी कंपनी में एक डेस्कटॉप एप्लिकेशन लिखा गया था जो ईडीएस कार्यों का उपयोग करता है, और क्रिप्टोएपीआई के साथ सीधे काम करने वाला एक घटक था, इसे डेल्फी में लिखा गया था। मैं वास्तव में किसी भी तरह से अपने सहयोगियों के इस अनुभव का उपयोग करना चाहता था और खुद को इस पर समय बर्बाद नहीं करना चाहता था, और सबसे महत्वपूर्ण बात, इसे जल्दी से करना। लेकिन यह कैसे करें? डेल्फी और वेब एप्लिकेशन पर घटक कनेक्ट करें? आरेख में उत्तर:



संक्षेप में बताएं कि क्या हो रहा है। जब हमें कुछ पर हस्ताक्षर करने की आवश्यकता होती है, तो हम ऐपलेट के जावा फ़ंक्शन को कॉल करने के लिए जावास्क्रिप्ट का उपयोग करते हैं:

  document.CryptoAPI.sign(text); 

एप्लेट, बदले में, डेस्कटॉप एप्लिकेशन के साथ सॉकेट्स के माध्यम से संचार करता है, इसके लिए आवश्यक पैरामीटर पास करता है, एप्लिकेशन उन संकेतों का अनुरोध करता है जो हमने अनुरोध किया था (इसके लिए सहकर्मियों के पहले लिखित घटक का उपयोग किया जाता है), और एप्लेट पर हस्ताक्षर किए गए डेटा को स्थानांतरित करता है, जो बदले में ब्राउज़र को कॉल करता है, कॉलिंग समारोह:

  function signResult(params) { //-     } 

एपलेट और एप्लिकेशन के बीच संचार के लिए एक सरल प्रोटोकॉल का आविष्कार किया गया था और इसे लागू किया गया था, संभवत: ज्यादातर समय लगा, क्योंकि बाकी चीजें काफी सरल थीं। कमियां विशिष्ट हैं: एक JRE की उपस्थिति और एक डेस्कटॉप अनुप्रयोग जो या तो स्थापित किया जाएगा या कहीं से लॉन्च किया जाएगा। इस पद्धति पर आपकी टिप्पणियों को सुनना दिलचस्प होगा।

मुझे उम्मीद है कि उपरोक्त जानकारी उन लोगों की मदद करेगी जो ब्राउज़र में ईडीएस की समस्या की बेहतर समझ का सामना करते हैं।