VPN માં DES વિરુદ્ધ 3DES: બંને કેમ ખોટું અપગ્રેડ છે

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

લોકો હજી જે તુલના શોધે છે તે ખોટી છે

2000 ના દાયકામાં લખાયેલા જવાબો DES ની ત્રિ-ગણા DES સાથે તુલના કરે છે અને તારણ કાઢે છે કે ત્રિ-ગણા DES વધુ મજબૂત છે. તે વખતે વાજબી હતું અને હવે નકામું છે, કારણ કે બંને નવા ટ્રાફિકની સુરક્ષા માટે નિવૃત્ત થયા છે અને તેમની વચ્ચેની પસંદગી બે મૃત માર્ગો વચ્ચેની પસંદગી છે.

NIST એ 2005 માં DES ધોરણ પાછું ખેંચ્યું, અને તેની TDEA ભલામણ જાન્યુઆરી 2024 માં પાછી ખેંચવામાં આવી, નવી ક્રિપ્ટોગ્રાફિક સુરક્ષામાં TDEA લાગુ કરવાની સમયમર્યાદા 2023 ના અંતમાં પૂરી થયા પછી. તે તારીખો સંક્રમણનું વર્ણન કરે છે, ક્રમનું નહીં. ટૂંકું સત્ર કે ઓછા મૂલ્યનો સંદેશ પ્રશ્ન ફરી ખોલતો નથી, કારણ કે અલ્ગોરિધમની સ્થિતિ કી કેટલા સમય સુધી વપરાય છે તેના પર આધારિત નથી.

કી નવીકરણ એ અલગ નિયંત્રણ છે, અને તે મંજૂરી પુનઃસ્થાપિત કરતું નથી.

વાટાઘાટને ડેટા માર્ગથી અલગ કરો

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

IPsec ગેટવે પર સંબંધિત આઉટપુટ સુરક્ષા સંગઠન છે; OpenVPN પર તે કનેક્શન લોગમાં સાઇફર અને TLS સેટિંગ્સ છે. બંને કહે છે કે શું પસંદ થયું. કન્ફિગરેશન ફાઇલમાં હજી રહેલા જૂના વિકલ્પ દ્વારા બંન્નેમાંથી કોઈ સાબિત થતું નથી.

જો તમે વાટાઘાટિત પરિણામ જોઈ શકતા નથી, તો તમે કહી શકતા નથી કે સાઇફર નિવૃત્ત થઈ ગયું છે.

હજી તેની માંગ કરતો ઘટક શોધો

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

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

સમાવેશ પેચ નથી, અને તે જૂના હોસ્ટને વિશ્વાસપાત્ર બનાવતું નથી.

તમારી પાસે પહેલેથી જ હોય તેવી તપાસ સાથે સ્થળાંતર કરો

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

openvpn --version
openssl ciphers -v 'DEFAULT:!DES:!3DES'

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

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

ઐતિહાસિક ડેટા એ અલગ સમસ્યા છે

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

આવા કામને અલગ હોસ્ટ પર રાખો, જેનો હેતુ દસ્તાવેજીકૃત હોય અને કોણ તેને ચલાવી શકે તેની ટૂંકી યાદી હોય.

આ ભેદ મહત્વપૂર્ણ છે કારણ કે નિવૃત્ત સાઇફર ઉપલબ્ધ રાખવાનું આ એકમાત્ર પ્રામાણિક કારણ છે. તે મર્યાદિત સાધનને ન્યાય આપે છે, જાહેર VPN પ્રોફાઇલમાં કાયમી લાઇનને ક્યારેય નહીં.