TLS पिनिंग आणि VPN प्रवेश वेगवेगळ्या प्रश्नांची उत्तरे देतात

एक खाजगी मोबाइल ऍप VPN च्या मागे ठेवा आणि विवेकी व्यक्ती विचारेल की त्याला अजूनही प्रमाणपत्र पिनिंगची गरज आहे का। प्रश्न दोन समतुल्य नियंत्रणांपैकी एक निवडल्यासारखा वाटतो, पण प्रत्यक्षात तो दोन वेगळ्या दारांबद्दलचा प्रश्न आहे। VPN ठरवते की या उपकरणाला हा मार्ग वापरण्याची परवानगी आहे का; ऍप ठरवते की पोहोचलेला सर्व्हर अपेक्षित असलेलाच आहे का। दोन्हींची उत्तरे वेगवेगळी द्या आणि रचना सोपी होईल।

दोन दारे, दोन प्रश्न

नेटवर्कमधील प्रवेश क्लायंटबद्दल आहे: हे उपकरण नोंदणीकृत आहे का, त्याचे क्रेडेन्शियल वैध आहे का, आणि धोरण त्याला या मार्गावर जाऊ देतो का? ऍपचा विश्वास सर्व्हरबद्दल आहे: जोडणी ऍप स्वीकारतो अशा ओळखीच्या सेवेपर्यंत पोहोचली का? ही उत्तरे वेगवेगळ्या प्रणालींमधून येतात, वेगवेगळ्या कारणांनी अपयशी होतात, आणि वेगवेगळ्या संघांकडून दुरुस्त होतात। VPN हस्तांदोलन यशस्वी होऊ शकते, पण ऍप सहभागीच्या मागील कालबाह्य प्रमाणपत्राशी बोलत असू शकते। पूर्णपणे पिन केलेले ऍपही कोणालाही न पोहोचणारे राहू शकते, कारण उपकरण कधीच नेटवर्कवर आले नाही।

दोन्ही एकत्र येतात। एक वगळल्यास एक नियंत्रण जाते; दुसरे जोडल्यास त्याची जागा घेतली जात नाही।

पिन प्रत्यक्षात काय मर्यादित करते

पिन ऍप स्वीकारणार्या सर्व्हर ओळखींचा संच अरुंद करते, सामान्यतः कोणत्याही भांडाराने हमी देईल अशा प्रत्येक साखळीवर विश्वास ठेवण्याऐवजी सार्वजनिक की किंवा प्रमाणपत्र हॅशचे नाव घेते। हे सामान्य पडताळणीवर ठेवलेले बंधन आहे, त्याचा पर्याय नाही। सामान्य पडताळणी सांगते की साखळी मुळात विश्वासार्ह आहे का; पिन सांगते की ही या ऍपला अपेक्षित असलेली साखळी आहे का। पहिले पाऊल वगळणारी अंमलबजावणी सुरक्षा मिळवत नाही, फक्त नावीन्य मिळवते।

पिन केली जाणारी वस्तू प्लॅटफॉर्मनुसार वेगळी असते, त्यामुळे एकटा शब्द फार कमी सांगतो। एका उत्पादनाच्या विश्वास भांडारातून हॅश कॉपी करून मोबाइल ऍपमध्ये त्यालाच तीच गोष्ट मानणे ही सामान्य आणि शांत चूक आहे।

प्लॅटफॉर्मवरील पिनिंग हे संरचना आहे, धोरण नाही

Android आपल्या नेटवर्क सुरक्षा संरचनेद्वारे पिनिंग देते, जिथे पिन संच सार्वजनिक कीचे डायजेस्ट ठेवतो आणि साखळीत त्यातील किमान एक असणे आवश्यक आहे। ती फाइल प्रत्येक ऍपसाठी वेगळी आहे आणि जाणीवपूर्वक बिल्ड बदल आवश्यक आहे। iOS कडे समतुल्य मॅनिफेस्ट यंत्रणा नाही, त्यामुळे तिथे पिनिंग ऍपच्या स्वतःच्या विश्वास मूल्यांकन कोडमध्ये राहते।

यंत्रणा वेगळी असल्याने आवश्यकता प्रत्येक प्लॅटफॉर्मसाठी लिहावी लागते। प्लॅटफॉर्मचे नाव न घेता प्रमाणपत्र पिन करा असे सांगणारे धोरण अंमलात आणता येत नाही।

रोटेशन पिन टिकेल की नाही हे ठरवते

अवघड भाग पहिली आवृत्ती नाही, तिच्यानंतरचे प्रमाणपत्र नूतनीकरण आहे। कठोर विश्वास धोरण वैध नवीन कीला हल्लेखोराच्या कीइतक्याच दृढतेने नाकारते।

दोन यंत्रणा रोटेशन सहनशील करतात: गरजेपूर्वीच विश्वासार्ह असलेला बॅकअप पिन, आणि पिन संचावर कालबाह्यता तारीख जेणेकरून अंमलबजावणी थांबेल, ऍप अडकणार नाही। दोन्ही धोरण निर्णय आहेत, आणि कालबाह्यता विशेषतः सुरक्षेची जाणीवपूर्वक घट आहे, निरुपद्रवी टाइमर नाही। ऍपची बिल्ड, TLS अंतिम बिंदू आणि प्रमाणपत्र नूतनीकरण कोण नियंत्रित करते ते नावाने सांगा, आणि त्यांना एका बदल प्रक्रियेत आणा। जर ते तीन वेगळे संघ असतील, तर पिन शेवटी कोणीही नियोजित न केलेला खंड निर्माण करेल।

हरवलेले उपकरण ही तिसरी समस्या आहे

VPN क्रेडेन्शियल रद्द करणे ऍपचे सत्र आवश्यकरीत्या संपवत नाही, आणि सर्व्हर पिन दुसर्याच्या हातातील फोनबद्दल काहीही करत नाही। उपकरण लॉक, क्रेडेन्शियल साठवण, सत्राचे आयुष्य आणि दूरून रद्द करणे हे वेगळे मालक असलेले वेगळे निर्णय आहेत। त्यांना पिनिंग चर्चेत गुंडाळल्यास त्यातील एकाचीही रचना होणार नाही याची खात्री आहे।

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