2010-10-20 16 views
5
चीन महान फ़ायरवॉल के कारण

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

मेरे योजना:

  • शेक हाथ:

ब्राउज़र अनुरोध सर्वर, सर्वर एन्क्रिप्ट कुंजी k1 उत्पन्न, और मुख्य k2 डिक्रिप्ट, ब्राउज़र को k1 भेजें। ब्राउज़र एन्क्रिप्ट कुंजी के 3 उत्पन्न करता है, और कुंजी k4 डिक्रिप्ट करता है, सर्वर पर k3 भेजता है।

  • ब्राउज़:

सत्र के दौरान, k1 के साथ ब्राउज़र एन्क्रिप्ट डेटा और सर्वर के लिए भेजने के लिए, सर्वर k2 साथ डिक्रिप्ट। सर्वर के 3 के साथ डेटा एन्क्रिप्ट डेटा और ब्राउज़र के लिए प्रतिक्रिया, ब्राउज़र के 4 के साथ डिक्रिप्ट।

कृपया मेरी गलती का पता लगाएं।

यदि यह सही है, मेरे सवाल का

  1. कैसे में एक महत्वपूर्ण जोड़ी उत्पन्न करने के लिए जावास्क्रिप्ट और अजगर, वहाँ कुछ पुस्तकालयों हो रहा है?
  2. एन्क्रिप्ट और में डेटा को डिक्रिप्ट जावास्क्रिप्ट और अजगर, वहाँ कुछ पुस्तकालय हैं के लिए?

उत्तर

0

सुरक्षा समस्या वास्तव में एक बड़ी चिंता है, तो एक बड़ी समस्या है: आपके एल्गोरिदम को असुरक्षित स्थानांतरित करने जा रहा है। क्या आप क्लाइंट पर भरोसा कर सकते हैं? क्या ग्राहक सर्वर पर भरोसा कर सकता है?

+0

मुझे लगता है कि ओपनसोर्स एल्गोरिदम ठीक है, कुछ एन्क्रिप्शन हैं, यहां तक ​​कि आप एन्क्रिप्ट कुंजी भी जानते हैं, लेकिन आप इसे डिक्रिप्ट नहीं कर सकते हैं, और आपको एन्क्रिप्ट कुंजी से डिक्रिप्ट कुंजी नहीं मिल सकती है। –

+1

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

+0

सिर्फ अपनी साइट के लिए, व्यापक रूप से उपयोग के लिए नहीं। –

2

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

नोट यह एक मौलिक सीमा, जिस तरह एसएसएल कार्यों का विशेष लक्षण है। सभी क्रिप्टोग्राफिक सुरक्षा एक साझा रहस्य स्थापित करने पर निर्भर करती है। मुख्यधारा के ब्राउज़र के साथ तैनात रूट प्रमाण पत्र प्राधिकरण (सीएएस) प्रमाणित करके स्थापित ट्रस्ट नेटवर्क को प्रवेश बिंदु प्रदान करते हैं जो आपको किसी ज्ञात तृतीय पक्ष के साथ साझा रहस्य स्थापित करने में सक्षम बनाता है। ये प्रमाण पत्र, AFAIK नहीं हैं, सीधे जावास्क्रिप्ट कोड तक पहुंच योग्य हैं। उनका उपयोग केवल सुरक्षित (उदा।, Https) कनेक्शन स्थापित करने के लिए किया जाता है।

+0

किसी भी सुरक्षा को जोड़ नहीं देगा। हाँ, मेरी योजना बहुत कमजोर है। लेकिन मैं जो चाहता हूं वह थोड़ी अधिक सुरक्षा है, मैं अपनी इच्छानुसार ऐसा करने के लिए मजबूर था। –

+0

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

1

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

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

मुझे नहीं पता कि जावास्क्रिप्ट में यह सब करना कितना व्यावहारिक है। जाहिर है यह यह कर सकता है - यह एक ट्यूरिंग-पूर्ण भाषा है, इसमें सभी आवश्यक सिस्को तक पहुंच है - लेकिन यह बेवकूफ महंगा हो सकता है। यह आसान GPG का उपयोग कर के मामले में सोचने के लिए ...

यहाँ सही हो सकता है

1

अन्य उत्तर कर रहे हैं (सरकार है कि आप सभी पर संवाद कर रहे हैं से तथ्य छिपाए जा रहे हैं एक अलग समस्या पूरी तरह से है।): आप जीता ' क्लाइंट पर चलने वाली जावास्क्रिप्ट को सुरक्षित रूप से वितरित करने में सक्षम नहीं हो। हालांकि, अगर आप इस सामान को और कुछ और देखना चाहते हैं, तो ओपनसोर्स प्रोजेक्ट फोर्ज देखें। यह जावास्क्रिप्ट में एक SSL/TLS कार्यान्वयन और एक साधारण अजगर SSL सर्वर है:

http://github.com/digitalbazaar/forge/blob/master/README

आप इसके उपयोग पर कुछ अधिक पढ़ा करना चाहते हैं:

http://digitalbazaar.com/2010/07/20/javascript-tls-1/

http://digitalbazaar.com/2010/07/20/javascript-tls-2/

संबंधित मुद्दे