हम Guzzle में TLS/SSL विकल्प कैसे निर्दिष्ट करते हैं?

Question

हम PHP में Guzzle का उपयोग कोड के साथ करना शुरू कर रहे हैं जो विभिन्न एपीआई को कॉल करता है, जिनमें से कुछ TLSv1.2 का समर्थन नहीं करते हैं और जिनमें से कुछ को TLSv1.2 की आवश्यकता होती है।

सबसे हालिया प्रोटोकॉल का उपयोग करने के लिए गुज़ल को मजबूर करने का सबसे अच्छा तरीका क्या है, सिवाय उन मामलों को छोड़कर जहां हम जानते हैं कि यह पहचाना नहीं जाएगा?

Answer 1

यह आसान और आसान है।

$client = new Client(); 
$guzzle = new GuzzleClient('https://www.yourweb.com', array(
    'curl.options' => array(
     CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2 
    ) 
)); 
$client->setClient($guzzle); 
... 

guzzle में 3.0+ (प्रति @limos 'टिप्पणी के रूप में अद्यतन):

'curl' => array(
    CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2 
) 

संभव CURLOPT_SSLVERSION विकल्पों आधिकारिक cURL पेज पर पाया जा सकता: http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html

--- अद्यतन (टिप्पणियों के आधार पर) ---

उचित एसएसएल प्रोटोकॉल संस्करण का चयन करने से केवल CURLOPT_SSLVERSION सेटिंग नहीं है, लेकिन बहुत अधिक कर्ल सेटिंग्स शामिल हैं। वांछित और महत्वपूर्ण परिणाम को "अधिकतम आगे गोपनीयता" कहा जाता है। यह सिर्फ कर्ल के लिए मान्य नहीं है!

आप एकाधिक CURLOPT_SSLVERSION पैरामीटर का उपयोग नहीं कर सकते (कम से कम, मुझे Guzzle दस्तावेज़ में ऐसा विकल्प नहीं मिला)। जब आप CURLOPT_SSLVERSION को परिभाषित करते हैं, तो कर्ल उस SSL संस्करण का उपयोग करने का प्रयास करेगा - कर्ल दस्तावेज़ (CURLOPT_SSLVERSION के बारे में ऊपर दिए गए लिंक) से - "एसएसएल/टीएलएस के किस संस्करण को उपयोग करने का प्रयास करने के लिए पैरामीटर के रूप में लंबे समय तक पास करें।"

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

यदि सुरक्षा शीर्ष प्राथमिकता है, तो उच्चतम उपलब्ध टीएलएस संस्करण (टीएलएस 1.2) के साथ जाएं। सेवा प्रदाता सुरक्षा देयता होने पर ग्राहक संगतता आपकी समस्या नहीं है।

यदि सुरक्षा महत्वपूर्ण है, यहाँ अन्य cURL विकल्पों को देखने के लिए कर रहे हैं:

• CURLOPT_SSL_VERIFYHOST
• CURLOPT_SSL_VERIFYPEER
• CURLOPT_CAINFO (cURL अपनी वेबसाइट पर प्रदान करता है CA CERTs)
• CURLOPT_SSL_CIPHER_LIST

उचित CURLOPT_SSL सेट करना _VERIFYHOST और CURLOPT_SSL_VERIFYPEER एमआईटीएम हमलों को रोक देगा।

CURLOPT_CAINFO - फिक्स त्रुटि: 35 - कनेक्शन में अज्ञात एसएसएल प्रोटोकॉल त्रुटि। अधिकतम आगे गोपनीयता में सुधार करें।

यहाँ cURL सिफर (CURLOPT_SSL_CIPHER_LIST) की जांच के लिए है, जो अधिकतम आगे गोपनीयता में सुधार होगा साथ एक सूची है:

'DHE-RSA-AES256-SHA', 
'DHE-DSS-AES256-SHA', 
'AES256-SHA', 
'ADH-AES256-SHA', 
'KRB5-DES-CBC3-SHA', 
'EDH-RSA-DES-CBC3-SHA', 
'EDH-DSS-DES-CBC3-SHA', 
'DHE-RSA-AES128-SHA', 
'DHE-DSS-AES128-SHA', 
'ADH-AES128-SHA', 
'AES128-SHA', 
'KRB5-DES-CBC-SHA', 
'EDH-RSA-DES-CBC-SHA', 
'EDH-DSS-DES-CBC-SHA:DES-CBC-SHA', 
'EXP-KRB5-DES-CBC-SHA', 
'EXP-EDH-RSA-DES-CBC-SHA', 
'EXP-EDH-DSS-DES-CBC-SHA', 
'EXP-DES-CBC-SHA' 

ये सिफर मजबूत Qualys एसएसएल लैब्स सूची (2014) के खिलाफ जाँच की कर रहे थे और कमजोर सिफर हटा दिया गया है । किसी भी सिफर जोड़ने/निकालने के लिए स्वतंत्र महसूस करें।

यदि आप अभी भी कई CURLOPT_SSLVERSION विकल्पों का पीछा करना चाहते हैं, तो मैं ऐसा करने के लिए एक स्क्रिप्ट लिखूंगा (जो, मुझे नहीं लगता कि यह एक अच्छा अभ्यास या आवश्यक है)। लेकिन फिर भी, यदि आप किसी भी कारण से उस कार्यक्षमता को आगे बढ़ाने का निर्णय लेते हैं, तो कुछ कोड लिखें जो सबसे मजबूत संभव SSL एन्क्रिप्शन का उपयोग करने का प्रयास करेगा और फिर कनेक्ट होने में विफल होने पर अगले संस्करण पर फ़ॉलबैक करेगा।

1. निर्णय लेने से पहले क्वालिस एसएसएल लैब्स 'projects पर सुरक्षा के बारे में एक नज़र डालें।
2. this SSL Labs' article पर एकदम सही आगे गोपनीयता और सर्वोत्तम प्रथाओं के बारे में एक नज़र डालें।
3. SSL Labs' web tool के साथ किसी भी भेद्यता के लिए अपने क्लाइंट (वेब ​​ब्राउज़र) का परीक्षण करें। यह आपको एक विचार देगा कि आपके सर्वर और ऐप पर क्या देखना है और क्या सुधार करना और सुरक्षित करना है।
4. क्वालिज़ एसएसएल लैब्स SSL tool के साथ अपनी वेबसाइट/वेब सेवा का परीक्षण करें।

भेद्यता और हमले: लोंगजम, फ्लेकी, पुडल, आप इसे नाम दें! कौन जानता है कि अन्य हमलों या भेद्यताएं अनदेखा क्यों हैं? हाँ! वे सभी एसएसएल/टीएलएस कनेक्शन की अपनी पसंद को प्रभावित करते हैं।

आपके पास क्लाइंट पर कोई नियंत्रण नहीं है (जब तक आप इसे विकसित नहीं करते), लेकिन आपके पास सर्वर और सर्वर-क्लाइंट वार्ता पर नियंत्रण होता है।

कोई फर्क नहीं पड़ता एप्लिकेशन को आप का निर्माण, आप, सर्वोत्तम प्रथाओं पर गौर करना चाहिए अपनी आवश्यकताओं पर और मामले के आधार प्रति निर्भर करता है, आप निम्नलिखित विकल्पों पर फैसला करना चाहिए:

संगतता

अनुरक्षणीयता

1. सुरक्षा
2. जटिलता

यदि सुरक्षा बहुत महत्वपूर्ण है, कम से कम TLS1.1 साथ जाना। सिफर सूचियों को भी देखें, मैं उस हिस्से को नजरअंदाज नहीं करूँगा।

यहां आपके ऐप के आस-पास एक अच्छा OWASP guide for creating a secure layer भी है।

ओडब्ल्यूएएसपी और क्वालिस एसएसएल लैब्स शुरू करने के लिए महान संसाधन हैं। मैं कमजोरियों, संभावित सुरक्षा विकल्पों और सर्वोत्तम प्रथाओं से परिचित होने के लिए कर्ल और ओपनएसएसएल पर कुछ शोध भी करूंगा।

सुरक्षा बिंदु हैं, जिनका मैं उल्लेख नहीं कर रहा हूं और गायब हैं, लेकिन हम सब कुछ शामिल नहीं कर सकते हैं। यह केवल एक ऊपरी हिस्सा है। यहां वर्णित कुछ भी आपके लिए शोध करने के लिए नहीं है।

शुभकामनाएं!

यदि मैं कर सकता हूं तो मैं किसी भी प्रश्न का उत्तर देने के लिए आसपास रहूंगा।

Answer 2

guzzle 5.3 में, मैं इस वाक्य का इस्तेमाल किया था:

$guzzle = new \GuzzleHttp\Client([ 
    'defaults' => [ 
     'config' => [ 
      'curl' => [ 
       CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2 
      ] 
     ] 
    ] 
]);