VPN ની ખાનગી કી પરનો પાસફ્રેઝ ખરેખર શું સુરક્ષિત કરે છે

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

વ્યવહારમાં જવાબ કિનારે ખોટો જાય છે: લોકો માને છે કે પાસફ્રેઝ ચાલતી ટનલને સુરક્ષિત કરે છે, અથવા તેને બદલવાથી પહેલેથી લીક થયેલી કીની નકલ રદ થાય છે. બંને ધારણાઓ નિષ્ફળ જાય છે, અને બંને એવી રીતે નિષ્ફળ જાય છે કે જ્યારે ઓપરેટર માને છે કે વાત સંભાળી લેવાઈ છે ત્યારે ઓળખપત્ર ખુલ્લું રહી જાય છે.

એક સંવાદ, અનેક અલગ રહસ્યો

ખાનગી કીનો પાસફ્રેઝ ફાઇલને ડિક્રિપ્ટ કરે છે. એકાઉન્ટ પાસવર્ડ તમને સેવા સમક્ષ પ્રમાણિત કરે છે. PKCS#12 આયાત પાસવર્ડ એવા બંડલને ડિક્રિપ્ટ કરે છે જેમાં કી અને તેનું પ્રમાણપત્ર હોય છે, અને તે કીના પોતાના પાસફ્રેઝ જેવી જ સ્ટ્રિંગ ન હોઈ શકે. આ પ્રોમ્પ્ટ લગભગ સમાન દેખાઈ શકે છે, અને કયું રહસ્ય ક્યાં જાય તેનું અનુમાન કરવું એ જ રીતે કીઓ ખોટા ક્ષેત્રમાં પેસ્ટ થાય છે.

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

ડિસ્ક પરનું એન્ક્રિપ્શન શું આવરે છે

એન્ક્રિપ્ટેડ PEM કી બે સ્વરૂપમાં આવે છે, અને હેડર કહે છે કે તમારી પાસે કયું છે. આધુનિક PKCS#8 સ્વરૂપ -----BEGIN ENCRYPTED PRIVATE KEY----- થી શરૂ થાય છે; જૂનું PEM સ્વરૂપ, જે જૂની OpenVPN સેટિંગ્સમાં હજી સામાન્ય છે, -----BEGIN RSA PRIVATE KEY----- થી શરૂ થાય છે અને તેની નીચે જ Proc-Type: 4,ENCRYPTED અને DEK-Info લાઇન ધરાવે છે. ફાઇલ ખાનગી કીને તમારા પાસફ્રેઝમાંથી મેળવેલી કી હેઠળ એન્ક્રિપ્ટ કરીને રાખે છે, સામાન્ય રીતે પાસવર્ડ-આધારિત KDF દ્વારા જેમાં નિર્દિષ્ટ પુનરાવર્તન સંખ્યા કે કાર્ય પરિબળ હોય છે. OpenSSL pkey દસ્તાવેજીકરણ ફોર્મેટ અને વાંચતી વખતે લાગુ પડતા પાસફ્રેઝ વિકલ્પો આવરે છે.

તેમાંથી બે પરિણામ આવે છે. નબળો પાસફ્રેઝ KDF જે દર આપે તે દરે ઑફલાઇન હુમલાને પાત્ર છે, તેથી ફાઇલ એન્ક્રિપ્ટેડ હોય ત્યારે પણ ફાઇલ પરવાનગીઓ અને બેકઅપ ઍક્સેસ મહત્વપૂર્ણ રહે છે. અને જે હુમલાવીર પાસફ્રેઝ વિના માત્ર ફાઇલ મેળવે છે તેને અનુમાન કરવું પડે છે; જે ફાઇલ અને પાસફ્રેઝ બંને મેળવે છે તેની પાસે કી હોય છે, જાણે તે ક્યારેય એન્ક્રિપ્ટ થઈ જ ન હોય.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 હેડર બતાવે છે અને જૂની ફાઇલમાં એન્ક્રિપ્શન સાબિત કરતી Proc-Type અને DEK-Info લાઇન બતાવે છે; એકલી એક લાઇન કોઈપણ દિશામાં પુરાવો નથી. pkey લાઇન પાસફ્રેઝ માંગે છે અને માત્ર જાહેર અડધો ભાગ છાપે છે, જે સાબિત કરે છે કે ફાઇલ અને પાસફ્રેઝ કામ કરે છે ખાનગી કી ખુલ્લી કર્યા વિના. તે ચકાસણી માટે -text ન વાપરો: તે ખાનગી ઘટકો, privateExponent, prime1, prime2 અને બાકીનું છાપે છે, અને તે આઉટપુટ ક્યારેય ક્યાંય પેસ્ટ ન કરવું જોઈએ, ટિકિટમાં, ચેટમાં કે લૉગમાં નહીં. PKCS#12 આદેશ એ પણ કહે છે કે બંડલમાં અલગ MAC કે એન્ક્રિપ્શન પાસવર્ડ છે કે નહીં, જે સહકર્મીને આપતા પહેલા જાણવા યોગ્ય છે.

કી લોડ થયા પછી તે શું સુરક્ષિત કરવાનું બંધ કરે છે

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

આ પાસફ્રેઝવાળી SSH કી કે પાસવર્ડ મેનેજરની અનલૉક કરેલી તિજોરી જેવી જ સીમા છે. તે આરામમાં રહેલી ફાઇલ ચોરવાની કિંમત વધારે છે અને તમારા વપરાશકર્તા તરીકે ચાલતા માલવેર, ક્લાયંટને સહી કરવા કહેતી અધિકૃત એપ્લિકેશન, કે મેમરી વાંચી શકતા એડમિનિસ્ટ્રેટર સામે કંઈ કરતું નથી. તેને એક સ્તર તરીકે ગણો, કીને આસપાસ પડી રહેવા સુરક્ષિત બનાવતા નિયંત્રણ તરીકે નહીં.

પ્રોમ્પ્ટ કેમ વારંવાર પાછો આવે છે

દરેક ફરી કનેક્ટ થાય ત્યારે ફરી પૂછતો ક્લાયંટ જરૂરી નથી કે તૂટેલો હોય. કેટલાક ક્લાયંટ સેશન માટે પાસફ્રેઝ કૅશ કરે છે, કેટલાક તેને OS કીહોલ્ડરમાં સંગ્રહે છે, અને કેટલાકને તે પૂરો પાડતા સહાયક તરફ નિર્દેશ કરી શકાય છે, તેથી તમને કઈ વર્તણૂક મળે તે ક્લાયંટ અને તેના રૂપરેખાંકન પર આધાર રાખે છે, કી ફાઇલ પર નહીં.

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

ખોટ અને ખુલાસો એક જ સમારકામ નથી

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

ખુલાસાને અલગ પ્રતિસાદ જોઈએ. એ જ કીને નવા પાસફ્રેઝ સાથે ફરી એન્ક્રિપ્ટ કરવાથી કી સામગ્રી અપરિવર્તિત રહે છે, તેથી બીજે ક્યાંય પહેલેથી અનલૉક થયેલી નકલ હજી કામ કરે છે. સમારકામ ઓળખપત્ર રદ કરવું કે બદલવું છે: નવી કી અને પ્રમાણપત્ર જારી કરો, વહેંચો, અને જૂનીને સહભાગી પર નિવૃત્ત કરો. તે ન થાય ત્યાં સુધી, ફાઇલ પાસવર્ડ બદલવો એ ઘરકામ છે, નિયંત્રણ નહીં. નવી ઓળખ કામ કરે છે તેની ખાતરી થયા પછી જ જૂની ફાઇલને બેકઅપની બહાર રાખો, અને કયો સીરિયલ કે ફિંગરપ્રિન્ટ તેને બદલે તે નોંધો.