AES-256 કેમ VPN એન્ક્રિપ્શન સ્યૂનું વર્ણન કરતું નથી
એક સ્યૂ ચાર ભૂમિકાઓ ભરે છે: બલ્ક એન્ક્રિપ્શન, અખંડિતતા, કી સ્થાપના અને પીઅર પ્રમાણીકરણ. સાઇફરનું નામ તેમાંથી એક જ, એક સ્તર પર આવરી લે છે.
VPN કયું એન્ક્રિપ્શન વાપરે છે તે પૂછો અને જવાબ સામાન્ય રીતે એક શબ્દમાં આવે છે: AES-256, અથવા ChaCha20, અથવા કદાચ WireGuard. એ જવાબ એક સ્તરના એક ઘટકનું નામ આપે છે, જ્યારે કનેક્શનને ખરેખર સુરક્ષિત કરતી વસ્તુ ચાર અલગ ભૂમિકાઓ ભરતા અલ્ગોરિધમનો સમૂહ છે. ઘટકને ગોઠવણી સાથે ગૂંચવવી એ આ વાતચીતોમાં સૌથી સામાન્ય ભૂલ છે અને એવી સરખામણીઓ ઊભી કરે છે જે ઉકેલી શકાતી નથી.
એક કનેક્શનમાં ચાર કામ
બલ્ક એન્ક્રિપ્શન ડેટા ચેનલ માટે સ્પષ્ટ લખાણને સાઇફર લખાણમાં ફેરવે છે અને તેની કી પ્રસારિત થવાને બદલે ઉત્પન્ન થાય છે. અખંડિતતા સંરક્ષણ ફેરફાર શોધે છે, જે અલગ કામ છે તેમ છતાં એક જ રચના બંને કરે. કી સ્થાપના સહિયારી ટ્રાફિક સામગ્રી બનાવે છે અને પીઅર પ્રમાણીકરણ નક્કી કરે છે કે બીજા છેડે કોણ છે. તેમાંથી એક પણ ન હોય તો કનેક્શન સુરક્ષિત નથી, બાકીનો ભાગ ગમે તેટલો મજબૂત હોય.
કેટલીક રચનાઓ બે ભૂમિકાઓને એકમાં ભેગી કરે છે. AES-GCM અને ChaCha20-Poly1305 પ્રમાણિત એન્ક્રિપ્શન રચનાઓ છે, તેથી ગોપનીયતા અને અખંડિતતા સાથે આવે છે; AES-CBC નથી, અને તેને પોતાની કી સાથે અલગ સંદેશ પ્રમાણીકરણ કોડની જરૂર છે. તેથી પ્રસ્તાવને સ્વતંત્ર સંખ્યાઓની થેલી તરીકે વાંચવો જોડી તરીકે રચાયેલા લોકોને ખોટી રીતે વાંચે છે.
ભૂમિકાઓ અલગ સ્તરો પર પણ હોય છે, તેથી એક જ શબ્દ બે ઉત્પાદનોમાં અલગ અર્થ કરી શકે છે. ESP ની અંદરનું બ્લોક સાઇફર અને TLS ની અંદરનું બ્લોક સાઇફર અલગ વાટાઘાટોમાં એક જ પ્રાથમિક વસ્તુ છે. તેથી મોડ અને સ્તર વિના પ્રાથમિક વસ્તુ ટાંકવી કંઈ ન ટાંકવા કરતાં ખરાબ હોઈ શકે.
સાઇફરનું નામ કેમ લગભગ કંઈ કહેતું નથી
AES-256 વાક્યને એક ક્ષણ માટે ગંભીરતાથી લો: તે બ્લોક સાઇફર અને કીનું કદ ઓળખે છે. તે ઓપરેટિંગ મોડ વિશે, અખંડિતતા આપવામાં આવે છે કે નહીં, કી કેવી રીતે સ્થાપિત થઈ અથવા પીઅરનું પ્રમાણીકરણ કેવી રીતે થયું તે વિશે કંઈ કહેતું નથી. બે ઉત્પાદનો બંને AES-256 ની જાહેરાત કરી શકે છે અને બાકીની દરેક બાબતમાં અલગ હોઈ શકે છે, જેમાં એક અપ્રમાણિત મોડ સાથે અને બીજું આધુનિક કી વિનિમય સાથે AEAD મોડ વાપરે છે.
TLS 1.3 એ આ વિભાજનને ધોરણમાં લાવ્યું, જે જૂની શબ્દાવલી શીખનાર દરેક માટે ઉપયોગી સુધારો છે. તેના સાઇફર સ્યૂ ફક્ત AEAD અને હેશનું નામ લે છે, જ્યારે કી વિનિમય જૂથો અને સહી અલ્ગોરિધમ અલગ પરિમાણ તરીકે વાટાઘાટ થાય છે. તેથી TLS 1.3 સ્યૂનું નામ TLS 1.2 સ્યૂના નામ સાથે સમાન ધોરણે સરખાવી શકાતું નથી, જોકે બંને કન્ફિગરેશન ફાઇલના એક જ ક્ષેત્રમાં દેખાય છે. જે બે શબ્દમાળાઓની સીધી સરખામણી કરે છે તે પ્રોટોકોલ સમર્થન ન આપતું નિષ્કર્ષ કાઢે છે. વાટાઘાટ થયેલ જૂથ અને સહી પરિમાણો પણ વાંચો, નહીં તો સરખામણી અધૂરી છે.
WireGuard વિરુદ્ધ માર્ગ પસંદ કરે છે અને વાટાઘાટને લગભગ સંપૂર્ણ દૂર કરે છે: પ્રોટોકોલ નિશ્ચિત અલ્ગોરિધમ સમૂહ નક્કી કરે છે, તેથી બે અમલીકરણો સાથે કામ કરે છે અથવા નહીં. આ કાયદેસર ડિઝાઇન પસંદગી છે, અને તેનો અર્થ એ પણ છે કે WireGuard કયા સ્યૂની વાટાઘાટ કરે છે તે પ્રશ્નનો સરખામણી લાયક જવાબ નથી. જો તમે તેનું ઓડિટ કરો છો, સ્પેસિફિકેશન એક વાર વાંચો અને પછી વાટાઘાટની જગ્યાએ તેની આસપાસની કી સંભાળનું ઓડિટ કરો.
સ્તર શબ્દાવલી નક્કી કરે છે
IPsec નું જમાવટ બે વાર વાટાઘાટ કરે છે: નિયંત્રણ ચેનલ માટે IKE પ્રસ્તાવ અને ડેટા માટે ESP રૂપાંતરણ, અને બંને કાયદેસર રીતે અલગ હોઈ શકે છે. પ્રથમ વાંચીને ધારવું કે તે બીજાનું વર્ણન કરે છે તે ઓડિટ દરમિયાન ગૂંચવણનો સામાન્ય સ્રોત છે, કારણ કે કન્ફિગરેશન ફાઇલ બંનેનો ઉલ્લેખ કરે છે અને રસપ્રદ એ બીજું છે.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
એક લાઇબ્રેરીમાં ઉપલબ્ધ નામ બીજા ડેટા માર્ગ માટે આપમેળે અમલમાં મૂકાયેલું હોતું નથી. તેથી અમારું ઉત્પાદન AES-256 ને સપોર્ટ કરે છે એ વિધાન સાંભળવામાં આવે તેનાથી નબળું છે, અને તેથી આંતરક્રિયાત્મકતાની સમસ્યા સામાન્ય રીતે બંને બાજુએ દરેક જૂના અલ્ગોરિધમને સક્ષમ કરવાને બદલે જાળવાયેલા છેદને શોધીને ઉકેલાય છે.
TLS 1.3 સ્પેસિફિકેશન આ વિભાજનનું સૌથી સ્પષ્ટ પ્રકાશિત ઉદાહરણ છે, કારણ કે તે સ્યૂને જોડી તરીકે વ્યાખ્યાયિત કરે છે અને બાકીનું તેની પોતાની વાટાઘાટમાં ખસેડે છે. એ આકાર પરિચિત થાય પછી IPsec પ્રસ્તાવ અને એકમાત્ર નિશ્ચિત WireGuard સમૂહ એક જ વિચારની વિવિધતા તરીકે વંચાય છે.
વાટાઘાટ થયેલ પરિણામ વાંચો, પછી થોભો
કન્ફિગર કરેલ પ્રસ્તાવ બે પીઅરે શું પસંદ કર્યું તેનો પુરાવો નથી. જીવંત સત્ર જવાબ ધરાવે છે, અને દરેક મુખ્ય અમલીકરણ પેકેટ કેપ્ચર વિના તેની જાણ કરી શકે છે.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show
આઉટપુટમાં આપેલી સૂચિને બદલે પસંદ કરેલા અલ્ગોરિધમ વાંચો. જવાબ નીતિ ઇચ્છતી હતી તેના કરતાં નબળો હોય તો સુધારો એક અથવા બીજી બાજુના પ્રસ્તાવ કન્ફિગરેશનમાં આવે છે, અને આધુનિક અમલીકરણોમાં અસંગતિ સામાન્ય રીતે શાંત ડાઉનગ્રેડ તરીકે નહીં પણ નિષ્ફળ વાટાઘાટ તરીકે દેખાય છે.
પછી યાદ રાખો કે સ્યૂ શું આવરી લેતું નથી. રૂટ, એપ્લિકેશન પરવાનગીઓ, લોગિંગ અને જાળવણી પોતાની સમીક્ષા સાથેના અલગ નિર્ણયો છે, અને સુસંગત ક્રિપ્ટોગ્રાફિક ગોઠવણી તેમના વિશે કંઈ કહેતી નથી. સાઇફરની ચર્ચા કરવા જેવી છે, પણ તે મોટાભાગના લોકો ખરેખર જે પ્રશ્ન પૂછે છે તેના કરતાં સાંકડા પ્રશ્નનો જવાબ આપે છે.
શબ્દાવલી ચોક્કસ રાખો અને દલીલ ટૂંકી થાય છે. સ્યૂ એ સ્તર પરની ભૂમિકાઓનો સમૂહ છે, સાઇફર એક ઘટક છે, અને વાટાઘાટ થયેલ પરિણામ એ જ એકમાત્ર વસ્તુ છે જે તમારી પાસે ખરેખર હોય તેવા કનેક્શનનું વર્ણન કરે છે. સરખામણીમાં બાકીનું બધું શણગાર છે.