કયા OpenVPN પેકેટને auth ડાયજેસ્ટ સુરક્ષિત કરે છે?
auth વિકલ્પ પ્રોફાઇલ સૂચવે તેના કરતાં ઓછું આવરી લે છે. ડાયજેસ્ટ નીતિ નક્કી કરતાં પહેલાં ચેનલ, AEAD કેસ અને કંટ્રોલ-ચેનલ સુરક્ષા તપાસો.
OpenVPN ડાયજેસ્ટ વિશેની મોટાભાગની ચર્ચા ખોટા પેકેટથી શરૂ થાય છે. auth SHA256 ને “ફક્ત એવા પીઅર સ્વીકારો જે SHA256 ઑફર કરે” તરીકે વાંચવું એ પહેલી વસ્તુ છે જે ભૂલવી પડે. વિકલ્પ ચોક્કસ પેકેટ માટે ડાયજેસ્ટનું નામ આપે છે, અને તે પેકેટ કયા છે તે ચેનલ પર અને તે ચેનલ AEAD છે કે નહીં તેના પર આધાર રાખે છે. નીચેના ચાર પ્રશ્નો ક્રમમાં લો; દરેક એ સંકોચે છે કે તમારી જમાવટમાં સેટિંગનો અર્થ શું હોઈ શકે.
સેટિંગ જે ચેનલને સુરક્ષિત કરવાનું છે તેનું નામ આપો
OpenVPN પાસે એક કંટ્રોલ ચેનલ છે જે TLS હેન્ડશેક ટ્રાફિક વહન કરે છે અને એક ડેટા ચેનલ છે જે ટનલનો પેલોડ વહન કરે છે. auth ડાયજેસ્ટ બંનેમાં ભૂમિકા ભજવે છે, પણ સમાન ભૂમિકા નહીં, અને પ્રોફાઇલ ભેદ ભાગ્યે જ દૃશ્યમાન બનાવે છે. કન્ફિગ ફાઇલને સ્પર્શ કરતાં પહેલાં લખો કે તમે બેમાંથી કોને મર્યાદિત કરવા માગો છો.
નીચેનું કોષ્ટક એ જ વિકલ્પ દરેક સંદર્ભમાં કેવી રીતે આવે છે તેનું ટૂંકું સ્વરૂપ છે.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
તેના પર આધાર રાખતાં પહેલાં તપાસો કે ડેટા ચેનલ AEAD છે કે નહીં
જો વાટાઘાટ કરેલ ડેટા સાઇફર AES-GCM અથવા CHACHA20-POLY1305 હોય, તો ડેટા ચેનલ પોતાને પ્રમાણિત કરે છે અને અલગ ડાયજેસ્ટ એ કામ કરતું નથી જે તમે કલ્પના કરી હોય. બંને AEAD રચનાઓ છે, તેથી અખંડિતતા એ જ ક્રિયાથી ઉત્પન્ન થાય છે જે પેલોડને એન્ક્રિપ્ટ કરે છે. આ કોઈ અધોગતિ નથી, પણ તેનો અર્થ એ છે કે “દરેક ડેટા પેકેટ HMAC-SHA256 છે” તરીકે ન્યાયી ઠરાવાયેલી નીતિ તે ટનલ પર તથ્યાત્મક રીતે ખોટી છે. નીતિ ફરી લખતાં પહેલાં સર્વર લોગ અથવા ક્લાયન્ટ સ્થિતિ આઉટપુટમાં વાટાઘાટ કરેલ મૂલ્યની પુષ્ટિ કરો.
પ્રોફાઇલની સૂચિને બદલે ખરેખર વાટાઘાટ કરેલ સાઇફરની તપાસ કરો, કારણ કે વાટાઘાટ સમૂહના બીજા સભ્ય પર આવી શકે છે. data-ciphers AES-256-GCM:AES-128-GCM એ વાટાઘાટ સૂચિ છે, અને બંને એન્ટ્રી AEAD છે, તેથી તેમાંથી કોઈ પેલોડ સુરક્ષા માટે auth ડાયજેસ્ટ વાપરતું નથી.
કંટ્રોલ-ચેનલ સુરક્ષાને સ્વતંત્ર નિર્ણય તરીકે લો
tls-auth કંટ્રોલ-ચેનલ પેકેટમાં HMAC ઉમેરે છે અને તેનો ડાયજેસ્ટ auth સેટિંગમાંથી લે છે, તેથી AEAD ટનલમાં પણ અર્થપૂર્ણ ડાયજેસ્ટ ગોઠવેલો હોઈ શકે. tls-crypt પોતાની નિશ્ચિત સુરક્ષા સાથેની અલગ ગોઠવણ છે, તેથી એવું ન માનો કે તે tls-authની દરેક લક્ષણ વારસામાં લે છે. ધારણાઓ એકબીજા વચ્ચે ખસેડવાને બદલે તમે પસંદ કરેલ મેકેનિઝમનું દસ્તાવેજીકરણ વાંચો.
બંને પીઅરને ગોઠવણ અને કીની દિશા પર પણ સહમત થવું પડે. મેળ ખાતો ડાયજેસ્ટ પણ ખોટી દિશામાં વપરાયેલ કી ફાઇલ એવું હેન્ડશેક બનાવે છે જે ડાયજેસ્ટ સેટિંગ સમજાવી ન શકે તેવા કારણોસર નિષ્ફળ જાય છે.
auth ને સાઇફર વાટાઘાટ અને પ્રમાણપત્રોથી અલગ રાખો
ત્રણ સેટિંગ વારંવાર ભેગા થઈ જાય છે: auth ડાયજેસ્ટ, ડેટા-સાઇફર સૂચિ અને પ્રમાણપત્રનું સહી અલ્ગોરિધમ. પહેલું બદલવાથી પ્રમાણપત્ર ફરી જારી થતું નથી, તેનો સાઇનિંગ ડાયજેસ્ટ પસંદ થતો નથી, અને વપરાશકર્તા-પાસવર્ડ પદ્ધતિ બનતી નથી. પ્રોટોકોલ વિકલ્પની વ્યાખ્યાઓ OpenVPN 2.6 સ્રોતોમાં દરેકને તેના પોતાના વિભાગમાં વર્ણવે છે, જે એ ઉપયોગી સ્મરણ છે કે તે સ્વતંત્ર નોબ છે.
ડાયજેસ્ટ ફેરફાર પછી પીઅર જોડાવાની ના પાડે તો કારણ સામાન્ય રીતે બીજા બે સેટિંગમાંથી એકમાં અસંગતિ હોય છે. કોઈપણ બદલતાં પહેલાં બંને છેડા વાંચો.
નીતિ લખો અને ચાલુ કન્ફિગ સાથે તેની સરખામણી કરો
ફ્લીટ-સ્તરીય નિવેદનમાં માન્ય ડેટા-ચેનલ મોડ અને પસંદ કરેલ કંટ્રોલ-ચેનલ સુરક્ષાનો સ્પષ્ટ ઉલ્લેખ એક જ વાક્યમાં થવો જોઈએ. તે વાક્ય ચકાસી શકાય તેવું છે; “અમે SHA256 વાપરીએ છીએ” નથી. પછી તેની સરખામણી અસરકારક સર્વર અને ક્લાયન્ટ પ્રોફાઇલ સાથે કરો, રિપોઝિટરીના ટેમ્પલેટ સાથે નહીં.
દરેક ટનલે ખરેખર શું વાટાઘાટ કર્યું અને કઈ મેકેનિઝમે તેના પેકેટ પ્રમાણિત કર્યા તે નોંધીને પૂર્ણ કરો. પ્રોફાઇલમાં દેખાતી auth લાઇન ફક્ત કન્ફિગરેશનના ઇરાદાનો પુરાવો છે, અને ઇરાદો તપાસનો સૌથી સસ્તો ભાગ છે.