TLSv1 हाथ मिलाना विफलता

Question

(अस्वीकरण: मैं कल्पना एक सुरक्षा विशेषज्ञ का कोई खिंचाव है और न ही उस बात के लिए एक विंडोज़ विशेषज्ञ द्वारा हूँ)

सेटअप: हमारे अंत पर

• सर्वर: जावा 1.6 (पहले से ही जोड़ा खिड़कियों पर सुरक्षा फाइल करने के लिए bouncycastle) 2003 सर्वर
• तीसरे पक्ष के ग्राहक: BizTalk साथ 2008 सर्वर
• सभी पुनः मध्यस्थता प्रणाली रीनिगोशिएशन हमले के कारण शुरू की गुण सर्वर साइड (सुरक्षित नहीं मुझे पता है)पर "सक्षम" कर रहे हैं 10

आदर्श रूप से हम इसे अपने अंत में ठीक करना चाहते हैं, लेकिन यदि आवश्यक हो तो ग्राहक को एक फिक्स प्रस्तावित करना संभव है।

> TLSv1: Client Hello 
< TLSv1: Alert (21): Unexpected Message 

आरएफसी के अनुसार (http://www.ietf.org/:

क्लाइंट सर्वर एक HTTPS कनेक्शन पर हमारे सर्वर से कनेक्ट करने है, लेकिन यह हमेशा विफल रहता है, wireshark निम्नलिखित बातचीत से पता चलता आरएफसी/आरएफसी 2246.txt) अलर्ट (21) एक असफल डिक्रिप्शन और वायरसहार्क में जो देख सकता है उससे संदर्भित करता है, क्लाइंट द्वारा प्रस्तावित कोई भी सिफर वास्तव में जेआरई 1.6 द्वारा समर्थित नहीं है (http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SupportedCipherSuites के अनुसार) पुन: पेश करने के प्रयास में त्रुटि को जांचने में सक्षम होने के लिए त्रुटि, मैंने कुछ अन्य सॉफ़्टवेयर के साथ परीक्षण किया:

• चयनित "https" के साथ विंडोज एक्सपी पर wfetch एसएसएलवी 2 में प्रारंभिक क्लाइंट हैंडशेक करेगा, सर्वर उत्तर देने के लिए टीएलएसवी 1 पर स्विच करेगा, यह काम करता है
• प्रारंभिक हैंडशेक के लिए "टीएलएसवी 1" का उपयोग करने के लिए कॉन्फ़िगर किए गए विंडोज एक्सपी पर wfetch BizTalk सर्वर कॉन्फ़िगर किया गया "https" के साथ खिड़कियां 2008 को
• WFetch प्रारंभिक हाथ मिलाना के लिए इस्तेमाल करेगा "TLSv1" और BizTalk सर्वर
• आईई के रूप में एक ही तरह से असफल (Windows XP पर) के रूप में एक ही तरह से असफल हो जायेगी शुरुआत में एक ही असफल परिणाम के साथ एक टीएलएसवी 1 हैंडशेक आज़माएं लेकिन तुरंत एसएसएलवी 3 का उपयोग करके फिर से कोशिश करता है जो काम करता है (इस बिंदु पर मुझे लगता है कि सभी माइक्रोसॉफ्ट सॉफ्टवेयर HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentCo पर उपलब्ध केंद्रीय कॉन्फ़िगरेशन का उपयोग करता है ntrolSet \ नियंत्रण \ SecurityProviders \ Schannel)
• फ़ायरफ़ॉक्स, पूरी बातचीत के लिए SSLv3 का उपयोग करता है तो कोई वहाँ समस्या
जब यह जवाब, कोई समस्या नहीं
• OpenSSL SSLv2 में एक प्रारंभिक हाथ मिलाना, और TLSv1 करने के लिए सर्वर स्विच करता है OpenSSL रूप में अच्छी तरह TLSv1 में प्रारंभिक हाथ मिलाना करने को मजबूर किया जा सकता है, यह 27 सिफर की एक सूची (के रूप में 11 सिफर से खिड़कियों आधारित सॉफ्टवेयर प्रस्तावित के खिलाफ) और मेरे अप्रशिक्षित करने के लिए एक समस्या के बिना

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

तो निष्कर्ष में मुझे आश्चर्य है अगर निम्नलिखित बातों में से एक इसे ठीक हैं और वे कैसे पूरा किया जाना चाहिए:

• JVM कि TLSv1 के लिए सिफर कि विंडोज़ द्वारा प्रस्तावित कर रहे हैं के साथ काम कर सकते हैं करने के लिए एक प्रदाता जोड़ने
• किसी भी तरह SSLv3 (अधिमानतः नहीं SSLv2) में प्रारंभिक हाथ मिलाना करने के लिए ग्राहक के लिए मजबूर या कम से कम अगर TLSv1 हाथ मिलाना
• किसी भी तरह ग्राहक खिड़कियों के TLSv1 के लिए एक JVM-समर्थित सिफर जोड़ने में विफल रहता है पुन: प्रयास

किसी भी अन्य समाधान की भी सराहना की जाती है।

संपादित

जावा संस्करण Java version (64 bit): 1.6.0_19-b04 है।

प्रस्तावित सिफर की सूची है:

• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
• TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
01,TLS_RSA_EXPORT_WITH_RC4_40_MD5
• TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_DES_CBC_SHA
• TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA

असीमित शक्ति क्रिप्टोग्राफी नीति फ़ाइलें स्थापित हैं। मैंने javax.net.debug=all सेट करने का प्रयास किया है और सर्वर को कंसोल से शुरू किया है, कोई अतिरिक्त आउटपुट दिखाई नहीं दिया है। मैंने sun.security.ssl.allowUnsafeRenegotiation=true को कोई फायदा नहीं हुआ है।

संपादित 2

यह सॉफ्टवेयर हम प्रयोग कर रहे हैं पता चला है एक कस्टम के बजाय डिफ़ॉल्ट HTTPS के लिए ढेर उपयोग करता है। एक फिक्स जारी किया गया था जो समस्या को हल करने लगता है हालांकि मुझे नहीं पता कि टीएलएस अनुरोध के किस हिस्से ने त्रुटि को ट्रिगर किया था (क्योंकि अधिकांश टीएलएसवी 1 हैंडशेक सफल हुए थे)।

प्रतिक्रिया के लिए धन्यवाद, यह व्यर्थ खोज में एक दिलचस्प रहा है। जियो और सीखो।

Answer 1

यह पता चला है कि हम जिस सॉफ्टवेयर का उपयोग कर रहे हैं वह डिफ़ॉल्ट के बजाय HTTP के लिए एक कस्टम स्टैक का उपयोग करता है। एक फिक्स जारी किया गया था जो समस्या को हल करने लगता है हालांकि मुझे नहीं पता कि टीएलएस अनुरोध के किस हिस्से ने त्रुटि को ट्रिगर किया था (क्योंकि अधिकांश टीएलएसवी 1 हैंडशेक सफल हुए थे)।

प्रतिक्रिया के लिए धन्यवाद, यह व्यर्थ खोज में एक दिलचस्प रहा है। जियो और सीखो।

Answer 2

आप detecting cipher strength पर अपना आलेख पढ़ सकते हैं (बस यह सुनिश्चित करने के लिए कि आपने जेसी सिफर सही तरीके से स्थापित किया है)। आपके प्रश्न में आप कहते हैं कि आपने असीमित सिफर स्थापित किए हैं लेकिन फिर आप 128 और 40-बिट कुंजी का संदर्भ देते हैं। तो, मैं आपके पास जो कुछ है उससे उलझन में हूं। साथ ही, क्या आप एसएसएल प्रमाण पर सिफर की ताकत की जांच कर सकते हैं जिसे आप कनेक्ट करने का प्रयास कर रहे हैं और हमें बताएं कि यह क्या है और एल्गोरिदम क्या है?साथ ही, सुनिश्चित करें कि जेडीके के लिए आपकी नीति फ़ाइल में असीमित ताकत की अनुमति देने के उचित अधिकार हैं।

अंत में, क्या आप अपने क्लाइंट हैंडशेक को सही तरीके से सत्यापित करने के लिए "ज्ञात अच्छी" एसएसएल साइट से कनेक्ट कर सकते हैं? (उदाहरण के लिए जीमेल वेब)