TLS पिनिङ र VPN प्रवेशले फरक प्रश्नहरूको जवाफ दिन्छन्

एउटा निजी मोबाइल एप VPN पछाडि राख्नुहोस्, विवेकी व्यक्तिले यसलाई अझै प्रमाणपत्र पिनिङ चाहिन्छ कि भनी सोध्नेछ। प्रश्न दुई समान नियन्त्रणमध्ये एउटा छान्ने जस्तो सुनिन्छ, तर वास्तवमा यो दुई फरक ढोकाको प्रश्न हो। VPN ले यो यन्त्रलाई यो बाटो प्रयोग गर्ने अनुमति छ कि छैन भन्ने तय गर्छ; एपले पुगेको सर्भर अपेक्षित नै हो कि भन्ने तय गर्छ। दुवैको जवाफ अलग-अलग दिनुहोस् र डिजाइन सरल हुन्छ।

दुई ढोका, दुई प्रश्न

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

दुवै जोडिन्छन्। एउटा हटाउँदा एउटा नियन्त्रण जान्छ; अर्को थप्दा त्यसको ठाउँ लिँदैन।

पिनले वास्तवमा के सीमित गर्छ

पिनले एपले स्वीकार गर्ने सर्भर पहिचानको समूह साँघुरो बनाउँछ, सामान्यतया कुनै भण्डारले जमानत दिने हरेक शृंखलामा भरोसा गर्नुको सट्टा सार्वजनिक कुञ्जी वा प्रमाणपत्र ह्यासको नाम लिन्छ। यो सामान्य प्रमाणीकरणमाथि राखिएको सीमा हो, त्यसको विकल्प होइन। सामान्य प्रमाणीकरणले शृंखला नै भरपर्दो छ कि छैन भन्ने जवाफ दिन्छ; पिनले यो यस एपले अपेक्षा गरेको शृंखला हो कि होइन भन्ने जवाफ दिन्छ। पहिलो चरण छोड्ने कार्यान्वयनले सुरक्षा पाएन, केवल नयाँपन पायो।

पिन गरिने वस्तु प्लेटफर्मअनुसार फरक हुन्छ, त्यसैले शब्द मात्रले धेरै थोरै बताउँछ। एउटा उत्पादनको भरोसा भण्डारबाट ह्यास प्रतिलिपि गरी मोबाइल एपमा त्यसैलाई उही कुरा मान्नु सामान्य र शान्त गल्ती हो।

प्लेटफर्ममा पिनिङ एउटा कन्फिगरेसन हो, नीति होइन

Android ले आफ्नो नेटवर्क सुरक्षा कन्फिगरेसनमार्फत पिनिङ दिन्छ, जहाँ पिन सेटले सार्वजनिक कुञ्जीका डाइजेस्ट राख्छ र शृंखलामा तीमध्ये कम्तीमा एउटा हुनैपर्छ। त्यो फाइल प्रत्येक एपको लागि छुट्टै छ र जानाजान बिल्ड परिवर्तन चाहिन्छ। iOS सँग समान म्यानिफेस्ट संयन्त्र छैन, त्यसैले त्यहाँ पिनिङ एपकै आफ्नै भरोसा मूल्याङ्कन कोडमा बस्छ।

संयन्त्र फरक भएकाले आवश्यकता प्रत्येक प्लेटफर्मका लागि लेख्नुपर्छ। प्लेटफर्मको नाम नलिई प्रमाणपत्र पिन गर्नु भन्ने नीति लागू गर्न सकिँदैन।

रोटेसनले पिन टिक्छ कि टिक्दैन भन्ने तय गर्छ

गाह्रो भाग पहिलो रिलिज होइन, त्यसपछिको प्रमाणपत्र नवीकरण हो। कडा भरोसा नीतिले वैध नयाँ कुञ्जीलाई आक्रमणकारीको कुञ्जीजत्तिकै दृढताका साथ अस्वीकार गर्छ।

दुई संयन्त्रले रोटेसनलाई सह्य बनाउँछन्: आवश्यक हुनुअघि नै भरोसा गरिएको ब्याकअप पिन, र पिन सेटमा म्याद सकिने मिति ताकि प्रवर्तन रोकियोस्, एप अड्किएर नबसोस्। दुवै नीति निर्णय हुन्, र विशेष गरी म्याद सकिनु सुरक्षाको जानाजान गरिएको कमी हो, हानिरहित टाइमर होइन। एपको बिल्ड, TLS अन्त्य बिन्दु र प्रमाणपत्र नवीकरण कसले नियन्त्रण गर्छ भनी नाम लिनुहोस्, र तिनलाई एउटै परिवर्तन प्रक्रियामा ल्याउनुहोस्। यदि ती तीन फरक टोली हुन् भने, पिनले अन्ततः कसैले योजना नगरेको अवरोध निम्त्याउनेछ।

हराएको यन्त्र तेस्रो समस्या हो

VPN प्रमाणपत्र रद्द गर्दा एपको सत्र अनिवार्य रूपमा अन्त्य हुँदैन, र सर्भर पिनले अरूको हातमा रहेको फोनबारे केही गर्दैन। यन्त्र लक, प्रमाणपत्र भण्डारण, सत्रको आयु र टाढाबाट रद्द गर्नु फरक मालिक भएका फरक निर्णय हुन्। तिनलाई पिनिङ छलफलमा पोको पार्दा तीमध्ये कुनै पनि डिजाइन नहुने निश्चित छ।

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