TLS पिनिंग और VPN प्रवेश अलग-अलग सवालों के जवाब देते हैं

एक निजी मोबाइल ऐप को VPN के पीछे रखिए और कोई विवेकशील व्यक्ति पूछेगा कि क्या उसे अब भी प्रमाणपत्र पिनिंग की ज़रूरत है। सवाल दो समतुल्य नियंत्रणों के बीच चुनाव जैसा लगता है, और असल में यह दो अलग-अलग द्वारों के बारे में सवाल है। VPN तय करता है कि इस उपकरण को इस रास्ते का इस्तेमाल करने की अनुमति है या नहीं; ऐप तय करता है कि जिस सर्वर तक वह पहुँचा वही है जिसकी उसे अपेक्षा थी। दोनों का जवाब अलग-अलग दीजिए और डिज़ाइन आसान हो जाएगा।

दो द्वार, दो सवाल

नेटवर्क में प्रवेश क्लाइंट के बारे में है: क्या यह उपकरण दर्ज है, क्या इसका क्रेडेंशियल वैध है, और क्या नीति इसे इस रास्ते पर जाने देती है? ऐप का भरोसा सर्वर के बारे में है: क्या कनेक्शन ऐसी सेवा तक पहुँचा जिसकी पहचान ऐप स्वीकार करता है? ये जवाब अलग-अलग सिस्टम से आते हैं, अलग-अलग कारणों से विफल होते हैं, और अलग-अलग टीमें इन्हें ठीक करती हैं। VPN हैंडशेक सफल हो सकता है जबकि ऐप साथी के पीछे के समाप्त प्रमाणपत्र से बात कर रहा हो। पूरी तरह पिन किया गया ऐप भी किसी तक न पहुँच सके, क्योंकि उपकरण कभी नेटवर्क पर आया ही नहीं।

दोनों जुड़ते हैं। एक को हटाना एक नियंत्रण हटाना है; दूसरे को जोड़ना उसकी जगह नहीं लेता।

पिन असल में क्या सीमित करता है

पिन ऐप द्वारा स्वीकार की जाने वाली सर्वर पहचानों का समुच्चय सँकरा करता है, आम तौर पर सार्वजनिक कुंजी या प्रमाणपत्र हैश का नाम लेकर, बजाय इसके कि किसी भंडार द्वारा प्रमाणित हर श्रृंखला पर भरोसा किया जाए। यह सामान्य सत्यापन पर रखी गई सीमा है, उसका विकल्प नहीं। सामान्य सत्यापन जवाब देता है कि श्रृंखला बिलकुल भरोसेमंद है या नहीं; पिन जवाब देता है कि क्या यही वह श्रृंखला है जिसकी इस ऐप को अपेक्षा है। जो कार्यान्वयन पहला कदम छोड़ देता है उसने सुरक्षा नहीं पाई, केवल नयापन पाया।

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

प्लेटफ़ॉर्म पर पिनिंग एक कॉन्फ़िगरेशन है, नीति नहीं

Android अपने नेटवर्क सुरक्षा कॉन्फ़िगरेशन के ज़रिए पिनिंग देता है, जहाँ एक पिन सेट सार्वजनिक कुंजी के डाइजेस्ट रखता है और श्रृंखला में उनमें से कम से कम एक होना चाहिए। वह फ़ाइल प्रति ऐप है और जानबूझकर बिल्ड बदलाव माँगती है। iOS में समतुल्य मैनिफ़ेस्ट तंत्र नहीं है, इसलिए वहाँ पिनिंग ऐप के अपने भरोसा मूल्यांकन कोड में रहती है।

चूँकि तंत्र अलग है, आवश्यकता प्रति प्लेटफ़ॉर्म लिखनी होगी। जो नीति प्लेटफ़ॉर्म का नाम लिए बिना कहती है कि प्रमाणपत्र पिन करो, वह लागू करने योग्य नहीं है।

रोटेशन तय करता है कि पिन टिकेगा या नहीं

कठिन हिस्सा पहला रिलीज़ नहीं है, उसके बाद का प्रमाणपत्र नवीनीकरण है। कड़ी भरोसा नीति वैध नई कुंजी को उतनी ही दृढ़ता से अस्वीकार करती है जितनी हमलावर की कुंजी को।

दो तंत्र रोटेशन को सह्य बनाते हैं: एक बैकअप पिन जिस पर ज़रूरत से पहले ही भरोसा हो, और पिन सेट पर समाप्ति तिथि ताकि प्रवर्तन ढीला पड़े, ऐप जाम न हो। दोनों नीति निर्णय हैं, और समाप्ति विशेष रूप से सुरक्षा में जानबूझकर की गई कमी है, कोई हानिरहित टाइमर नहीं। नाम लीजिए कि ऐप का बिल्ड, TLS एंडपॉइंट और प्रमाणपत्र नवीनीकरण कौन नियंत्रित करता है, और उन्हें एक ही बदलाव प्रक्रिया में लाइए। अगर वे तीन अलग टीमें हैं, तो पिन आख़िरकार ऐसा ठहराव लाएगा जिसकी किसी ने योजना नहीं बनाई थी।

खोया हुआ उपकरण तीसरी समस्या है

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

जो एक संबंध आप देखते हैं उसके बजाय चार जाँचिए: इच्छित सर्वर और क्रिया, ऐसा खाता जिसे अस्वीकार होना चाहिए, ऐसी सर्वर पहचान जिसे अस्वीकार होना चाहिए, और नियोजित रोटेशन। काम करता VPN केवल पहले का अभ्यास करता है। लिखिए कि हर परीक्षण ने क्या सिद्ध किया, क्योंकि अगला व्यक्ति मान लेगा कि हरा सुरंग मतलब चारों पास हुए।