OpenConnect લોગિન કૂકીને ટનલમાં કેવી રીતે બદલે છે?

OpenConnect બે અલગ વિનિમયને એક ટૂંકા આયુષ્યના મૂલ્ય સાથે જોડે છે: વેબ લોગિન અને VPN ટનલ. પ્રથમ વિનિમય સામાન્ય HTTPS છે: ઓળખપત્રો, SAML પ્રવાસ અથવા ટોકન ગેટવે પર જાય છે, અને જવાબ પ્રમાણીકરણ કૂકી લાવે છે. બીજો વિનિમય એ જ કૂકીને એ જ ગેટવે સમક્ષ એ પુરાવા તરીકે રજૂ કરે છે કે વેબ તબક્કો પહેલેથી થઈ ગયો છે, અને ત્યાર પછી જ ટનલ ઉપર આવે છે.

લોગિન દરમિયાન ટનલ વિશે કંઈ પણ વાટાઘાટ થતી નથી. એ જ સમજવા જેવો ભાગ છે, કારણ કે મોટાભાગની સ્ક્રિપ્ટ ભૂલો ધારે છે કે કૂકી સંગ્રહ કરવાનો પાસવર્ડ છે, અથવા ટ્રાફિક સુરક્ષિત કરતી ચાવી છે, જ્યારે તે વાસ્તવમાં ચોક્કસ ગેટવે સેશન માટે વાહક ટિકિટ છે.

ક્લાયન્ટ અને ગેટવે ક્રમમાં શું વિનિમય કરે છે

પ્રમાણીકરણ તબક્કો સામાન્ય સુરક્ષિત વેબસાઇટ જેવો દેખાય છે. OpenConnect વપરાશકર્તાના ઓળખપત્રો મોકલે છે, અથવા ગેટવેના રીડાયરેક્ટને ઓળખ પ્રદાતા તરફ અનુસરે છે, અને ગેટવે એવા દસ્તાવેજ સાથે જવાબ આપે છે જેમાં પ્રમાણીકરણ કૂકી જડેલી હોય છે. AnyConnect પ્રોટોકોલમાં એ મૂલ્ય આગલી વિનંતીઓમાં કૂકી હેડરમાં જાય છે, સામાન્ય રીતે webvpn જેવા નામ હેઠળ, અને માર્ગદર્શિકા તેને સેશનને આગળ લઈ જતા ઓળખપત્ર તરીકે ગણે છે.

બીજો તબક્કો એ ગેટવેના VPN અંતિમ બિંદુ પર એ કૂકી જોડેલી CONNECT વિનંતી છે. ગેટવે તેને ચકાસે છે, સરનામું ફાળવે છે, અને ક્લાયન્ટ TLS ઉપર CSTP શરૂ કરે છે, જ્યારે સેશન અસ્તિત્વમાં હોય ત્યારે DTLS વૈકલ્પિક ઝડપી ડેટા માર્ગ છે. ફક્ત આ બિંદુએ જ ટનલ પરિમાણો, રૂટ, DNS સેટિંગ્સ અને સેશનની ટ્રાફિક કી સ્થાપિત થાય છે. કૂકીએ ક્લાયન્ટને દરવાજેથી પસાર કરાવ્યો; તેણે કંઈ એન્ક્રિપ્ટ કર્યું નહીં.

આ ક્રમ સમજાવે છે કે openconnect --authenticate કેમ અસ્તિત્વમાં છે. તેને ચલાવો, અને તે વેબ તબક્કો કરે છે, COOKIE, HOST, CONNECT_URL અને FINGERPRINT જેવા શેલ ચલોનો નાનો બ્લોક છાપે છે, અને પછી કોઈ ટનલ બનતાં પહેલાં બહાર નીકળી જાય છે. પછી રેપર સ્ક્રિપ્ટ એ મૂલ્યો સાથે ખરેખરું જોડાણ શરૂ કરી શકે છે, અને હેડલેસ અથવા બે-કન્ટેનર તૈનાતીને એ જ વિભાજન જોઈએ છે.

કૂકી સેશનનું વાહક છે, ચાવી નહીં

મૂલ્ય સાથે એમ વર્તો જેમ વેબ એપ્લિકેશનમાં સેશન આઈડી સાથે વર્તતા. જેની પાસે તેના આયુષ્ય દરમિયાન તે હોય તે ગેટવે પાસેથી એ ટનલ માંગી શકે છે જેનો એ સેશનને હક છે, તેથી તેની ગુપ્તતા મહત્વપૂર્ણ છે. પણ તેની નકલ કરવાથી ટ્રાફિક જાહેર થતો નથી, કારણ કે ટનલની ગોપનીયતા TLS હેન્ડશેક અને વ્યુત્પન્ન ચાવીઓમાંથી આવે છે, કૂકી શ્રેણીમાંથી નહીં.

તે કાયમી પરવાનગી પણ નથી. ગેટવે અને ઓળખ પ્રદાતા નક્કી કરે છે કે સેશન કેટલું જીવે, અને હજી લોગિન થયેલું પૃષ્ઠ બતાવતું બ્રાઉઝર એ વિશે કંઈ કહેતું નથી કે ટનલ સેશન હજી માન્ય છે કે નહીં. સમાપ્તિ પછી ફરી જોડાવું એટલે વેબ તબક્કો પુનરાવર્તિત કરવો અને નવી કૂકી બનાવવી, અને પુનઃપ્રમાણીકરણનો હેતુ એ જ છે, ઈજનેરી દ્વારા ટાળવાની હેરાનગતિ નહીં.

કૂકીને અન્ય ઓળખપત્રોના સાર્વત્રિક વિકલ્પ તરીકે ન ગણો. SAML દાવો, બ્રાઉઝર પાસવર્ડ અને બીજી સેવાએ આપેલી કૂકી અલગ પ્રેક્ષકો સાથેની અલગ વસ્તુઓ છે, અને એકને બીજાના ક્ષેત્રમાં ચોંટાડવાથી સામાન્ય રીતે ગેટવે પર નિષ્ફળતા મળે છે અથવા વધુ ખરાબ, ખોટી વિશ્વાસ સીમા સામે સફળ થાય છે.

નકલો ન છોડતાં કૂકી પસાર કરવી

Linux પર સૌથી સુરક્ષિત યાંત્રિક હસ્તાંતરણ પ્રમાણભૂત ઇનપુટ છે. --cookie-on-stdin મૂલ્ય stdin માંથી વાંચે છે, તેથી કૂકી ક્યારેય પ્રક્રિયાના આર્ગ્યુમેન્ટ સૂચિમાં દેખાતી નથી, જ્યાં કોઈ પણ સ્થાનિક વપરાશકર્તા તેને ps વડે વાંચી શકે. એક પ્રક્રિયામાં પ્રમાણીકરણ કરીને બીજામાં ટનલને ખવડાવતી પાઇપલાઇન મૂલ્યને ફાઇલ કે પર્યાવરણ ચલમાં નહીં, પાઇપમાં રાખે છે.

આર્ગ્યુમેન્ટ અને પર્યાવરણ ચલ અલગ કારણોસર નબળા છે. આર્ગ્યુમેન્ટ ક્લાયન્ટના આખા આયુષ્ય દરમિયાન પ્રક્રિયા કોષ્ટકમાં દેખાય છે અને ઘણી વાર શેલ ઇતિહાસમાં જતું રહે છે. પર્યાવરણ ચલ સંતાન પ્રક્રિયાઓને વારસામાં મળે છે, અને યુનિટ ફાઇલમાં તેને સેટ કરતું systemd યુનિટ ગુપ્તતાને વાંચી શકાય તેવી ગોઠવણીમાં સંગ્રહે છે. જો ફાઇલ જરૂરી હોય, તો તેને સેવા ખાતા સુધી મર્યાદિત કરો અને સેશન પૂરું થાય ત્યારે દૂર કરો.

વિશેષાધિકાર સીમા પણ જાણી જોઈને રાખો. ઓળખ પ્રદાતા સાથે વાત કરતી અને કદાચ બ્રાઉઝર ખોલતી પ્રક્રિયા એ વપરાશકર્તા તરીકે ચાલવી જોઈએ જેનું એ લોગિન છે. રૂટ, DNS અને ટનલ ઉપકરણ ગોઠવતી પ્રક્રિયાને વધુ વિશેષાધિકારની જરૂર પડી શકે. root ની માલિકીની ટનલ માટે કૂકી ઉપલબ્ધ કરાવવા આખું બ્રાઉઝર root તરીકે ચલાવવું ખોટી આપલે છે, અને આધુનિક OpenConnect ગોઠવણો એ સીમા પાર મૂલ્ય સ્પષ્ટપણે આપી શકે છે.

લોગિંગ પણ એ જ શંકાને પાત્ર છે. વિગતવાર ક્લાયન્ટ આઉટપુટ, સહાયક સ્ક્રિપ્ટો અને ગેટવે નિદાન બધા વિનંતીની સામગ્રી પુનરાવર્તિત કરી શકે છે, અને દરેક લોગ સ્તર કૂકી છુપાવતું નથી. તમને જરૂરી સૌથી નાનું ભૂલ રેકોર્ડ પકડો, તેને વહેંચાયેલા ચેનલોથી બહાર રાખો, અને ટિકિટ સાથે જોડતા પહેલાં છુપાવેલું નમૂનું તપાસો.

બીજા તબક્કામાં ચકાસણી અને સમાપ્તિ

બીજા તબક્કામાં હજી સર્વરની ચકાસણી કરવી પડે છે. --authenticate જે FINGERPRINT છાપે છે તે pin-sha256: સ્વરૂપમાં પ્રમાણપત્ર પિન છે, અને તેને --servercert સાથે ટનલ કૉલને આપવાથી ચકાસણી તે ગેટવે પર લંગરાયેલી રહે છે જેની સામે તમે પ્રમાણીકરણ કર્યું. સ્ક્રિપ્ટ સરળ બનાવવા પ્રમાણપત્ર ચકાસણી બંધ કરવાથી એકમાત્ર પુરાવો દૂર થાય છે કે કૂકી ઇચ્છિત યજમાનને આપવામાં આવે છે.

જ્યારે ગેટવે કૂકી નકારે, ત્યારે ઉકેલ નવો પ્રમાણીકરણ રાઉન્ડ છે, લાંબું કેશ નહીં. કૂકી ફક્ત જોડાણના આયુષ્ય સુધી સંગ્રહો, બહાર નીકળતી વખતે કામચલાઉ ફાઇલો દૂર કરો, અને સેશન જાહેર થાય કે ઉપકરણ ખોવાય ત્યારે ઓળખ પ્રદાતા કે ગેટવેની સેશન દૂર કરવાની પ્રક્રિયા વાપરો. કેશ કરેલી કૂકી MFA માંથી મુક્તિ નથી.

આને સ્વયંક્રિય કરતાં પહેલાં ચાર વસ્તુ ચકાસો: ટનલ યોગ્ય ખાતા હેઠળ ચાલે છે, કૂકી stdin દ્વારા આવે છે, પ્રમાણપત્રની આંગળીની છાપ પિન થયેલી છે, અને ટનલ બંધ થાય ત્યારે સેશન કાઢી નાખવામાં આવે છે. જો એમાંથી કંઈ પણ ખૂટે, તો સ્વયંક્રિયકરણે જાતેનો પ્રવાહ પુનઃઉત્પાદિત કરવાને બદલે કૂકીમાંનો વિશ્વાસ વધાર્યો છે.