क्या यह मायने रखता है कि एसएसएल प्रमाणन के लिए सीएसआर और कुंजी फाइलें कहां से उत्पन्न होती हैं?


18

मुझे वाइल्डकार्ड एसएसएल प्रमाणपत्र के लिए सीएसआर बनाना होगा। SSL प्रदाताओं के कुछ FAQ कहते हैं कि मुझे उस मशीन पर CSR फ़ाइल बनानी चाहिए जहाँ मैं प्रमाणपत्र स्थापित करना चाहता हूँ? मेरी समझ यह है कि जहां मैं बाद में फ़ाइलों को सही स्थान पर ले जाता हूं, वहां सीएसआर या कुंजी फ़ाइल उत्पन्न करने से कोई फर्क नहीं पड़ता।

तो मेरा सवाल यह है कि क्या यह बात मायने रखती है कि सीएसआर और एसएसएल सर्टिफिकेशन की अहम फाइलें कहां से जेनरेट होती हैं?

जवाबों:


21

आपकी समझ सही है। अन्य सभी चीजें समान हैं, इससे कोई फर्क नहीं पड़ता; लेकिन झुर्रियाँ हैं।

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

एक अलग मशीन पर जेनरेट करने का एक फायदा: आमतौर पर, यह आपका डेस्कटॉप होगा। एक डेस्कटॉप मशीन पर एन्ट्रापी पूल एक नायाब सर्वर की तुलना में लगभग हमेशा गहरा होता है, क्योंकि डेस्कटॉप में कीबोर्ड और माउस केबल्स (यानी, आप!) के माध्यम से यादृच्छिकता का एक बड़ा स्रोत जुड़ा होता है। एन्ट्रापी की कमी या तो महत्वपूर्ण पीढ़ी को लंबे समय तक ले जा सकती है, या /dev/urandomइसके बजाय PRNG आउटपुट का उपयोग करने का कारण बन सकती है, यह इस बात पर निर्भर करता है कि जनरेटिंग टूल कितना पागल है, और इससे कमजोर कुंजी हो सकती है; डेस्कटॉप मशीनों में यह समस्या नहीं है।

बाद में संपादित करें : एक चर्चा के अनुसार जो यहां से जुड़ी है, दो बिंदु उठाए गए हैं। सबसे पहले, आपको उत्पन्न करके एक आधे रास्ते घर के लिए जा सकते हैं एन्ट्रापी जैसे के साथ अपने डेस्कटॉप पर dd if=/dev/random bs=1k count=10 of=/tmp/entropy.dat, प्रतिलिपि बनाई जा रही है कि सीधे दूरस्थ सर्वर से, और अपने प्रमुख पीढ़ी की प्रक्रिया के लिए यह खिला या तो या दूरस्थ सर्वर के एन्ट्रापी पूल को मजबूत बनाने के द्वारा। मुझे अभी तक पूर्व करने का कोई तरीका नहीं मिला है, और बाद वाले को आम तौर पर विशेषाधिकार प्राप्त करने की आवश्यकता होती है, जो - यदि आपके और रिमोट सर्वर के बीच का चैनल सुरक्षित नहीं है, जो कि पूरी आपत्ति का बिंदु है - भी असुरक्षित है।

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

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


मुझे यकीन नहीं है कि वर्चुअलबॉक्स पर मेरे सर्वर पर उत्पन्न सीएसआर कोड यादृच्छिकता के एक बड़े स्रोत के लाभ हो सकता है । क्या आपको इस बारे में कोई आइडिया है?
लुईस

@Tresdin जैसा कि मेरा जवाब कहता है, इसे स्थानीय रूप से डेस्कटॉप पर उत्पन्न करें, और इसे कॉपी करें।
मदहैटर

लिनक्स पर, आप मौजूदा एन्ट्रापी पूल में / dev / random लिखकर अतिरिक्त एन्ट्रापी जोड़ सकते हैं। यकीन नहीं होता कि यह अन्य * निक्स पर काम करता है।
एक CVn

7

यह कुछ मायने रखता है।

यदि आप उन्हें किसी अन्य मशीन पर उत्पन्न करते हैं, तो कुंजी जनरेटिंग मशीन पर, और फिर सर्वर पर असुरक्षित हैं। यदि आप उन्हें उत्पन्न करने के लिए एक संक्रमित मशीन का उपयोग करते हैं, तो कुछ virii कुंजियों को चुरा सकते हैं, इससे पहले कि वे सुरक्षित सर्वर पर चले जाएं।

यदि आप उन्हें एक सुरक्षित सर्वर पर उत्पन्न करते हैं, और बस CSR / सर्टिफिकेट को इधर-उधर करते हैं, तो किसी के / निजी कुंजी प्राप्त करने की संभावना कम होती है, तो पहली स्थिति में, चूंकि निजी कुंजी केवल एक मशीन पर स्थित होती है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.