एसएसएल पिनिंग और प्रमाणपत्र समाप्ति

Question

यह प्रश्न किसी वेब एपीआई और प्रमाणपत्र समाप्ति के विरुद्ध क्लाइंट ऐप में SSL पिनिंग के उपयोग से संबंधित है।

परिदृश्य:

मैं खुद example.com और एक उप डोमेन है, जहां एक एपीआई होस्ट किया गया है, जैसे कि: api.example.com

मैं उपयोग करना चाहते हैं एपीआई एसएसएल, इसलिए सबडोमेन के लिए एक एसएसएल प्रमाणपत्र बनाया गया है।

के बाद प्रमाण पत्र प्राप्त किया गया है, मेरे पास है:

• एक सार्वजनिक प्रमाणपत्र
• एक मध्यवर्ती प्रमाणन
• एक निजी कुंजी

यह मेरी समझ है कि मुझे इन प्रमाणपत्रों पर स्थापित है मेरा वेबसर्वर

मैं फिर अपने क्लाइंट ऐप को एपीआई से कनेक्ट करने की इच्छा करता हूं। मैन-इन-द-मिडिल स्टाइल हमलों के खिलाफ कम करने के लिए, मैं एसएसएल पिनिंग का उपयोग करना चाहता हूं, ताकि क्लाइंट केवल मेरे एपीआई के साथ संवाद करे, कोई इसे धोखा दे।

क्लाइंट ऐप में पिन करने के लिए, मेरे पास दो विकल्प हैं, या तो सार्वजनिक या इंटरमीडिएट प्रमाण पत्र के विरुद्ध पिन करें।

मान लें कि मैं इसे कार्यान्वित करता हूं।

क्या होता है जब पर प्रमाणपत्र प्रमाणपत्र api.example.com समाप्त हो जाता है?

यह मेरी समझ है कि क्लाइंट ऐप अब काम नहीं करेगा।

क्या मुझे फिर से सार्वजनिक/मध्यवर्ती/निजी वस्तुओं का एक पूरा सेट पुन: उत्पन्न करने की आवश्यकता है? और फिर ऐप में एक नया सार्वजनिक या इंटरमीडिएट प्रमाणपत्र डाला?

प्रश्न:

मैं अभी भी क्लाइंट ऐप की तरह काम करने के लिए जब तक api.example.com पर प्रमाण पत्र अद्यतन किया गया था। बेशक, क्लाइंट ऐप में एक नया प्रमाणपत्र लगाया जा सकता है, लेकिन रोल-आउट जैसी चीजें समय लेती हैं।

मैं इसे कैसे प्रबंधित कर सकता हूं?

मैं पढ़ा है गूगल हर महीने उनके प्रमाण पत्र अपडेट कर देता है, लेकिन किसी भी तरह सार्वजनिक कुंजी एक ही बनाए रखने में सफल: How to pin the Public key of a certificate on iOS

अगर यह संभव है, तो समाधान बस सर्वर से सार्वजनिक कुंजी को निकालने के लिए है और इसे स्थानीय रूप से संग्रहीत सार्वजनिक कुंजी के विरुद्ध जांचें ... लेकिन Google इसे कैसे करता है?

धन्यवाद

क्रिस

Answer 1

नोट: मैं सर्वर से ब्राउज़र pinning (HTTP सार्वजनिक कुंजी लगाए - HPKP) से अधिक परिचित हूँ सर्वर पिन करने के लिए एप्लिकेशन के बजाय, लेकिन मुझे लगता है प्रिंसिपल ही है। एचपीकेपी में पिनिंग नीति सर्वर द्वारा HTTP शीर्षलेख के रूप में प्रदान की जाती है लेकिन समझती है कि इसे अक्सर HTTP प्रतिक्रिया से पढ़ने के बजाय ऐप में बनाया जाता है। तो नीचे दिये गये सभी के साथ जवाब नीचे पढ़ें:

पिनिंग आम तौर पर कुंजी के खिलाफ नहीं है और यह एकाधिक स्तर हो सकता है। तो आपके पास कई विकल्प हैं:

1. एक नया प्रमाण उत्पन्न करने के लिए एक ही कुंजी/सीआरटी का पुन: उपयोग करें। कुछ (सही मायने में मेरी राय में!) प्रत्येक बार जब आप अपना प्रमाण नवीनीकृत करते हैं तो एक नई कुंजी उत्पन्न करने की सलाह देते हैं लेकिन जब आप पिनिंग का उपयोग करते हैं तो यह जटिल होता है। तो क्या पिनिंग खराब सुरक्षा आदतों को प्रोत्साहित करती है जैसे कि मुख्य पुन: उपयोग?

2. अपनी पिनिंग नीति में कई बैक अप कुंजियां हैं और उन्हें अपने पुरानेतम को छोड़कर प्रमाणित नवीनीकरण पर घूमते हैं और बहुत समय और अद्यतनों के साथ एक नया जोड़ना कभी कम नहीं किया जाता है। निजी तौर पर मैं कुछ बैकअप लेने के बजाय प्रमाणित नवीनीकरण समय पर कुंजी उत्पन्न करना पसंद करता हूं जिसके बारे में समझौता किया जा सकता है या नहीं, इसलिए मैं इसका विशेष प्रशंसक नहीं हूं। और आपके पास कितने बैकअप होना चाहिए? जैसे यदि आपको नवीनीकरण के आसपास समझौता करने के कारण प्रमाण को फिर से जारी करने की आवश्यकता है और इसे गड़बड़ भी करना है? तो 2? 3? 100?

3. आगे पिन करें। पहला इंटरमीडिएट या रूट सीए प्रमाण कहें। तो कोई भी नया जारी प्रमाण अभी भी भरोसेमंद है (इसे एक ही प्रमाण पथ द्वारा जारी किया जाता है) इसका नकारात्मक हिस्सा चार गुना है: i) आप अभी भी उस पिन किए गए प्रमाण द्वारा जारी मिस-जारी किए गए कर्टों के लिए स्वयं को छोड़ दें (आपके जैसे बड़े पैमाने पर आईएमएचओ नहीं अभी भी आपकी आक्रमण की सतह को बड़े पैमाने पर कम कर दिया है, लेकिन फिर भी कुछ लोगों के लिए चिंता है), ii) आप गारंटी नहीं दे सकते कि क्लाइंट उस इंटरमीडिएट प्रमाण का उपयोग करेगा क्योंकि कभी-कभी कई वैध पथ होते हैं। यह दूसरा एक बड़ा सौदा है। आपको लगता है कि इंटरमीडिएट प्रमाण प्रदान करने से यह गारंटी होगी कि इसका उपयोग किया जाएगा लेकिन यह मामला नहीं है (इस के शा -1 उदाहरणों के बहुत सारे)। iii) इस बात की कोई गारंटी नहीं है कि एक ही इंटरमीडिएट या रूट (विशेष रूप से जब तकनीकें sha2 की शुरूआत की तरह बदलती हैं) द्वारा नया प्रमाण जारी किया जाएगा, इसलिए मेरे लिए यह पूरा विकल्प एक गैर-स्टार्टर iv है) यह आपको उसी प्रमाणपत्र प्रदाता का उपयोग करने के लिए जोड़ता है (शायद एक बड़ा सौदा नहीं है लेकिन मुझे स्थानांतरित करने की आजादी पसंद है)। निश्चित नहीं है कि ऐप्स इस सुविधा का मूल रूप से समर्थन करते हैं लेकिन ब्राउज़र निश्चित रूप से करते हैं।

4. अग्रिम में नवीनीकृत करें और पॉलिसी कैश की समयसीमा समाप्त होने तक नई कुंजी का उपयोग न करें। उदाहरण के लिए यदि आपके पास एक वर्ष का कर्ट और 30 दिन की पिनिंग नीति है तो आप 11 महीनों के बाद नवीनीकरण कर सकते हैं, पॉलिसी में नई कुंजी जोड़ सकते हैं, फिर 30 दिनों तक प्रतीक्षा करें ताकि आप सुनिश्चित हो सकें कि हर कोई नई नीति उठाएगा या कम से कम पुरानी नीति समाप्त हो जाएगी, फिर कुंजी और कर्ट स्विच करें। हालांकि, एक छोटी पॉलिसी पर निर्भर करता है और संभावित रूप से उस समय के एक हिस्से को बर्बाद कर देता है (इस उदाहरण में कम से कम 30 दिन), जब तक कि पुराना पॉलिसी समाप्त होने के बाद प्रमाण प्रदाता पहले से ही प्रमाणित नहीं करता है। किसी ऐप के लिए, यदि पिनिंग पॉलिसी में इसे कोड किया गया है, तो इसमें अपडेट को धक्का देने में लगने वाले समय की अवधि शामिल हो सकती है।

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

पिनिंग आश्वासन प्रदान करता है कि एक दुष्ट सीए आपके डोमेन के लिए कर्ट जारी नहीं कर रहा है, लेकिन वास्तव में यह पिनिंग की परेशानी की तुलना में कितनी संभावना है?प्रमाणपत्र पारदर्शिता की तरह कुछ - या यहां तक ​​कि केवल पिनिंग की रिपोर्ट भी उस समस्या का बेहतर उत्तर हो सकती है भले ही वे वास्तव में उस हमले को रोक न दें।

अंत में स्थानीय स्तर पर स्थापित जड़ों (जैसे एंटीवायरस स्कैनर या कॉर्पोरेट प्रॉक्सी के लिए), बाईपास pinning चेक (ब्राउज़र पर कम से कम) फिर से उसकी प्रभावशीलता मेरी आँखों में कम कर देता है जो।

तो पिनिंग का उपयोग करने से पहले ध्यान से सोचें और सुनिश्चित करें कि आप सभी परिणामों को समझते हैं।

Answer 2

mozilla developer site सर्वर प्रमाण पत्र पर हस्ताक्षर किए गए मध्यवर्ती सीए के प्रमाण पत्र को पिन करने की अनुशंसा करता है।

"सीए के मध्यवर्ती प्रमाण पत्र पर पिन रखने की अनुशंसा की जाती है जो प्रमाण पत्र नवीनीकरण और घूर्णन को कम करने के लिए सर्वर प्रमाण पत्र जारी करता है।"

को लागू करने और सार्वजनिक कुंजी pinning परीक्षण के बारे में अधिक जानकारी के लिए आप उल्लेख कर सकते हैं Implementing and Testing HTTP Public Key Pinning (HPKP)