📮 😚 🧕 Nginx पर HTTPS सर्वर को कॉन्फ़िगर करें 🙍🏻 🕵🏾 🛡️

मैं यह क्यों लिख रहा हूँ?

हाल ही में, कारकों का एक गुच्छा (एनएसए, विज्ञापन के साथ डीपीआई , आदि) के कारण, व्यामोह जागना शुरू हो गया और मैंने अपनी छोटी साइट को पूरी तरह से https में स्थानांतरित करने के लिए सोचा। एसएसएल / टीएलएस के तकनीकी विवरण के साथ हब पर कई लेख थे, हालांकि, https-web सर्वर को कॉन्फ़िगर करने के बारे में जानकारी की तलाश में, मुझे लेखों का पारंपरिक विभाजन मिला - या तो ये "इस तरह से करें" लेख हैं, जहां सेटिंग्स बस किसी भी स्पष्टीकरण के बिना दिए गए हैं और मामलों का उपयोग करते हैं, या ये बड़े सैद्धांतिक लेख हैं जो उपयोग के विभिन्न पैटर्नों पर चर्चा करते हैं, लेकिन व्यावहारिक रूप से लागू ऑफ-द-शेल्फ विकल्प के बिना। हब पर सेटअप के बारे में एक लेख था, लेकिन इसमें डीएच एन्कोडिंग के बारे में कोई जानकारी नहीं है, और कुछ मापदंडों का वर्णन नहीं किया गया है। मुझे लगा कि यह एक लेख के रूप में पाया गया है, जो उन लोगों के लिए उपयोगी है, जो उन लोगों के लिए उपयोगी होंगे जो अपने सर्वर पर https को तैनात करना चाहते हैं, लेकिन SSL के विकलों में बहुत गहराई तक नहीं जाते हैं।

कथन को ध्यान में रखते हुए आयोजित किया जाएगा कि nginx वेब सर्वर के रूप में कार्य करता है (और एक स्थान पर php-fpm के लिए एक पैरामीटर होगा)।

प्रमाणपत्र

मेरे पास पहले से ही StartSSL का एक प्रमाण पत्र था। उन्होंने पहले से ही हब पर उसके बारे में लिखा था , इसलिए मैं इस कदम पर झूठ नहीं बोलूंगा। मैं केवल यह कह सकता हूं कि पहले दो या तीन दिनों के दौरान, सर्वर पर प्रमाण पत्र की जांच करने वाले ब्राउज़र इस पर शपथ ले सकते हैं (यह मेरे साथ ओपेरा 12 और फ़ायरफ़ॉक्स के साथ हुआ था), जाहिरा तौर पर StartCom पर वैध प्रमाणपत्र के कैश इतनी बार अपडेट नहीं किए जाते हैं। स्थापना के बारे में नीचे चर्चा की जाएगी

अनुकूलन विकल्पों के बारे में

नए संस्करणों में बॉक्स से बाहर निकैनेक्स व्यावहारिक रूप से प्रासंगिक प्रदान करता है, लेकिन फिर भी पॉलिशिंग मापदंडों की आवश्यकता होती है, हालांकि, वास्तविक पैरामीटर मानक कॉन्फ़िगरेशन में बहुत पहले नहीं दिखाई देते हैं, इसलिए कुछ मामलों में कॉन्फ़िगरेशन में एक HTTPS सर्वर का मानक उदाहरण प्रासंगिक नहीं होगा।

सामान्य तौर पर, दो वर्तमान में प्रासंगिक कॉन्फ़िगरेशन विकल्प हैं - फॉरवर्ड सिक्योरिटी के साथ और बिना। सेट करते समय, अंतर केवल एन्कोडिंग्स (ssl_ciphers निर्देश) के सेट में होता है, लेकिन यहां यह ध्यान देने योग्य है कि आप https से क्या चाहते हैं।

आप यहां फॉरवर्ड सेक्रेसी के बारे में पढ़ सकते हैं। संक्षेप में, लब्बोलुआब यह है कि वर्तमान में प्रासंगिक RC4 एल्गोरिदम के लिए, सर्वर की निजी कुंजी के आधार पर सत्र कुंजी उत्पन्न होती है। इस प्रकार, यदि निजी कुंजी से समझौता किया जाता है, तो सभी सत्रों को डिक्रिप्ट करना संभव होगा (यदि वे रिकॉर्ड किए गए थे)। DH एनकोडिंग का उपयोग करने के मामले में, प्रत्येक सत्र की अपनी कुंजी होती है, जो सत्र निजी कुंजी पर निर्भर नहीं होते हैं। हालांकि, इस मामले में बहुत अधिक प्रोसेसर समय हैंडशेक पर खर्च किया जाता है, जिससे लोड बढ़ता है और पृष्ठ को खोलने में समय लगता है।

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

Nginx सेटअप

सेटिंग्स के परिणामस्वरूप, मैंने लगभग इस तरह के एक कॉन्फ़िगरेशन का गठन किया, मैं नीचे दिए गए मापदंडों का सार समझाऊंगा।

Http सेक्शन में, आपको जोड़ना होगा:

ssl_session_cache shared:SSL:10m; ssl_session_timeout 5m; ssl_prefer_server_ciphers on; ssl_stapling on; resolver 8.8.8.8;

सर्वर अनुभाग लगभग इस तरह से निकलेगा:

 server { listen 443 ssl; server_name www.site.ru; ....... keepalive_timeout 60; ssl_certificate certificate_bundled.crt; ssl_certificate_key privatekey.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers "HIGH:!RC4:!aNULL:!MD5:!kEDH"; add_header Strict-Transport-Security 'max-age=604800'; ....... location ~ \.php$ { ....... fastcgi_param HTTPS on; #  php-fpm ....... } }

इस उदाहरण में, कोई डीएच एल्गोरिदम का उपयोग नहीं किया जाता है, अर्थात्। कोई फॉरवर्ड सिक्योरिटी नहीं। यहां सुधारों में से, हम SSLv3 समर्थन (इसे ssl_ciphers से हटाकर) को छोड़ सकते हैं, इस प्रकार IE 6 और नीचे का समर्थन नहीं किया जाएगा, क्योंकि यह TLS का समर्थन नहीं करता है, साथ ही साथ STS समय को बढ़ाता है, लेकिन इसके नीचे से अधिक।
SSLv3 के बिना, यह सेटिंग SSL परीक्षण में 100-95-100-90 का स्कोर देता है।

मापदंडों के माध्यम से चलते हैं

ssl_session_cache साझा: एसएसएल: 10 मीटर;
ssl_session_timeout 5 मी;
"सत्र मापदंडों को संग्रहीत करने के लिए कैश के प्रकार और आकार को सेट करता है।" (Nginx.org) सत्र कुंजियों के पुन: उपयोग के लिए कैश आवश्यक है, इसलिए पुराने कनेक्शन का उपयोग एक नया कनेक्शन स्थापित करने के लिए किया जाएगा, अर्थात्। हैंडशेक का फिर से निर्माण नहीं किया जाएगा। डीएचई एन्कोडिंग का उपयोग करते समय यह विशेष रूप से प्रासंगिक है (उदाहरण के लिए, ओपेरा 12 ब्राउज़र में), चूंकि सभी तत्वों के साथ पृष्ठ लोडिंग समय कैश की अनुपस्थिति में बहुत बढ़ जाता है, और डीएचई भी अधिक संसाधनों और समय (ईईसीडीएच और आरसी 4 के सापेक्ष) का उपयोग करता है। साझा पैरामीटर सभी वर्कफ़्लोज़, 10 मी - कैश आकार (1 एमबी ~ 4000 सत्रों के साथ 10 एमबी, इसलिए इन सेटिंग्स के साथ आप 40 हज़ार सत्रों तक स्टोर कर सकते हैं), 5 मी - सत्र टाइमआउट को कैश में सामान्य (5 मिनट) सेट करता है ।

ssl_prefer_server_ciphers पर;
"निर्दिष्ट करता है कि एसएसवी 3 और टीएलएस प्रोटोकॉल का उपयोग करते समय सर्वर सिफर को क्लाइंट सिफर पर प्राथमिकता दी जानी चाहिए।" (Nginx.org) - क्लाइंट सिफर्स (CBC) कुछ प्रकार के हमलों के लिए असुरक्षित हैं।

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

Keepalive_timeout - मुझे लगता है कि इसे विवरण की आवश्यकता नहीं है, इसे फिर से चालू न करें या फिर से जोड़ने के कारण लोड को कम करने के लिए इसे बहुत छोटा सेट करें।

ssl_cert सर्टिफिकेट और ssl_certificate_key सर्टिफिकेट फ़ाइल और उसके लिए निजी कुंजी फ़ाइल को इंगित करता है। चूंकि मैं StartSSL से एक प्रमाण पत्र के उदाहरण के बारे में बता रहा हूं, यहां मैं प्रमाण पत्र को स्थापित करने के लिए StartSSL निर्देशों के बारे में एक छोटी सी टिप्पणी करूंगा - आपको सामान्य प्रमाण पत्र फ़ाइल में रूट CA प्रमाणपत्र को जोड़ने की आवश्यकता नहीं है, क्योंकि इससे कोई मतलब नहीं है और केवल बढ़ जाता है, हालांकि बहुत अधिक नहीं, प्रेषित का आकार। डेटा। फ़ाइल में एक व्यक्तिगत प्रमाण पत्र और एक मध्यवर्ती प्रमाणन प्राधिकरण का प्रमाण पत्र होना पर्याप्त है। नगीनेक्स के लिए तैयार प्रमाणपत्र फ़ाइल (स्टार्टएसएसएल प्रमाण पत्र के लिए) निम्न आदेश के साथ प्राप्त की जा सकती है:

 cat certificate.crt sub.class1.server.ca.pem > certificate_bundled.crt

जहां आपका प्रमाण पत्र है। सर्टिफिकेट। इंटरमीडिएट का प्रमाणपत्र www.startssl.com/certs/sub.class1.server.ca.pem है

add_header सख्त-परिवहन-सुरक्षा 'अधिकतम आयु = 604800';
Strict-Transport-Secutiry - एक हेडर जो ब्राउज़र को बताता है कि साइट केवल https के माध्यम से सुलभ है। यह अनएन्क्रिप्टेड कनेक्शन के माध्यम से बाद के हमले के लिए http संस्करण पर वापस जाने की संभावना को रोकता है। वैसे, यह पैरामीटर इस लिहाज से भी सुविधाजनक है कि अगर http के माध्यम से एक ही साइट से पेज कोड (इमेज / स्क्रिप्ट / स्टाइल / ...) में "भूल गए" रिसोर्स कनेक्शन है, तो ब्राउजर खुद https वर्जन पर जाएगा और आंशिक अनएन्क्रिप्टेड की कसम नहीं खाएगा। कनेक्ट। बेशक, यह बाहरी संसाधनों के लिए काम नहीं करेगा। समय एक सप्ताह है। कई लोग इसे 1 साल तक सेट करने की सलाह देते हैं, लेकिन यदि आप भविष्य में https का उपयोग नहीं करने का निर्णय लेते हैं, तो यह कुछ उपयोगकर्ताओं के लिए समस्या पैदा कर सकता है। इस हेडर के प्रत्येक ट्रांसमिशन के साथ समय अपडेट किया जाता है, अर्थात हर बार जब आप साइट पर जाएँ।

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
समर्थित प्रोटोकॉल इंगित करता है। SSLv2 और v3 की महत्वपूर्ण कमजोरियां हैं।

ssl_ciphers "High:! RC4:! aNULL:! MD5:! kEDH";
उपयोग किए गए सिफर को इंगित करता है। दरअसल सिफर सूट में बदलाव के कारण फॉरवर्ड सेक्रेसी को कॉन्फ़िगर किया गया है। यह केवल KEDH पैरामीटर के साथ nginx द्वारा प्रस्तुत मानक सेट से अलग है,

आगे की गोपनीयता

फॉरवर्ड सेक्रेसी को सक्षम करने के लिए, आप उपयोग कर सकते हैं, उदाहरण के लिए, निम्नलिखित सिफर सूट:

 ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

इसके अलावा, आपको ओपनएसएसएल सिफर्स की प्राथमिकता को कॉन्फ़िगर करना होगा:

 openssl ciphers -V 'EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA256 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EDH+aRSA EECDH !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS'

यह विकल्प RC4 के उपयोग को कुछ ब्राउज़रों के साथ संगतता बनाए रखने के लिए निषिद्ध नहीं करता है, लेकिन बहुत समय पहले इसमें कमजोरियों की खोज की गई थी , हालांकि इसे लागू करना व्यावहारिक रूप से कठिन है।

एन्क्रिप्शन को मजबूत करने के लिए, आप डीएच सिपहर्स के लिए मापदंडों की एक फ़ाइल बनाकर डीएच सिफर की ताकत बढ़ा सकते हैं (एक फ़ाइल बनाने में थोड़ा समय लगेगा!), 4096 बिट्स लंबा कहें:

 openssl dhparam -out dh4096.pem 4096

और नगीने विन्यास को निर्देश जोड़ना

 ssl_dhparam dh4096.pem;

यह वेब-आधारित सर्वर / सेवा प्रबंधन इंटरफेस के लिए कहा जा सकता है, लेकिन हैंडशेक में अधिक समय लगेगा, इसलिए इसे नियमित साइट पर न करें।

CDN सेवाओं के बारे में

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

उपयोगी लिंक

परीक्षण https वेब सर्वर सेटिंग्स
फॉरवर्ड सेक्रेसी के लिए अपाचे और नेग्नेक्स सेटिंग्स

Nginx पर HTTPS सर्वर को कॉन्फ़िगर करें