एक वेब सर्वर को कैसे पता चलता है कि SSL डिक्रिप्शन के लिए किस प्रमुख जोड़ी का उपयोग करना है?


18

यह मेरी समझ है कि जब अपाचे को टीसीपी बंदरगाहों में से एक पर एक अनुरोध प्राप्त होता है, जिस पर वह सुन रहा होता है (उदाहरण 80, 443), तो यह तय करेगा कि HTTP हेडर को देखकर किस मेजबान से अनुरोध किया जा रहा है Host। सर्वर को तब पता चलेगा कि उसे किस वर्चुअल होस्ट को अनुरोध को रीडायरेक्ट करना चाहिए।

लेकिन यह एसएसएल / टीएलएस पर HTTP के लिए कैसे काम करता है? चूंकि पूरे HTTP अनुरोध को एन्क्रिप्ट किया जा रहा है (कम से कम मुझे विश्वास है कि मैंने कहीं पढ़ा है), हेडर की जानकारी केवल सर्वर द्वारा डेटा को डिक्रिप्ट करने के बाद पढ़ी जा सकती है। लेकिन डिक्रिप्ट करने के लिए, यह जानना आवश्यक है कि वेब सर्वर पर आपके पास कई एसएसएल प्रमाणपत्रों का उपयोग करने के लिए कौन-सी मुख्य जोड़ी है।

तो सर्वर को कैसे पता चलता है कि इसे डिक्रिप्शन के लिए किस कुंजी की आवश्यकता है?


मेरा अनुमान :

मैं सोच सकता था कि टीएलएस हैंडशेक आवश्यक जानकारी प्रदान करता है।


के बारे में "संभव डुप्लिकेट" झंडा:

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




मैं मानता हूं कि उत्तर काफी समान हैं, हालांकि मेरा मानना ​​है कि प्रश्न काफी अलग हैं।
पाओलो

जवाबों:


29

मूल रूप से, वेब सर्वर को पता नहीं था। यही कारण था कि आपको सर्वर पर होस्ट करने के लिए इच्छित प्रत्येक SSL vhost के लिए एक अलग आईपी पते की आवश्यकता थी। इस तरह, सर्वर को पता था कि जब आईपी एक्स पर एक कनेक्शन आया था, तो उसे संबंधित vhost के लिए कॉन्फ़िगरेशन (प्रमाण पत्र सहित) का उपयोग करने की आवश्यकता थी।

यह सर्वर नाम संकेत के साथ बदल गया , एक टीएलएस एक्सटेंशन जो वास्तव में क्लाइंट को हैंडशेकिंग प्रक्रिया में आवश्यक होस्टनाम को इंगित करने की अनुमति देता है। यह एक्सटेंशन सभी आधुनिक OS में उपयोग किया जाता है, लेकिन पुराने ब्राउज़र या सर्वर इसका समर्थन नहीं करते हैं, इसलिए यदि आप क्लाइंट से अभी भी WinXP पर IE 6 का उपयोग करने की उम्मीद करते हैं, तो आप भाग्य से बाहर हो जाएंगे।


2
यदि कोई अभी भी XP का उपयोग करता है, तो वे वैसे भी मेरी साइट पर जाने के लायक नहीं हैं;)
पाओलो

2
इस तरह से ग्राहकों को सीमित करते समय बहुत सावधानी बरतने की जरूरत है (ब्राउज़र लोगों को नहीं)। कई, कई व्यवसाय बहुत अच्छी तरह से खिड़कियों को अपग्रेड नहीं करते हैं, और कुछ एंड्रॉइड फोन विक्रेताओं के साथ समान है, वे आमतौर पर अपने ओएस को बिल्कुल भी नहीं अपग्रेड करते हैं (या कम से कम ज्यादा नहीं)। विंडोज एक्सपी 8% पर है और प्री 4.4 एंड्रॉइड मार्केट शेयर भारी लगता है।
coteyr

यदि सर्वर में एसएनआई सपोर्ट का अभाव है तो एसएनआई सपोर्ट के बिना एसएनआई सपोर्ट के साथ प्रॉक्सी का उपयोग करना संभव है।
कैस्परल्ड

1
@coteyr शेष XP उपयोगकर्ताओं के विशाल बहुमत चीन में हैं। अन्यत्र बहुत कम उपयोग है, सौभाग्य से, कम से कम इंटरनेट पर।
माइकल हैम्पटन

7

ऐसा लगता है कि आपको TLS / SSL के बारे में कुछ गलत धारणाएँ हैं। HTTP अनुरोध सर्वर की सार्वजनिक कुंजी द्वारा एन्क्रिप्ट नहीं किया गया है। यह पिछले हैंडशेक में एक महत्वपूर्ण बातचीत का उपयोग करके एक सममित सिफर द्वारा एन्क्रिप्ट किया गया है।

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

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

बस एक मामूली बात है कि मैं टीएलएस के बारे में क्यों लिख रहा हूं, जबकि आपने एसएसएल के बारे में पूछा था: टीएलएस एसएसएल का नया संस्करण है। एसएसएल के सभी संस्करण को सामान्य उपयोग के लिए असुरक्षित माना जाता है, इसलिए हम अब ज्यादातर टीएलएस (1.0, 1.1, 1.2) का उपयोग कर रहे हैं।


"HTTP अनुरोध सर्वर की सार्वजनिक कुंजी द्वारा एन्क्रिप्ट नहीं किया गया है। यह पिछले हैंडशेक में एक महत्वपूर्ण बातचीत का उपयोग करके एक सममित सिफर द्वारा एन्क्रिप्ट किया गया है।" नहीं पता था कि, सिर के लिए धन्यवाद! हालांकि, मुझे पता है कि टीएलएस ने एसएसएल की जगह ले ली है, फिर भी हम पारंपरिक शब्द "एसएसएल सर्टिफिकेट" के साथ अटके हुए हैं, इसलिए मेरा उल्लेख है।
पाओलो

मुझे पता है कि "एसएसएल प्रमाणपत्र" जैसे शब्द टीएलएस के लिए काफी हैं। मैं उनसे बचने की कोशिश कर रहा हूं, लेकिन मुझे यकीन नहीं था कि आप (या अन्य) टीएलएस शब्द को जानते हैं।
v6ak
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.