tls-auth vs tls-crypt: OpenVPN માં દરેક શું સુરક્ષિત કરે છે

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

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

સહિયારી કી ખરેખર શું રક્ષે છે

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

tls-auth એ રહસ્યનો ઉપયોગ નિયંત્રણ પેકેટો પર HMAC ગણવા માટે કરે છે. માન્ય હસ્તાક્ષર વગરનું પેકેટ વધુ ખર્ચાળ TLS પ્રોસેસિંગ સુધી પહોંચતાં પહેલાં કાઢી નાખવામાં આવે છે, તેથી આ વિકલ્પને ઘણી વાર TLS નો વિકલ્પ નહીં, પરંતુ પ્રથમ ફિલ્ટર કહેવામાં આવે છે.

tls-crypt આગળ વધે છે અને સુરક્ષિત નિયંત્રણ ટ્રાફિકને પ્રમાણિત કરવા ઉપરાંત એન્ક્રિપ્ટ પણ કરે છે. પ્રમાણપત્રોની સામગ્રી, વાટાઘાટ કરેલા સાઇફર નામો અને હેન્ડશેકની અન્ય વિગતો હવે નેટવર્ક પર દેખાતી નથી, અને કી વગરનો નિરીક્ષક કઈ TLS આવૃત્તિ પ્રયત્ન થઈ રહી છે તે પણ જોઈ શકતો નથી. પોતાની VPN આંગળીની છાપ ઉઘાડી પડવાની ચિંતા કરતી તૈનાતી માટે આ ગુણધર્મ જ તેને પસંદ કરવાનું મુખ્ય કારણ છે. તે હજી પણ સમૂહ રહસ્ય છે, વપરાશકર્તા દીઠ ઓળખપત્ર નહીં.

કોઈ પણ પદ્ધતિ ઓળખ આપતી નથી. સહિયારી કી સમૂહ રહસ્ય છે, અને જેની પાસે તે છે તે ચકાસણીનું એ સ્તર પાર કરી શકે છે.

બંને વિકલ્પો ક્યાં અલગ પડે છે

દેખાતો ભેદ એ છે કે નિરીક્ષક શું જુએ છે. tls-auth સાથે હેન્ડશેક દેખાય છે પણ કી વગર ચકાસી શકાતું નથી. tls-crypt સાથે હેન્ડશેક એવા કોઈને માટે અસ્પષ્ટ છે જેની પાસે કી નથી.

રૂપરેખાંકન પણ અલગ છે. tls-auth દિશા મૂલ્ય સાથે વપરાય છે, તેથી એક બાજુ કી સામગ્રીનો એક અડધો ભાગ વાપરે છે અને બીજી બાજુ બીજો અડધો. tls-crypt બંને દિશામાં એક જ કી વાપરે છે, તેથી દિશા સૂચના તેની ગોઠવણીનો ભાગ નથી.

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

નવીન પ્રકાર, tls-crypt-v2, દરેક ક્લાયન્ટને તેની પોતાની લપેટેલી કી સાથે જોડે છે જેથી એક ક્લાયન્ટ રદ કરવા સમૂહ કી ફરી બહાર પાડવી ન પડે. તે જાણવા જેવું છે, પણ તે અલગ વિકલ્પ છે અને અહીંના બંનેમાંથી કોઈનો પર્યાય નથી.

અસંગતિ કેમ એવું લાગે કે કંઈ થતું નથી

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

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

સર્વર લોગમાં છેલ્લી ફરી-પ્રયાસ લાઇનને બદલે પેકેટ-સ્તરની પ્રથમ ફરિયાદ વાંચો. ખાતરી કરો કે બંને બાજુઓ સમાન કી સામગ્રી સાથે એક જ વિકલ્પ ધરાવે છે અને કી ફાઇલ ફક્ત એક જ બાજુ પર ફરી બનાવાઈ નથી.

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

હજી શું અલગથી ગોઠવવું પડે

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

તેઓ ડેટા સાઇફર પણ પસંદ કરતા નથી. તે અલગ વાટાઘાટ છે જે બંને છેડાના ડેટા-ચેનલ સેટિંગ્સ નિયંત્રિત કરે છે, અને tls-crypt થી સુરક્ષિત ટનલ પણ એવું સાઇફર વાપરી શકે છે જે તમે ઇચ્છ્યું ન હતું.

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