क्या एक VirtualHost (पूडल) के लिए Apache में SSLProtocol सेट करना संभव है?

13

मैं poodle भेद्यता के लिए एक पैच का परीक्षण करने की कोशिश कर रहा हूं जिसमें मेरे वेब सर्वर पर SSLv3 को अक्षम करना शामिल है। पहले गैर-उत्पादन वातावरण पर इसका परीक्षण करने के लिए, मैं एक अलग परीक्षण सर्वर के लिए एक वर्चुअलहॉस्ट पर SSLProtocol स्थापित कर रहा हूं। मेरा विन्यास कुछ इस तरह दिखता है:

<VirtualHost *:443>
    SSLEngine On
    SSLProtocol All -SSLv2 -SSLv3
    ServerName test.mysite.com
    # bunch of other stuff omitted
</VirtualHost>

हालाँकि, अपाचे को फिर से शुरू करने के बाद भी मेरे परीक्षण स्थल के असुरक्षित होने का दावा किया जाता है। क्या इससे काम करने की उम्मीद है? मुझे आश्चर्य हो रहा है कि क्या मुझे इसे ग्लोबल ssl config में सेट करना है या क्या कुछ और सूक्ष्म है जो सेटिंग को / और काम नहीं करने का कारण बना रहा है।

— कोरी
स्रोत

16

आप SSLProtocol को केवल कॉन्फ़िगरेशन फ़ाइल में पहले VirtualHost के लिए सेट कर सकते हैं। सभी बाद की VirtualHost प्रविष्टियाँ इनहेरिट करेंगी कि पहली प्रविष्टि से सेटिंग और एक ओपनएसएसएल बग के कारण चुपचाप अपनी स्वयं की सेटिंग को अनदेखा करें ।

Mod_ssl के लिए एक संबंधित बग रिपोर्ट है , लेकिन जैसा कि बग रिपोर्ट में वर्णित है, समस्या को OpenSSL में हल किया जाना चाहिए (प्रमाण पत्र विरासत में मिला है, लेकिन प्रोटोकॉल नहीं है)।

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

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

मुझे Apache 2.4 के साथ इस समस्या का सामना करना पड़ा और OpenSSL 1.0.1k के साथ modssl, और मुझे उम्मीद है कि Apache 2.2 उसी मुद्दों के अधीन होगा।

अद्यतन (अक्टूबर 2016): ओपनएसएसएल बग को 13 अक्टूबर, 2016 को हल के रूप में चिह्नित किया गया था। हालांकि, यह खुले मुद्दों के बड़े पैमाने पर बंद होने का हिस्सा था और हालांकि 'आंशिक रूप से तय' की आपूर्ति की गई थी, समस्या को पूरी तरह से संबोधित नहीं किया गया था।

अद्यतन (अप्रैल २०१)): पुनर्विकसित ओपनएसएसएल बग में अब एक पैच उपलब्ध है (९ अप्रैल २०१) के अनुसार)। यह पैच कई SNI वर्चुअल होस्ट के साथ कॉन्फ़िगर किए गए Apache इंस्टेंस के व्यवहार को बदल देगा:

उन कनेक्शनों को अस्वीकार करें जो vhost SSLProtocol के अनुरूप नहीं हैं

यह 2.4.27 और उस संस्करण के साथ उत्पादन में विकसित और परीक्षण किया गया था। पैच को 2.4.33 के लिए संशोधित किया गया था और हल्के से परीक्षण किया गया था।

यह SNI पर आधारित वर्चुअल होस्ट के लिए कॉन्फ़िगर किए गए SSLProtocol के विरुद्ध कनेक्शन के संस्करण की जाँच करता है। क्योंकि शुरू में कनेक्शन पोर्ट के लिए डिफ़ॉल्ट होस्ट के लिए कॉन्फ़िगर किए गए SSLProtocol के साथ किया जाता है, डिफ़ॉल्ट होस्ट में सभी प्रोटोकॉल शामिल होने चाहिए जो किसी भी वर्चुअल होस्ट द्वारा समर्थित होंगे।

यह पैच init_vhost फ़ंक्शन के लिए APR_EMISMATCH का एक अतिरिक्त रिटर्न स्टेटस जोड़ता है ताकि OpenSSL के साथ पंजीकृत ssl_callback_ServerNameIndication कॉलबैक घातक अलर्ट SSL -AD_PROTOCOL_VERSION को वापस कर सके। इसका उद्देश्य क्लाइंटहेलो के लिए एक ही प्रतिक्रिया उत्पन्न करना है क्योंकि इसमें SSLProtocol निर्दिष्ट है जो संस्करण को प्रश्न में शामिल नहीं करता है। क्योंकि एसएनआई कॉलबैक को क्लाइंटहेलो के प्रसंस्करण के दौरान कहा जाता है और प्रतिक्रिया उत्पन्न होने से पहले, यह वास्तव में ऐसा लगता है।

यदि आप अचानक निम्न प्रारूप के संदेश देखते हैं:

Rejecting version [version] for servername [hostname]

फिर आपको SSLProtocolअपने डिफ़ॉल्ट होस्ट के लिए अपनी जांच दोबारा करनी चाहिए ।

— vallismortis
स्रोत

@Anx द्वारा जोड़ी गई अतिरिक्त जानकारी SSLStrictSNIVHostCheckको काफी सराहा गया है। हालांकि, यह भी उद्धृत दस्तावेज से ध्यान दिया जाना चाहिए कि यदि किसी अन्य वर्चुअल होस्ट में सेट किया गया है, तो एसएनआई अनजान क्लाइंट को इस विशेष वर्चुअल होस्ट तक पहुंचने की अनुमति नहीं है ।

— vallismortis

5

यदि आप एक अलग आईपी पर सुन रहे हैं तो आपके पास प्रत्येक Vhost के लिए अलग-अलग एसएसएल प्रोटोकॉल हो सकते हैं।

टीएलएसवी 1 और अन्य सभी को केवल टीएलएसवी 1 और टीएलएसवी 1.2 की अनुमति देने वाले एक विशिष्ट होस्ट के साथ उदाहरण - और केवल टीएलएसवी 1 की अनुमति देने वाला एक:

<VirtualHost *:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3 -TLSv1
  ServerName test.mysite.com
  # bunch of other stuff omitted
</VirtualHost>

<VirtualHost 10.0.0.2:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3
  ServerName test2.mysite.com
</VirtualHost>

<VirtualHost 10.0.0.3:443>
  SSLEngine On
  SSLProtocol TLSv1.2
  ServerName test2.mysite.com
</VirtualHost>

— BitLegacy01
स्रोत

इसके अलावा, यदि आपको केवल परीक्षण उद्देश्यों के लिए इसकी आवश्यकता है, तो आप दूसरे आईपी के बजाय किसी अन्य पोर्ट का उपयोग कर सकते हैं, जैसे सामान्य वैकल्पिक HTTPS पोर्ट 8443।

— एसा जोकिनेन

0

यदि आप सर्वर नाम संकेत (SNI) का उपयोग अपने vhost के साथ कर रहे हैं, तो वास्तव में, आप कई SSL संस्करण को परिभाषित नहीं कर सकते हैं।

हालाँकि, यदि आप एक समर्पित सर्वर का उपयोग कर रहे हैं, तो आप संभवतः अपने सर्वर में एक और आईपी एड्रेस जोड़ सकते हैं। इस तरह, आप प्रति आईपी एक अलग एसएसएल संस्करण का उपयोग करने में सक्षम होंगे। आपको बस अपनी vhost सेटिंग्स को अपेक्षित IP: 443 के रूप में बदलना होगा।

— TRYP
स्रोत

-2

या आप उपयोग कर सकते हैं:

SSLProtocol TLSv1 TLSv1.1 TLSv1.2

मुझे कई सर्वरों पर परीक्षण किया गया था और मेरे लिए काम करता है! आप इस वेबसाइट में अपनी साइट का परीक्षण कर सकते हैं

— रोड्रिगो मोरेनो
स्रोत

4

यह SSLProtocol लाइन केवल ऐसा दिखता है क्योंकि यह काम कर रहा है क्योंकि Apache इसके बारे में शिकायत नहीं करती है। वास्तव में, पहले VirtualHost प्रविष्टि में केवल SSLProtocol का उपयोग किया जाता है।

— vallismortis