मुख्य मजकुराकडे जा

RadSec: TLS वरील RADIUS मुळे WiFi प्रमाणीकरण सुरक्षा कशी सुधारते

हा अधिकृत तांत्रिक संदर्भ स्पष्ट करतो की RadSec (RFC 6614) पारंपारिक RADIUS ट्रॅफिकला TLS एन्क्रिप्शनमध्ये रॅप करून एंटरप्राइझ WiFi प्रमाणीकरण कसे सुरक्षित करते. IT व्यवस्थापक आणि नेटवर्क आर्किटेक्ट्ससाठी डिझाइन केलेले, हे कॉर्पोरेट आणि अतिथी नेटवर्कवर अनएन्क्रिप्टेड UDP RADIUS ट्रॅफिकचे धोके कमी करण्यासाठी आर्किटेक्चर, डिप्लॉयमेंट धोरणे आणि व्यावहारिक पायऱ्या कव्हर करते.

📖 4 मिनिट वाचन📝 871 शब्द🔧 2 सोडवलेली उदाहरणे3 सराव प्रश्न📚 8 महत्वाच्या व्याख्या

हे मार्गदर्शक ऐका

पॉडकास्ट ट्रान्सक्रिप्ट पहा
RadSec: TLS वरील RADIUS मुळे WiFi प्रमाणीकरण सुरक्षा कशी सुधारते एक Purple एंटरप्राइझ WiFi इंटेलिजन्स ब्रीफिंग अंदाजे रनटाइम: 10 मिनिटे --- [परिचय आणि संदर्भ — अंदाजे 1 मिनिट] Purple एंटरप्राइझ WiFi इंटेलिजन्स सिरीजमध्ये आपले स्वागत आहे. मी तुमचा होस्ट आहे, आणि आज आपण अशा एका विषयावर चर्चा करत आहोत जो नेटवर्क सुरक्षा आणि ऑपरेशनल जोखमीच्या अगदी छेदनबिंदूवर आहे: RadSec — औपचारिकरित्या RFC 6614 मध्ये परिभाषित केलेले — आणि जर ते आधीपासून नसेल तर ते तुमच्या इन्फ्रास्ट्रक्चर रोडमॅपवर का असले पाहिजे. जर तुम्ही हॉटेल ग्रुप, रिटेल इस्टेट, स्टेडियम किंवा सार्वजनिक क्षेत्रातील कॅम्पसमध्ये एंटरप्राइझ WiFi साठी जबाबदार असलेले IT व्यवस्थापक, नेटवर्क आर्किटेक्ट किंवा CTO असाल, तर हे ब्रीफिंग तुमच्यासाठी आहे. आम्ही RadSec प्रत्यक्षात काय आहे, पारंपारिक RADIUS प्रोटोकॉल तुम्हाला असुरक्षित का ठेवतो, वास्तविक-जगातील वातावरणात RadSec कसे डिप्लॉय करावे आणि टीम्सना अडकवणाऱ्या त्रुटी कव्हर करणार आहोत. केवळ सिद्धांतासाठी सिद्धांत नाही — तर या तिमाहीत निर्णय घेण्यासाठी तुम्हाला आवश्यक असलेली माहिती. चला तर मग सुरुवात करूया. --- [तांत्रिक सखोल माहिती — अंदाजे 5 मिनिटे] तर, समस्येपासून सुरुवात करूया. RADIUS — रिमोट ऑथेंटिकेशन डायल-इन युझर सर्व्हिस — 1990 च्या दशकापासून एंटरप्राइझ WiFi प्रमाणीकरणाचा कणा आहे. जेव्हा एखादा युझर किंवा डिव्हाइस तुमच्या कॉर्पोरेट किंवा अतिथी WiFi शी कनेक्ट होतो, तेव्हा अ‍ॅक्सेस पॉईंट RADIUS क्लायंट म्हणून काम करतो, प्रमाणीकरण विनंत्या RADIUS सर्व्हरकडे फॉरवर्ड करतो, जो तुमच्या डिरेक्टरीच्या विरूद्ध क्रेडेन्शियल्स प्रमाणित करतो — Active Directory, LDAP, किंवा क्लाउड आयडेंटिटी प्रोव्हायडर — आणि एकतर अ‍ॅक्सेस देतो किंवा नाकारतो. हे 802.1X प्रमाणीकरण मॉडेल आहे जे WPA2-Enterprise आणि WPA3-Enterprise नेटवर्क्सला आधार देते. समस्या अशी आहे की पारंपारिक RADIUS एका वेगळ्या युगासाठी डिझाइन केले गेले होते. ते UDP — युझर डेटाग्राम प्रोटोकॉल — वर पोर्ट्स 1812 आणि 1813 वर चालते. UDP कनेक्शनलेस आहे, ज्याचा अर्थ असा की कोणताही हँडशेक नाही, कोणतीही सेशन स्टेट नाही आणि गंभीरपणे, कोणतेही नेटिव्ह एन्क्रिप्शन नाही. तुमचा अ‍ॅक्सेस पॉईंट आणि तुमचा RADIUS सर्व्हर यांच्यातील एकमेव संरक्षण म्हणजे एक शेअर्ड सिक्रेट — मूलत: एक पासवर्ड — जो MD5 हॅशिंग वापरून ट्रान्झिटमध्ये युझरचा पासवर्ड लपवण्यासाठी वापरला जातो. MD5, जसे तुमच्यापैकी बहुतेकांना माहीत असेल, क्रिप्टोग्राफिकरित्या तुटलेले आहे. ते वर्षानुवर्षे तुटलेले आहे. व्यवहारात याचा अर्थ काय होतो? याचा अर्थ असा की कोणत्याही नेटवर्क सेगमेंटवर जिथे हल्लेखोर RADIUS ट्रॅफिक इंटरसेप्ट करू शकतो — आणि त्यामध्ये तडजोड केलेले स्विचेस, तुमच्या मॅनेजमेंट VLAN वरील रोग (rogue) उपकरणे किंवा रिमोट अ‍ॅक्सेस पॉईंट आणि क्लाउड-होस्टेड RADIUS सर्व्हरमधील कोणताही बिंदू समाविष्ट आहे — ते संभाव्यतः प्रमाणीकरण एक्सचेंजेस कॅप्चर करू शकतात, शेअर्ड सिक्रेट विरूद्ध ऑफलाइन डिक्शनरी हल्ल्यांचा प्रयत्न करू शकतात आणि काही कॉन्फिगरेशन्समध्ये, युझर क्रेडेन्शियल्स पूर्णपणे उघड करू शकतात. 200 प्रॉपर्टीजवर अतिथी WiFi चालवणाऱ्या हॉटेल ग्रुपसाठी, किंवा सार्वजनिक इंटरनेटवरून मध्यवर्ती RADIUS सर्व्हरकडे बॅक हॉलिंग करणाऱ्या प्रत्येक स्टोअरमध्ये अ‍ॅक्सेस पॉईंट्स असलेल्या रिटेल चेनसाठी, हा सैद्धांतिक धोका नाही. हा एक लाइव्ह अटॅक सरफेस आहे. RadSec नेमके हेच सोडवते. RadSec — RFC 6614 मध्ये परिभाषित केलेले आणि RFC 7360 द्वारे अपडेट केलेले — RADIUS ट्रॅफिकला TLS टनेलमध्ये रॅप करते. UDP ऐवजी, ते पोर्ट 2083 वर TCP वापरते. शेअर्ड सिक्रेट आणि MD5 ऐवजी, ते X.509 प्रमाणपत्रांसह म्युच्युअल TLS प्रमाणीकरण वापरते. RADIUS क्लायंट आणि RADIUS सर्व्हर दोघेही प्रमाणपत्रे सादर करतात, एकमेकांची ओळख पडताळतात आणि कोणताही प्रमाणीकरण डेटा एक्सचेंज होण्यापूर्वी एन्क्रिप्टेड सेशन स्थापित करतात. TLS 1.3 ही सध्याची शिफारस केलेली आवृत्ती आहे, जी फॉरवर्ड सिक्रेसी प्रदान करते आणि लेगसी सायफर असुरक्षिततेची श्रेणी दूर करते. याचा व्यावहारिक परिणाम लक्षणीय आहे. क्रेडेन्शियल डेटा, युझर अ‍ॅट्रिब्यूट्स आणि सेशन टोकन्स अ‍ॅक्सेस पॉईंट — किंवा RadSec प्रॉक्सी — आणि RADIUS सर्व्हर दरम्यान एंड-टू-एंड एन्क्रिप्टेड असतात. वायरवर ट्रॅफिक इंटरसेप्ट करणाऱ्या हल्लेखोराला फक्त एन्क्रिप्टेड TLS रेकॉर्ड्स दिसतात. शेअर्ड सिक्रेट अद्याप बॅकवर्ड कंपॅटिबिलिटीसाठी उपस्थित आहे, परंतु ते आता कोणतेही अर्थपूर्ण सुरक्षा कार्य करत नाही — TLS भार उचलत आहे. येथे आणखी एक परिमाण आहे जे वाढत्या प्रमाणात संबंधित आहे: रोमिंग. युरोप आणि त्यापलीकडील विद्यापीठे आणि संशोधन संस्थांद्वारे वापरले जाणारे Eduroam फेडरेशन, त्याच्या आंतर-संस्थात्मक रोमिंग पायाभूत सुविधांचा भाग म्हणून वर्षानुवर्षे RadSec चालवत आहे. अलीकडेच, Wi-Fi अलायन्सचे OpenRoaming स्टँडर्ड — जे सहभागी ठिकाणांवर अखंड WiFi रोमिंग सक्षम करते — सर्व फेडरेशन ट्रॅफिकसाठी RadSec अनिवार्य करते. जर तुम्ही OpenRoaming-सक्षम पायाभूत सुविधा डिप्लॉय करत असाल, तर RadSec ऐच्छिक नाही; ती एक पूर्वअट आहे. Purple त्याच्या कनेक्ट लायसन्स अंतर्गत OpenRoaming ला सपोर्ट करते, फेडरेशनमध्ये आयडेंटिटी प्रोव्हायडर म्हणून काम करते आणि ते सुरक्षित रोमिंग फॅब्रिक कसे कार्य करते यासाठी RadSec मध्यवर्ती आहे. अनुपालनाच्या दृष्टिकोनातून, RadSec हे PCI DSS 4.0 शी वाढत्या प्रमाणात संबंधित आहे, जे ट्रान्झिटमधील प्रमाणीकरण डेटाच्या संरक्षणाभोवती आवश्यकता कडक करते. जर तुमची WiFi पायाभूत सुविधा पेमेंट कार्ड वातावरणाला स्पर्श करत असेल — आणि रिटेल आणि हॉस्पिटॅलिटीमध्ये, ती वारंवार करते — तर पारंपारिक RADIUS मधील एन्क्रिप्शन गॅप ही एक घडण्याची वाट पाहत असलेली त्रुटी आहे. GDPR ला वैयक्तिक डेटाचे संरक्षण करण्यासाठी योग्य तांत्रिक उपायांची आवश्यकता आहे; तुमच्या नेटवर्कवर अनएन्क्रिप्टेड वाहणारे युझर क्रेडेन्शियल्स आणि सेशन मेटाडेटा डेटा संरक्षण ऑडिटमध्ये बचाव करणे कठीण आहे. आता आर्किटेक्चरबद्दल बोलूया. RadSec साठी दोन प्राथमिक डिप्लॉयमेंट पॅटर्न आहेत. पहिला म्हणजे तुमच्या RADIUS सर्व्हर आणि अ‍ॅक्सेस पॉईंट्सवर नेटिव्ह RadSec सपोर्ट. FreeRADIUS 3.0 आणि त्यावरील आवृत्त्या RadSec ला नेटिव्हली सपोर्ट करतात. Microsoft NPS सध्याच्या रिलीझनुसार RadSec ला नेटिव्हली सपोर्ट करत नाही, जी Windows-केंद्रित पायाभूत सुविधा चालवणाऱ्या संस्थांसाठी एक महत्त्वपूर्ण मर्यादा आहे. Cisco ISE RadSec ला सपोर्ट करते. Aruba ClearPass RadSec ला सपोर्ट करते. जर तुमचा RADIUS सर्व्हर आणि तुमचा अ‍ॅक्सेस पॉईंट व्हेंडर दोघेही RadSec ला नेटिव्हली सपोर्ट करत असतील, तर हा सर्वात स्वच्छ मार्ग आहे — दोन्ही टोकांना TLS प्रमाणपत्रे कॉन्फिगर करा, तुमच्या फायरवॉलवर TCP 2083 उघडा आणि तुम्ही RADIUS ट्रॅफिक एंड-टू-एंड एन्क्रिप्ट करत आहात. दुसरा पॅटर्न RadSec प्रॉक्सी आहे. व्यवहारात हे अधिक सामान्य डिप्लॉयमेंट आहे, विशेषतः लेगसी RADIUS पायाभूत सुविधा किंवा मिश्र-व्हेंडर वातावरण असलेल्या संस्थांसाठी. एक RadSec प्रॉक्सी — radsecproxy ही सर्वात मोठ्या प्रमाणावर डिप्लॉय केलेली ओपन-सोर्स अंमलबजावणी आहे — तुमच्या अ‍ॅक्सेस पॉईंट्स आणि तुमच्या RADIUS सर्व्हरच्या दरम्यान बसते. अ‍ॅक्सेस पॉईंट्स लोकल नेटवर्कवरील प्रॉक्सीला UDP वर स्टँडर्ड RADIUS पाठवतात. प्रॉक्सी ते कनेक्शन संपुष्टात आणते, TLS टनेलमध्ये RADIUS ट्रॅफिक पुन्हा एन्कॅप्स्युलेट करते आणि TCP 2083 वर अपस्ट्रीम RADIUS सर्व्हरकडे फॉरवर्ड करते. हा दृष्टिकोन तुम्हाला तुमचा RADIUS सर्व्हर न बदलता विद्यमान पायाभूत सुविधांमध्ये RadSec जोडण्याची परवानगी देतो आणि जेव्हा तुमचा RADIUS सर्व्हर क्लाउडमध्ये होस्ट केलेला असतो किंवा सार्वजनिक इंटरनेटवरून अ‍ॅक्सेस केला जातो तेव्हा तो विशेषतः उपयुक्त ठरतो. सर्टिफिकेट मॅनेजमेंट ही ऑपरेशनल गुंतागुंत आहे ज्यासाठी तुम्हाला नियोजन करणे आवश्यक आहे. म्युच्युअल TLS साठी वापरलेली X.509 प्रमाणपत्रे जारी करण्यासाठी आणि व्यवस्थापित करण्यासाठी तुम्हाला PKI — पब्लिक की इन्फ्रास्ट्रक्चर — ची आवश्यकता असेल. याचा अर्थ सर्टिफिकेट ऑथॉरिटी, प्रत्येक RADIUS क्लायंट आणि सर्व्हरसाठी प्रमाणपत्र जारी करणे आणि कालबाह्य होण्यापूर्वी प्रमाणपत्र रोटेशनची प्रक्रिया. लक्ष न देता कालबाह्य होणारी प्रमाणपत्रे तुमच्या नेटवर्कवरील प्रत्येक युझरसाठी एकाच वेळी प्रमाणीकरण खंडित करतील — आणि ही अशी परिस्थिती आहे जी तुम्हाला टाळायची आहे. ACME किंवा तुमच्या CA च्या API चा वापर करून प्रमाणपत्र नूतनीकरण स्वयंचलित करा आणि कालबाह्य तारखांच्या खूप आधी मॉनिटरिंग अलर्ट सेट करा. --- [अंमलबजावणी शिफारसी आणि त्रुटी — अंदाजे 2 मिनिटे] मी तुम्हाला व्यावहारिक शिफारसी देतो. पहिले: तुम्ही डिप्लॉय करण्यापूर्वी ऑडिट करा. तुमच्या वातावरणातील प्रत्येक RADIUS क्लायंट — अ‍ॅक्सेस पॉईंट्स, VPN कॉन्सन्ट्रेटर्स, 802.1X करणारे स्विचेस — आणि प्रत्येक RADIUS सर्व्हर मॅप करा. कोणते नेटिव्हली RadSec ला सपोर्ट करतात आणि कोणाला प्रॉक्सीची आवश्यकता असेल हे समजून घ्या. हे ऑडिट सामान्यतः लेगसी उपकरणे समोर आणते जे TLS ला अजिबात सपोर्ट करत नाहीत आणि ते तुमच्या रिप्लेसमेंट रोडमॅपवर असणे आवश्यक आहे. दुसरे: सर्वाधिक-जोखमीच्या ट्रॅफिकपासून सुरुवात करा. जर तुमच्याकडे सार्वजनिक इंटरनेटवरून जाणारे RADIUS ट्रॅफिक असेल — रिमोट साइट्स, क्लाउड-होस्टेड RADIUS, मल्टी-प्रॉपर्टी हॉटेल ग्रुप्स — तर ती तुमची पहिली प्राथमिकता आहे. चांगल्या प्रकारे विभागलेल्या मॅनेजमेंट VLAN वरील लोकल RADIUS ट्रॅफिक कमी जोखमीचे आहे, परंतु ते अद्याप रोडमॅपवर असले पाहिजे. तिसरे: गो-लाइव्ह होण्यापूर्वी म्युच्युअल TLS ची पूर्णपणे चाचणी करा. RadSec डिप्लॉयमेंट्समधील सर्वात सामान्य अपयश मोड म्हणजे प्रमाणपत्र पडताळणी त्रुटी — न जुळणारी कॉमन नेम्स, कालबाह्य झालेली इंटरमीडिएट प्रमाणपत्रे किंवा सर्व्हर प्रमाणपत्रावर स्वाक्षरी करणाऱ्या CA वर विश्वास न ठेवणारे क्लायंट्स. तुम्ही प्रोडक्शन ट्रॅफिक कट ओव्हर करण्यापूर्वी TLS हँडशेक्सची चाचणी करण्यासाठी openssl s_client वापरा. चौथे: मॉनिटरिंगकडे दुर्लक्ष करू नका. RadSec एक TCP कनेक्शन लेयर जोडते जे पारंपारिक RADIUS मध्ये नसते. TCP कनेक्शन अपयश, TLS हँडशेक टाइमआउट्स आणि प्रमाणपत्र त्रुटी तुमच्या युझर्ससाठी प्रमाणीकरण अपयश म्हणून प्रकट होतील. तुमचे RADIUS सर्व्हर लॉग्स आणि तुमचे प्रॉक्सी लॉग्स तुमच्या SIEM किंवा मॉनिटरिंग प्लॅटफॉर्ममध्ये फीड होत असल्याची खात्री करा जेणेकरून तुम्ही प्रमाणीकरण धोरण समस्येपासून RadSec कनेक्टिव्हिटी समस्या वेगळी करू शकाल. मी सर्वात जास्त वेळा पाहतो ती त्रुटी म्हणजे संस्था सर्व्हरच्या बाजूला RadSec डिप्लॉय करतात परंतु त्यांचे फायरवॉल नियम अपडेट करायला विसरतात. प्रत्येक RADIUS क्लायंट आणि RADIUS सर्व्हर किंवा प्रॉक्सी दरम्यान TCP 2083 उघडे असणे आवश्यक आहे. जर तुम्हाला UDP 1812 नियम व्यवस्थापित करण्याची सवय असेल, तर फायरवॉल बदल प्रक्रियेत TCP 2083 सुटू शकते. --- [रॅपिड-फायर प्रश्नोत्तरे — अंदाजे 1 मिनिट] मी नियमितपणे ऐकत असलेल्या काही प्रश्नांवरून जातो. "RadSec 802.1X ची जागा घेते का?" नाही. RadSec अ‍ॅक्सेस पॉईंट आणि RADIUS सर्व्हरमधील ट्रान्सपोर्ट लेयर सुरक्षित करते. 802.1X हे क्लायंट डिव्हाइस आणि अ‍ॅक्सेस पॉईंटमधील प्रमाणीकरण फ्रेमवर्क आहे. ते वेगवेगळ्या लेयर्सवर काम करतात आणि पूरक आहेत. "सर्व अ‍ॅक्सेस पॉईंट व्हेंडर्सवर RadSec समर्थित आहे का?" सार्वत्रिकपणे नाही. Cisco, Aruba, Ruckus आणि Meraki या सर्वांमध्ये RadSec सपोर्टचे वेगवेगळे स्तर आहेत — तुमची विशिष्ट फर्मवेअर आवृत्ती तपासा. जिथे नेटिव्ह सपोर्ट अनुपस्थित आहे, तिथे RadSec प्रॉक्सी हा तुमचा उपाय आहे. "DTLS बद्दल काय — DTLS वरील RADIUS?" RFC 7360 DTLS वरील RADIUS परिभाषित करते, जे TCP ऐवजी UDP वापरते, एन्क्रिप्शन जोडताना पारंपारिक RADIUS ची काही कनेक्शनलेस वैशिष्ट्ये जतन करते. हे TLS वरील RadSec पेक्षा कमी प्रमाणात डिप्लॉय केले जाते परंतु हाय-थ्रूपुट वातावरणात लेटन्सीची चिंता असल्यास मूल्यांकन करण्यासारखे आहे. "याचा रोमिंग कार्यप्रदर्शनावर कसा परिणाम होतो?" RadSec चे TCP कनेक्शन पर्सिस्टंट आहे, जे पुढील प्रमाणीकरण विनंत्यांसाठी कनेक्शन सेटअप ओव्हरहेड कमी करून फेडरेटेड वातावरणात रोमिंग कार्यप्रदर्शन प्रत्यक्षात सुधारू शकते. --- [सारांश आणि पुढील पायऱ्या — अंदाजे 1 मिनिट] शेवटी: पारंपारिक RADIUS मधील खऱ्या सुरक्षा त्रुटीसाठी RadSec हे परिपक्व, मानकांवर आधारित उत्तर आहे. जर तुम्ही मोठ्या प्रमाणावर एंटरप्राइझ WiFi चालवत असाल — एकाधिक साइट्सवर, इंटरनेटवर किंवा PCI DSS किंवा GDPR च्या अधीन असलेल्या वातावरणात — तर प्रश्न RadSec डिप्लॉय करायचे की नाही हा नाही, तर कधी आणि कसे हा आहे. तुमच्या पुढील पायऱ्या: या आठवड्यात तुमच्या RADIUS पायाभूत सुविधांचे ऑडिट करा. तुमचे सर्वाधिक-जोखमीचे ट्रॅफिक फ्लो ओळखा. नेटिव्ह RadSec सपोर्टसाठी तुमचे RADIUS सर्व्हर आणि अ‍ॅक्सेस पॉईंट व्हेंडर डॉक्युमेंटेशन तपासा. जर तुम्ही FreeRADIUS चालवत असाल, तर तुम्ही एका दिवसात टेस्ट RadSec डिप्लॉयमेंट चालू करू शकता. जर तुम्ही Microsoft NPS वर असाल, तर प्रॉक्सी किंवा RadSec-सक्षम सर्व्हरकडे मायग्रेशन मार्गाचे मूल्यांकन सुरू करा. Purple चे प्लॅटफॉर्म एंटरप्राइझ RADIUS पायाभूत सुविधांशी इंटिग्रेट करण्यासाठी डिझाइन केलेले आहे, जे कॉर्पोरेट आणि अतिथी WiFi दोन्ही वातावरणांसाठी सुरक्षित प्रमाणीकरण फ्लोला सपोर्ट करते. जर तुम्हाला समजून घ्यायचे असेल की RadSec तुमच्या विशिष्ट डिप्लॉयमेंटमध्ये कसे बसते, तर Purple टीम तुम्हाला त्यातून मार्गदर्शन करू शकते. ऐकल्याबद्दल धन्यवाद. पुढच्या वेळेपर्यंत. --- स्क्रिप्टचा शेवट

header_image.png

Executive Summary

Traditional RADIUS over UDP (ports 1812/1813) was not designed for the modern enterprise threat landscape. Relying solely on a shared secret and MD5 hashing, it leaves authentication credentials and session attributes vulnerable to interception, particularly when traversing public networks or large distributed estates like hospitality and retail chains. RadSec (RADIUS over TLS, RFC 6614) solves this fundamental security gap by encapsulating RADIUS traffic within a TCP-based TLS 1.3 tunnel over port 2083.

For CTOs and network architects, deploying RadSec is no longer just a best practice—it is a critical requirement for protecting corporate wifi , maintaining PCI DSS 4.0 compliance, and participating in modern federated roaming frameworks like OpenRoaming. This guide details the architecture, implementation patterns, and operational requirements for securing your authentication infrastructure.

Technical Deep-Dive: RADIUS vs. RadSec

The Vulnerability in Traditional RADIUS

In a standard 802.1X deployment, the access point (authenticator) forwards client credentials to the RADIUS server (authentication server). In traditional RADIUS, this payload is sent over UDP. The only protection is a pre-shared key (PSK) used to obfuscate the password via MD5.

This architecture presents three critical risks:

  1. Lack of Transport Encryption: User attributes, MAC addresses, and session data are transmitted in cleartext.
  2. Cryptographic Weakness: MD5 is vulnerable to offline dictionary attacks if an attacker captures the traffic.
  3. No Mutual Authentication: The access point cannot cryptographically verify it is talking to the legitimate RADIUS server, enabling rogue server attacks.

The RadSec Architecture (RFC 6614)

RadSec addresses these flaws by shifting the transport layer from UDP to TCP and wrapping the entire payload in TLS.

architecture_overview.png

  • Transport: TCP Port 2083 ensures reliable delivery and stateful connections, improving performance in high-latency environments.
  • Encryption: TLS 1.2 or 1.3 provides robust, end-to-end encryption of all RADIUS attributes.
  • Mutual Authentication: Both the RADIUS client (or proxy) and the server must present valid X.509 certificates issued by a trusted Certificate Authority (CA). The shared secret is retained only for backwards compatibility; TLS provides the actual security. This architecture is essential for distributed environments, such as Retail chains or Hospitality venues, where access points backhaul authentication requests over the public internet to a central or cloud-hosted RADIUS server.

Implementation Guide

Deploying RadSec typically follows one of two patterns: Native Support or Proxy-based.

Pattern 1: Native RadSec

If your infrastructure supports it natively (e.g., FreeRADIUS 3.0+, Cisco ISE, Aruba ClearPass), you configure TLS certificates directly on the RADIUS server and the access points/controllers. This provides true end-to-end encryption from the edge to the core.

Pattern 2: The RadSec Proxy

Many legacy RADIUS servers (notably Microsoft NPS) do not natively support RadSec. In these environments, a proxy (such as radsecproxy) is deployed.

  1. Local Leg: The AP sends standard UDP RADIUS to the local proxy.
  2. WAN Leg: The proxy encapsulates the traffic in TLS and sends it over TCP 2083 to the upstream server.

This pattern allows you to secure wide-area traffic without replacing legacy infrastructure.

deployment_checklist.png

Integration with Purple

Purple's Guest WiFi and WiFi Analytics platforms integrate seamlessly with enterprise RADIUS infrastructure. Under the Connect licence, Purple acts as a free identity provider for OpenRoaming, where RadSec is a mandatory requirement for securing federation traffic between venues and the central hub.

Best Practices

  1. Certificate Lifecycle Management: Mutual TLS relies on valid certificates. Implement automated renewal (e.g., via ACME) and strict monitoring. An expired certificate will cause a total authentication outage.
  2. Firewall Configuration: Ensure TCP port 2083 is explicitly allowed both outbound from the venue and inbound to the RADIUS server. Do not assume existing UDP 1812 rules will apply.
  3. Prioritise High-Risk Traffic: Begin deployment on links that traverse the public internet or untrusted WANs before moving to local management VLANs.

For more on securing the edge, read our guide on Access Point Security: Your 2026 Enterprise Guide .

Troubleshooting & Risk Mitigation

When RadSec fails, it is rarely an authentication issue; it is almost always a TLS or TCP issue.

  • Symptom: Access points show as disconnected from the RADIUS server.
    • Check: Firewall rules for TCP 2083. Traditional RADIUS uses UDP; network teams frequently forget to open the TCP port.
  • Symptom: TCP connection establishes, but authentication fails immediately.
    • Check: Certificate validation. Verify that the Common Name (CN) or Subject Alternative Name (SAN) matches, the certificate has not expired, and the client trusts the signing CA. Use openssl s_client -connect :2083 to debug the handshake.

Ensure your network fundamentals are solid. Review our advice on Protect Your Network with Strong DNS and Security .

ROI & Business Impact

Implementing RadSec is a risk mitigation investment. The ROI is measured in the avoidance of data breaches, compliance fines (PCI DSS, GDPR), and reputational damage. Furthermore, it enables participation in modern roaming federations like OpenRoaming, which can significantly enhance the guest experience in Healthcare and Transport environments.

Listen to the Briefing

For a deeper dive into the operational realities of deploying RadSec, listen to our 10-minute technical briefing:

For specific configuration steps on client devices, refer to How to Set Up Enterprise WiFi on iOS and macOS with 802.1X or the Portuguese version Como Configurar WiFi Corporativo em iOS e macOS com 802.1X .

महत्वाच्या व्याख्या

RadSec

RADIUS प्रोटोकॉलचा एक विस्तार जो TCP पोर्ट 2083 वर TLS टनेलमध्ये RADIUS ट्रॅफिक एन्कॅप्स्युलेट करतो.

अविश्वासू नेटवर्कवरून प्रवास करताना प्रमाणीकरण ट्रॅफिक सुरक्षित करण्यासाठी वापरले जाते, ज्यामुळे क्रेडेन्शियल इंटरसेप्शनला प्रतिबंध होतो.

Mutual TLS (mTLS)

एक सुरक्षा प्रक्रिया जिथे एन्क्रिप्टेड कनेक्शन स्थापित करण्यापूर्वी एकमेकांची ओळख पडताळण्यासाठी क्लायंट आणि सर्व्हर दोघेही X.509 प्रमाणपत्रे सादर करतात.

RadSec ची मुख्य प्रमाणीकरण यंत्रणा, जी स्टॅटिक शेअर्ड सिक्रेट्सवरील अवलंबित्व बदलते.

802.1X

पोर्ट-आधारित नेटवर्क अ‍ॅक्सेस कंट्रोलसाठी IEEE स्टँडर्ड, जे LAN किंवा WLAN शी कनेक्ट होण्याचा प्रयत्न करणाऱ्या उपकरणांना प्रमाणित करण्यासाठी वापरले जाते.

एक फ्रेमवर्क जे डिरेक्टरीच्या विरूद्ध युझर क्रेडेन्शियल्स प्रमाणित करण्यासाठी RADIUS (आणि विस्ताराने, RadSec) वर अवलंबून असते.

radsecproxy

एक ओपन-सोर्स डेमन जो प्रॉक्सी म्हणून काम करतो, स्टँडर्ड UDP RADIUS ट्रॅफिकला RadSec (TCP वरील TLS) मध्ये रूपांतरित करतो आणि याउलट.

जेव्हा अ‍ॅक्सेस पॉईंट्स किंवा Microsoft NPS सारख्या लेगसी RADIUS सर्व्हर्समध्ये नेटिव्ह RadSec सपोर्ट नसतो तेव्हा डिप्लॉय केले जाते.

OpenRoaming

Wi-Fi अलायन्सने विकसित केलेले एक फेडरेशन स्टँडर्ड जे युझर्सना जागतिक स्तरावर सहभागी WiFi नेटवर्क्सशी अखंडपणे आणि सुरक्षितपणे कनेक्ट होण्याची परवानगी देते.

OpenRoaming ठिकाणे आणि आयडेंटिटी प्रोव्हायडर्स दरम्यान प्रमाणीकरण ट्रॅफिक सुरक्षित करण्यासाठी RadSec चा वापर अनिवार्य करते.

Shared Secret

पारंपारिक RADIUS मध्ये पासवर्ड लपवण्यासाठी आणि विनंत्यांच्या स्रोताची पडताळणी करण्यासाठी वापरली जाणारी एक स्टॅटिक टेक्स्ट स्ट्रिंग.

बॅकवर्ड कंपॅटिबिलिटीसाठी RadSec कॉन्फिगरेशनमध्ये तांत्रिकदृष्ट्या अद्याप उपस्थित असले तरी, त्याची जागा TLS एन्क्रिप्शनने घेतली आहे.

FreeRADIUS

एक मोठ्या प्रमाणावर डिप्लॉय केलेला ओपन-सोर्स RADIUS सर्व्हर जो RadSec साठी नेटिव्ह सपोर्ट प्रदान करतो.

त्याच्या लवचिकतेमुळे आणि नेटिव्ह TLS क्षमतांमुळे अनेकदा एंटरप्राइझ वातावरणात आणि रोमिंग फेडरेशन्समध्ये वापरले जाते.

PKI (Public Key Infrastructure)

डिजिटल प्रमाणपत्रे तयार करण्यासाठी, व्यवस्थापित करण्यासाठी, वितरित करण्यासाठी आणि रद्द करण्यासाठी आवश्यक असलेल्या भूमिका, धोरणे आणि सॉफ्टवेअरचे फ्रेमवर्क.

RadSec डिप्लॉय करण्यासाठी एक पूर्वअट, कारण तुम्ही सर्व RADIUS क्लायंट्स आणि सर्व्हर्ससाठी प्रमाणपत्रे जारी करणे आणि व्यवस्थापित करणे आवश्यक आहे.

सोडवलेली उदाहरणे

एक 200-प्रॉपर्टी हॉटेल ग्रुप कर्मचाऱ्यांच्या प्रमाणीकरणासाठी मध्यवर्तीरित्या Microsoft NPS वापरतो. प्रत्येक हॉटेलमधील अ‍ॅक्सेस पॉईंट्स सध्या UDP 1812 द्वारे सार्वजनिक इंटरनेटवरून RADIUS विनंत्या पाठवतात. CTO सर्व प्रमाणीकरण ट्रॅफिकसाठी एन्क्रिप्शन अनिवार्य करतात, परंतु या वर्षी NPS बदलणे हा पर्याय नाही.

प्रत्येक हॉटेल साइटवर RadSec प्रॉक्सी (उदा. radsecproxy) आणि NPS सर्व्हर्सच्या समोर मध्यवर्ती डेटा सेंटरमध्ये संबंधित प्रॉक्सी डिप्लॉय करा. स्थानिक APs स्थानिक प्रॉक्सीला UDP RADIUS पाठवतात. स्थानिक प्रॉक्सी इंटरनेटवरून मध्यवर्ती प्रॉक्सीकडे TCP 2083 वर म्युच्युअल TLS टनेल स्थापित करते. मध्यवर्ती प्रॉक्सी TLS टनेल संपुष्टात आणते आणि NPS सर्व्हरला स्टँडर्ड UDP RADIUS फॉरवर्ड करते.

परीक्षकाचे भाष्य: हा दृष्टिकोन मुख्य Microsoft NPS पायाभूत सुविधांच्या महागड्या आणि व्यत्यय आणणाऱ्या रिप-अँड-रिप्लेसची आवश्यकता न ठेवता—अविश्वासू WAN वर प्रमाणीकरण डेटा एन्क्रिप्ट करण्याचे—प्राथमिक सुरक्षा उद्दिष्ट साध्य करतो. हे प्रॉक्सीसाठी सर्टिफिकेट मॅनेजमेंट ओव्हरहेड सादर करते, जे स्वयंचलित असणे आवश्यक आहे.

एक मोठे विद्यापीठ भेट देणाऱ्या शिक्षणतज्ञांना अखंड अ‍ॅक्सेस देण्यासाठी त्यांच्या कॅम्पसमध्ये OpenRoaming डिप्लॉय करत आहे. ते FreeRADIUS 3.0 चालवत आहेत.

FreeRADIUS मध्ये नेटिव्ह RadSec सक्षम करा. OpenRoaming फेडरेशनद्वारे विश्वासार्ह असलेल्या CA कडून X.509 प्रमाणपत्रे जनरेट करा. फेडरेशन हबकडे इनबाउंड आणि आउटबाउंड TCP 2083 ट्रॅफिकला परवानगी देण्यासाठी कॅम्पस फायरवॉल कॉन्फिगर करा. सर्व फेडरेशन-बाउंड प्रमाणीकरण विनंत्यांसाठी RadSec वापरण्यासाठी वायरलेस LAN कंट्रोलर्स कॉन्फिगर करा.

परीक्षकाचे भाष्य: FreeRADIUS नेटिव्हली RadSec ला सपोर्ट करत असल्यामुळे, कोणत्याही प्रॉक्सीची आवश्यकता नाही. हे सर्वात स्वच्छ आर्किटेक्चर आहे. येथील महत्त्वपूर्ण अवलंबित्व म्हणजे प्रमाणपत्रे OpenRoaming फेडरेशनच्या विशिष्ट PKI आवश्यकतांशी संरेखित असल्याची खात्री करणे.

सराव प्रश्न

Q1. तुमच्या टीमने तुमचे रिमोट ब्रांच अ‍ॅक्सेस पॉईंट्स आणि तुमच्या मध्यवर्ती FreeRADIUS सर्व्हर दरम्यान नेटिव्ह RadSec डिप्लॉय केले आहे. APs सर्व्हरला पिंग करू शकतात, परंतु प्रमाणीकरण विनंत्या पूर्णपणे टाइम आउट होत आहेत आणि RADIUS लॉग्सवर कोणतेही ट्रॅफिक येत नाहीये.

टीप: RadSec पारंपारिक RADIUS पेक्षा वेगळा ट्रान्सपोर्ट प्रोटोकॉल आणि पोर्ट वापरते.

नमुना उत्तर पहा

फायरवॉल बहुधा TCP पोर्ट 2083 ब्लॉक करत आहे. पारंपारिक RADIUS ची सवय असलेल्या नेटवर्क टीम्स अनेकदा फक्त UDP पोर्ट्स 1812/1813 ला परवानगी देतात. तुम्ही ब्रांचमधून आउटबाउंड आणि RADIUS सर्व्हरकडे इनबाउंड TCP 2083 ला स्पष्टपणे परवानगी देणे आवश्यक आहे.

Q2. तुम्ही एका रिटेल क्लायंटच्या WiFi आर्किटेक्चरचे ऑडिट करत आहात. ते मध्यवर्तीरित्या Microsoft NPS वापरतात. त्यांचे स्टोअर APs IPsec VPN द्वारे इंटरनेटवरून प्रमाणीकरण विनंत्या पाठवतात. येथे RadSec आवश्यक आहे का?

टीप: आधीपासूनच अस्तित्वात असलेल्या एन्क्रिप्शनच्या लेयर्सचा विचार करा.

नमुना उत्तर पहा

जरी RadSec ही सर्वोत्तम सराव असली तरी, IPsec VPN आधीपासूनच अविश्वासू इंटरनेटवरील UDP RADIUS ट्रॅफिकसाठी ट्रान्सपोर्ट लेयर एन्क्रिप्शन प्रदान करत आहे. येथे RadSec डिप्लॉय केल्याने डिफेन्स-इन-डेप्थ मिळेल परंतु ट्रॅफिक नेटिव्हली इंटरनेटवरून प्रवास करत असल्याच्या तुलनेत हे कमी तातडीचे आहे.

Q3. यशस्वी RadSec प्रॉक्सी डिप्लॉयमेंटच्या एका आठवड्यानंतर, सोमवारी सकाळी 09:00 वाजता संपूर्ण एंटरप्राइझमधील सर्व WiFi प्रमाणीकरण एकाच वेळी अयशस्वी होते. नेटवर्क टीम पुष्टी करते की फायरवॉल नियम बदललेले नाहीत.

टीप: स्वतः TLS टनेलसाठी प्राथमिक प्रमाणीकरण यंत्रणा काय आहे?

नमुना उत्तर पहा

म्युच्युअल TLS प्रमाणीकरणासाठी वापरलेली X.509 प्रमाणपत्रे बहुधा कालबाह्य झाली आहेत. जेव्हा प्रमाणपत्रे कालबाह्य होतात, तेव्हा TLS हँडशेक अयशस्वी होतो, TCP कनेक्शन ड्रॉप होते आणि RADIUS ट्रॅफिक वाहू शकत नाही. हे टाळण्यासाठी स्वयंचलित प्रमाणपत्र मॉनिटरिंग आणि रोटेशन लागू करा.

या मालिकेमध्ये पुढे वाचा

कर्मचारी आणि अतिथी WiFi नेटवर्क सुरक्षितपणे कसे वेगळे करावे

हे अधिकृत तांत्रिक मार्गदर्शक IT नेत्यांना VLAN आणि 802.1X चा वापर करून कर्मचारी, अतिथी आणि IoT WiFi नेटवर्क्स सुरक्षितपणे वेगळे करण्यासाठी कृतीयोग्य रणनीती प्रदान करते. हे एंटरप्राइझ इन्फ्रास्ट्रक्चर सुरक्षित कसे करावे, PCI DSS अनुपालन कसे राखायचे आणि फर्स्ट-पार्टी डेटा कॅप्चर करण्यासाठी कॅप्टिव्ह पोर्टलचा कसा फायदा घ्यावा याचे तपशील प्रदान करते.

मार्गदर्शिका वाचा →

सर्वोत्तम DNS filtering: व्यवसायांसाठी एक व्यापक मार्गदर्शक

हे तांत्रिक संदर्भ मार्गदर्शक स्पष्ट करते की कशा प्रकारे एंटरप्राइझ DNS filtering हे कनेक्शन स्थापित होण्यापूर्वीच - रिझोल्यूशन लेयरवर दुर्भावनापूर्ण डोमेन्स ब्लॉक करून सार्वजनिक नेटवर्क सुरक्षित करते. हे IT संचालक, नेटवर्क आर्किटेक्ट आणि वेन्यू ऑपरेशन्स टीम्सना डेव्हलपमेंट आर्किटेक्चर, फायरवॉल कॉन्फिगरेशन आणि अनुपालन संदर्भ प्रदान करते जे त्यांना हॉस्पिटॅलिटी, रिटेल आणि सार्वजनिक क्षेत्रातील वातावरणात Guest WiFi सुरक्षित करण्यासाठी आवश्यक आहे. Purple Shield हे ८०,००० पेक्षा जास्त थेट वेन्यूवर DNS स्तरावर मालवेअर, बॉटनेट्स आणि अयोग्य कंटेंट ब्लॉक करते.

मार्गदर्शिका वाचा →

Cisco SUDI समजून घेणे: Secure Network Access Control मधील Hardware-Anchored Identity

हे मार्गदर्शक स्पष्ट करते की Cisco SUDI कशा प्रकारे एंटरप्राइझ नेटवर्क इन्फ्रास्ट्रक्चरसाठी hardware-anchored, गुपित-सुरक्षित (cryptographically secure) ओळख प्रदान करते. तुमच्या वेन्यूच्या नेटवर्क ॲक्सेस कंट्रोल सुरक्षित करण्यासाठी स्पूफ करता येण्याजोग्या MAC ॲड्रेसेस ऐवजी अपरिवर्तनीय 802.1AR सर्टिफिकेट्स वापरण्याची पद्धत जाणून घ्या.

मार्गदर्शिका वाचा →