OpenVPN tls-crypt-v2: ક્લાયન્ટ કી અને રેપ્ડ બ્લોબ શું કરે છે
tls-crypt-v2 પ્રોફાઇલમાં ક્લાયન્ટ કંટ્રોલ કી અને એક લપેટેલી નકલ હોય છે જે ફક્ત સર્વર જ ખોલી શકે. દરેક ઑબ્જેક્ટ અને દરેક નિવૃત્તિ પગલું અલગ રાખો.
tls-crypt-v2 પ્રોફાઇલને ટિકિટમાં પેસ્ટ કરવું હાનિકારક લાગતું નથી, ત્યાં સુધી તમે ગણતા નથી કે ફાઇલમાં શું છે. ક્લાયન્ટની કંટ્રોલ-ચેનલ કી એ જ કીની એન્ક્રિપ્ટેડ નકલની બાજુમાં બેસે છે, અને ત્રીજું ઑબ્જેક્ટ, રેપિંગ કી, સ્વીકારનાર સર્વરને ક્યારેય છોડતું નથી. એ ત્રણેય કસ્ટડી, શેરિંગ અને નિવૃત્તિ વિશે જુદા જુદા પ્રશ્નોના જવાબ આપે છે. તેમને અલગ પાડવાથી મોટાભાગની નીતિ ચર્ચાઓ શરૂ થતાં પહેલાં જ નિકાલ થાય છે.
પ્રોફાઇલમાં ખરેખર શું છે
tls-crypt-v2નો ક્લાયન્ટ ભાગ એક કી અને તેની લપેટેલી નકલ છે. ક્લાયન્ટ કંટ્રોલ-ચેનલ સંરક્ષણ માટે સાદી કી વાપરે છે અને સેટઅપ દરમિયાન લપેટેલી નકલ સર્વરને આપે છે, જેથી સર્વર દરેક ક્લાયન્ટ માટે પ્લેઇનટેક્સ્ટ નકલ સંગ્રહ્યા વિના એ જ કી પાછી મેળવે છે. રેપિંગ કી એ પુનઃપ્રાપ્તિ શક્ય બનાવે છે અને ફક્ત સ્વીકારનાર બાજુ પર જ હોવી જોઈએ. નીચેનું બધું એ ત્રણ ઑબ્જેક્ટ ક્યાં રહે છે તેના પરથી આવે છે.
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
કોષ્ટકને નામ પ્રમાણે નહીં, કસ્ટડી પ્રમાણે વાંચો અને પરિણામો જાતે જ સ્પષ્ટ થઈ જાય છે. રેપિંગ કી ગુમાવવી એ ખર્ચાળ ઘટના છે, કારણ કે પ્રોફાઇલમાં કંઈ પણ તેને પુનઃરચી શકતું નથી અને પ્રામાણિક પુનઃપ્રાપ્તિ એ ગ્રુપને ફરી જારી કરવી છે. લીક થયેલી પ્રોફાઇલ સસ્તી છે પણ વધુ સામાન્ય છે, કારણ કે લોકો ટિકિટમાં પ્રોફાઇલ પેસ્ટ કરે છે એવું માનીને કે લપેટેલી નકલ ફાઇલને શેર કરવા સુરક્ષિત બનાવે છે. બંને નિષ્ફળતાઓને જુદા જવાબો જોઈએ, અને તેથી જ ઑબ્જેક્ટ અલગ રાખવામાં આવે છે.
લપેટેલી નકલ આખી વાર્તા કેમ નથી
પ્રોફાઇલ વાપરી શકાય તેવી ક્લાયન્ટ સામગ્રી સાથે તેની લપેટેલી જોડી વહન કરે છે, તેથી સર્વર માટે નકલ સુરક્ષિત કરવી એ ફાઇલ સુરક્ષિત કરવા વિશે કંઈ કહેતું નથી. બ્લોબ મોકલવા માટે સુરક્ષિત છે અને પ્રકાશિત કરવા માટે અસુરક્ષિત. તેની અંદરના મેટાડેટા જેને બ્લોબ મળે તેને દેખાય છે, જેમાં પછી તે ટિકિટ વાંચનાર કોઈ પણ સામેલ છે જેમાં તે પેસ્ટ કરવામાં આવ્યું હતું.
પ્રોફાઇલને કન્ફિગરેશન નમૂના તરીકે નહીં, ક્રેડેન્શિયલ તરીકે ગણો. લીક થયેલી ફાઇલ તેના ધારકને કાર્યરત ક્લાયન્ટ ઓળખ આપે છે ત્યાં સુધી કે સર્વર એ ઓળખ સ્વીકારવાનું બંધ કરે, અને રેપિંગ એ વિન્ડો વિશે કંઈ કરતું નથી. દરેક ક્લાયન્ટ માટે એક પ્રોફાઇલ જારી કરો જેથી પાછળ ખેંચવું એક-ફાઇલનો નિર્ણય રહે, અને રેપિંગ કીનો બેકઅપ તે જે સર્વર કન્ફિગરેશન સક્ષમ કરે તેનાથી અલગ રાખો. બંનેમાંથી કોઈ આદત છેડાયેલી પ્રોફાઇલ સુધારતી નથી, પણ બંને નક્કી કરે છે કે આગલી કેટલી ઝડપથી કાબૂમાં આવશે.
હેન્ડશેકમાં વેરિફાય હૂક ક્યાં બેસે છે
વેરિફાય હૂક TLS સ્ટેક ખુલ્લો થાય તે પહેલાં ચાલે છે, અને તેનું કામ લપેટેલા બ્લોબમાં રહેલા મેટાડેટાની તપાસ કરવાનું છે. તેને એ મેટાડેટા વત્તા નાનું, દસ્તાવેજીકૃત વાતાવરણ મળે છે, અને ઓથેન્ટિકેશન હૂક કરતાં તેની પાસે ઓછું કામ કરવાનું હોય છે. તે વપરાશકર્તાનામ, સેશન સ્થિતિ કે પ્લગઇન ચલ જોઈ શકે એવું માનવું એ આ હૂક ખરાબ લખાવાનો સામાન્ય રસ્તો છે. બીજા હૂકની અપેક્ષાઓ ઉધાર લેવાને બદલે હૂકના પોતાના મેન્યુઅલ વિભાગ વાંચો.
તેની એક્ઝિટ સ્થિતિ એ નિર્ણય છે: બિન-શૂન્ય પરિણામ ક્લાયન્ટને નકારે છે અને શૂન્ય પરિણામ હેન્ડશેક ચાલુ રહેવા દે છે. તેથી નીતિએ કહેવું પડે કે મેટાડેટા ખૂટે, પાર્સ ન થાય કે અણધાર્યું હોય ત્યારે શું થાય. પ્રથમ નકાર માર્ગ લખો, પછી નક્કી કરો કે કઈ કિંમતો સ્વીકાર્ય છે.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shએ બે લીટીઓ સર્વર પરની નીતિની સપાટી છે: એક રેપિંગ કીનું નામ આપે છે, બીજી દરેક ક્લાયન્ટનો નિર્ણય કરતા પ્રોગ્રામનું. રસપ્રદ બધું સ્ક્રિપ્ટમાં જ છે, જે વર્ઝન કંટ્રોલ અને અન્ય કોઈ પણ ઍક્સેસ નિયમ જેવી સમીક્ષાને લાયક છે.
એકાઉન્ટ, સર્ટિફિકેટ અને કંટ્રોલ કી અલગ નિવૃત્ત થાય છે
કંટ્રોલ-ચેનલની વહેલી સ્વીકૃતિ ઓથેન્ટિકેશન નથી, કારણ કે તે TLS ઓળખ તપાસ પહેલાં અને કોઈ પણ એકાઉન્ટ ઓથોરાઇઝેશન પહેલાં થાય છે. એકાઉન્ટ નિષ્ક્રિય કરવું, સર્ટિફિકેટ રદ કરવું અને ક્લાયન્ટ કંટ્રોલ કી નકારવી એ ત્રણ મિકેનિઝમ સાથેની ત્રણ ક્રિયાઓ છે. જે ડિપ્લોયમેન્ટ તેમાંથી ફક્ત એક કરે છે તેની પાસે નીતિને બદલે અંતરાલ છે. ત્રણેયનો જાણી જોઈને મેળ કરો, અને નોંધો કે કયું પગલું કઈ સત્તા વાપરે છે.
સમય એ બીજો ભેદ છે. બદલાયેલી સ્વીકૃતિ યાદી નવા હેન્ડશેક પર લાગુ પડે છે, જ્યારે પહેલેથી સ્થાપિત સેશન કંઈક તેમને સમાપ્ત કરે ત્યાં સુધી ચાલુ રહે છે. નવી યાદીમાંની નોંધોને જૂના સેશન પૂરા થયાના પુરાવા તરીકે ગણવું એ જ રીતે દૂર કરેલો ક્લાયન્ટ કલાકો સુધી જોડાયેલો રહે છે.
અસંગત સત્તાઓ બે છિદ્રો છોડે છે જે વ્યવહારમાં સરળતાથી મળી આવે છે. એકાઉન્ટ નિષ્ક્રિય હોઈ શકે જ્યારે તેની કંટ્રોલ કી હજી હેન્ડશેક ખોલે, અને સર્ટિફિકેટ રદ થયેલું હોઈ શકે જ્યારે મેટાડેટા નીતિ હજી એ જ ક્લાયન્ટને સ્વીકારે. બંને જુદી જગ્યાએ એક જ ભૂલ છે, કારણ કે ઓપરેટરે એક યાદીને આખી સત્તા ગણી. દૂર કરવાના સમયે ત્રણેય યાદીઓ બાજુમાં મૂકો અને ભૂલ દેખાવા લાગે છે.
પ્રોફાઇલ જારી કરવી અને પાછળ ખેંચવી
જારી કરવું સરળ અડધું છે: સ્વીકારનાર બાજુ પર ક્લાયન્ટ કી બનાવો, પ્રોફાઇલ બરાબર એક માલિકને આપો, રેપિંગ સામગ્રી પ્રતિબંધિત રાખો, અને દરેક સ્વીકારનાર સર્વર પર એ જ વેરિફાય પ્રોગ્રામ ચલાવો. સસ્તું પ્રવેશ એ આખા ગ્રુપની ગુણવત્તા છે, નવા હોસ્ટની નહીં. જૂની કે ઢીલી સ્ક્રિપ્ટવાળું બીજું સર્વર ચૂપચાપ ડિપ્લોયમેન્ટનો સૌથી નબળો રસ્તો બની જાય છે.
પાછળ ખેંચવા માટે ત્રણ પગલાં જાણી જોઈને ક્રમમાં જોઈએ. વેરિફાય હૂકમાં ક્લાયન્ટને નકારો જેથી નવા હેન્ડશેક નિષ્ફળ જાય, જો PKI વપરાય છે તો તેનું સર્ટિફિકેટ રદ કરો, અને એકાઉન્ટ નિષ્ક્રિય કરો જેથી પછીના ઓથોરાઇઝેશન પાસે ઓથોરાઇઝ કરવા કંઈ ન રહે. પછી જૂની સ્વીકૃતિએ મંજૂર કરેલા સેશન સમાપ્ત કરો, કારણ કે તે ત્રણમાંથી કંઈ પણ નોંધશે નહીં. તમે તોડી શકો એવા ક્લાયન્ટ પર ક્રમનો અભ્યાસ કરો.
પ્રોફાઇલમાંનો મેટાડેટા એ નીતિ માટે ઇનપુટ છે, ઍક્સેસ કંટ્રોલ પહેલેથી છે તેનો પુરાવો નહીં. OpenVPN 2.6 ડિઝાઇન દસ્તાવેજ ઑબ્જેક્ટ અને તેમની વચ્ચેની સીમાનું વર્ણન કરે છે, જ્યારે તેમને લાગુ કરવાનું ઓપરેટર પાસે જ રહે છે.